Grant Storage and contact to eDrive

See merge request !69

[RELEASE] Sprint Lockdown

See merge request !66

Pie new user icons

See merge request !61

Change-Id: I560753b0bade38785987e43abdaf7b2cb35ccb74

Merge tag 'android-9.0.0_r56' of https://android.googlesource.com/platform/frameworks/base into staging/lineage-16.0_merge-android-9.0.0_r56

Android 9.0.0 release 56

* tag 'android-9.0.0_r56' of https://android.googlesource.com/platform/frameworks/base:
  Verify all possible hosts that match web nav
  RESTRICT AUTOMERGE Prevent accessing companion records from arbitrary uids
  Revert "DO NOT MERGE - Kill apps outright for API contract violations"
  RESTRICT AUTOMERGE Use consistent calling uid and package in navigateUpTo
  RESTRICT AUTOMERGE Create separated tasks for different apps from startActivities
  DO NOT MERGE - Kill apps outright for API contract violations
  DO NOT MERGE Ensure package names read from config are system packages.
  RESTRICT AUTOMERGE Update keyguard locked state from TrustManagerService
  Only suspend package from system or shell

Change-Id: I678145bad18e8b34e462cde9f79f2952085f5e55

Even if an <intent-filter> matches non-web schemes in addition to http
or https, make sure to include its cited hosts in the autoVerify
evaluation.

Bug: 150038428
Test: atest OsHostTests#testIntentFilterHostValidation
Change-Id: If9ef0fc53d96e6581c56d86f89fe63bc9a5fb89a
Merged-In: If9ef0fc53d96e6581c56d86f89fe63bc9a5fb89a
(cherry picked from commit 1fba0f897f276d5d47962534867e764da8061105)
(cherry picked from commit bfa779601082d9021ea4e7d4cca571575bd0b13b)

Prevent accessing companion records from arbitrary uids

Test: manual
Fixes: 129476618
Change-Id: I7b18cfcdf58e62a445cbb508116c6ce7c1cea8d7
(cherry picked from commit 84cccfe6cdbc57ee372ee1a0fea64c7a11c53766)

This reverts commit ca006a7d.

Both Display.STATE_DOZE and Display.STATE_DOZE_SUSPEND returns true in
func isScreenDoze(int state),so if state change from STATE_DOZE to
STATE_DOZE_SUSPEND or the other way round, mScreenDozeTimer.startRunningLocked
may execute many times, then StopwatchTimer.mNesting++ executes
many times, mScreenDozeTimer.stopRunningLocked runs less than
 mScreenDozeTimer.startRunningLocked. The bad result is even we
close ambient.display or stopRunningLocked, the return value from
StopwatchTimer.computeRunTimeLocked() always rises, then Estimated power
for ambient.display in batterystats always rises, it's obviously wrong.
After modifying, startRunningLocked and stopRunningLocked could be
one-to-one correspondence, and the return value from
StopwatchTimer.computeRunTimeLocked() is right.

Problem background: When we turn on AOD(Alway On Display), the display state
may change from STATE_DOZE to STATE_DOZE_SUSPEND or the other way round, then
we find that in BatteryStatsHelper.addAmbientDisplayUsage(), ambientDisplayMs
always rises even after we turn off AOD. ambientDisplayMs equals
mScreenDozeTimer.getTotalLocked(elapsedRealtimeUs, which). At last, we find
that because of the mismatching startRunningLocked and stopRunningLocked,
mNesting is greater than zero even we turn off AOD, then the return value
from computeRunTimeLocked(long curBatteryRealtime) always rises. The appearance
is the ambient.display value in BatteryStats always rises even we turn off AOD.

Test: manual- use modifying version for daily use two days,
the Estimated power for ambient.display is right now.

Change-Id: I7731a60c3bc8be331eebfcd923bb70ecbc661a77
Signed-off-by: zhuguangqing <zhuguangqing@xiaomi.com>

MSIM devices are not reporting state changes for SIM slots without SIMs,
so when toggling airplane mode it would get stuck in the intermediate
state because a phone state callback would never happen.

Now we dynamically add phone state listeners for each active SIM slot.
If there is no active SIM slot, we immediately fall back to the
setting-based behavior. When a subscription update occurs (such as
inserting or removing SIM cards, we'll reinitialize the listener and
use the proper mechanism).

Ticket: CYNGNOS-989

Change-Id: Ifa4f418dd11fda6f67ba31f3847bed225187b95c
Signed-off-by: Roman Birg <roman@cyngn.com>
(cherry picked from commit c4f6df9942855327752dd925f6eb27b096aab66f)

Actually, the initial status of airplane mode toggle is set to false
when the power menu dialog is initialized.
This causes an issue if you set airplane mode and then reboot.
After the reboot, the dialog displays the wrong airplane mode status,
eg. "Airplane mode is not active", and if you toggle that option, a wrong
intent is sent again to put ON the airplane mode, instead of OFF, the
toggle (that is in transition state) will be set disabled.

This commit fixes this issue.

Change-Id: Id30355c1e090355645c437086c79ab59093c27a8
(cherry picked from commit 760256495f567d211d217362fafc9e979018685e)

grant esmssync permission

See merge request !56

This reverts commit 8f6b9431.

Merge tag 'android-9.0.0_r55' of https://android.googlesource.com/platform/frameworks/base into staging/lineage-16.0_merge-android-9.0.0_r55

Android 9.0.0 Release 55 (6197209)

* tag 'android-9.0.0_r55' of https://android.googlesource.com/platform/frameworks/base:
  Fix potential double destroy of AssetManager
  Revoke 'always' web handler status when not autoverifying

Change-Id: I2932ef023c6841c376dcdd789dd7eef32d61138a

[RELEASE] Sprint Istanbul grant esms permissions for v1-pie

See merge request !52

[RELEASE] Sprint Istanbul

See merge request !49

Change-Id: I30c9922da8fb4d4b524a521d6819ba73547fdfb1

Change-Id: Ie97a2b0c2af6a028e235316bf5d057d6e7262465

// mAccountEvictors.put(k.account, tokenEvictor);
// should be:
mAccountEvictors.put(k.account, accountEvictor);

This error in putToken() method causes the confusion of mAccountEvictors,
and may causes the evict() method does not clean up the cache data correctly.

Change-Id: I9435c206a6fa4d90177bbbe8816004365a213d1b
Signed-off-by: Haohua Li <lihaohua90@gmail.com>

Originally, if the caller of navigateUpTo is alive, even the calling
uid is set to the caller who launched the existing destination activity,
the uid from caller process has higher priority to replace the given
calling uid. So this change doesn't modify the existing behavior if
the caller process is valid. Besides, the case of delivering new intent
uses the source record as calling identity too, so the case of starting
new activity should be consistent.

Also forbid attaching null application thread to avoid unexpected state
in process record.

Bug: 144285917
Test: atest ActivityStackTests#testNavigateUpTo
Test: atest CtsSecurityTestCases:ActivityManagerTest# \
      testActivityManager_attachNullApplication
Change-Id: I60732f430256d37cb926d08d093581f051c4afed
(cherry picked from commit da78af4d6696dda77c692a7c6f2f49d4277cf341)

Assume there are 2 applications A, B with different uids.
There are 4 activities A1, A2, B1, B2 with default task
affinity and launch mode.

After A1 called startActivities(B1, A2, B2):
 Original   : Task(A1, B1, A2, B2)
 This Change: Task(A1, B1), Task(A2, B2)
In other words, the source caller cannot launch its activity
above the activity of other application in the same task, and
it can still launch activity of other application in its task.

Bug: 145669109
Test: atest StartActivityTests# \
      testStartActivitiesWithDiffUidNotInSameTask
Change-Id: I97bd875146a52f62b8fe82235487ccefb2955e8e
(cherry picked from commit 48d8d370f3d1dac06719ca6a52bda5f45a1a533a)

...rather than relying on in-app code to perform the shutdown.

Backport of security fix.

Bug: 128649910
Bug: 140108616
Test: manual
Test: atest OsHostTests#testForegroundServiceBadNotification
Change-Id: I94d9de50bb03c33666471e3dbd9c721e9278f7cb
Merged-In: I94d9de50bb03c33666471e3dbd9c721e9278f7cb
(cherry picked from commit a79b6ba5c59dc6aaa8adbe1ffa3ee4b761f45e7f)

Bug: 145981139
Test: manually tested ensureSystemPackageName() returns null for non-system app
Change-Id: I1d23910cbd282f6702785c9dfb059d7be6b0e895
(cherry picked from commit 6a56247200e1a8afc4dacc2497ec384efa200b92)
(cherry picked from commit 584d73a0b066e01b0877b475c8e2b1a85fcf5328)

Update keyguard locked state from TrustManagerService

TrustManagerService holds the ground truth about whether a user is
locked or not, so update keystore using the information there,
instead of doing it from KeyguardStateMonitor. This fixes the issue
of work profile locked state not being correctly pushed to keystore.

Note: since this change is likely to be backported as a security
patch, I'm refraining from doing major refactoring right now.

Bug: 141329041
Bug: 144430870
Test: manually with KeyPairSampleApp
Change-Id: I3472ece73d573a775345ebcceeeb2cc460374c9b
(cherry picked from commit 0860a5c5c303426073c36763bef28644673ff441)

Test: manual
Bug: 148059175
Change-Id: I50ee768e792266ad2091f1913168e89d5d1463ed
Merged-In: I50ee768e792266ad2091f1913168e89d5d1463ed
(cherry picked from commit 1c943a2670c1ff499669b42ef72dcd9f07db08c3)
(cherry picked from commit adc39de3)
(cherry picked from commit eb4f716bf3a0ee3ac8015cde48305aeb82724039)

Android 9.0.0 release 54

* tag 'android-9.0.0_r54':
  Fixes NPE when preparing app data during init
  Use KNOWN_PACKAGES when shared lib consumers
  Handles null outInfo in deleteSystemPackageLI
  Fix security problem on PermissionMonitor#hasPermission

Change-Id: I471247e71a4aaaf8a64e3d7c136ebcdacd65bfe3