Lines Matching refs:that

9    through Android P. Note that this isn't actually a single format; it evolved
38 that we can not just record explicitly what the API contract is, but also
39 enforce that changes are not only deliberate changes but also compatible
86 (Notice how the annotations are not using fully qualified name; that's discussed
89 The annotations to be included are annotations for annotation types that are not
100 explicit nullness, use Kotlin's syntax for nullness. That means that for
155 referred to as classes that extend java.lang.Enum, or java.lang.Annotation etc.
180 The v1 signature files uses raw types in some places but not others.  Note that
211 Note how that's "throws Throwable" instead of "throws X". This results in b/110302703.
265 Kotlin's Java support means that it wil take a Kotlin property and compile it
303 Note that this isn't just for Kotlin. Just like there are special nullness
334 record the default value for usage from languages that support default parameter
344 Consider a scenario where a public class extends a hidden class, and that hidden
352 files, that method does not exist, but clearly it's there in the SDK. The reason
353 this happens is that StringBuilder is a public class which extends hidden class
372 It didn't do that in stubs, because you can't: those are special methods
436 referencing annotation classes that are generally **not** part of the API. When
438 androidx.annotation, such that Studio, lint, the Kotlin compiler and others can
442 signature file? The one that appeared in the source (which is hidden, or in the
443 case of Kotlin code, a special JetBrains nullness annotation), or the one that
447 signature file, for annotations that are in the well known packages. In other
466 classes from java.lang that are used in lots of places in the signature file
487 modifiers, ignoring some that are not API significant (such as "native"). Note
488 also that some modifiers are implicit; for example, if a method is implementing