There isn't much users can do to get app developers to care anyway, so
leaving this on just for apps with debuggable="true" should be
sufficient.
Bug: http://b/141754375
Test: treehugger
Change-Id: I3a796f9c4b9358fce499649c3f289e956ee9a97a
All callers of requestBugReport(enum) have been migrated to use
wrappers, so it's safe to switch the internal enum we use for bugreport
mode from ActivityManager constants to BugreportParams enum.
Note that in requestBugReport() we have been passing ActivityManager
constant enum for INTERACTIVE bugreport, when sending an intent to
Shell, where BugreportPramas enum was expected, but it worked fine
because they had the same value. We can stop relying on that.
Bug: 137825297
Bug: 141355059
Test: Interactive bugreports created successfully
Change-Id: I1ab5d471a6d5c70fcd201719eae90f820e17cb80
Only log once per change-package-state(resets every app launch if used
from within the app process).
Next: reset every app launch for server usage as well.
Test: using the test app.
Bug: 138374585
Change-Id: I5587f7138cf2cd8d144e88cf294e65c14bb32bfb
We want to allow wellbeing apps to suspend in managed profiles.
This requires changing the internal data design of package-suspend
state to allow more than one suspending package, each with their
own parameters, namely - dialog info, app extras and launcher extras.
Also, removed the restriction of using setPackagesSuspendedAsUser when a
PO/DO exists
Test: atest com.android.server.pm.PackageUserStateTest
atest com.android.server.pm.PackageManagerSettingsTests
atest com.android.server.wm.ActivityStartInterceptorTest
atest GtsSuspendAppsTestCases
Bug: 138812320
Change-Id: If1263142fc9e6687e95af9b8d71ba8eff0c0fae9
We will supply a default "http://" scheme for URIs without one to the
parser.
Fixes: 140887246
Test: manual verification
Change-Id: Ib580f13fb66885437f99d4935976708523a62d95
This is a violation of layering (LSS is considered a lower level
component than DPM) and source of deadlock due to lock inversion.
This change tries to remove most of the direct calls into DPM from
LSS. After this, there will only be a handful non-critical invocations
remaining:
1. DPM.reportPasswordChanged()
This is always called on a handler thread so it's OK (LSS does not
hold any hold while calling out). Consider this as a (asynchronous)
broadcast.
2. DPMi.reportSeparateProfileChallengeChanged()
This is now moved to the handler thread, similar to
DPM.reportPasswordChanged().
3. DPMi.canUserHaveUntrustedCredentialReset()
This is still a violation but it will soon be removed as we
remove the caching of syhnthetic password alltogether (deprecating
old resetPassword()). So I'll leave it for now.
Test: atest com.android.server.locksettings
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: atest MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: atest MixedDeviceOwnerTest#testResetPasswordWithToken
Bug: 37090873
Bug: 141537958
Change-Id: Ie44cb418ab255bd016c5dd448674beabd362b74c
We're wrongly showing the BigText content after ag/5928752
Fixes: 141446552
Test: post big text notification, look at lock screen
Change-Id: I02506a160afefb457f86eb00adccdaff44ddbd29
Introduce a new API to request use of individual attestation
certificate for attesting keys generated by the
DevicePolicyManager.generateKeyPair method.
It builds on existing device ID attestation capabilities in two ways:
(1) Eligibility check: Assuming similar privacy requirements for the use
of individual attestation certificates, enforce the same conditions
for using them as the conditions for requesting device identifiers
in the attestation record.
(2) Keymaster interaction: Passing the right Keymaster tag to the
attestKey call, which is easily done in AttestationUtils.
Bug: 136494773
Test: CTS test to be added.
Change-Id: Idb5cee66d986a521c17e1955532d0bfae66c035d
For admin apps targeting R+, throw when the app sets password requirement
that is not taken into account at given quality, e.g. when quality is set
to UNSPECIFIED, it doesn't make sense to require certain password length.
If the intent is to require a password of certain length having at least
NUMERIC quality, the admin should first call setPasswordQuality() and only
then call setPasswordMinimumLength().
Conversely when an admin targeting R+ lowers password quality, those
requiremnts that stop making sense, are reset to default values.
+ fix the behaviour of getPasswordMinimumLength to match the docs: only
admins with password quality >= NUMERIC should be taken into account.
Test: com.android.cts.devicepolicy..MixedDeviceOwnerTest#testResetPasswordWithToken
Test: com.android.cts.devicepolicy.DeviceAdminHostSideTestApi23#testRunDeviceOwnerPasswordTest
Test: com.android.cts.devicepolicy.MixedDeviceOwnerTestApi#testPasswordRequirementsApi
Test: com.android.cts.devicepolicy.MixedDeviceOwnerTestApi25#testPasswordRequirementsApi
Bug: 123562444
Change-Id: Id134a7918718e3b0a220caaf6c672df4238a062c
today telephonyRegistry lives in system process
this is intended to persists all telephony listeners when
phone process crash. Telephony today notify system server by
using AIDL APIs directly. Instead, we are exposing a proper API
surface: telephonyRegistryManager where only phone app and
carrier privileged apps are allowed to use APIs in
TelephonyRegistryManger to notify telephony related status update.
Bug: 140908357
Test: Build & Manaul
Change-Id: I1b750751148925b4a7bd94553318907654012fc1
Fixes: 141162306
When transitions have completed, the EnterTransitionCoordinator
is no longer needed, so should be cleared so that its references
can be released.
Test: ran code producing the leak
Change-Id: Ia049d88a45dc27b77fcf4ab58a444457a6b87f88
And also pre-grant it to all apps that currently get any storage
permission pre-granted
cherry-pick for qt-qpr1-dev Ib9f50d25c002036f13cf2d42fc4d1b214f20920c
Test: - straight cherry-pick
- atest SplitPermissionTest
Bug: 141048840,140961754
Change-Id: Ia2219639a2104965a382ffef647e5ebaa0f9d540
And also pre-grant it to all apps that currently get any storage
permission pre-granted
Test: atest SplitPermissionTest
m -j gts && gts-tradefed run commandAndExit gts-dev -m GtsPermissionTestCases --test=com.google.android.permission.gts.DefaultPermissionGrantPolicyTest#testDefaultGrantsWithRemoteExceptions
Manual testing:
All combinations of
- App targetSdk = 28 and 29 (and 22 for extra credit)
- App having the <uses-permission> tag for
ACCESS_MEDIA_LOCATION or not
- Upgrade from P->Q-QPR and from vanilla Q->Q-QPR
Further upgrade of targetSdk from 28->29 while on Q-QPR
==> All permission behavior should make sense. Sometimes there
are weird, but expected behaviors. Hence we need to
collect the results and then look at the unexpected ones.
See SplitPermissionTest for some tests I added for the
location-background permission which was split from
the fine/coarse-location permissions
Fixes: 141048840,140961754
Change-Id: Ib9f50d25c002036f13cf2d42fc4d1b214f20920c
* removed the defaults mentioned in PASSWORD_QUALITY_COMPLEX. now it
refers the reader to setPasswordMinimumXXX docs, where they can find
information about the default values.
* removed reference to password quality constraints from
setPasswordMinimumLength docs since it wasn't true and doesn't make
sense.
Test: compiles
Bug: 138922259
Change-Id: I0b31273846cfb3546d99bd27b1b0174de3d7425a
