Currently, netd is the only source of tethering statistics.
In order to support multiple sources, define a new
ITetheringStatsProvider interface that can be registered with
NetworkManagmentService. Convert the existing code into the
first ITetheringStatsProvider.
Bug: 29337859
Bug: 32163131
Test: builds, boots
Test: tethering stats continue to be collected
Change-Id: Ie1b5a5e47ae4bf5af922365b09fa241e834236e4
Adds an option to dumpheap that calls mallocInfo and write the xml produced
to a file.
Bug: 36871013
Test: Run am dumpheap -m <FILE>, am dumpheap -n <FILE>, am dumpheap <FILE>
Test: and verified that they produce the correct data.
Change-Id: Ifb9e878ea621c7cacc3aa6e3a889c414681dee2d
Factory reset of eSIM failed due to the euiccWipeFinishReceiver cannot
be registered by the context directly. This CL changes the context to
application context to solve this problem.
Bug: 63610700
Test: E2E
Change-Id: I7e4c8b75b5b5b4203efd7302677ffa5cf00198b5
This CL reverts the implementation of eSIM factory reset in
MasterClearReceiver and uses RecoverySystem#rebootWipeUserData to erase
eSIM data. Besides this, when the eSIM data isn't erased, we should call
EuiccManager#retainSubscriptionsForFactoryReset to let the fastboot know
that.
Bug: 62957212
Test: TreeHugger
Merged-In: I08ab9d53ec4fc73a65e8e7d0c39ac95b2d44d012
Change-Id: I08ab9d53ec4fc73a65e8e7d0c39ac95b2d44d012
This CL reverts the implementation of eSIM factory reset in
MasterClearReceiver and uses RecoverySystem#rebootWipeUserData to erase
eSIM data. Besides this, when the eSIM data isn't erased, we should call
EuiccManager#retainSubscriptionsForFactoryReset to let the fastboot know
that.
Bug: 62957212
Test: TreeHugger
Change-Id: I08ab9d53ec4fc73a65e8e7d0c39ac95b2d44d012
This will be caught by surrounding code and will result in an
abort that will contain details of the exception + the associated
state of each thread. Catching the OOME in this manner is
counter-productive because we're immediately allocating inside the
catch, which is likely to cause more problems (and obscure the original
exception) unless there was an intervening GC.
Bug: 62514767
Test: make
Change-Id: I5a17707036c832d65480f18989faaf6747a29877
When using a reference-counted wakelock together with a timeout, we
can end up with an over-released wakelock which causes an app crash.
To mitigate this, only throw based on count of external
acquire/release events.
Bug: 62326550
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.PowerManager_WakeLockTest
Change-Id: I66480cb9798f9404ae3d45a70d68eae136d289de
When we have trouble pushing a saved instance state Bundle out of
a process, log high-level statistics to help narrow down where bloat
is coming from.
Bug: 62409379
Test: builds, boots, stats logged
Change-Id: Iaff01eaf31ff0fd4d0fde3da15e9526dac559af9
Before this change, ZygoteProcess.preloadPackageForAbi returned
as soon as the command was written to the zygote socket and not
after the preload completed. This meant that there was a small
window of time before the server side of the socket polled its FDs
where a second command could be written to the zygote socket. This
would lead to only one of the commands being processed and the
other being dropped. The client side of that socket would then wait
forever for a response and bring down the system once the watchdog
timeout was hit.
Example failure case :
--------------
system_server：send command(preloadPackage)
system_server：send command(fork)
zygote：poll & process command(preloadPackage) // the fork command is dropped.
Example of normal operation :
------------------
system_server：send command(preloadPackage)
zygote：poll & process command(preloadPackage)
system_server：send command(fork)
zygote：poll & process command(fork)
This change makes preloadPackageForAbi synchronous, which ensures
that each POLLIN event corresponds to precisely one command.
Bug: 62886909
Bug: 13618569
Test: Manual
Contributed-By: yuqianyu@huawei.com
(cherry-picked from commit 24a3306c32)
Change-Id: I83faf974c9a70a6ab18323f692c1981784e4c56a
Before this change, ZygoteProcess.preloadPackageForAbi returned
as soon as the command was written to the zygote socket and not
after the preload completed. This meant that there was a small
window of time before the server side of the socket polled its FDs
where a second command could be written to the zygote socket. This
would lead to only one of the commands being processed and the
other being dropped. The client side of that socket would then wait
forever for a response and bring down the system once the watchdog
timeout was hit.
Example failure case :
--------------
system_server：send command(preloadPackage)
system_server：send command(fork)
zygote：poll & process command(preloadPackage) // the fork command is dropped.
Example of normal operation :
------------------
system_server：send command(preloadPackage)
zygote：poll & process command(preloadPackage)
system_server：send command(fork)
zygote：poll & process command(fork)
This change makes preloadPackageForAbi synchronous, which ensures
that each POLLIN event corresponds to precisely one command.
Bug: 62886909
Bug: 13618569
Test: Manual
Contributed-By: yuqianyu@huawei.com
Change-Id: I83faf974c9a70a6ab18323f692c1981784e4c56a
In both battery stats and job scheduler statistics, keep track of
the reason jobs are ending. This can help to identify apps that
are having bad behavior with jobs (in particular, regularly timing
out their job instead of finishing it when done).
Test: manual
Change-Id: Icc12d5e0dc0df1906716e7d995c56d50a9fa148a
SharedMemory is parcelable and AIDL friendly
and exposes cool things like dropping write permissions
that are useful for shared memory to have.
Also exposes getFileDescriptor() on MemoryFile
since that was necessary to use MemoryFile
with IPC previously and there are a sizeable
number of reflections that access it, so just make
it public.
Test: SharedMemory CTS tests pass
Change-Id: I71a322abf2eb55267d7299a8e41f847339af8b08
Apps with a normal UID are typically isolated enough to not require
socket tagging; we're mostly interested in tracking down internal
UIDs that have lots of code sharing the same UID.
Also fix up everyone doing manual string checks of Build.TYPE, since
we now have first-class fields for those.
Bug: 38126076
Test: builds, boots
Change-Id: I3a40348196bd8459289f2b9355d9783a07f1e7dd
