Note that with the new Bugreporting API, SystemServer is the only
expected DumpstateListener implementation. Once we fully migrate Shell
app, we can remove the implementation in BugreportService as well.
BUG: 128980174
Test: bugreport from power menu, observe progress bar
Change-Id: I40d654a70bd9ceb3a29f8a0113b85616100f4ee9
Merged-In: I40d654a70bd9ceb3a29f8a0113b85616100f4ee9
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
Due to the restriction of Treble, update_engine cannot access to OTA
packages located on non-core domain area.
(e.g. /data/vendor/upgrade/xxx.zip)
To solve such problem, update_engine needs to accept a file descriptor
(FD) of OTA package file instead of its URI. Accordingly, UpdateEngine
also needs to add a new interface of applyPayload which accepts FD.
Test: Manual update
Bug: 130209137
Change-Id: Ic924445c4abf27fd7dc111c74b972ac7ff9ffa6b
