It looks like one operation was done out of order and some of the times used in
the calculations were leading to incorrect results.
BUG: 31023263
Test: bit FrameworksCoreTests:com.android.internal.os.BatteryStatsDurationTimerTest
Change-Id: I417cc28c5a55748067b6c7f682a66fe3dbc09f09
This is needed for unbundling of OobConfig app.
Test: gts-tradefed run gts -m GtsGmscoreHostTestCases --test com.google.android.gts.devicepolicy.DeviceOwnerUserRestrictionTest#testDisallowOemUnlock_canSetWithSystemApi
Test: gts-tradefed run gts -m GtsGmscoreHostTestCases --test com.google.android.gts.devicepolicy.DeviceOwnerUserRestrictionTest#testDisallowOemUnlock_doCannotSet
BUG: 32974379
Change-Id: I7710df96006821a5d0eddfe0b411dd3efa0e10f0
Now that installd is throwing both SecurityException and
IllegalArgumentException, it's time that we turned all these
into InstallerException.
Also extend ServiceSpecificException to include the contained
errorCode value when printing.
Test: builds, boots, apps install/uninstall fine
Bug: 13758960, 30944031
Change-Id: Ic9c1e99ae87f4442402ef528bf352c7978572c85
UserManager.isUserUnlocked/isUserRunning/isUserUnlockingOrUnlocked now
return state from UMS.mUserStates that is pushed from ActivityManager.
Test: create managed profile using TestDPC and check Launcher3
Test: manually create unstarted managed profile and check launchers
Bug: 33232933
Change-Id: I6b619ba1880188eabdd6e3e4cc7eb60d3a22a977
When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
(cherry-picked from commit 58f27b5033)
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
Only the device owner will be able to set the restriction
and the restriction will prevent usage of Bluetooth on the
entire device - i.e. in all the users.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.UserRestrictionsTest
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest#testBluetoothRestriction
Bug: 32895300
Change-Id: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
Only the device owner will be able to set the restriction
and the restriction will prevent usage of Bluetooth on the
entire device - i.e. in all the users.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.UserRestrictionsTest
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest#testBluetoothRestriction
Bug: 32895300
Merged-In: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
Change-Id: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
UserManager.isUserUnlocked/isUserRunning now returns state from
UMS.mUserStates that is pushed from ActivityManager.
Test: manual
Bug: 33232933
Bug: 28957340
Change-Id: Ic5f56d7d577bc336acd2bf44fab7f74feac4f7b3
Follows the same marshalling scheme as other list types, such
as lists of Strings etc.
Bug: 30792387
Test: ParcelTest
Change-Id: I2003f4fcf4de5a1bee060f3c2723cfb155105b14
Developers regularly put content:// Uris into Intents, but they can
easily forget to add FLAG_GRANT_READ_URI_PERMISSION to actually
extend a permission grant to the receiving app.
Also fix NPE when path is missing.
Test: builds, boots, common actions work without triggering
Bug: 32447617, 31900890
Change-Id: Ic6054b1d73de50967cf7fe66abc293c60a41b97e
The CL adds FuseAppLoop internal class to the framework. It parses FUSE commands
from the proxy in the system service and invokes a callback provided by
application.
Bug: 29970149
Test: None, will be tested with CTS for StorageManager#openProxyFileDescriptor.
Change-Id: I10b2add4c2743fb91eae3cb194f55843a74fb668
Support a system property on debugable builds to
override the max number of managed profiles to
allow easier dogfooding of multiple profiles.
Support 3 different badge colours for managed profiles.
Bug: 30473760
Test: runtest -c com.android.server.pm.UserManagerServiceCreateProfileTest frameworks-services
Test: runtest -c com.android.server.pm.UserManagerServiceUserInfoTest frameworks-services
Test: manual - attempting to create 2 profiles with adb fails, passes once I set the property.
Change-Id: Ie7fb19048a04a01572666f229283152254d0ffc3
We know they will be ASCII, so use String.getBytes(US-ASCII) which is
much faster than creating a new ICU based CharsetEncoder for UTF-8 every time
we write one of these files (there will be a lot of them).
Test: make + manual.
Change-Id: I8eb62862ea1083e194d3f23ac68bb40aaae5efd5
