There are intermittent issues where either the returned Bluetooth
MAC address to Java framework is uninitialized or this address update
arrives too late. This fix will do 2 things:
(1) Returns error when MAC address is unavailable in the native code.
(2) Updates the MAC address later by adding a new broadcast event.
Test: Check address for these cases: factory reset, system reboot, and
Bluetooth re-enable.
Bug: 36709382
Merged-In: I09720193e38fdf9139e1bb146f8e1847e2b65b1a
(cherry picked from commit ad4d1d8e28)
Change-Id: Ifae3adf6e2aad1f0811c03d3114d1bd0452e7c23
Bug: 62196835
Test: Created an accessibility service that displays a system
and a toast overlay, confirmed that it disappeared when we
reached the accessibility permission screen that uses this
flag.
Change-Id: Ic51ead670fc480e549512ba1d02f49d9c13bc3f0
Bug: 62196835
Test: Created an accessibility service that displays a system
and a toast overlay, confirmed that it disappeared when we
reached the accessibility permission screen that uses this
flag.
Change-Id: Ic51ead670fc480e549512ba1d02f49d9c13bc3f0
Bug: 62196835
Test: Created an accessibility service that displays a system
and a toast overlay, confirmed that it disappeared when we
reached the accessibility permission screen that uses this
flag.
Change-Id: Ic51ead670fc480e549512ba1d02f49d9c13bc3f0
GateKeeperResponse has inconsistent writeToParcel() and
createFromParcel() methods, making it possible for a malicious app to
create a Bundle that changes contents after reserialization. Such
Bundles can be used to execute Intents with system privileges.
This CL changes writeToParcel() to make serialization and
deserialization consistent, thus fixing the issue.
Bug: 62998805
Test: use the debug app (see bug)
Change-Id: Ie1c64172c454c3a4b7a0919eb3454f0e38efcd09
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 is done on wear power button doesn't turn off the screen,
when the device wakes from keyguard UI isn't visible yet, so
it needs to react to power press in some way.
Bug: 35147955
Change-Id: I22619ea446770d09b53370e9244215646b60a9db
