The property is currently set by the AIDL compiler to indicate the original
position of the annotation in the AIDL file. Use this position in
preference to the annotation position within Java code if it's present.
Also rework the tests to use the google compile-testing library rather than
my crufty javac library. This makes testing failure conditions much nicer.
Bug: 145120552
Test: atest unsupportedappusage-processor-test
Test: m framework-annotation-proc
Change-Id: Icaac9b40672dce028095b578c19950b688506c0d
It seems the compiler has started adding a top level MODULE which broke
assumptions made in here.
Also add some tests to verify this and other basic functionality, so that
future such breaks may be caught sooner.
Test: m framework-annotation-proc-index
Test: atest unsupportedappusage-processor-test
Bug: 144495446
Change-Id: I43efb25c1600af15809d48aa84498a6800f713b1
Add support for the libcore UnsupportedAppUsage annotation to
UnsupportedAppUsageProcessor. This is in order to make the two
annotations even more interchangeable.
Also take the opportunity to correct the documentation:
UnsupportedAppUsageProcessor no longer is involved in creating
greylist.txt, that functionality has been moved to
Class2Greylist.java in the art repository.
Bug: 130721457
Test: m framework-annotation-proc
Change-Id: I5cf1f97ca41349fc053315a2fd5bfd53a80ae128
+ Remove IntEnumMapping class, (use a bound lambda of
SparseArray#get(int) instead).
+ Remove IntFlagMapping.Builder, and make IntFlagMapping mutable. The
immuability guarantees are provided by using a lambda of
IntFlagMapping#get(int).
+ Change PropertyMapper#mapIntEnum(String, int, IntFunction<String>)
and #mapIntFlag(String, int, IntFunction<Set<String>>) to take
IntFunctions instead of semantic types.
+ Changes to the annotation processor to support code generation for the
lambdas and additional internal cleanups.
Bug: 124448834
Test: atest --host view-inspector-annotation-processor-test
Change-Id: I3e7ccac63d50caa6ff49be1e78732831886e7f6e
+ Generate inspection companions as MyClass$InspectionCompanion instead
of MyClass$$InspectionCompanion. This allows the discovery of custom
inspection companions written as nested classes.
+ Rename GeneratedInspectionCompanionProvider to
StaticInspectionCompanionProvider to more clearly articulate how it
function in the new world.
+ StaticInspectionCompanionProvider now explicitly checks if a class it
discovered implements InspectionCompanion, and returns null instead of
throwing a ClassCastException.
+ The annotation processor checks for the existence of a nested class
named InspectionCompanion, and fails the build if a class has both a
custom InspectionCompanion and @InspectableProperty annotations.
Test: atest --host view-inspector-annotation-processor-test
Bug: 126913705
Change-Id: Ic0d2100ec22420e36f9db44e56c66fe9146eeb0c
This allows for inspectors to do special handling on values known to be
resource IDs, such as converting them to a string format.
+ Add PropertyMapper#mapResourceId(String, int) and
PropertyReader#readResourceId(int, int)
+ Add RESOURCE_ID to @InspectableProperty.ValueType
+ Add code generation support in the annotation processor, and value
type inference for accessors annotated with a resource ID annotation
like @AnyRes.
Bug: 127348933
Test: atest --host view-inspector-annotation-processor-test
Change-Id: I132aea319dcddf51c553057c036ce5609e3c381a
+ Add a field target to @InspectableProperty
+ Refactor PlatformInspectableProcessor to process annotated fields and
generate InspectionCompanions that read fields.
+ Require that all inspectable getters and fields be public.
+ Make some hidden getters added to View for inspection public.
Test: atest --host view-inspector-annotation-processor-tests
Bug: 126913705
Change-Id: I0c012f42794885f17a397a2e3dd541b3aa4c2634
The annotation_processors property is deprecated, replace it with
plugins, and use java_plugin for modules that provide annotation
processors.
Bug: 77284273
Test: m checkbuild
Change-Id: I467b899e0c8f2c8fa74a9bfbe6e952ad0f7aa009
The annotation_processors property is deprecated, replace it with
plugins, and use java_plugin for modules that provide annotation
processors.
Bug: 77284273
Test: m checkbuild
Change-Id: I14ed4d81e097510866cbb9a27c72be4426117885
When editing annotations, we want the ability *not* to overwrite any
existing annotation properties already in place. Include any properties
set on the annotation in the output, so that the edit_annotations script
can know that they're there.
The annotation properties are encoded like URL query parameters for
convenience; it makes them easy to encode here & subsequently decode on
the other side (in Python).
Test: m framework-annotation-proc & inspect output.
(cherry picked from commit bd7077065c211f49b090aa4250b53b58461adfd9)
Merged-In: I71fb1215ad2790751be336b4955c163bb323a4a6
Change-Id: I0b33e2b379076346ce258d93a9225a9143b7d91a
This does not include the annotation processing needed to build the
property model the generator consumes or support for IntEnumMapping or
IntFlagMapping. Support will be added in subsequent CLs.
Bug: 117616612
Test: atest --host view-inspector-annotation-processor-test
Change-Id: I1d7829a12c7243645a96a32c8fc22b13c70c64e1
When editing annotations, we want the ability *not* to overwrite any
existing annotation properties already in place. Include any properties
set on the annotation in the output, so that the edit_annotations script
can know that they're there.
The annotation properties are encoded like URL query parameters for
convenience; it makes them easy to encode here & subsequently decode on
the other side (in Python).
Test: m framework-annotation-proc & inpsect output.
Change-Id: I71fb1215ad2790751be336b4955c163bb323a4a6
CL [1] added a new compilation target that uses internal API
that is now in the jdk.compiler module and is not exported
(it is subject to removal without notice in future versions of
OpenJDK). The fact that these packages are not exported suggests
that a replacement API is already available, but I don't know the
details.
For now, this CL uses javac command-line flags to export these
packages, which fixes compilation. Since the commit message from
CL [1] implies that the entire tool can be removed once bug 77284273
is fixed, a longer-term solution should not be required.
[1] https://android-review.googlesource.com/c/platform/frameworks/base/+/745655
commit bad89e5e5b171a71e42d7c738ec97a39747e4318
Test: The following breaks before but not after this CL:
EXPERIMENTAL_USE_OPENJDK9=true make unsupportedappusage-annotation-processor
Bug: 113853502
Change-Id: I24b77af9262891428a01e2eccc18fa3a5c3b3bc9
The processor outputs unsupportedappusage_index.csv, containing source
position info for every@UnsupportedAppUsage annotation processed. It is a
mapping of dex signature to the source postion of the annotation on that
signature. It is used as input for scripts which update the annotations.
We include a META-INF file which causes the compiler to automatically
pick up the annotation processor. Otherwise we would need to explicitly
specify the processor with a -processor flag to javac.
We create a new build target for just the @UnsupportedAppUsage annotation
and the @IntDef annotation (which it depends on) so that the processor can
also depend on that directly.
The processor only runs on a new build target framework-annotation-proc
so that it is not invoked as part of a regular build. This is done so
that we don't slow down peoples builds: Soong does not support annotation
processors when javac sharding is in use. This workaround can be removed
once b/77284273 is fixed.
Test: m framework-annotation-proc
Bug: 113853502
Change-Id: Ie9cd5a90ddf7a51f6035e849703fc39ad9127557
