summaryrefslogtreecommitdiff
path: root/stub-annotations/src/main/java/androidx/annotation
AgeCommit message (Collapse)Author
2018-07-09111216907: Private stub annotation classes breaks compilationTor Norbye
This CL updates metalava such that it *only* packages the @RecentlyNullable and @RecentlyNonNull annotations as package private stub annotations; the rest of the annotations are packaged as external annotations (which was the case prior to P anyway). It also turns off type-use annotations, since they are not properly supported anyway; their restoral is tracked in issue 111253910. Fixes: 111216907 Test: Unit tests updated Change-Id: I1d454024aeaee60daa8c717d40e352300ff768cc
2018-06-07Fix stub compilation for -showAnnotations (e.g. system api etc)Tor Norbye
Test: Manual compilation Bug: N/A Change-Id: I79dff3a876a1074fa9291a37fcb991669460ee49
2018-06-05Metalava fixes for compatibility with doclavaTor Norbye
This CL updates metalava in a few ways to make its output closer to doclava: * In compat mode, it inserts two spaces instead of one before elements without any visibility modifiers (e.g. package private.) This shows up in private API files. Also fixed it to properly treat Kotlin "internal" modifiers. * Explicitly include private constructors in enum classes * When emitting dex files, don't include inherited methods. Change-Id: Ice04229fbadffd82bc681e9d5fe5486f33e54c73
2018-05-21Improvements to annotation extraction, doconly and nullness migrationTor Norbye
This CL fixes a number of issses in metalava: (1) Support separate stub file generation for android.jar and for documentation stubs. The "--stubs" flag continues to create stubs intended for compilation into android.jar, and the new "--doc-stubs" flag generates stubs intended for documentation migration. Why are these separate, you ask? It turns out the stubs we compile for android.jar needs to be slightly different from those we generate documentation for. Here are some specific examples: (a) In the SDK stubs we'll use different nullness annotations for recently annotated elements than for elements that have been annotated for a while. This allows the Kotlin compiler to treat violations of these contracts as a warning instead of an error. In the documentation, however, we just want the normal @NonNull/@Nullable annotations to show up, not the specialized migration versions of these. (b) @doconly: Some elements, such as R.styleable, are marked with @doconly and should be present when running for example javadoc on the code, but should not be present in the actual SDK. (2) This CL updates the set of stub annotations that the stubs can be compiled with. These are in many cases nearly identical to the androidx.annotations in the support library, but with some notable changes, such as allowing type parameter and type use for the nullness annotations, switching to class retention for a few annotations, and removing some that don't apply. (3) This CL updates the nullness migration to the new scheme supported by Kotlin 1.2.50, and removes earlier handling for multiple stages of migration (@Newly<X> vs @Recently<X>). It also changes the annotation package handling from prefering android.support.annotation to androidx.annotation. There area also various fixes to the nullness coverage code which lets the reports be written to files, which more correctly accounts for static final primitive constants, etc. Finally, misc bug fixes I encountered. At this point, metalava can spit out stubs containing annotations that compile -- and which contain the right migration names for Kotlin. Bug: N/A Test: Unit tests included and updated Change-Id: I4915e199e2e14473df62206015461108bc58b962