summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorRobert Carr <racarr@google.com>2019-02-15 15:48:11 -0800
committerandroid-build-team Robot <android-build-team-robot@google.com>2019-05-15 05:32:40 +0000
commit5fc1b18b7fcc8c556f745ce1858a4cb9e99a1888 (patch)
treed0275775c59ff48f0c0b9c01dc996c91ecc8b628 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent42dd8b626b9547fc145306d1aabe035e58341662 (diff)
[RESTRICT AUTOMERGE]: Exclude secure layers from most screenshots taken by the system server.
In pre-P versions of Android, it was allowed to screenshot secure layers if the buffer queue producer which was the target of the screenshot was owned by the system (in this case SurfaceFlinger). This really was a synonym for: The screen rotation animation was allowed to capture secure layers, but the other code paths weren't. In O we mistakenly changed this check to always allow the system server to capture secure layers via the captureScreen path (the captureLayers path used for TaskSnapshots was unaffected). This can result in data leakage in cases where the system server takes screenshots on behalf of other parts of the system (e.g. for the assistant). To mitigate this we provide an explicit switch for the system server to specify whether it wishes to capture Secure layers. While this is dangerous, I think it is less dangerous than the previous implicit switch of capturing secure layers based on which type of BufferQueue was passed in. The flag defaults to not capturing secure layers and we set it to true in the one place we need it (for the screen rotation animation). Non privileged clients can still not capture secure layers at all directly. Test: TransactionTest.cpp#SetFlagsSecureEUidSystem Bug: 120610669 Change-Id: I9d32c5ac2b005059be9f464859a415167d9ddbd4 (cherry picked from commit dc49e0088a05108a0616704ca5565136f89c0a1f)
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions