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 It puts build artifacts in `../../out/metalava/`.
78 * Ability to read in an existing android.jar file instead of from source, which
80 new formats (e.g. to fix past errors in doclava, such as annotation instance
83 * Ability to merge in data (annotations etc) from external sources, such as
88 * Support for an updated signature file format (which is described in [FORMAT.md](FORMAT.md))
90 * Address errors in the doclava1 format which for example was missing
96 modifiers in the canonical modifier order, using "extends" instead of
98 tweaks outlined in the `Compatibility` class. (Metalava also allows (and
99 ignores) block comments in the signature files.)
103 API contract (in particular nullness contracts, as well as parameter names
123 * Other compactness improvements: Skip packages in some cases both for export
134 annotations are not included in signature files) use just the simple name
143 …roid/content/res/AssetManager.java:166: error: Replaced Kitkat with KitKat in documentation for Me…
144 …print/PrinterCapabilitiesInfo.java:122: error: Replaced Kitkat with KitKat in documentation for Me…
146 * Built-in support for injecting new annotations for use by the Kotlin compiler,
147 not just nullness annotations found in the source code and annotations merged
148 in from external sources, but also inferring whether nullness annotations have
150 compiler treat errors in the user code as warnings instead of errors.)
155 need to be able to figure out which parts of the source code is included in
159 * Support for parsing Kotlin files. API files can now be implemented in Kotlin
173 same signatures as in the signature files.
178 extraction code in doclava1 missed, but accidentally included in the SDK
180 the exact same API as is listed in the signature files, and once this was
185 checks on the public API in the codebase and flag issues that are discouraged
194 finds a problem, it will only be reported if it is not already in the
198 Lint, being able to check in the set of accepted or verified false positives
214 in a targeted way. For example, running the analysis on the current version of
279 for. However, in metalava, annotation references are available at the AST
284 annotation files needed by Studio and lint in Gradle, which captures the
285 typedefs (@IntDef and @StringDef classes) in the source code. Prior to this
287 merges in manually curated data; some of this is in the manual/ folder in this
294 API usage. (Prior to this, this was based on signature file parsing in
314 (1) It allows us to have multiple "back-ends": for example, metalava can read in
317 files. Reading in multiple versions of an API lets doclava perform
318 "diffing", such as warning if an API is changing in an incompatible way. It
319 can also generate signature files in the new format (including data that was
320 missing in older signature files, such as annotation methods) without having
323 (2) There's a lot of logic for deciding whether code found in the source tree
324 should be included in the API. With the model approach we can build up an
369 the API items in the codebase, and then in each relevant method they emit the
394 types in the codebase.
396 When computing the API, all types that are included in the API should be
445 in which case the deletion is allowed.))