adjacent TFs
An old secondary TaskFragment can be in middle of the primary and new
secondary TaskFragments. We don't want to show it even if it has a
different bounds from the new secondary.
Fix: 215467839
Test: atest SplitActivityLifecycleTest
Change-Id: I85dccdc4a931eda7d53c91d288ad19b6ef865dc9
When a package is added or removed on a secondary user, the broadcast
was not being processed, leading to inconsistent state, like lingering
defunt alarms and stale exact alarm candidates.
Test: atest FrameworksMockingServicesTests:com.android.server.alarm
Bug: 218868406
Change-Id: I1f1b9a5b8f63d6564c9e121bee7d6d6d697b471d
Merged-In: I1f1b9a5b8f63d6564c9e121bee7d6d6d697b471d
(cherry picked from commit 6c9df302ae)
Check both NORMALIZED_NUMBER and NUMBER for a phone call contact, in case one or the other is populated but not both, for more phone number coverage.
Use Uri.decode instead of URLDecoder as it seems simpler and more directly relevant.
Bug: 183924362
Test: NotificationManagerTest, ValidateNotificationPeopleTest, ZenModeFilteringTest
Change-Id: I29c39bf1e3d7dc69cc1f83854a23f6b33a6eac58
Merged-In: I29c39bf1e3d7dc69cc1f83854a23f6b33a6eac58
(cherry picked from commit b9290319b6)
It is possible to have a fullscreen closing TF between two resume TFs
(this can happen when closing the fullscreen TF results the bottom
activity open a new activity into split). In that case, we don't want
the fullscreen TF to hide the activity below it during cross fade
animation.
Fix: 214175523
Test: manually verify with Settings
Change-Id: I4350114d800442308c9c53f474ba60542c8a86e5
(cherry picked from commit c562f322b2)
When primary activity launches a new intent with a split rule with same
presentation (split ratio), we can launch the new activity to the
existing secondary container.
Bug: 216492188
Test: manual
Change-Id: Iad6d238c6dfb009402376a725136be6c6fdab98c
(cherry picked from commit 449fceaa1c)
Then, when a call comes in, store the additional phone numbers in the NotificationRecord (if any) in the repeat callers map.
This allows us to store those phone numbers in the repeat callers data to confirm whether future calls from that contact's phone are considered "repeat" when a caller passes in the phone number. This matches on any number that belongs to the contact, and not just the one used to give in the phone call (as contact lookup seems not to distinguish).
Bug: 183924362
Bug: 203806689
Test: ValidateNotificationPeopleTest; NotificationRecordTest; ZenModeFilteringTest; manually confirmed that the phone rings audibly when repeat callers is allowed and a contact calls
Change-Id: I83cc7fc036a3962d2468557d41b546f40a3cfbcf
Merged-In: I83cc7fc036a3962d2468557d41b546f40a3cfbcf
(cherry picked from commit fa8fd0d917)
Make sure that the native spatializer interface reference
if cleared when the native audio server dies so that is is properly
re-created by SpatializerHelper.init().
Bug: 224701940
Test: enable spatial audio and kill native audio server
Change-Id: Ib409e35f6aee9c149d6a998878f53209d74c54ad
* changes:
DO NOT MERGE Listen for config changes when updating features.
DO NOT MERGE Add LifecycleCallback adapter.
DO NOT MERGE Merge state producer and feature producer.
DO NOT MERGE Remove DisplayFeature from common package.
for both Direct USB Access and AoC Offload feature
According to USB audio warning dialog message conditions matrix, add
a UsbAudioWarningDialogMessage to handle the conditions.
Bug: 199034378
Bug: 222434773
Test: manually install NeutronPlayer to test usb audio device
permission warning dialog sentence.
Test: manually modify each audio api condition to test each sentence
correntness.
Change-Id: I5d670f7835a38e83b7d0d3955e966dba3b7f7664
The onUidActive/onUidInactive are called from AMS. The timing of
invocation may be somewhat indeterministic with WM.
For example: (it should be extreme corner case)
A process was died and restarted to show a window, but the uid
inactive/active are a bit late to notify. That causes the count
to be cleared.
If the count of visible window is cleared, the caller will be
considered as a background caller and may be unable to start activity.
So this change makes the count only depend on the state of window.
Fix: 222252947
Test: WindowStateTests#testHasActiveVisibleWindow
Change-Id: I2ac3e0ac777145bcf74819be7ffedaec80acb556
This file has been moved to a different location in "tm-dev" Hence, DO NOT MERGE
Bug: 194334719
Test: Manual
Change-Id: I6b25e4ea1d14051902b53d6542b346d55646b16c
- The Launcher currently manages gesture nav, so often a bug report
taken with better bug will prevent the launcher state from being
recorded as a part of the BR. This ensures that both the activity
dump and the window hierarchy is saved even if it is not visible
Bug: 223509022
Bug: 223498680
Test: dumpsys activity -v all, cmd window dump-visible-window-views
while Launcher is not visible
Change-Id: I06c5eaf4a82368996c734cd245803b3d7c4e7d71
Merged-In: I06c5eaf4a82368996c734cd245803b3d7c4e7d71
(cherry picked from commit 154a763558)
There is a "race condition" where a MessagingGroup is recycled while the
contents of that group are being used elsewhere in the
ConversationLayout, namely in the "image message container" used to show
the most recent image message in the collapsed state.
This state isn't cleared until later in the bind() process, which
unfortunately depends on the groups being updated. For that reason, we
defer all synchronous calls to recycle() until the end of bind(), which
will ensure that the old groups are still around as long as necessary.
Fixes: 216202070
Test: manual
Change-Id: Idef815d54690544615512bd2bd1006f172403e18
(cherry picked from commit 2a68270c76)
When switching users and attempting to lock the device, the sysui main
thread becomes overwhelmed with events, creating a significant lag
between the time a message is posted and processed on the main
thread. This can be dangerous when these events are critical for
security, such as calls coming from PhoneWindowManager#lockNow() that
call KeyguardViewMediator#doKeyguardTimeout(). On older devices with
slower CPUs and less memory, the delay in processing can be
significant (15 - 30s).
The result of not prioritizing these events leads to a window of time
where a guest user can switch back to the owner, and gain access to
the owner's homescreen without needing to unlock the device with the
owner's credentials.
As a mitigation, prioritize two events originating in two specific
methods to make sure the device locks as soon as possible as well as
have the system server preemptively update its local cache.
Bug: 151095871
Test: Very manual race condition - follow steps listed in bug
Change-Id: I7585a0a5eeb308e0e32a4f77f581556d883b5cda
Merged-In: I7585a0a5eeb308e0e32a4f77f581556d883b5cda
(cherry picked from commit 28c53ab8bc)
(cherry picked from commit f8023c9829)
