Lines Matching refs:signature

3 This document describes the signature file format created and used by metalava,
8 1. The format emitted by doclava, and used for Android's signature files up
10    over time, so older signature files vary a bit (many of these changes were
30 Why did we change from the historical doclava signature format (v1)
37 That means the annotations should be part of the signature files too -- such
43 And if we were going to change the signature format, we might as well make some
50 reminders and other issues with the signature source (though the update-api task
55 New signature files (v2+) generally include a file header comment which states
57 signature files. For example, in v3 the type "String" means "@NonNull String",
71 The new signature format now includes annotations; not all annotations (such as
141 The above signature line is turned into
152 structure in the signature file. For example, in v1, an interface is called an
157 With these changes, these lines from v1 signature files:
180 The v1 signature files uses raw types in some places but not others.  Note that
204 v1 used this signature:
251 This doesn't currently apply to the SDK, but the signature files are also used
268 syntax. Therefore, we need to also capture properties in the signature files. If
276 it will get recorded in the signature files like this:
292 contract, so we need to include them in the signature format.
309 Therefore, the following Java code (not signature code) will also produce
310 exactly the same signature as the above:
322 also be part of the v2 signature since (as an example) removing a default value
347 Doclava did not include these methods in the signature files, but they **were**
348 present in the stub files (and therefore part of the API). In the v2 signature
351 An example of this is StringBuilder#setLength. According to the old signature
359 Doclava always inserted two special methods in the signature files for every
373 generated by the compiler. There's no reason to list these in the signature
389 The old signature file format used "deprecated" as if it was a modifier. In the
396 In the new signature format, we're using the standard modifier order for Java
417 In "extends" lists, the signature file can list a comma separated list of
442 signature file? The one that appeared in the source (which is hidden, or in the
447 signature file, for annotations that are in the well known packages. In other
465 importing them. In v2 offer the same thing in signature files. There are several
466 classes from java.lang that are used in lots of places in the signature file
473 signature files, and implicitly adding it back when reading in signature files.
486 overriding method is left out of the signature file. This basically compares the
490 implementation will be included in the signature file.
494 method is not included in the signature file. The same is the case for
513 For example, to update all the signature files to v3, run this command: