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
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)
* 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
A side effect of CL topic r.android.com/q/topic:bug136256059_attempt2
was that the default MimeMap instance is now loaded eagerly (pre-fork)
regardless of whether any app process ends up using it, whereas
previously it was loaded lazily (post-fork) the first time an app
process used it.
This traded off CPU and memory use post-fork vs. pre-fork. Because it
isn't known / hasn't been proven whether and how many app processes
use that instance, the net CPU and memory impact is not known: if at
least one process makes use of a relevant API, the net impact will be
neutral or positive, or else negative.
Until this can be investigated and undergo system health review, this
CL topic changes the behavior back to post-fork lazy loading of the
default MimeMap instance.
Bug: 142019040
Test: Treehugger
Change-Id: I2a3f244240c51e7ada1f41a8abadb946ebcab40b
Another CL in this topic moves libcore.net.MimeMap to package
libcore.content.type. This CL updates associated references.
Bug: 136256059
Bug: 124232146
Test: Treehugger
Test: CtsMimeMapTestCases
Exempt-From-Owner-Approval: move affecting imports only
Change-Id: I30aac8b28a1740180ea01834a2bb66b61cb255d4
