This project is mirrored from https://github.com/LineageOS/android_frameworks_base.git. Pull mirroring updated .
  1. 29 Jun, 2020 2 commits
  2. 06 Jun, 2020 1 commit
  3. 05 Jun, 2020 1 commit
  4. 27 May, 2020 1 commit
  5. 20 May, 2020 2 commits
  6. 17 May, 2020 1 commit
  7. 06 May, 2020 2 commits
  8. 28 Apr, 2020 3 commits
  9. 24 Apr, 2020 1 commit
  10. 16 Apr, 2020 1 commit
  11. 14 Apr, 2020 2 commits
  12. 08 Apr, 2020 3 commits
  13. 07 Apr, 2020 1 commit
  14. 06 Apr, 2020 4 commits
  15. 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
  16. 16 Mar, 2020 2 commits
  17. 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
  18. 09 Mar, 2020 1 commit
  19. 03 Mar, 2020 1 commit
  20. 24 Feb, 2020 1 commit
  21. 11 Feb, 2020 2 commits
  22. 10 Feb, 2020 1 commit
  23. 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
  24. 04 Feb, 2020 1 commit
  25. 23 Jan, 2020 1 commit