Using Preconditions and dedicated static methods for checking arguments
to improve error stack traces without error messages.
Test: covered by previously added unit test
Bug: 36701874
Change-Id: Id872b2c887a4bca43a8c3644622add1c2ee57c6d
Please see commit 3082eb7c72 for an
explanation of this change.
This capability is not used by system_server.
Bug: 34951864
Bug: 38496951
Test: code compiles, device boots, no selinux errors ever reported.
Change-Id: I4242b1abaa8679b9bfa0d31a1df565b46b7b3cc3
(cherry picked from commit 35775783fc)
Commit https://android.googlesource.com/kernel/common/+/f0ce0eee added
CAP_SYS_RESOURCE as a capability check which would allow access to
sensitive /proc/PID files. system_server uses this capability to collect
smaps from managed processes. Presumably this was done to avoid the
implications of granting CAP_SYS_PTRACE to system_server.
However, with SELinux enforcement, we can grant CAP_SYS_PTRACE but not
allow ptrace attach() to other processes. The net result of this is that
CAP_SYS_PTRACE and CAP_SYS_RESOURCE have identical security controls, as
long as system_server:process ptrace is never granted.
Add CAP_SYS_PTRACE to the set of capabilities granted to system_server.
Don't delete CAP_SYS_RESOURCE for now. SELinux has blocked the use of
CAP_SYS_RESOURCE, but we still want to generate audit logs if it's
triggered. CAP_SYS_RESOURCE can be deleted in a future commit.
Bug: 34951864
Bug: 38496951
Test: Device boots, functionality remains identical, no sys_resource
denials from system_server.
Change-Id: I2570266165396dba2b600eac7c42c94800d9c65b
(cherry picked from commit 3082eb7c72)
This patch is a cherry pick of the two following commits:
- 15fd4395e1 which addresses several
issues in the public api of ConnectivityManager.
- e2d48ff57c which fixes the documentation
of several methods in ConnectivityManager public api.
Because the first commit change the public api that is referenced in
the documentation fixed by the second commit, it is not possible to one
without the other. In both cases trying to cherry pick only one of them
results in a build error.
The first commit was submitted successfully on an internal branch before
the checks done in the built got stricter.
Bug: 36370941
Test: marlin builds and boots
Change-Id: I86dcf056e6b165e527c3ee88dbabc2764ac09a08
Merged-In: I693ee5270bf186c88c7c5056293519f7237504ff
(cherry picked from commit 15fd4395e1)
The restriction on system property key length has been lifted.
Update the invoke-with code to first check the full-length property.
Then fall back to the truncated version for backwards-compatibility.
Test: m
Test: manual with long package name (Maps)
Change-Id: I9f714af093a6017307cfef18c84de769f0de7c3e
These classes are only used by android.test classes that are
being removed. As their name suggests they should not be in the
Android API at all so it makes sense to remove them. Especially
as there is java.lang.function.Predicate available now.
It appears as though Predicate was only added in to the API
because it was used by a method in the API as the directory in
which it and Predicates live was not on the list of classes to
explicitly index. Moving it into legacy-test meant that they are
now being indexed explicitly which means that Predicates needs
to be hidden.
Keeps running the tests as part of the existing target.
At runtime apps targeted at the API version before these are
removed will have the legacy-test library automatically added
to their classpath so they should see no effect. Apps that
target a later API will have to include those classes from the
android.legacy.test.jar which will contain all the android.test
classes that depend on it as well.
Bug: 30188076
Test: make checkbuild
Change-Id: Ia8502ec77ac11f85e078d70b68df214a9435eee7
Merged-In: I6f6f5f16fe93bd80227a450c6254166632fc6813
This patch introduces between ConnectivityManager and
ConnectivityService a mechanism for propagating back to clients
informative errors in the form of error codes and associated custom
runtime exceptions.
Without error code, the service can only throw a limited number of
different exceptions over Binder. Furthermore the throw site stack
traces are always loss. Although for individual instances of a throw,
the error message can be inspected, aggregations of stack traces from
app crashes sanitize error messages and only leaves the stack traces.
This makes debugging dificult for some service calls such as
requestNetwork that can have a variety of failure modes.
In this patch only one failure mode is codified. More can be added later
at a light cost by: 1) defining an error code, 2) defining an
associated exception, 3) mapping the code to the exception. This patch
can serves as a template for doing so.
Test: $ runtest frameworks-net,
#testNetworkRequestMaximum() detects the new exception type.
Bug: 36556809, 36701874
Change-Id: I611fd7915575c9e418f7149fcdc8a879d2a3716d
