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
The offset used to adjust MotionEvents for swipe velocity tracking
was incorrect, and caused issues when touch points where close
together. Fixed the offset used, which resolved swiping issues.
Bug: 34673753
Change-Id: Ide6060b511510bcf299e3db778e6ffc6afda5e19
Cancelling swipe-to-dismiss will trigger a check to ensure the window
is reset to its original state. Ensure that the reset is actually
required before setting the new layout attributes.
Bug: 34816397
Change-Id: Idf26ce7c8b63dc44a76effefcb32eb8d8665f605
Instead of
(current charge) * (current battery level percentage)
the formula should be
(current charge) / (current battery level percentage)
to estimate the charge at 100% battery level.
Bug: 34255953
Fixes: 34255953
Test: formula change CL. No existing unit tests found.
Change-Id: I56ef7af3fb097a3082e0ef24329f522d2a0229cc
(cherry picked from commit 9238b6124c)
On FBE devices, don't save the metrics to disk but compute them when the
password is first entered and only store them in RAM.
Merged-in: 5daf273b7e
Bug: 32793550
Change-Id: Icee7f615167761177b224b342970a36c7d90f6ba
In some cases (e.g. Android Wear) SystemWindowInsets can be non-zero
due to overscan layout hints even when no SystemUI is present.
This change resepects the overscan flag on input method windows
allowing an IME to opt-out of the navigation bar guard and receive
full-height content view.
BUG: 32700226
Change-Id: Ic38f204a892bf34e8dae65990d5aa8c95af555d8
OEMs can overlay the default 9 dots by providing two drawables that represent
those dots:
* lockscreen_notselected: asset to display when a cell has not been selected.
* lockscreen_selected: asset to display when a cell has been selected.
BUG: 33755663
Change-Id: Ic595b01f5e1321696b7a3feb0ff73c1acccfb942
Swipe to dismiss on dialogs did not dispatch onCancel events
to OnCancelListeners. Resolve by adding listener to monitor
swipe to dismiss events and dispatch onCancel events when
that occurs.
Bug: 33663411
Change-Id: I64ff29e008d485a4559eb3d1ff7f0e74dccff404
Modifies swipe-to-close activities to be opaque by default (instead
of translucent by default). Previously, android:noHistory properties
on most activities in Wear were being ignored because they were
usually transitioning to a swipe-to-close activity that was marked
as translucent. This meant that the noHistory activity was still
technically visible, and so would never be culled from the task
history.
Now, we convert a swiped activity to translucent as soon as a swipe
begins, and convert it back after the swipe finishes. The previous
version of SDL tries to do this, but fails in the case where the
context is a ContextWrapper.
This approach is hacky and isn't merge-able into master. We leave
it DO NOT MERGE and will do a long-term fix after the holidays.
Test: Built a test app to verify that noHistory is now being
correctly respected. Manually verified that new activities start
out opaque and not translucent. Manually verified that Home
correctly starts/stops when it's revealed from underneath a
partially swiped activity. Tested general swipe behavior on Settings,
Contacts, Flashlight, Fit.
Bug: 33252029
Change-Id: Ib2e7f21ea1e0d52db03e78d25676501e5f73b31f
Instead of relying on the window animation system, in the special
case of a swipe-dismiss, disable any default window exit animation
and perform a custom animation. This bypasses some bugs in the
window animator codebase and allows us to have a nice "rebound"
animation if the user doesn't swipe far/fast enough to trigger a
dismiss.
Bug: 33041168
Change-Id: Ied45700d35a59950bacef1ba0650eaa5bc60fadb
The emergency call was not launched in the current user
and therefore was only launching once the user had switched.
Change-Id: If6f3bcf77d88a0658b6e0f91f7e4da5d6264b04f
Fixes: 32424103
Test: manual: switch to secondary user and launch emergency affordance
Allows configuring notification and sensor triggers
separately. Introduces a helper class that hosts the
logic for determining what kinds of triggers a device
supports.
Bug: 32073185
Change-Id: Ie7e8eb6b895dcc54e6f972e70642c7248b9e223a
Test: disable "ambient display", sensor triggers should still work
This is a follow up CL to my previous CL [1] that let
IInputConnectionWrapper to call InputContentInfo#requestPermission()
automatically so that temporary URI permissions can be granted
automatically on API 25+ devices whenever
INPUT_CONTENT_GRANT_READ_URI_PERMISSION is specified.
However, in that CL we forgot to handle exceptions thrown from
InputContentInfo#requestPermission(). This is problematic because it is
actually easy for IMEs to cause SecurityException by specifying a
content URI that does not allow grantUriPermission, e.g.:
inputConnection.commitContent(
new InputContentInfo(Uri.parse("content://call_log/test"),
new ClipDescription("test", new String[]{"image/gif"}));
As a result, IMEs can let the application crash at any time because
InputContentInfo#requestPermission() is automatically called inside the
Framework.
This CL makes sure that exceptions thrown from
InputContentInfo#requestPermission() can be handled gracefully.
[1]: Id955435dd2e72549ee7134f46b3c6951581694ad
f3806f57a5
Bug: 32162481
Change-Id: I08916a1f54518390d3b67ab1673dc901e3f9716a
