Test: Unit tests pass. Creating a Notification with the Notify app allows access to rich media insertion via gboard, and inserted images show up in the Notify app upon sending.
Bug: 137398133
Change-Id: I65218dfaa083f7c24512430e647d8ca79058dff9
Input method frameworks uses focused window and some tricks
to best guestimate IME target. Though it doesn't always know the
actual IME target. e.g. when window has both NOT_FOCUSABLE,
ALT_FOCUSABLE_IM; IMF thinks focued window is IME target but it isn't
the case.
The right thing to do is to call both show(IME), hide(IME) on IME
target.
Bug: 142461756
Bug: 111084606
Test: Manually tested using steps below:
1. Make sure new insets flag is enabled
2. Launch any activity which has child window with NOT_FOCUSABLE,
ALT_FOCUSABLE_IM (e.g. Instagram login screen)
3. Verify IME can be shown and hidden by this window.
Change-Id: I13f3e04f6f9e1574db9cbb56bdb7817152499d03
This CL adds two new methods to the IPlatformCompat binder interface for
toggling multiple compat changes at once, and for clearing all the
overrides for a given package name.
Bug: 140367850
Test: http://aosp/1113771
Change-Id: I02d08d76e42da308856408dadc2c8c73c7ff20d1
Store the reported changes by app and clear the app info on app launch.
This means that changes reported to the system server would be logged
once per app launch instead of once per device boot.
Bug: 138374585
Test: flash device, run test app
Change-Id: I24f5dc125488c6af3164b6503f236bc3a24e6292
Merged-In: I24f5dc125488c6af3164b6503f236bc3a24e6292
Store the reported changes by app and clear the app info on app launch.
This means that changes reported to the system server would be logged
once per app launch instead of once per device boot.
Bug: 138374585
Test: flash device, run test app
Change-Id: I24f5dc125488c6af3164b6503f236bc3a24e6292
- Fix some bugs in how we compute association data.
- Add in overall time for an association, since you can't
tell that from the time of its individual sources.
- Fix issues in printing data filtered by package/process
to better select the data.
- Sort the association and source data by active time, so
the ones with the most impact are first.
- And sort associations by process so that in apps with
multiple processes (ahem GmsCore), you can tell what is
going on for each process separately.
Bug: 142283699
Test: manual
Change-Id: I504bd1a0614fce4f4410f3f53993af5cbd576b79
The <component-override> tag in sys config allows an OEM to configure
the enabled state of package components.
Eg.
<!-- Disable com.foo.bar.MyActivity -->
<component-override package="com.foo.bar">
<component class=".MyActivity" enabled="false">
</component-override>
The value in the sys config file overrides the value defined within
the package manifest.
Bug: 135048762
Test: adb shell pm resolve-activity
com.android.settings/com.android.settings.RegulatoryInfoDisplayActivity
Change-Id: I71de31601bb175d4be1cc5996142ef93ca279fc1
Sometimes, we have seen cases that 'set as default' feature does not work properly in ResolverActivity.
This issue occurs when an activity, with 'exported=false' attribute, is included in the list returned by PackageManager.queryIntentActivities().
By the logics in ResolverListController.java#getResolversForIntent(), the activity is removed from the list.
This creates a difference between the list that ResolverActivity sends to PackageManager when calling addPreferredActivity() and
the list PackageManager maintains. Due to the difference, PackageManager does not set preferredActivity requested from ResolverActivity,
which results the showing of ResolverActivity the next time with same action(even though user has set preferred activity).
To handle this issue, we recommend that the removal logic should be removed from getResolversForIntent() method
because it is already handled in ResolverListController.java#filterIneligibleActivities() through ActivityManager.checkComponentPermission() api.
As the result of that, the list which will be delivered to PackageManager is not changed.
Bug: b/135738126
Test: 1. Install 'JustDial' application via Play store
2. Try below command to launch ResolverActivity
adb shell am start –a android.intent.action.VOICE_COMMAND
3. Pick an item on ResolverActivity, then press 'Always' button
4. Repeat the second step again.
(you will see ResolverActivity comes again)
(cherry picked from commit 5cdfeeaca5516a6d64fa259f9a4ffd2955f8d2ab)
* 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
* 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
If the user is locked out of biometrics, and
BiometricPrompt#setDeviceCredentialAllowed(true), the user should be
shown the credential UI.
This change gives BiometricService the ability to request SystemUI
to show AuthCredentialView without first showing AuthBiometricView.
Bug: 140127687
Test: atest BiometricServiceTest
Test: atest com.android.systemui.biometrics
Change-Id: Ic26986ba044b7992641676c3d3b99fc1395a45b7
This way it can be turned on/off without a recompile, and checking the
flag doesn't require a context
Test: adb shell device_config put systemui notifications_use_people_filtering false && adb shell kill $(pid com.android.systemui)
Bug: 140232781
Change-Id: I8ba5e7809dc58e9493397db8447456601a398540
