ActivityManagerService#isAppForeground now checks if the caller has the
permission to view if an app is in the foreground.
Bug: 115384617
Test: cts-tradefed run cts -m CtsSecurityTestCases -t android.security.cts.ActivityManagerTest#testIsAppInForegroundNormal
Test: cts-tradefed run cts -m CtsSecurityTestCases -t android.security.cts.ActivityManagerTest#testIsAppInForegroundMalicious
Change-Id: I9602c89b2d40036e525c38960a08326dc74c6682
Make sure the number of entries written by Parcel#writeMapInternal
matches the size written. If a mismatch were allowed, an exploitable
scenario could occur where the data read from the Parcel would not
match the data written.
Fixes: 112859604
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest
Change-Id: I325d08a8b66b6e80fe76501359c41b6656848607
Merged-In: I325d08a8b66b6e80fe76501359c41b6656848607
Without this test, someone could trick us into constructing other
shady classes.
Test: builds, boots
Bug: 65281159
Change-Id: If678d0681708d1b0dcf056aa1133830ad3dbce31
Previously, the background timebases (of a Uid) were reset when the Uid
resets in the wrong place. This caused StopwatchTimer.reset() to have the timesbase's old value to keep
track of its mUpdateTime. The solution is to call TimeBase.init at the
start of Uid.reset(), instead of calling TimeBase.reset() at the end of
Uid.reset().
Bug: 62352334
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java
Change-Id: I23c886544e18f154fc226cc81c22c3ea70fb4c7e
This is a revert of change I414a16cde11e76ccc390e7a63a6803f5b402fe78.
As an additional safety latch, we bypass all logic (either wipe or
retain) if the eSIM has never been provisioned. An unprovisioned eSIM
cannot possibly have profiles - indeed, we don't show the "Wipe eSIM"
checkbox in this case - so there's no reason to tell the LPA to retain
them.
Bug: 63693573
Test: TreeHugger + factory reset local test
Change-Id: I1fea50db317388e81823bf1bd0977ffe787a05e0
The Subsystem power stats string in batteryStats dumpsys has an extra
newline that is causing PowerBug to skip the line when parsing the
history information.
Also, the string for subsystem power stats is missing a heading title
and has some redundant text
This commit fixes these format errors so powerbug can read and parse that
line successfully
Bug: 63447034
Test: Manual testing + Read the bugreport by historian and verify output
Change-Id: Idf971823dd5f769e653b4788b00fc025593d0d3d
Signed-off-by: Ahmed ElArabawy <arabawy@google.com>
Noted affected users for versions prior to Android O.
Staged at: go/dac-stage/reference/android/os/UserManager.html#ENSURE_VERIFY_APPS
Test: make ds-docs and output staged
Bug: 38024373
Change-Id: Ida80c2134bdd4013c7adabee778e8296039747a2
This seems to be causing users who elect not to wipe their eUICC on a
factory reset to end up on the eSIM slot after the reset instead of
the pSIM slot.
Bug: 63693573
Test: TreeHugger + factory reset local test
Change-Id: I414a16cde11e76ccc390e7a63a6803f5b402fe78
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
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
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
Bug: 29875093
Test: Run dumpsys meminfo -a, verify SwapPss adds up and is non-zero
for dalvik and native.
Change-Id: I79d0b6a59bf5f4e73f75f0b9540ec0fcc9e23b02
Add a new flag in the DevicePolicyManager so that we can Use
EuiccManager#eraseSubscriptions(PendingIntent) to erase all the carrier data
from eUICC chip if the user choose to "ERASE" from the Android device manager.
Bug: 37277944
Test: E2E
Change-Id: Ia78090a00d956c645725be4fd591e02ded8ec467
Causes too many GCs and related slowdowns.
Verified that assistant launch from holding down home button is now
faster than N.
Test: make and flash
Bug: 62769566
Change-Id: Ib0c1f7a45831b241d3376d1e56db3c6937913b1b
...can't hide themselves
Tune the policies for when we tell about apps running in the
background after their services have stopped.
- If it ran while the screen was on, the time we require for it
to be running is much shorter (a couple seconds) as well as the
time we tell about it having run (with another tunable for the
minimum time we tell about this).
- If it has only run while the screen is off and stops a sufficient
amount of time before the screen goes on (currently a second) then
we will not show anything when the screen goes on.
- If it stops when the screen turns on, we will make sure the user
sees about it for a short period of time (currently 5 seconds).
Also includes some improved debug output about handler message
queues.
Test: manual
Change-Id: Iab438410d7182b2dfe4f9c1cce7069b26b34834c
We normally prevent apps from allocating into the "reserved" cache
space, but this change makes an exception for an active camera app,
since the user is probably trying to capture an important memory.
This change only lets the active camera app clear up to half of the
reserved space, since we don't want to completely destroy the
experience of all other apps.
Test: manual app before/during/after active camera session
Bug: 38267830
Change-Id: Ie9e63884fb2638ca881e10b894629eea84601648
