The stack trace in b/194344478 and b/194280568 is actually from the
preceding ActivityThreadTest test, which does not fail but does crash
certain test cases after that.
Since we may set a start delay on the content overlay fading out
animation, there is chance that onTaskVanished happens before it is
actually started. It's also possible that onTaskVanished happens during
the content overlay fadeout. This CL should have addressed both cases.
Bug: 194344478
Bug: 194280568
Test: atest --iteration 5 \
ActivityThreadTest#testHandlePictureInPictureRequested_overriddenToEnter \
ScreenshotTests#testScreenshotSecureLayers \
TaskStackChangedListenerTest#testTaskChangeCallBacks
Change-Id: I81c0622966df32e02db7cb5aa3cd42d7c4af735e
Merged-In: I81c0622966df32e02db7cb5aa3cd42d7c4af735e
We're tracking the phantom processes with the combination of
its process name and pid/uid, while if the process name changes
it'll be removed from the internal bookkeping, we should close
the FD to that process upon then.
Bug: 194146206
Test: atest AppChildProcessTest
Test: atest CtsAppTestCases:ActivityManagerTest
Change-Id: I62064afe55aa8bc51a2d523bc5d8fe6e97f171a8
It'll be used to feed into the app kill stats.
Meanwhile, use the real process UID instead of the package UID for
indexing the app kill stats container internally, it'll be better
in terms of aligning with the caller UID in queries.
Bug: 194364213
Test: atest ApplicationExitInfoTest
Test: atest CtsAppExitTestCases:ActivityManagerAppExitInfoTest
Test: Manual - dumpsys activity exit-info
Change-Id: I5c966086bb90675294b5dfc1c5cdb0c163f05170
- HBMController no longer listens to changes on the brightness setting
directly, and instead gets brightness updates from DPC. This was
necessary since some of the brightness-sources (such as app-override)
are not reflected in the actual setting.
- Clamp override and temporary brightness sources so that they cannot
push brightness beyond the bounds set by HbmController.
- Always save away the actual brightness setting in BrightnessInfo
cache, ignoring any temporary or override brightness values. This ensures
that Display.getBrightnessInfo() reflects the user setting, and not some
temporary brightness state.
Bug: 193392737
Test: manually test HDR with app-override
Test: atest HighBrightnessModeControllerTest
Change-Id: Iffe777a22d058ddb779dc6fc22c2382f6bbac1ab
Found an error in the logs:
ControlsBindingControllerImpl: Provider for
token:android.os.Binder@147a7f9 does not exist anymore
And then noticed that the ControlsActivity was being started by
framework when transitioning between ControlsFavoritingActivity and
ControlsProviderSelelctionActivity. This is strictly due to window
animations being enabled, and framework realizing that the
ControlsActivity will be visible momentarily between
activities. Previously uiController.show() was in the onStart()
method, which resulted in ControlsBindingControllerImpl rebinding to a
different service.
By moving to onResume(), the call to uiController.show() can be
avoided, hence avoiding the service rebinding so the controls can
correctly be shown in the favoriting activity.
Fixes: 191589943
Test: manual (requires multiple control services)
Change-Id: I634ab7c386c2098dc8f9971d320a8b80b8cd429a
the top of One-handed mode
1. Implement the Dynamic color theme at the top Tutorial area
but the color should not be the same as the recents UI.
2. Do not translate Tutorial icon & text vertically, then provide
quick subtle fade-in effect for Tutorial window.
3. Apply new icon for tutorial.
Bug: 193126258
Bug: 193589897
Test: Local verify when changing dark theme and wallpaper theme.
Test: Local verify Tutorial icon & text fade-in effect.
Test: atest SystemUITests
Test: atest WMShellTests
Test: Perfetto check enter & exit performance
Change-Id: I60f4e7a709f3a27fe6c7f480f1012caccdbbe5ec
SSA#updateHeadsUpStates defines the top HUN as having
mustStayOnScreen = TRUE
headsUpIsVisible = FALSE
However, SSA#updateChild sets
headsUpIsVisible = TRUE
for the top HUN when shade is closed
When we tap the reply button and show IME, SSA#updateHeadsUpStates
does not recognize the top HUN as such and skips it when
reducing yTranslation by scrollY (which includes IME inset)
This change skips setting headsUpIsVisible on HUNs when shade is closed.
Fixes: 187485733
Test: expand HUN in portrait/landscape with largest font/display
tap reply button to show IME
=> HUN shifts up to align bottom of input with top of IME
Change-Id: I236b01a7f9070ebe58457eab9ea8072703acb12c
If face auth fails and fingerprint is running,
show the "use fingerprint to open" msg.
Fixes: 194358779
Test: manual
Change-Id: I249fcf550ac1ca5881d55566a4366937263690bf
launch help page""
This reverts commit c2d0388962.
Reason for revert: Reverting the revert and avoiding the TH failure
Fixes: 191727929
Change-Id: I741f35aab78ba32f69f204dbdf4ebcf632bd741c
There is a interesting interaction between staged and non-staged
installs of the same APEX. Let's say an installer staged v1 -> v2 APEX
update, and then does a non-staged update to v3. After device is
rebooted, apexd will apply the staged v1 -> v2 session, silently
downgrading an APEX from v3.
For apks, this problem is solved by storing an expected version. When an
APK session is being applied during boot, Package Manager will check if
the currently installed version is equal to the expected one stored in
the staged session. If they mismatch, an install is failed.
Unfortunately, implementing the same logic in apexd will require a
non-trivial refactoring which is too late to do in S. Instead we are
just going to fail the non-staged installation.
Test: atest StagedInstallInternalTest
Bug: 187864524
Change-Id: I9000f40cede9a324a5059a09deb8eb5be13b21f9
