@SystemApi and @TestApi entries in the whitelist can now be
differentiated from the rest of the apis. @TestApi methods
are implicitly greylisted.
Test: m test-art-host-gtest-hiddenapi_test
Change-Id: Id739f04550842f7b3160685e1635ba20efb223cc
@IntDefs and @LongDefs cannot be stored in a .class file, because the constant
names are lost. Instead, they are packaged out-of-band.
Therefore, they should never be in the API.
Test: python tools/apilint/apilint.py api/current.txt
Change-Id: If22e0cf7db0bb90dae6174bf546f2ec8be4e5458
Registers verifiers via a decorator to avoid error-prone registration
elsewhere.
Test: Run apilint before and after the change, verify identical output
Change-Id: I77ae47a2f3f1a486bb78d3167f8439ade6fc28ab
The UnsupportedAppUsage annotations could not be added directly to the
java files in src/ as they have to be built against the current api
which does not include the annotation. Instead this uses the same
technique as used for libcore/ojluni files and adds the annotations to
stub files (in hiddenapi/src) which are built as part of the
android.test.base-hiddenapi target. That target is added to a special
whitelist in build/soong/java/config/config.go which causes the
hiddenapi information to be extracted from the target.
Also, updates the preupload check to prevent anymore entries being
added to the config/hiddenapi-greylist.txt for android.test or junit
classes.
Bug: 73711752
Test: m cts-hiddenapi_flags-csv and check that it contained the
correct entries even though they had been removed from
config/hiddenapi-greylist.txt
Change-Id: Ifaf15d2751f54cb03f8402b866a0ee4da7acc4d2
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