Lines Matching refs:in

13    such as dropping the "final" modifier in front of every member if the
16 2. The "new" format, which is described below, and is used in Android Q. This
24    in format v2, but it was deferred since type-use annotations introduces
25    somple complexities in the implementation.
57 signature files. For example, in v3 the type "String" means "@NonNull String",
58 but in v2 "String" means "String with unknown nullness".
97 (Note: Only in version format 3+)
152 structure in the signature file. For example, in v1, an interface is called an
180 The v1 signature files uses raw types in some places but not others.  Note that
181 in the above it was missing from super interface Collection:
189  whereas in the v2 format it's included:
197 Similarly, v1 used erasure in throws clauses. For example, for this method:
211 Note how that's "throws Throwable" instead of "throws X". This results in b/110302703.
230 since those are API-significant. Here's how this looks in the v2 file format
252 in the support library, and some of these are written in Kotlin and exposes
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.
300 In v1 files we only list type names, but in v2 we allow an optional parameter
301 name to be specified; "commit" in the above.
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
352 files, that method does not exist, but clearly it's there in the SDK. The reason
359 Doclava always inserted two special methods in the signature files for every
372 It didn't do that in stubs, because you can't: those are special methods
373 generated by the compiler. There's no reason to list these in the signature
397 and Kotlin, wihch more closely mirrors what is done in the source code.
418 classes. The classes are listed by fully qualified name, but in v1 it was sorted
430 the nullness as deprecation ones (which are specially supported in v3 via the
435 In the codebase, these are typically in the android.annotation. package,
441 That begs the question: which fully qualified name should we put in the
442 signature file? The one that appeared in the source (which is hidden, or in the
446 In v2 we do neither: We use only the simple name of the annotations in the
447 signature file, for annotations that are in the well known packages. In other
456 in v2 we have simply 
462 ### Simple Names in Java.lang
464 In Java files, you can implicitly reference classes in java.lang without
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
467 (java.lang.String alone is present in over 11,000 lines of the API file), and
473 signature files, and implicitly adding it back when reading in signature files.
490 implementation will be included in the signature file.
494 method is not included in the signature file. The same is the case for
499 Some other minor tweaks in v2:
504 *   Don't add spaces in type bounds lists (e.g. Map<X,Y>, not Map<X, Y>.)
511 The Android source tree also has checked in versions of the signatures for all