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
Also fix up some issues with expression parsing, type use annotations, etc.
Test: python tools/apilint/apilint_test.py
Change-Id: I38145a51470ce6c3e5813a546d681489fd87fc19
(cherry picked from commit 403c8e35d8)
Fixes false positives that occur when a class in current.txt is faulty, and an
entry for that class is then added to system-current.txt.
This was so because when parsing the previous revison's system-current.txt, we
did not know about the class and thus didn't look for it in current.txt, and
thus never recorded that the error is preexisting.
To avoid that, we track all classes in system-current.txt with a matching entry
in current.txt in the current revision, and later use that to look up all classes we
may have missed when examining the previous revision.
Test: python tools/apilint/apilint_test.py
Change-Id: Ibe09f1159e351e56b35b8816ce0db760de4ef791
(cherry picked from commit 61e3730bc0)
Fixes a bug where only the name instead of the fully qualified name was
considered when looking for a class, which lead to faulty results for inner
classes.
Test: python tools/apilint/apilint_test.py
Change-Id: Ib015669ed3faef21d2bdd16f1e27bc55c8669d70
(cherry picked from commit 2c5cacfd36)
Allows specifying a base current.txt and previous.txt file when linting
system-current.txt and test-current.txt to avoid false positive error
messages due to public API members not being duplicated in the respective
non-public APIs
Test: python tools/apilint/apilint.py --base-current=api/current.txt api/system-current.txt
Change-Id: I306a99b1423584ef3fcdc9272a83cb5eacc37227
(cherry picked from commit 7690d0d4ee)
It's a better alternative that should be used instead of adding
new "ForUser" or "AsUser" methods.
Bug: 115654727
Test: manual
Change-Id: I8742c2ef42d743ef69f8f7a91378f498fdc81e43
(cherry picked from commit 86445841ac)
We're starting to see "@interface" show up, so handle them like any
other interface. We're also seeing more details argument lists
with names and annotations; ignore them for now, since all our
existing lint checks work on the "real" data type.
Verified that it handles new support library current.txt files
without causing any regressions against existing framework
current.txt files.
Test: manual inspection
Bug: 111555356
Change-Id: Id11c3561edd317e4ba1a9b43993fd96d8243e00d
(cherry picked from commit bd26119169)
Libcore class members annotated with @CorePlatformApi now generate
a new hiddenapi flag. This is the first of "domain API" flags which
can be used in conjunction with API list flags. Therefore modify
the 'generate_hiddenapi_lists.py' logic to treat them differently.
Specifically, the script marks otherwise unassigned class members
blacklisted. A class member with 'core-platform-api' may still not
be assigned an API list and should be blacklisted.
Bug: 119068555
Test: m appcompat
Change-Id: I2b67e7a619677e853c87bc2da934410458ce4d14
Refactor of `hiddenapi` changed the output format of public/private API
lists to a single CSV file. Change API list generation accordingly.
In order to avoid special-casing this CSV file, it is treated the same
as the CSV files produced by `class2greylist`. The merging rules are
relaxed so that signatures in CSV files are not checked against
a pre-initialized set of all signatures (previously generated from the
public/private API files). This should not lead to build errors as the
CSV files are always auto-generated, and a missing/extra signature will
be caught by `hiddenapi`.
API lists in frameworks/base/config are processed later and checked
that they are a subset of the signatures in CSV.
Bug: 119068555
Test: compiles, hiddenapi-flags.csv unchanged
Change-Id: I33f2cbaa15f2d423a75e6ca64abe1c5b0c40c86f
To avoid conflict between statslog.write() function signatures for
Atom1 {
Foo foo = 1 [logMode=bytes];
}
and
Atom2 {
string bar = 1;
int64 arg2 = 2;
}
Bug: 122571213
Test: manually tested with new atoms.
Change-Id: Ied0f0bd81cef8d0964f571e921f47022301157d9
Merged-In: Ied0f0bd81cef8d0964f571e921f47022301157d9
(cherry picked from Ied0f0bd81cef8d0964f571e921f47022301157d9)
This CL updates the code generator which creates the
hidden StatsLogInternal class to explicitly hide
the generated constants and write methods as well.
The intent of this class was for everything to be hidden,
but it turns out that public methods and fields in
hidden classes which are extended by a public class also
ends up in the SDK, even though they don't appear in the
signature file. StringBuilder#setLength(int) is an
example of this.
Bug: 118395019
Test: make sdk
Change-Id: I97e510e8155ee50ade653f6abeb5479c7ca9029d
* Add explicit to conversion constructors/operators
* Use NOLINT or NOLINTNEXTLINE to suppress warnings on intended converters
Bug: 28341362
Test: make with WITH_TIDY=1 DEFAULT_GLOBAL_TIDY_CHECKS=-*,google-explicit-constructor
Change-Id: Ie02101ea7c422e8add535c111a30a2f21ead0ace
* libutils must be used as a static library when compiled on host
* Host does not have Android system properties and hence we cannot
use <cutils/properties.h>. In fact, properties.cpp is not even
compiled on host for libcutils. Therefore, this CL adds a check
for __ANDROID__ macro before including <sys/propoerties.h> and
before calling properties_get_bool()
* On host, statsd logging will be disabled since host does not
use statsd for anything
Fixes: 121294178
Test: test drive statsd
Change-Id: I838ff02468c650c5f7d85e68fa5008b98f08ce8c
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 bd7077065c)
Merged-In: I71fb1215ad2790751be336b4955c163bb323a4a6
Change-Id: I0b33e2b379076346ce258d93a9225a9143b7d91a
The proto binary data can contain '\0's and in the native layer,
the current liblog api would convert that into string and thus
the data is truncated.
This CL adds a "size_t bytes_field_len" after the bytes fields so that
we can correctly pass the data from JAVA to native.
Java StatsLog.write() APIs remain the same
Bug: 120635548
Test: test_drive with atom 103
Change-Id: I34f1c4ddd6a4ec5f3604b0c67a47a5399e3c6ddd
Merged-In: I34f1c4ddd6a4ec5f3604b0c67a47a5399e3c6ddd
(cherry picked from commit 1fe9f59498)
Test: unit test added
Bug: 120635548
Change-Id: I825b1ce526944a20fe65705508ad180ece37492c
Merged-In: I825b1ce526944a20fe65705508ad180ece37492c
(cherry picked from commit 8e6f998300)
There are an increasing number of requests to log data in complex format to statsd, while the data
is not expected to be parsed or aggregated by statsd and only to be uploaded as events.
Instead of making an exception for each of these cases in a hard coded way, this CL add a feature to
annotate these field in atoms.proto and the stats-log-api-gen tool will produce byte array
interfaces for them.
Note that log_msg does not have byte array type, and only has string type, when statsd receives the
log, these fields are in string type. Only when the atom is written to proto, we will check if this
field should be bytes field and write it to protobuf in message format.
Change-Id: If53dd95c5826710c76d7fe982bf951a435dfc738
Merged-In: If53dd95c5826710c76d7fe982bf951a435dfc738
Fix: 118386797
Bug: 120635548
Test: unit test & manual test
(cherry picked from commit bbdd67d19f)
Previous changes could not remove these entries as they are implicit
methods, i.e. are not present in the source, and so could not be
annotated. That is no longer true and so these entries can now be
removed.
This was tested by making and then manually checking that the generated
out/target/common/obj/PACKAGING/hiddenapi-light-greylist.txt was the
same (after sorting) before and after this change.
Bug: 117818301
Bug: 119861512
Test: as above
Change-Id: Ic33c693f50cac011332c5ba5a5c0e2b6562e6ef8
New category of hidden API has been created. Update the script
generate_hiddenapi_lists.py with the new flag name.
Test: m, phone boots
Change-Id: I79e5478678880939e20e500cb8dad9b2a56fc84f
Maintaining multiple text files has become too cumbersome as adding
each new category of API requires changes across many projects.
This patch changes generate_hiddenapi_lists.py to produce a single
CSV file in the format:
<api_signature>,<flag1>,...,<flagN>
It can accept legacy API list files as input (for existing
frameworks/base/config/hiddenapi-*.txt files) as well as per-package
CSVs produced by class2greylist.
Test: m, check lists have not changed
Test: phone boots
Test: tools/hiddenapi/generate_hiddenapi_lists_test.py
Change-Id: Iebcef426ec93ea1d72b662bbff91d4e068fa0a70
The libcore related projects (see below) have been (mostly) switched
over to use UnsupportedAppUsage annotations, This change will prevent
entries for those projects being added to a config/hiddenapi-* file.
* libcore
* external/bouncycastle
* external/conscrypt
* external/icu
* external/okhttp
* external/libphonenumber - still has a couple of entries in
config/hiddenapi-light-greylist.txt due to limitations in
UnsupportedAppUsage/class2greylist.
Tested by attempting to upload the file with entries for libcore
projects and without those entries and checking that the behavior
is expected.
Test: see above
Bug: 117818301
Change-Id: I67a30b307e12e842b28cfb2160fab0029868fa06
It will be a global error by default.
Test: make checkbuild
Bug: 112564944
Change-Id: I26616fd50ccf3639fa7c01d850a14d079273ede7
Exempt-From-Owner-Approval: do not block on new warnings