- Upgrade -> migrate suppressScreenOn and suppressScreenOff to
suppressVisualEffects
- New -> all visual effects are off, starred contacts are allowed
to call
Also fixed an NPE noticed while testing this CL
Test: runtest systemui-notification
Change-Id: I1efd6e3f9bc7519b2fb769bae62ffa1aaae59cb6
Fixes: 78778706
Fixes: 78768955
- Only count visual changes for non-foreground service notifications,
because users consider the notification to be one 'session'
- Don't count every remoteviews update, but those where the layoutid
or sequence number has changed.
Bug: 78643290
Test: runtest systemui-notification
Change-Id: I49483d26ebe63329ef2d6d3f10dd730c310fcf2a
Prior to the implementation of detachChildren we handled this
case via the "mWindowStopped" codepath in SurfaceView.java which this
CL deletes. That codepath however causes confusion due to it's failure
to set null the SurfaceControl, meaning we may not necessarily
recreate it when resuming if we didn't hit any other code-path
to do such as happens in linked bug 78588930. Anyway it seems clearest
to handle all these preserve-child-surfaces-on-tear-down cases via
one mechanism (detachChildren).
Bug: 78588930
Test: Manual.
Change-Id: Iac7c0bc0c6b4da0d405bdc2b57d13d5c881611b0
- So that AM can perform all the necessary caller checks, except for the cross-profile/user check.
- Note PixelLauncher is the recent app which gets extra privileges. So I used ShortcutLauncherDemo
and a 3p launcher for manual tests.
Fixes: 78635323
Test: manual test, with a 3p launcher. (nova)
- Launch primary profile app -> launches fine
- Launch work profile app-> launches fine
- Launch suspended work profile app -> "can't open this app" dialog is shown.
- Launch the primary counterpart of the suspended work profile app -> launches fine.
- Launch work profile app in quiet mode, with separate work challenge
-> "turn on work profile"? dialog is shown
-> then "cancel" -> nothing happens.
-> then "turn on" -> "re-enter your pin" is shown -> type pin -> work profile app starts fine.
- Launch work profile app without separate work challenge
-> "turn on work profile"? dialog is shown
-> then "cancel" -> nothing happens.
-> then "turn on" -> work profile starts and the app starts fine.
- "App info" on work profile app -> Setting page opens fine.
- "App info" on primary profile app -> Setting page opens fine.
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/pm/ShortcutManagerTest*.java
Test: atest cts/hostsidetests/devicepolicy/src/com/android/cts/devicepolicy/LauncherApps*.java
Change-Id: Ie665a8890407d05c1d877f04d9c5c3a1caad18e1
PersistableBundle.java expects items to be sorted by the hash codes
of the keys, but PersistableBundle.cpp isn't compatible to it.
PersistableBundle.java now knowns what was parceled by C++
because it now uses a different magic, and change the unpercel
strategy.
Change-Id: Ia516f80b6d48dcb9f981767e0e64303434f39fb4
Fixes: 65744965
Test: adb shell sm fstrim and check logcat
Problem was RemoteAction(...) takes a non-null PendingIntent but
TextClassification.createPendingIntent(...) returns a nullable PendingIntent.
Bug: 78515224
Test: manual
- Disable Contacts apps in settings
- Select a phone number in a TextView
- Verify that a Phone smart action is displayed
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Change-Id: Icab581d4eef38b4801d1b9ee3af04ffefd1eec6f
SurfaceTextureRenderer::swapBuffers interpreted EGL_BAD_SURFACE as
indicating an abandanoned buffer queue. But the EGL 1.4 lists additional
errors that also indicate extreme failure: EGL_CONTEXT_LOST, and
EGL_BAD_NATIVE_WINDOW.
Discovered while debugging CTS test
android.hardware.camera2.cts.RobustnessTest#testAbandonRepeatingRequestSurface
on ARC++ x86 boards.
Test: cts-tradefed/android.hardware.camera2.cts.RobustnessTest#testAbandonRepeatingRequestSurface
Bug: 64496778
Bug: 36063477
Change-Id: I782f2c923aa5ff2442bbcf3dfb09861e129a2872
(cherry picked from commit 3511f99cf986a9fe7a67a8aee301e05f1be07f62)
The StackWindowController was calculating task bounds with
the WM-side windowingMode instead of the AM-side.
In this case, we are resizing during a windowingMode change
(fullscreen -> freeform). Since the windowingMode isn't sent
to WM-side yet, the smallestScreenWidthDp was set using
the old windowingMode resulting in the wrong resources being
used.
This change makes windowingMode one of the parameters (like
bounds/density) used to adjust the configuration.
Bug: 71028905
Test: ActivityStackTests and WindowConfigurationTests still pass.
Open playstore maximized, go to an app page, restore window.
Layout should now be appropriate for the smaller window.
Change-Id: Idcb538a768cd983ab9eac0d61a6dbea3e9dc64a5
Test: On sailfish, set vibration intensity to High, lock the phone and
unlock with FPS. Vibration should be played.
Bug: 76129874
Change-Id: I546341e55fa0e6de0af1d22c8e8e07d67670f0b9
Merged-In: I546341e55fa0e6de0af1d22c8e8e07d67670f0b9
Also fix some tests that were broken on TV.
Bug: 78285926
Test: runtest systemui-notification
Change-Id: Icf4e5a1e02c3075b466305023c986ada52e9ec93
Merged-In: Icf4e5a1e02c3075b466305023c986ada52e9ec93
Previously, we were making the magnifier surface a child of the main
window unless the magnified view was a SurfaceView, in which case we
were setting the SurfaceView to be the parent of the magnifier. In
Chrome, where the magnified views are usually SurfaceViews, this caused
the magnifier to be displayed underneath the omnibox, which was a
terrible user experience when trying to magnify the first lines of text
on a page. This was because the omnibox had a higher Z than the
SurfaceView, and therefore a higher Z than all children of the
SurfaceView (including the magnifier).
This CL sets the parent of the magnifier surface to be the main window's
surface when the magnified view is a SurfaceView as well. Therefore, the
magnifier becomes a sibling of the Chrome omnibox and, by giving the
magnifier a higher Z, it ends up being rendered on top.
Bug: 77926365
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e
Moving UsageEvent.Event objects to an array list sorted on the event
timestamps as there can be multiple events with the same timestamps.
Test: atest android.app.usage.EventListTest
Existing tests:
atest android.app.usage.cts.UsageStatsTest
Bug: 74406113
Change-Id: Idc7f2a8db6e5a9499b3b0b74efbf014b17fa495f
COLOR_MODE_SATURATED disables color management and thus treat any
color space as panel color space. COLOR_MODE_AUTOMATIC is similar
to COLOR_MODE_SATURATED in that it stretches color spaces to panel
color space, but the stretching is color space aware.
persist.sys.sf.native_mode is extended to be a integer, where
0: use DisplayColorSetting::MANAGED
1: use DisplayColorSetting::UNMANAGED
2: use DisplayColorSetting::ENHANCED
Bug: 73824924
Test: manual
Change-Id: Ia356958d8e1fbae90f244ded7111de2e45aa4b3c
1. Define default Themes for autofill window and save dialog.
(http://go/theme_autofill). Phone uses light themes, TV uses
dark themes.
2. Apply autofill theme to RemoteViews passed from autofill service.
So this can make sure the textColor of RemoteViews matches
the background of autofill theme uses.
Updated public javadoc that autofill service should not
hardcode color values.
3. A new TV ux that occupies half screen height (go/autofill-for-tv).
TV autofill now passes unhandled physical keyevent to app window
in the same way phone/tablet does.
4. Fixed ATV autofill window to be SYSTEM_DIALOG, so it wont be
clipped by app activity window (DialogLauncherActivityTest).
Bug: 71720680
Bug: 74072921
Test: CtsAutofillTest
Change-Id: Ib570227b0958b1800e8f0600b8aec36478568d74
