Lines Matching refs:in
11 (which in turn get compiled into android.jar, the Android SDK library) and
17 the typedef annotations, which cannot be stored in the SDK as .class level
32 This builds a binary distribution in `../../out/host/common/install/metalava/bin/metalava`.
74 * Compatibility with doclava1: in compat mode, metalava spits out the same
77 * Ability to read in an existing android.jar file instead of from source, which
79 new formats (e.g. to fix past errors in doclava, such as annotation instance
82 * Ability to merge in data (annotations etc) from external sources, such as
87 * Support for an updated signature file format (which is described in FORMAT.md)
89 * Address errors in the doclava1 format which for example was missing
95 modifiers in the canonical modifier order, using "extends" instead of
97 tweaks outlined in the `Compatibility` class. (Metalava also allows (and
98 ignores) block comments in the signature files.)
102 API contract (in particular nullness contracts, as well as parameter names
122 * Other compactness improvements: Skip packages in some cases both for export
133 annotations are not included in signature files) use just the simple name
142 …roid/content/res/AssetManager.java:166: error: Replaced Kitkat with KitKat in documentation for Me…
143 …print/PrinterCapabilitiesInfo.java:122: error: Replaced Kitkat with KitKat in documentation for Me…
145 * Built-in support for injecting new annotations for use by the Kotlin compiler,
146 not just nullness annotations found in the source code and annotations merged
147 in from external sources, but also inferring whether nullness annotations have
149 compiler treat errors in the user code as warnings instead of errors.)
154 need to be able to figure out which parts of the source code is included in
158 * Support for parsing Kotlin files. API files can now be implemented in Kotlin
172 same signatures as in the signature files.
177 extraction code in doclava1 missed, but accidentally included in the SDK
179 the exact same API as is listed in the signature files, and once this was
184 checks on the public API in the codebase and flag issues that are discouraged
193 finds a problem, it will only be reported if it is not already in the
197 Lint, being able to check in the set of accepted or verified false positives
213 in a targeted way. For example, running the analysis on the current version of
278 for. However, in metalava, annotation references are available at the AST
283 annotation files needed by Studio and lint in Gradle, which captures the
284 typedefs (@IntDef and @StringDef classes) in the source code. Prior to this
286 merges in manually curated data; some of this is in the manual/ folder in this
293 API usage. (Prior to this, this was based on signature file parsing in
313 (1) It allows us to have multiple "back-ends": for example, metalava can read in
316 files. Reading in multiple versions of an API lets doclava perform
317 "diffing", such as warning if an API is changing in an incompatible way. It
318 can also generate signature files in the new format (including data that was
319 missing in older signature files, such as annotation methods) without having
322 (2) There's a lot of logic for deciding whether code found in the source tree
323 should be included in the API. With the model approach we can build up an
368 the API items in the codebase, and then in each relevant method they emit the
393 types in the codebase.
395 When computing the API, all types that are included in the API should be
444 in which case the deletion is allowed.))