DUMP OF SERVICE Usagestats was empty in bugreports
because an unexpected -a argument was being passed.
adb shell pm dump <package> had a similar issue with --packages
Change-Id: Ic67c723b8edc74ec7c9c48582b08896ca3430a4a
Fix: 70777338
Test: adb shell pm dump <package> and bugreports now contain usage stats
When an app is on the top of the activity stack but the screen
is not on, this doesn't really count as a top app in the normal
sense. In particular, we'd really like to apply the normal
restrictions we have on background and cached apps: no network
access, no ability to use wake locks, etc. (In other words, in
this state the app's activity is stopped, so from its perspective
it is no different than the user leaving it to go to another app.)
To do this, we change the order of the TOP_SLEEPING proc state
out from the range of foreground states down to between the
cached and background states.
Test: ActivityManagerProcessStateTest
Bug: 70808931
Change-Id: I994caba8c27553a452de75efa358be0e683d046f
This allows us to generally treat heavy-weight processes in
the background as cached processes, applying all of the limitations
we want for such things -- disable wake locks, etc.
Test: run-am-test ActivityManagerProcessStateTest
Bug: 63937884
Change-Id: I7c140c8f48188f6aa9c09731e83e3db4e4405e77
Such wallpaper has to define supportsAmbientMode,
and set it to true on its android.service.wallpaper
meta data.
Also introduces WallpaperService.Engine#onAmbientModeChanged
to notify a live wallpaper that the display state has changed.
Change-Id: I49e846069a698b3cc3bb6e7cda98172920eaae4c
Bug: 64155983
Test: runtest -x frameworks/base/packages/SystemUI/tests/src/com/android/systemui/doze/DozeWallpaperStateTest.java
Test: runtest -x frameworks/base/tests/Internal/src/android/app/WallpaperInfoTest.java
Test: runtest -x frameworks/base/tests/Internal/src/android/service/wallpaper/WallpaperServiceTest.java
Test: set AoD wallpaper, go to aod, lock screen, launcher
Test: set regular wallpaper, go to aod, lock screen, launcher
It doesn't make sense to call it via parent instance.
Bug: 70788883
Test: cts-tradefed run cts -m DevicePolicyManager -t com.android.cts.devicepolicy.ManagedProfileTest#testParentProfileApiDisabled
Change-Id: I66334757ca8e9ee2525dbe88c83216563837aee6
Allows admins to blacklist passwords so they cannot be enrolled by the
user or the admin.
Test: bit FrameworksServicesTests:com.android.server.devicepolicy.PasswordBlacklistTest
Test: bit FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testPasswordBlacklist
Test: cts-tradefed run cts -m CtsAdminTestCases -t android.admin.cts.DevicePolicyManagerTest
Bug: 63578054
Change-Id: I8949ac929c760b66dc719cb058a9f88dc9cad727
Add a new method in the DevicePolicyManager to associate certificates (and
set the user-visibility) with a given key alias.
Conceptually, the new method, setKeyPairCertificate is very similar to
installKeyPair, except it does not install a key, only certificates.
(The new setKeyPairCertificate, together with generateKeyPair is
functionally equivalent to installKeyPair, except the keys are generated
in hardware rather than supplied externally).
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG
Change-Id: Idbfe151f6e5311766decbc1a010bff78dc60249f
CTS tests are now throwing security exceptions for accessibility actions.
This reverts commit 19eb58959b.
Change-Id: I2027ee4cca0fcc2b38bb615a58d992ef309e2d70
We've tried our best to protect against malicious storage devices
with limited SELinux domains, but let's be even more paranoid and
refuse to look at disks inserted while a secure keyguard is
showing. We'll gladly scan them right away once the user confirms
their credentials.
Test: builds, boots, manual testing
Bug: 68054513
Change-Id: I19b7446e855176921ed477ef6d07bc9a2cc0ef9a
Currently, process start is initiated in ActivityManagerService
holding the main lock and this takes ~40ms to complete. As seen
in some of the issues in previous releases, this is one of the
contributors of the lock contention in system_server. This change
tries to address this issue by moving the process start outside
the locked section.
When a process start is required, instead of doing it synchronously,
this request will be posted on a handler thread. On the handler thread,
this process start request will be completed without holding a lock.
If for some reason, we decide the process is not needed anymore before
it is actually started or being started, then AMS does everything as
usual removing the references to the process from internal state except
actually killing the process which will be handled on the handler
thread.
Bug: 68775202
Test: Ran app startup perf tests using forrest, will update the bug with results.
Test: https://docs.google.com/spreadsheets/d/1cW81guRALZXKsN-WZsKyQiCSY-RgkJ2m_M9IfqIquz8
Test: cts-tradefed run singleCommand cts-dev -m CtsActivityManagerDeviceTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWindowManagerDeviceTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsMultiUserHostTestCases
Test: adb shell am instrument -e package com.android.server.am -w \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -e class com.android.server.pm.UserManagerTest -w \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -e package android.content -w \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Test: cts-tradefed run singleCommand cts-dev -m CtsProviderTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsContentTestCases -t \
android.content.cts.ContentResolverTest
Test: cts-tradefed run singleCommand cts-dev -m CtsContentTestCases -t \
android.content.cts.ContentProviderTest
Test: cts-tradefed run singleCommand cts-dev -m CtsWebkitTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideWebViewTests
Test: cts-tradefed run singleCommand cts-dev -m CtsAssistTestCases
Test: make WebViewLoadingTests && make tradefed-all && tradefed.sh \
run template/local_min --template:map test=WebViewLoadingTests
Test: adb shell setprop wrap.com.google.android.apps.maps \
'"LIBC_DEBUG_MALLOC_OPTIONS=backtrace logwrapper"'
&& adb shell dumpsys meminfo --unreachable <PID_OF_APP>
&& check ppid of <APP> is logwrapper's pid.
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapNoDebugTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapDebugTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapNoWrapTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapDebugMallocDebugTestCases
Test: manual
Change-Id: I1fe7ce48cd5a4aadccaf6b3d6fdb5cad3304f1d3
Bug: 63907873
Test: manually tested that the app op is being logged for TalkBack and a 3rd party accessibility service. Ran UIAutomator-based tests to check that they work as expected.
Change-Id: I1a40d4ead52ba2258cc7ddc8be594a13895d8340
These APIs allow apps to know when they should be sending updates
to any given slice uri.
Test: update-api
Bug: 68378571
Change-Id: I4fa218c8d376692fa843f21777c87d592169a377
When DISALLOW_UNIFIED_PASSWORD is enforced by managed profile
owner, the user is disallowed to user single lock for both primary
user and the profile.
DMP.isUsingUnifiedPassword() can be called by DPC to check if
this restriction is obeyed.
Test: make cts-verifier
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
com.android.cts.devicepolicy.ManagedProfileTest#testIsUsingUnifiedPassword
Test: cts-tradefed run cts -m CtsAdminTestCases -t
android.admin.cts.DevicePolicyManagerTest#testIsUsingUnifiedPassword_failIfNotProfileOwner
Bug: 63909482
Change-Id: Ib758e32d4bf4012d805185bce874f481e17576ba
If the KeyGenParameterSpec passed into
DevicePolicyManager.generateKeyPair contains an attestation challenge,
request an attestation record for the newly-generated key with the
challenge provided.
This particular implementation was chosen, rather than letting the
attestation record be generated at the same time as key generation, to
avoid having the attestation chain stored in Keystore and associated
with the generated alias.
The rationale is that this is a key that is potentially accessible by
multiple applications and the attestation chain may end up being sent
as a TLS client certificate chain, for example.
As the attestation challenge should be unique per device, to avoid
the potential of sending / sharing unique device information, by
explicitly requesting an attestation record after key generation, the
attestation record is only returned to the generateKeyPair client and
not persistend in Keystore.
Bug: 63388672
Test: New CTS test to be run with: 'cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG'
Change-Id: I95a9aef179173b571b533301ac438c675e8fe702
- Rename varaibles holding LoadedApk to make the code easier to read.
- Move resource creation into LoadedApk, consolidating the logic.
Test: manual
Change-Id: I6bdc70482fbbb346ff694ada528ded18d3a63ef7
