When roaming, we assume that the roaming operator will support
control plane fallback for emergency SUPL. For roaming operators
that we know do not support control plane fallback, we must perform
a DDS switch before dialing an emergency number on that operator.
Bug: 144383368
Test: atest TeleServiceTests; manual
Merged-In: I4a033f89610fd409ea81c40230938720ca76541c
Change-Id: I4a033f89610fd409ea81c40230938720ca76541c
am skip reason: Change-Id Ie3daecd1e8fc2f7fdf37baeb5979da9f2e0b3937 with SHA-1 33f56060d5 is in history
Change-Id: I14b85400e9d1c85360d677839286dfe97bcc391a
am skip reason: Change-Id Ie3daecd1e8fc2f7fdf37baeb5979da9f2e0b3937 with SHA-1 33f56060d5 is in history
Change-Id: I438a0c90c903fe615dddf4eb54e8ccaded51fc9c
The string is preloaded according to PRODUCT_CHARACTERISTICS which is
automotive for AAE platform.
Bug: b/143243229
Test: Install recording app(coarse edition) on a hawk head unit, go to Settings > Apps &
notifications > Show all apps > Sensor Replay Recording > Permissions >
All permissions, click on access approximate location and verify the
string.
Change-Id: I54fe5903364b881498f0a0066efcc0fc7833d526
am skip reason: Change-Id Iaa78a7edcf23755c89d7b354edbc28d37d74d891 with SHA-1 f98611062c is in history
Change-Id: I72c045aeeb3c516a286ad5ef6413fb227019a299
am skip reason: Change-Id Iaa78a7edcf23755c89d7b354edbc28d37d74d891 with SHA-1 f98611062c is in history
Change-Id: I33d00fde7d89d4cd84876bc982c6b28fa95287f5
am skip reason: Change-Id Iaa78a7edcf23755c89d7b354edbc28d37d74d891 with SHA-1 f98611062c is in history
Change-Id: I92c1131ef02f7ca5e399b47c62993cf28719b66a
Only show unlock dialog when the foreground user has screenlock and trusted device.
Bug:144590810
Test: Manually on IHU
Change-Id: I2585ec33391aec9f3cd71f03507e863cbd5d4e76
Merged-in: I08c7aa677150ca950785428580eee6a39ffadd37
setNightMode if it is AAE.
Bug: 145997050
Test: Manual
Change-Id: I6450dda422622ac29862f5d1fc362e23f55228f0
Merged-In: I6450dda422622ac29862f5d1fc362e23f55228f0
Fixes NPE when preparing app data during init
When deleting an unused static shared library on Q, the user manager was
fetched via mContext.getSystemService. At this time during boot, the
service wasn't registered and so null was returned. This has already
been addressed in R with a move to injecting dependencies in the
PackageManagerService constructor.
Bug: 142083996
Bug: 141413692
Test: manual; remove static dependency on eng Q build and reboot
Change-Id: I8ae4e331d09b4734c54cdc6887b273705dce88b1
Merged In: I8ae4e331d09b4734c54cdc6887b273705dce88b1
Use KNOWN_PACKAGES when shared lib consumers
This change ensures we find ALL known packages that could be consuming a
shared library, not only currently installed ones. Without this check,
the system may get into a state in which we have currently uninstalled
but on-device apps that depend on a shared library that does not exist
on device.
This change also leaves static shared library packages on device even if
it's not installed for any of the remaining users as it could still be
used, but marked uninstalled for users in which it is consumed.
Bug: 141413692
Bug: 142083996
Test: Manual; attempt to remove shared lib after marking its consumer uninstalled.
Test: atest StaticSharedLibsHostTests
Change-Id: Id4e37c3e4d3ea3ad5fddae5d2c7305e56f50eeea
Merged In: Id4e37c3e4d3ea3ad5fddae5d2c7305e56f50eeea
Handles null outInfo in deleteSystemPackageLI
This change adds null checks before accessing outInfo in
deleteSystemPackageLI.
Bug: 142083996
Bug: 141413692
Test: manual; remove static dependency on eng build and reboot
Change-Id: If0fd48343e89cbb77ccd25826656194195d5b0cd
(cherry picked from commit 1747101650)
Merged In: If0fd48343e89cbb77ccd25826656194195d5b0cd
When a notification becomes lifetime-extended, NotificationEntryManager
was holding onto the RankingMap that was passed at the time of removal
of _that_ notification, and using it again in the
NotificationSafeToRemoveCallback. The problem here is that when
onSafeToRemove gets called, it was passing that same stale ranking map
to removeNotification, which caused any notification that arrived in the
intervening time to get improperly ranked.
This fixes an issue where any notification that arrives while another is
lifetime-extended can get the wrong ranking applied to it, causing
trouble later in time such as mis-ranking and mis-sorting until the next
update from system server.
Bug: 146046016
Bug: 119041698
Test: atest SystemUITests
Test: manual - Post a FGS notification and immediately cancel, then post
a regular notification and wait for the FGS notification to dismiss.
Note that the regular notification keeps showing in the status bar.
Change-Id: I3df1279f13c424fcedd878bae2095fadc75d61b4
