Skip to content

A
android_frameworks_base
Switch branch/tag
This project is mirrored from https://github.com/LineageOS/android_frameworks_base.git. Pull mirroring updated .
  1. 29 Jun, 2020 2 commits
  3. 06 Jun, 2020 1 commit
  5. 05 Jun, 2020 1 commit
  7. 27 May, 2020 1 commit
  9. 20 May, 2020 2 commits
  11. 17 May, 2020 1 commit
  13. 06 May, 2020 2 commits
  15. 28 Apr, 2020 3 commits
  17. 24 Apr, 2020 1 commit
  19. 16 Apr, 2020 1 commit
  21. 14 Apr, 2020 2 commits
  23. 08 Apr, 2020 3 commits
  25. 07 Apr, 2020 1 commit
  27. 06 Apr, 2020 4 commits
  29. 30 Mar, 2020 1 commit
    • Riddle Hsu's avatar
      RESTRICT AUTOMERGE Create separated tasks for different apps from startActivities · a952197b
      Riddle Hsu authored 
      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: run cts --test android.server.cts.StartActivityTests \
      -m CtsServicesHostTestCases
Change-Id: I97bd875146a52f62b8fe82235487ccefb2955e8e
(cherry picked from commit 973ecc61)
      a952197b
  31. 16 Mar, 2020 2 commits
  33. 12 Mar, 2020 2 commits
    • Riddle Hsu's avatar
      RESTRICT AUTOMERGE Use consistent calling uid and package in navigateUpTo · d37eb962
      Riddle Hsu authored 
      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: bit FrameworksServicesTests:com.android.server.am.ActivityStackTests
Change-Id: I60732f430256d37cb926d08d093581f051c4afed
(cherry picked from commit 0d7e27af)
      d37eb962
    • Christopher Tate's avatar
      DO NOT MERGE - Kill apps outright for API contract violations · c6fd63a7
      Christopher Tate authored 
      ...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 874c974f)
      c6fd63a7
  35. 09 Mar, 2020 1 commit
  37. 03 Mar, 2020 1 commit
  39. 24 Feb, 2020 1 commit
  41. 11 Feb, 2020 2 commits
  43. 10 Feb, 2020 1 commit
  45. 06 Feb, 2020 2 commits
    • Ryan Mitchell's avatar
      Fix potential double destroy of AssetManager · b7a2a333
      Ryan Mitchell authored 
      Assume there is a XmlBlock [X] created by a AssetManager [A]
([A] will have mNumRefs = 2). After [A].close is called
(mNumRefs = 1) and then both [X] and [A] are going to be GCed,
if [A].finalize is called first (nativeDestroy), the later
[X].finalize will invoke [A].xmlBlockGone that triggers the
second nativeDestroy of [A] and leads to crash.

By clearing the mObject in AssetManager.finalize, the
decRefsLocked from other paths won't call nativeDestroy again.

Bug: 144028297
Test: atest android.security.cts.AssetManagerTest

Change-Id: Ia938502d2443f5a6de6a3cabdb7ce1d41d3ff6d1
Merged-In: Ia938502d2443f5a6de6a3cabdb7ce1d41d3ff6d1
(cherry picked from commit 93320661)
      b7a2a333
    • Christopher Tate's avatar
      Revoke 'always' web handler status when not autoverifying · 35c45595
      Christopher Tate authored 
      If an app has previously used autoVerify to make claims about its status
re handling web navigation intents, but is updated such that it no
longer makes those claims, step down its "official handler" status as
though it had never invoked autoVerify in the first place.

Bug: 146204120
Test: manual: as described in bug; observe policy before/after via
      'adb shell dumpsys package d'
Test: atest CtsOsHostTestCases
Change-Id: I58502d1b32d793aba9aa772fa2ad5ac38acca48a
Merged-In: I58502d1b32d793aba9aa772fa2ad5ac38acca48a
(cherry picked from commit ef5220e5)
      35c45595
  47. 04 Feb, 2020 1 commit
  49. 23 Jan, 2020 1 commit