- 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
Refactored docked position code into PhoneWindowManager to determine
which side the docked app should go based on the position of the nav bar
in landscape (as portrait will only have top). Fixed the split screen
entrance animation for quick step's overview.
Change-Id: I30f1be9d791c23f4cd197f17487609964f78fac0
Fixes: 73250406
Test: play around with splitscreen and minimized mode
Test: atest com.android.server.policy.PhoneWindowManagerTest
- 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
Measure the last action view normally instead of measuring it full width.
Test: enable show layout bounds and check the bounds of it.
Change-Id: I38f234928f7214baf2b532ecae63c3f4514b3247
Fixes: 78032480
DecorContext is created with the resources from the activity. However,
the resources in DecorContext may not get updated properly
ResourcesManager if the original resource object it's pointing to isn't
updated by ResourcesManager. Because of this, resources for the
DecorView can be incorrect when the activity's resources are updated.
This change updates the DecorContext's resources with the activity's
resources when getResources is called to ensure they get properly
updated.
This fixes the issue where windowing mode was incorrect when determining
what the window elevation should be. It was incorrectly getting full
screen when it should have gotten pinned. This was preventing surface
insets from getting set on the WM side, so PIP windows didn't get
shadows.
Change-Id: I5af2364f81b167e3732811d7413554d035c4a021
Test: PIP has shadows
Fixes: 78214575
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
