The `MethodItem` type represents both a normal method as well as being
the super type of `ConstructorItem`. That organization causes a number
of issues in Metalava and has lead to quite a few issues where code
that only expected to be run on methods and not constructors was run on
both. So, a new type `CallableItem` has been added that will eventually
become the super type of both `MethodItem` and `ConstructorItem` and
`ConstructorItem` will no longer extend `MethodItem`.
This change prepares this code for that change by overriding
`visitCallable(CallableItem)` instead of `visitMethod(MethodItem)`
because the latter is only called for methods not constructors.
Bug: 352481366
Test: atest check-flagged-apis-test
Change-Id: I3039bc0154b00ca57cb48c7447c5901b991b57e5
Add a new subcommand to list all flagged APIs and corresponding flags.
This provides an overview of what flagged APIs exist in the Android
tree.
Bug: 345207706
Test: build/tools/check-flagged-apis/check-flagged-apis.sh list
Test: atest check-flagged-apis-test
Flag: EXEMPT host side tool
Change-Id: Icc224f3787480353baabbd3946f36f003f35db59
Extract the command line argument names (and help texts) into constants.
This will allow future subcommands to re-use the same names and keep
things consistent.
Bug: 345207706
Test: atest check-flagged-apis-test
Flag: EXEMPT host side tool
Change-Id: I430f36c99f28aab8511a357f572086ee238d653b
The tool currently only supports a single subcommand, the "check"
command. Follow-up CLs will add new subcommands.
Bug: 345207706
Test: build/tools/check-flagged-apis/check-flagged-apis.sh
Flag: EXEMPT host side tool
Change-Id: I1aaaf313db8a10a7427aab378aac8d946d5a8a3d
When parsing API signature files, check-flagged-apis relies on
ClassItem.superClass to get the parent class of a class or interface.
That method always returns null for interfaces.
When generating api-versions.xml, metalava marks interface classes as
inheriting from java/lang/Object:
<class name="android/os/Parcelable" since="1">
<extends name="java/lang/Object"/>
[...]
</class>
This confuses check-flagged-apis when comparing data parsed from both
sources, as the symbol signatures will be identical, but the superclass
entries differ. Work around this by explicitly marking all interfaces
as inheriting from java/lang/Object when parsing API signature files.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: Icbb8f7d4c3d4232a083289a778b347e33a0856ab
Consider
@FlaggedApi(FLAG_OUTER) Clazz {
@FlaggedApi(FLAG_INNER) method();
}
If FLAG_OUTER is disabled, any class members are ignored. Teach
check-flagged-apis to recognize this and stop reporting false positives.
Bug: 339183637
Test: atest --host check-flagged-apis-test
Change-Id: Ie6799e952dc33874c1239231f841d7dfd947c7ce
If a symbol can't be found in a class, (recursively) check the class'
superclass before reporting the symbol as missing.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: I8ef1fbfcc51e0c5ba00959536c087213d688fe39
Extend ClassSymbol with a nullable reference to the class' superclass.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: Ia2741a4d7fb5de908a03ef640f5fcd38d0ce0e28
When searching for potential errors, if a symbol can't be found in the
api-verions.xml data, check if it is present in any of the class'
interfaces.
A follow-up CL will add similar logic to handle super classes.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: Ia6dfcfa8495b89465db60f6a4eb77d304112046b
The return value of ClassItem.allInterfaces will sometimes include the
interface itself (e.g.
android.accessibilityservice.BrailleDisplayController). It is unclear
when this happens; it doesn't happen for the unit test.
Update the logic to record the interfaces for a class to filter out
interfaces named the same as the class.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Test: croot && ./build/tools/check-flagged-apis/check-flagged-apis.sh
Change-Id: I8d93c230dfedde30e8d43fefd560a47944085d3a
Extend ClassSymbol with a list of the interfaces that class implements.
This will be used in a follow-up CL to improve the logic that checks if
a class member exists in the api-versions.xml data.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: I4db7ff47c3ce40ca892cb872810dd559426dfcb8
Change Symbol from a wrapper around a String to a more fleshed out data
class; symbols now encode if they represent a class, or a class member
(including a reference to the containing class).
Bug: 334870672
Test: atest --host check-flagged-apis-test
Test: croot && ./build/tools/check-flagged-apis/check-flagged-apis.sh # with and without this CL; the output should be the same
Change-Id: I003535c721c45d559d00fb3e008325e1db0e18c0
The constructor of a nested class is represented as follows in
api-versions.xml:
<class name="android/Clazz$Foo$Bar" since="1">
<method name="<init>()V"/>
</class>
The nested dollar signs are not replaced by forward slashes before the
parsing logic uses `split("/")` to find the name of the inner-most
class, incorrectly resulting in `Class$Foo$Bar` instead of `Bar`. Fix
this by immediately replacing dollar signs with forward slashes after
extracting the package and class.
Also clean up the following call of `Symbol.create`.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: I8c0619faae90ded7eb14dcc20ecb94a086a1c764
Previously, the check-flagged-apis.sh script used `api-versions.xml`
for `module-lib` and `system-server` which did not include the
latest up-to-date information about updatable modules or historical
information about sdk extensions which lead to false positives for
APIs from those updatable modules. This changes switches to use the
`api-versions.xml` produced by the new `api_versions_*_complete`
modules which does include that information.
Bug: 337836752
Test: Run script before and after applying this change to make sure
that flagged APIs from updatable modules are no longer
reported as missing.
Change-Id: If09e89a4595a19d9f00390fb5fbd24330ec11be5
Instead of building the entire SDK, explicitly build the
api-versions.xml files.
Bug: 334870672
Test: croot && build/tools/check-flagged-apis/check-flagged-apis.sh
Change-Id: Ib165c0acd4766ad3000aaf17220050d5e66ddf2c
The path to the generated API signature files used with --api-signature
in the check-flagged-apis.sh script are different based on the lunch
target used: sometimes it's under $ANDROID_PRODUCT_OUT, other times
under out/target/product/mainline_x86.
Teach check-flagged-apis.sh to dynamically find the correct path by
querying ninja.
Bug: 334870672
Test: croot && build/tools/check-flagged-apis/check-flagged-apis.sh
Change-Id: I1b0b41ef3ad1bc7113a3b31323d81251e7e65933
Switch the internal format to represent Symbols to (something close to)
the format described in section 4.3.2 of the JVM spec, i.e.
com/android/SomeClass/someMethod(II[Ljava/lang/String;)Z
This will make parsing method parameters from api-versions.xml easier,
as that file already uses this format, and converting API signature
files to the same format is less painful than going in the other
direction.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: I1e1fb8fe208cd51cce2cc129f5aa1cb495672c16
Allow forward slash characters (/) in Symbol names: when adding support
for method arguments, this will be needed.
The current implementation does not change; forward slash conversions to
dots still happen, but now explicitly at the call site of Symbol.create.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: Ia860d7b0c8703fcc56fec6ea722cf995ccf20cd0
Teach check-flagged-apis to parse methods. The implementation is only
half done: method signatures that accept parameters are ignored. A
follow-up CL will add support for these.
check-flagged-apis treats constructors and regular methods the same.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: Ie98db767289ac2a35aa85371f60ecb3970170d86
Occasionally sourcing the script would close my overall shell when it
hit an error. By having it just be an executable script, this prevents
it from impacting a user's normal shell environment and can depend on it
always being bash, rather than whatever shell people happen to be using.
Bug: 334870672
Test: tools/check-flagged-apis/check-flagged-apis.sh
Change-Id: Ic46cb4fefdea8d51be018d4f7a92b0d9ca7e57b3
Add a script to make it easier to check-flagged-apis for the public APIs
and the three flavours of @FlaggedApi.
Bug: 334870672
Test: lunch sdk-next-eng && source check-flagged-apis.sh
Change-Id: I8b5e2642ade84560c5c61ae49d8c0dcdedb841ca
Replace the current unit test runner DeviceJUnit4ClassRunner with JUnit4
and replace the (larger) dependency tradefed with the (smaller)
dependency junit.
This has no impact other than minimizing the unit test static_libs.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Change-Id: I0520ab0feeea5ea2ed15905136ba2647f86162cb
Teach check-flagged-apis to cross-check the data from its three input
sources. This allows the tool to detect
- @FlaggedApi references to non-existent flags
- @FlaggedApi APIs present in the build artifacts even though the flag
is disabled
- @FlaggedApi APIs not present in the build artifacts even though the
flag is enabled
By passing in different sources, the tool can detect these errors for
any of the API surfaces (public, @SystemApi(MODULE_LIBRARIES), etc).
Note: the tool assumes that a disabled flag means that the @FlaggedApi
should not be present in the build output. This is currently true, but
won't be once metalava starts reverting @FlaggedApis to their previous
SDK snapshot.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Test: check-flagged-apis --api-signature out/target/product/mainline_x86/obj/ETC/frameworks-base-api-current.txt_intermediates/frameworks-base-api-current.txt --flag-values out/soong/.intermediates/all_aconfig_declarations.pb --api-versions out/dist/data/api-versions.xml
Change-Id: I790234865f831af7d45895def14d1d6740365622
Teach check-flagged-apis to parse API versions XML; this represents the
APIs after metalava has processed the source and kept APIs as is, or
reverted them to the previous SDK snapshot, according to their
@FlaggedApi flags.
As with the API signature parser, limit support to fields to keep things
simple; support for classes and methods will be added in later CLs.
Note: `m sdk dist` will generate an API versions XML file.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Test: check-flagged-apis --api-signature out/target/product/mainline_x86/obj/ETC/frameworks-base-api-current.txt_intermediates/frameworks-base-api-current.txt --flag-values out/soong/.intermediates/all_aconfig_declarations.pb --api-versions out/dist/data/api-versions.xml
Change-Id: I779a0d0cdb8a50536d3fc8d517fa38ba4b0dcd1c
Teach check-flagged-apis to parse the parsed_flags protobuf generated by
aconfig.
Note: `m all_aconfig_declarations` generates a protobuf file that
contains all info about all flags.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Test: check-flagged-apis --api-signature out/target/product/mainline_x86/obj/ETC/frameworks-base-api-current.txt_intermediates/frameworks-base-api-current.txt --flag-values out/soong/.intermediates/all_aconfig_declarations.pb
Change-Id: I397b32ae2a373b429ef6ce22e0a06a0f15202b91
Teach check-flagged-apis to extract flagged APIs from API signature files.
To keep things simple, only consider fields for now: support for classes
and methods will be added in a later CL.
Note: `m frameworks-base-api-current.txt` will generate an API signature
file that includes both the platform and mainline APIs.
Bug: 334870672
Test: atest --host check-flagged-apis-test
Test: check-flagged-apis --api-signature out/target/product/mainline_x86/obj/ETC/frameworks-base-api-current.txt_intermediates/frameworks-base-api-current.txt
Change-Id: Ic244b896672569f44af793796189b34c1f9d0c36
Add a value class to represent Flag names. We could use plain Strings
but having a dedicated class (with no overhead compared to String) makes
the intent of the code much clearer.
Bug: 334870672
Test: m check-flagged-apis && check-flagged-apis
Change-Id: Icdd4fb97d3fd49e507b7559504ea173a3dc52dea
check-flagged-apis will read contents from various sources, which use
different formats to represent the same piece information (e.g.
"class#field" or "<class><field>").
Introduce a Symbol value class to represent any API (i.e. a class, field
or method) in a unified format.
Bug: 334870672
Test: m check-flagged-apis && check-flagged-apis
Change-Id: Id9404294a87b23a9d43e5e13ce39ea5a92608e33
Use clikt as the command line options parser library.
Bug: 334870672
Test: m check-flagged-apis && check-flagged-apis
Change-Id: I7c406456b00e29293294dcdbef411d2543a1e8d5
Add a new CLI to verify that the build artifacts contain the right set
of @FlaggedApi APIs, based on the value of the corresponding aconfig
flag.
This CLI will act as an end-to-end test of Soong and metalava.
This CL only adds the project scaffolding; later CLs will add the
implementation.
Bug: 334870672
Test: m check-flagged-apis && check-flagged-apis
Change-Id: Ib00653f2a549217da2b0058867c711f35efd5760
