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
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
Added a service that listens whether emergency affordances
are necessary.
If the they are needed, it adds an option to the
global actions dialog that directly launches the
emergency call and also adds a long-press listener
to the keyguard emergency button.
Test: adb shell settings put global force_emergency_affordance 1 && adb shell settings put global emergency_affordance_number 111112
Bug: 30404490
Change-Id: Ib96a15da2ef4b568a8d77140ebca6aa6f20f5ddb
The limit is MAX_WAKELOCKS_PER_UID+1, since OverflowArrayMap
will add one more to contain the overflow.
Change-Id: I53004582daa0c405427308816728f2c1d2bef40d
Add the FLAG_RECEIVER_FOREGROUND flag to the broadcast intent
triggered by hardware key.
This prevents the framework from delaying the delivery of the
intent to its recipients, and improves the response for hardware
key event under heavy load on the system.
Bug: 28735973
Change-Id: Ib7f219845be34794f4c7545927e53cc6c2b504a3
* changes:
Fixed a bug where the dimmed background could be invisible
Fixed an issue where the inline controls where not usable
Added Emergency affordance feature
Sometimes, makeSingleLayout() can be invoked before layout direction is resolved.
When not resolved, it indents in LTR layout although it should be RTL.
So, to guarantee the exact indenting, we should re-build the text layout
when the layout direction is changed.
Test: manual - Test BigTextStyle notifications with LargeIcon under RTL configurations.
Fixes: 31633875
Change-Id: Idc6c5d7d41632cb9e1b70d9c67c13852e3f25023
Fix a bug where ResolverComparator's results were not consistent for
targets that cross profile boundaries.
Bug: 31640894
Change-Id: Ic6bf9512d2c2eb6f8fb7851e18eb9a347db29755
Added a service that listens whether emergency affordances
are necessary.
If the they are needed, it adds an option to the
global actions dialog that directly launches the
emergency call and also adds a long-press listener
to the keyguard emergency button.
Test: adb shell settings put global force_emergency_affordance 1 && adb shell settings put global emergency_affordance_number 111112
Fixes: 30404490
Change-Id: Ib96a15da2ef4b568a8d77140ebca6aa6f20f5ddb
Sync adapters without an account access cannot run until the
user approves the account access (for the case the account
access is not allowed by other policy such as being singed
with the same cert as the authenticator). If the sync adapter
does not have permission to access the account we ask the
user to grant access and take a note. This CL adds backup
for the explicit user grants.
bug:31162498
Change-Id: I31e3f3d010475352c7c54255ac2d3a2fed4d0c72
Handler has no fewer than three ways by which a message might be
handled:
[1] the msg itself contains a callback (msg.callback.run())
[2] the Handler was instantiated with a Handler.Callback
(mCallback.handleMessage(msg))
[3] the Handler instance was a subclass and could have
overridden handleMessage()
Handler#dispatchMessage() tries to find the correct way to dispatch
a message, check the above in the above order.
Bug: 21859053
Change-Id: I284cf7ace93af167d95d13b297ec42d4bed15992
Attempt to reduce the chances of watchdog killing the system
server if process pss gathering takes too long during heavy load.
Bug: 30896716
Change-Id: I4ed1a15c0c512a8c82842cde74e733d99d887ee0
Before there was a jump-cut when a window that was occluding Keyguard
was going away, leading to an ugly flicker. To fix this, we do the
following.
- Always show windows with FLAG_SHOW_WHEN_LOCKED above lockscreen, even
if they don't "match" the currently occluding app (which is null in the
animation case)
- Move wallpaper behind last window that is not hidden by policy, so the
window doesn't get occluded by the wallpaper.
- Add a flag in the setOccluded call whether to animate or not. SystemUI
then plays a nice animation when it's set.
- Override the animation to always be the animation that happens when we
exit a window which is revealing the wallpaper behind, to make it
consistent with the home screen case.
Fixes: 30829255
Change-Id: Ib3fe20fc9003a0f9f291c974740f044ed8707e75
Symptom:
When sharing an image from Album, ChooserActivity can be shown.
But then the app to be located to the bottom part of the list may not
be started even if user tap it.
Root cause:
ChooserActivity uses ResolverDrawerLayout. And ResolverDrawerLayout
can display only some items on the list (known as "Collapse mode").
When the item clipping along the bottom edge is tapped by the user,
ResolverDrawerLayout tries to expand the list and scroll it to a
better position, instead of starting an application.
In this problem case, ResolverDrawerLayout continues to try to expand
the list whenever tapping, so an application will never start.
Solution:
Change a condition so that mOpenOnClick becomes true only when the list
has been collapsed (mCollapseOffset > 0).
Bug: 30153542
Change-Id: I576fb6c8b6a91d79c1e0d46d069146779f4dbd17
(cherry picked from commit 4f3a843ea9)
Use application context to get the screen's display metrics.
Bug: 30127070
Change-Id: I2c453c494ef210c12d89fc7e3ff026728f9ecb0f
(cherry picked from commit afb38c5cc4)
LinearLayout sets up internal state during onLayout that's missing when
we override onMeasure. Avoid calling super.onMeasure() by re-implementing
onLayout without the internal state dependencies.
Bug: 30494039
Change-Id: I1149517a2fe5f5afdb4125db5e7f573588fea740
BootReceiver was using current build information when reporting
various versions. This was causing A/B devices to report the
wrong build information when reporting crashes since rebooting
a A/B device with a pending OTA would automatically apply the
OTA. (the problem was not seen on devices without A/B due to
booting through recovery to apply the OTA)
Bug: 30594862
Change-Id: I6f52081142e338c822c9135cba48a1f88f4d4bdb
If we return to the lockscreen from a FLAG_SHOW_WHEN_LOCKED activity,
there was an additional black flicker as the wallpaper wasn't shown
for a couple of frames. The issue is that we didn't set the wallpaper
flag again, to fix another flicker with lockscreen wallpapers. Now,
we pass the state whether we currently have a lockscreen wallpaper
and if we don't have one, we immediately set the wallpaper flag
again.
Bug: 30829255
Bug: 30883413
Change-Id: I9faeaa77b98eb02058171ce19cf90b43826ebe9e
This type behaves like a normal TYPE_APPLICATION, except that WM
will always wait for it to be drawn before starting a transition.
WM always waits for TYPE_BASE_APPLICATION (main window), but for
TYPE_APPLICATION, it only waits if the window relayouts to visible
and gets a surface before the main window is drawn. If main window
itself is ready very fast, transition could start without the other
window.
bug: 30830849
Change-Id: Ife71a9812db7c8eba6ee4ead10ce4f31d9e93b40
The summary is supposed to just hold enough data to continue counting
once the device has reset. Since kernel stats reset when the device
resets, and the first update is ignored to account for soft resets where the
kernel continues running, SamplingTimer should not be recording the last value
it saw from /proc/wakelocks in the summary.
Bug:30575302
Change-Id: Ic193bc5af9a0ede514e3abc8146523d7316c47d3
