1. PasswordMetrics now doesn't have 'quality', it is only used inside DPMS.
This allows easier and unambiguous comparisons.
2. Password complexity code reworked.
Future work: factor validation code into a android.app.PasswordPolicy class
to make PasswordMetrics just represent metrics. It is still used in two ways:
specifying an actual metrics and specifying a minimum metrics for comparison,
this will be addressed later.
Test: atest com.android.cts.devicepolicy.PasswordComplexityTest
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: atest FrameworksCoreTests:PasswordMetricsTest
Test: atest FrameworksCoreTests:PasswordPolicyTest
Test: atest com.android.cts.devicepolicy.ManagedProfilePasswordTest
Bug: 138375712
Change-Id: I8ad55f373712ac1dc8343f8cbae23ebb1efe78b9
for oems which take telephony mainline module, all telephony related
apks will be signed with non-platform certificate. that said apks won't
be able to grant platform signature permission. Solution is to add a new
telephony protection level.
Bug: 141479803
Test: cts & manual
Change-Id: Ib3be016080d42fd76e7c131f4e44d815ce431e6e
ResourceLoaders allow inserting another .apk/.arsc into AssetManager's
resource resolution search. The effect is similar to overlays,
where a entry of >= config later in the path list will return that
ApkAsset's resource value instead.
Because loading from an .arsc is supported, which doesn't contain
any actual files, ResourceLoader exposes loadDrawable and
loadXmlResourceParser to allow an application load those files from
anywhere or create them in code.
The data being loaded is either pushed into an .apk or .arsc that
mocks itself as the package being "overlaid" and is passed in
through ResourcesProvider, an interface with static methods that
supports loading from a readable path on disk or a FileDescriptor.
The APIs are accessed through a Context's getResources(), which
has been changed to be unique per "Context-scope", which is usually
the lifetime of the Java object. The exception is that Activities
who get their Resources object persisted across recreations
maintain that logic for persisting ResourceLoaders.
Bug: 135270223
Test: atest FrameworksResourceLoaderTests
Change-Id: I6929f0828629ad39a21fa155e7fec73bd75eec7d
Without it, apps (mainline modules) will need to use createPackageContext...,
which is a bit painful.
Bug: 142472686
Test: atest android.content.cts.ContextTest#testCreateContextAsUser
Change-Id: Id640e03862462724df1a4a3101f0b08faafba22f
Make TimestampedValue Parcelable for simplicity.
TimetampedValue objects are not generally parcelable, depending on the
type of the value held. Previously, TimestampedValue did not implement
Parcelable to avoid committing to a general contract. Developers
parceling TimestampedValue objects were expected to call
TimestampedValue.writeToParcel() / TimestampedValue.readFromParcel()
explicitly when they knew it was safe to do so. This also meant that
TimestampedValues couldn't be used directly via AIDL.
This change makes TimestampedValue parcelable because it's more
familiar / convenient. Attempts to marshall a TimestampedValue that
contains a non-parcelable value will still throw a RuntimeException.
Bug: 140712361
Test: atest android.util.TimestampedValueTest
Change-Id: I8ca9c72f0433b380ce720cd813f650e743b3ddae
The one messy internal caller is the settings provider, so a new @hide
API on PackageManager was introduced to decouple the provider from
LocalServices. That new entry point is only callable by uid 1000,
paralleling the previous system-caller-only availability.
Bug: 140833849
Test: system boots & runs normally
Change-Id: I93ae38b8f55db7864893a97795aea63014bf5e12
Allow the active supervision component to access app usage limit APIs.
This includes #registerAppUsageLimitObserver
and #unregisterAppUsageLimitObserver.
Bug: 138681869
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest#testIsActiveSupervisor
Test: atest AppTimeLimitControllerTests
Test: atest android.app.usage.cts.UsageStatsTest
Change-Id: I3daafc14ccdbf27558c1325b965f2bc6d2dab2f6
We were performing agent startup-attach during bind but this was too
late for some agents, as it occurred after Context was created. Change
implementation to make this occur prior to bind.
Test: atest CtsJvmtiAttachingHostTestCases
Bug: 142010970
Change-Id: I5f75e8b3c508116762b7863d9b47251d0e808ea9
* Wrap credential bytes and type into one single object.
* Update all external APIs dealing with lockscreen passoword
to use the LockscreenCredential class. Remove existing variants
that handles pin/password/pattern separately.
* Coerce password quality passed to LockSettingsService into one
of UNSPECIFIED, PATTERN, NUMERIC or ALPHABETIC (explained below).
* Update all clients & tests to interface with LockscreenCredential.
Note: LockscreenCredential distinguishes between PIN and password
in its public interfaces, this is to pave the way for the next
patch of formally introducing a CREDENTIAL_TYPE_PIN type and
getting rid of the requestedQuality being passed along (whose
sole purpose nowadays is to distinguish between PIN and password)
For now LockscreenCredential still uses the quality value internally
to make that distinction. This does result in a change to what
quality values LockSettingsService receives as part of credential
change: after this CL LSS will only see the quality being
one of UNSPECIFIED, PATTERN, NUMERIC or ALPHABETIC, while it used to
receive other qualities (NUMERIC_COMPLEX, ALPHANUMERIC etc) if device
admin sets a password policy. This shouldn't make any behaviour changes
though, because the new range of values is still sufficient to
distinguish between PIN/Pattern/Password, which is what the consumers
of the stored quality care about.
Bug: 65239740
Test: atest com.android.server.locksettings
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: atest com.android.internal.widget.LockPatternUtilsTest
Test: atest com.android.internal.widget.LockscreenCredentialTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password
Test: atest MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: atest MixedDeviceOwnerTest#testResetPasswordWithToken
Test: manually set an PIN/Pattern/Password; then change to
PIN/Pattern/Password; finally remove password
Test: manually create a work profile; try unify and ununify work
challenge.
Test: manually test lockscreen FRP flow (change password via Settings /
DPC)
Change-Id: I04cc04057c96292a7b1b672bff2a09d594ea9b3c
TaskStackListener can now know when
RecentTasks recents list has been
frozen and unfrozen.
Launcher needs this to know when to listen
for multiple swipe regions in quickstep
for apps with different orientations.
Fixes: 140116135
Test: Had Launcher be a consumer of new
listener and verified via logs and
debugger that it was sending the correct
callback when quickswitching apps.
Change-Id: I65fb92d2490c91837523b99563d4fef422dabb76
Add KEY_ALIAS_SELECTION_DENIED contant to flag that no private key alias has
been chosen in onChoosePrivateKeyAlias, but no KeyChainActivity selection dialog
should be presented to the user.
Bug: 136649900
Test: run cts --test MixedManagedProfileOwnerTest#testDelegationCertSelection
Change-Id: I9aeea7be0c2a6172ca054f91d49183c843ecfa6e
* changes:
Animate panel to transparent if profile is managed
17/n: Show credential UI if setDeviceCredentialAllowed(true) and no biometrics
16/n: Add PIN/Password
15/n: Allow Auth UI to start in credential UI
14/n: Animate to device credential UI when lockout occurs
13/n: persist device credential across configuration changes
12/n: Add LockPatternView for setDeviceCredentialAllowed(true)
11/n: Animate panel to full-screen when "Use Password" is pressed
Removing old confirm device credential logic
1. Implementing the new API for supporting multi-display.
SparseArray<List<AccessibilityWindowInfo>> getWindowsOnAllDisplays()
2. Modifying the documents of this API and its function is to get the window lists of
default display.
List<AccessibilityWindowInfo> getWindows()
Bug: 133279356
Test: a11y CTS & unit tests
Change-Id: Id4e874f43390bdf4196d106a44bbca18bf9fd1d6
* No longer need the embedded flag as of ag/9341444
* Instead of requiring the app to specify documentLaunchMode=always we'll
apply the relevant intent flags to force that behaviour
* Adds a new param to include a "fillInIntent" which can adjust the
flags on the PendingIntent.
Bug: 138325285
Test: manual with BubblesTest (removed the flags in the test app, things
should still bubble)
Test: atest NotificationManagerTest (needs CTS CL)
Change-Id: I08de491fc89d8182f2b2a7df95c985d8be847aab
getFinancialSms is not functional and not used today, thus
remove it to avoid future confusion
Bug: 138745655
Bug: 140908357
Test: atest android.telephony.cts.SmsManagerTest
Change-Id: Ib57d0fc189b6c894227894ee02b592f7ee46f22f
