See go/UnsupportedAppUsage for more details.
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 137350495
Test: m
Change-Id: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
This commit was reverted in Q because it broke things, but we want it in
master.
This reverts commit c36d0765a25d4701980738dc3e2053f19eb3d6b8.
Change-Id: I809d9191eee4909d265d2864ebd523f262f6bb61
Test: treehugger
Don't rely on the GC to clean up FD resources when they can
just be cleaned up immediately. We know the MemoryFile isn't
going to be used any further, so just close it.
Bug: 138323667
Test: Repro steps in bug. Verified addresses FD leak in system_server from repeatedly opening & closing settings.
Change-Id: Ic82006c9cb48f580aaad942c4679e774186382c9
Bug: 138422309
This reverts commit 390d9e6a18.
Reason for revert: crashes documented in b/138422309
Change-Id: I235f727d0fe87c09f6f05dddcae7759bab64dfd8
Bug: 138422309
This reverts commit 20ab1e3427.
Reason for revert: crashes documented in b/138422309
Change-Id: Ic9e33fdb24bad2b30f0eb357d6752c1834df41d5
We run the Cleaner in close, but after the fix in commit 6ca916a6, this
no longer clears the value stored in the FileDescriptor, which means
that subsequent operations on an explicitly closed SharedMemory will
operate on a bogus fd number. Clearing the FileDescriptor value in close
is sufficient, because Cleaner.clean is idempotent, and the only other
case where it executes is when the FileDescriptor is phantom reachable,
which means no one can access it to get its integer value.
Bug: http://b/138392115
Bug: http://b/138323667
Test: treehugger
Change-Id: I8bdb4c745466532a0712976416184c53fcf0dbf6
(cherry picked from commit a7641806dd)
We run the Cleaner in close, but after the fix in commit 6ca916a6, this
no longer clears the value stored in the FileDescriptor, which means
that subsequent operations on an explicitly closed SharedMemory will
operate on a bogus fd number. Clearing the FileDescriptor value in close
is sufficient, because Cleaner.clean is idempotent, and the only other
case where it executes is when the FileDescriptor is phantom reachable,
which means no one can access it to get its integer value.
Bug: http://b/138392115
Bug: http://b/138323667
Test: treehugger
Change-Id: I8bdb4c745466532a0712976416184c53fcf0dbf6
Previously, the Cleaner we create to close the ashmem file descriptor
used a thunk that held a strong reference to the FileDescriptor we
wanted to clean up, which prevented the Cleaner from ever running.
Break the cycle by storing the integer value of the file descriptor
instead.
Bug: http://b/138323667
Test: treehugger
Change-Id: I613a7d035892032f9567d59acb04672957c96011
(cherry picked from commit 6ca916a657)
Previously, the Cleaner we create to close the ashmem file descriptor
used a thunk that held a strong reference to the FileDescriptor we
wanted to clean up, which prevented the Cleaner from ever running.
Break the cycle by storing the integer value of the file descriptor
instead.
Bug: http://b/138323667
Test: treehugger
Change-Id: I613a7d035892032f9567d59acb04672957c96011
- isHeadlessSystemUserMode() returns whether the device is running with
headless system user (go/multi-user-headless-user0)
- RoSystemProperties.MULTIUSER_HEADLESS_SYSTEM_USER is replaced by
isHeadlessSystemUserMode()
Bug: 137755681
Test: Bluetooth service and Network policy manager should work fine with
headless system user. A profile user should be created with headless
system user.
Change-Id: Ic48d98426f7a5ea47dde2008ae51f78855f622e6
