Android offers several efficient alternatives to some upstream
String operations, such as the newly added TextUtils.formatSimple().
This checker also detects and discourages transparent StringBuilder
operations related to Preconditions, where we always pay the cost of
building the failure message string, even in the successful case.
Bug: 170978902
Test: atest error_prone_android_framework_test
Change-Id: I8cef4c50d8b0da3f1e66727dfa724ad44b88963b
Android offers several efficient alternatives to some upstream
Collections containers, such as SparseIntArray instead of
Map<Integer, Integer>.
Bug: 155703208
Test: atest error_prone_android_framework_test
Change-Id: I080fd9489fb037391b717901345a905a9753b370
Binder maintains thread-local identity information about any remote
caller, which can be temporarily cleared while performing operations
that need to be handled as the current process. However, it's
important to restore the original remote calling identity after
carefully scoping this work inside a try/finally block, to avoid
obscure security vulnerabilities.
Bug: 155703208
Test: atest error_prone_android_framework_test
Change-Id: I568771a50af27637e4984950dcada2248ce16afe
Two specific managers have their own strategies using indirection to
obtain Context.getUserId(), and we're willing to special case these
to reduce warning noise.
Bug: 115654727, 159626156
Test: atest error_prone_android_framework_test
Change-Id: I290b74f7b6ec17c647f1cbb9ea7995f3fd56b132
Purposefully exclude telephony Binder interfaces, since we know they
always run under the separate AID_RADIO.
Bug: 155703208
Test: atest error_prone_android_framework_test
Change-Id: I3ce87caeb2abe3a7ca01ce10560d02b499ece07d
Because shifting newly written code over to using CompatChanges is
important, this change refines the recently added check and upgrades
it to become a fatal build error.
Bug: 169879376
Test: atest error_prone_android_framework_test
Change-Id: Ic3126518ebaac9995b8f649e44b839de30faa17f
Each SDK level often has dozens of different behavior changes, which
can be difficult for large app developers to adjust to during preview
or beta releases. For this reason, android.app.compat.CompatChanges
was introduced as a new best-practice for adding behavior changes.
During a preview or beta release, developers can temporarily opt-out
of each individual change to aid debugging. This opt-out is only
available during preview of beta releases, and cannot be adjusted on
finalized builds.
Bug: 169879376
Test: atest error_prone_android_framework_test
Change-Id: Ib3b2e2139e084b0fa1bcbb5e89dd55e7ca4bfa00
Parcelable data can be transported in many ways (some of which can be
very inefficient) so this checker guides developers towards using
high-performance best-practices.
Bug: 154436100, 155703208
Test: atest error_prone_android_framework_test
Change-Id: I253b5e1088c9bf9c3cf0d684cf73134f3bbf27ab
Several managers keep an "int mUserId" field which is assigned from
Context.getUserId(), so Binder calls referencing that field are okay.
Also shift to borrowing the "flavor" logic for detecting userId
parameters consistently.
Bug: 115654727, 159626156
Test: atest error_prone_android_framework_test
Change-Id: I9841fdf16f34c08b113e689e74b94f1ede839e2c
Many system internals pass around PID, UID and user ID arguments as a
single weakly-typed "int" value, which developers can accidentally
cross in method argument lists, resulting in obscure bugs.
Bug: 155703208
Test: atest error_prone_android_framework_test
Change-Id: I5e4d9b5a533071f94d82dff17faff5d52ae54564
To avoid an explosion of startActivityForUser style methods, we've
converged on recommending the use of Context.createContextAsUser(),
and then ensuring that all system services pass Context.getUserId()
for any int userId arguments across Binder interfaces.
This design allows developers to easily redirect all services
obtained from a specific Context to a different user with no
additional API surface.
Bug: 115654727, 159626156
Test: atest error_prone_android_framework_test
Change-Id: I2d665016e8356807c371a1e18a4e102dea5b5d8e
Often a permission check in the app's process is an indicative of a
security issue since the app could work around it. Permission checks
should be done on system_server.
This errorprone warning checks for invocations of
Context.checkPermission() in any class inside android.app package and
emits a warning if it finds one. I also added a @SuppressWarnings for
one such call that has a todo and it and seems like an already tracked
workaround. The other call found by the checker is tracked in
b/157548188.
I also found that errorprone was not running for framework-minus-apex,
so I added the plugin to the relevant build rule. Let me know if this is
not the way to go!
Test: build/soong/soong_ui.bash --make-mode framework-minus-apex
RUN_ERROR_PRONE=true
Bug: 157626959
Change-Id: Ieb94f2f43722837c8354ac66474797f4f338ae16
Apps making calls into the system server may end up persisting
internal state or making security decisions based on the perceived
success or failure of a call, or any default values returned. For
this reason, we want to strongly throw when there was trouble with
the transaction.
The rethrowFromSystemServer() method is the best-practice way of
doing this correctly, so that we don't clutter logs with misleading
stack traces, and this checker verifies that best-practice is used.
Disable this check on managers that we know are hosted outside the
system process.
Bug: 155703208
Test: ./build/soong/soong_ui.bash --make-mode framework-minus-apex services RUN_ERROR_PRONE=true
Exempt-From-Owner-Approval: trivial annotations
Change-Id: I04b4daf7c92251a14bcc3ebb1e18cd00f6a7f283
Over the years we've had several obscure bugs related to how SDK level
comparisons are performed, specifically during the window of time
where we've started distributing the "frankenbuild" to developers.
Consider the case where a framework developer shipping release "R"
wants to only grant a specific behavior to modern apps; they could
write this in two different ways:
1. if (targetSdkVersion > Build.VERSION_CODES.Q) {
2. if (targetSdkVersion >= Build.VERSION_CODES.R) {
The safer of these two options is (2), which will ensure that
developers only get the behavior when *both* the app and the
platform concur on the specific SDK level having shipped.
Consider the breakage that would happen with option (1) if we
started shipping APKs that are based on the final R SDK, but are
then installed on earlier preview releases which still consider R
to be CUR_DEVELOPMENT; they'd risk crashing due to behaviors that
were never part of the official R SDK.
Bug: 64412239
Test: ./build/soong/soong_ui.bash --make-mode services RUN_ERROR_PRONE=true
Exempt-From-Owner-Approval: trivial blueprint changes
Change-Id: Ia20181f8602451ac9a719ea488d148e160708592
