Lines Matching refs:be

33 meaning. If you need to add any comments that should not be interpreted by the
49 These map files can (and should) also be used as version scripts for building
53 file. Without this, APIs that you have not explicitly exposed will still be
55 symbol named in any `global:` group will be visible.
59 Version names that end with `_PRIVATE` or `_PLATFORM` will not be exposed in any
60 stubs, but will be exposed in the implementation library. Using either of these
67 interpreted by the stub generator. Multiple space-delimited tags may be used on
72 Indicates that the version or symbol is to be exposed in the APEX stubs rather
73 than the NDK. May be used in combination with `llndk` if the symbol is exposed
86 API level 21. This tag can be applied to either a version definition or an
96 Codenames can (and typically should) be used when defining new APIs. This allows
98 release. For example, `introduced=S` can be used to define APIs added in S. Any
99 code name known to the build system can be used. For a list of versions known to
112 symbol is defined with only architecture-specific tags, it will not be present
115 Note: The architecture-specific tags should, in general, not be used. These are
122 Indicates that the version or symbol is to be exposed in the LL-NDK stubs rather
123 than the NDK. May be used in combination with `apex` if the symbol is exposed to
129 should not be exposed in the stub library. Developers can still access them via
130 `dlsym`, but they will not be exposed in the stubs so it should at least be
142 tag may be used.
172 Indicates that the symbol should be [weak] in the stub library.