Lines Matching refs:to

5 semantically meaningful to [gen_stub_libs.py]. For an example of a map file, see
33 meaning. If you need to add any comments that should not be interpreted by the
52 symbol visibility of the library to expose only the interface named by the map
54 available to users via `dlsym`. Note: All comments are ignored in this case. Any
62 naming schemes is equivalent to marking the version with the `platform-only`
73 Indicates that the version or symbol is to be exposed in the APEX stubs rather
75 to both APEX and the LL-NDK.
80 level. This is an arbitrarily high API level used to define APIs that have not
81 yet been added to a specific release.
91 API level 21. This tag can be applied to either a version definition or an
92 individual symbol. If applied to a version, all symbols contained in the version
96 Note: The map file alone does not contain all the information needed to
104 allows the actual number of the API level to remain vague during development of
105 that release. For example, `introduced=S` can be used to define APIs added in S.
106 Any code name known to the build system can be used. For a list of versions
107 known to the build system, see `out/soong/api_levels.json` (if not present, run
108 `m out/soong/api_levels.json` to generate it).
129 Indicates that the version or symbol is to be exposed in the LL-NDK stubs rather
130 than the NDK. May be used in combination with `apex` if the symbol is exposed to
140 clear to the developer that they are up to no good.
142 The typical use for this tag is for exposing an API to the platform that is not
143 for use by the NDK, LL-NDK, or APEX (similar to Java's `@SystemAPI`). It is
144 preferable to keep such APIs in an entirely separate library to protect them
149 Used to define a public global variable. By default all symbols are exposed as
155 Behaves similarly to `introduced` but defines the first version that the stub
172 This tag is not commonly needed and is only used to hide symbol versioning