Lines Matching refs:to

11   and more importantly to hide code intended to be implementation only, driven
39     metalava extracts metadata from source code to generate artifacts such as the
74 * Ability to read in an existing android.jar file instead of from source, which means
75   we can regenerate signature files etc for older versions according to new formats
76   (e.g. to fix past errors in doclava, such as annotation instance methods which were
79 * Ability to merge in data (annotations etc) from external sources, such as
103     the goal is to have **all** API elements explicitly state their nullness
135   * Misc documentation handling; for example, it attempts to fix sentences
152   code). This means that the documentation tool itself does not need to be able to
163   nullness, such as attempting to change a nullness contract incompatibly
164   (e.g. you can change a parameter from non null to nullable for final classes,
166   require you to create two signature files to diff.
173   (This turned out to be incredibly important; this revealed for example that
179   hooked up to the build it immediately became apparent that it was missing
183   target efforts since we plan to annotate the entire API). First, it can
191   More importantly, you can also point it to some existing compiled applications
196   version of framework, and pointing it to the
251   From this it's clear that it would be useful to start annotating android.os.Parcel
257   the code which generated documentation for typedef constants had to require the
258   constants to all share a single prefix it could look for. However, in metalava,
260   and map them back to the original field references and include those directly.
264   @StringDef classes) in the source code. Prior to this this was generated manually
271   will use this information when recording API levels for API usage. (Prior to this,
273   incorrect results. Metalava uses the android.jar files themselves to ensure that
285 (1) It allows us to have multiple "back-ends": for example, metalava can read
291     in older signature files, such as annotation methods) without having to
292     parse older source code which may no longer be easy to parse.
299     and having to keep the filtered data separately and remembering to always
305 implementation hierarchies: One is PSI based, where you point metalava to a
313 There are methods to load codebases - from source folders, from a .jar file,
332 `visitItem`, or to specifically visit methods, fields and so on
336 but which limits itself to visiting code elements that are part of the
365 There is a `TypeVisitor` similar to `ItemVisitor` which you can use
366 to visit all types in the codebase.
370 This is easy to do with the `TypeVisitor`.
400 This makes it easy to perform API comparison operations.
402 For example, metalava has a feature to mark "newly annotated" nullness annotations
414 to flag all API elements that have been removed as invalid (since you cannot
416 hierarchy to see if there still is an inherited method with the same signature,
422 files, which can then be processed by Dokka and Javadoc to generate the
427 annotations) was to insert auxiliary tags (`@range`, `@permission`, etc) and
432 does not use javadoc data structures to pass maps like the arguments for
434 code which generates the documentation is easier to reason about and to