We currently specially handle the HotwordDetectionService uid in
AppOpsPolicy. But CheckOpsDelegate doesn't currently include finishOp,
so that doesn't work for the hotword service. This change adds finishOp
to the interface and implements it in AppOpsPolicy to be consistent with
the other ops.
Bug: 190011174
Test: manual - no error in logs for finishOp
Test: manual - privacy indicator works as expected (with another wip
change)
Change-Id: I77907092a917362aacd0d5562e54abd6f3c3d47b
If the IME is bound with capabilities it is considered to be in use by
the user so when they attempt to open the mic or camera we show the
dialog to renable.
Test: Disable microphone and use gboard
Bug: 187154145
Change-Id: Icf8d91f2a2b97068852c1b98d36916c07c42d3fa
Previously we use cache to store value returned from
DisplayManagerGlobal#getAdjustedDisplay(int, DisplayAdjustments)
in RM#getAdjustedDisplay(int, DisplayAdjustments).
Since RM#getAdjustedDisplay(int, DisplayAdjustments) is just
used in RM#getDisplayMetrics(int, DisplayAdjustments), we can
furthur call getDisplayInfo(int) from DisplayManagerGlobal and call
DisplayInfo#getAppMetrics to obtain DisplayMetrics directly.
Also, #getDisplayInfo has binder cache, so we don't need another cache
to store returned DisplayMetrics value from DisplayManagerGlobal.
Before this CL
[1/1] android.app.ResourcesManagerPerfTest#getDisplayMetrics: PASSED
(10.844s)
getDisplayMetrics_median: 1840
perfetto_file_path:
/sdcard/test_results/android.app.ResourcesManagerPerfTest_getDisplayMetrics/PerfettoListener/perfetto_android.app.ResourcesManagerPerfTest_getDisplayMetrics-1.pb
getDisplayMetrics_mean: 1857
getDisplayMetrics_min: 1817
getDisplayMetrics_standardDeviation: 35
After this CL,
com.android.perftests.core (1 Test)
[1/1] android.app.ResourcesManagerPerfTest#getDisplayMetrics: PASSED
(11.185s)
getDisplayMetrics_median: 733
perfetto_file_path:
/sdcard/test_results/android.app.ResourcesManagerPerfTest_getDisplayMetrics/PerfettoListener/perfetto_android.app.ResourcesManagerPerfTest_getDisplayMetrics-1.pb
getDisplayMetrics_mean: 733
getDisplayMetrics_min: 725
getDisplayMetrics_standardDeviation: 5
Test: atest android.app.ResourcesManagerPerfTest#getDisplayMetrics
fixes: 191662456
Change-Id: I934ecae19431800a9a4e0f3e3821e80ef4b5d8cf
In R, when overlay changes a configuration change event is triggered
within the app process affected by the overlay change immediately
after updating the overlay paths of resources objects. All activities
would be relaunched after the configuration changed occurred resulting
in activity life-cycle events occurring for activities running in the
background. Apps may assume that onResume is invoked while they are in
the foreground so we made a fix that triggered the activities to be
relaunched when they are brought to the foreground.
The fix involved storing the asset sequence in the AMS and triggering
a configuration change from the AMS for each process affected by the
overlay change. This created problems where the app may receive a
configuration from the AMS with an updated asset sequence before the
event to handle the application info changing actually updated
resources objects. This resulted in reinflating views with the updated
configuration before the overlays were updated in the underlying
resources objects.
This change allows allows RM to apply changes to application infos when
it sees the asset sequence increase during a configuration change,
rather than having to wait for handleApplicationInfoChanged to run.
Bug: 189100984
Test: toggle wallpaper and observe QS has correct colors
Test: launch an app, navigate away from the app, change wallpapers, and
observe app is relaunched and has correct colors when resumed
Change-Id: Icf81845da9890cda0fb38cf6fe51d1d66e5ea840
Enforce the permission check for both INTERACT_ACROSS_USERS and
PACKAGE_USAGE_STATS permissions.
Bug: 191382775
Test: atest CtsUsageStatsTestCases:UsageStatsTest
Change-Id: I1371070478306005b2b4a59a1bc794bc368ae0c4
Add a historical flag to signify that attribution chains should be
assembled. Assemble the chains, filter out middle nodes, and attach the
last visible node to the start as a proxy info
Bug: 158792096
Test: manual
Change-Id: I8fbd8f438c62b28fd90039440e86224c624dea79
All populations were being set to 0, causing all colors to be wrong.
Test: manual
Bug: 191391779
Bug: 191374703
Change-Id: Id5bef180ca3e6f30e30631781a74b2efb4402ac5
When a context is requested through Context#createApplicationContext,
the underlying LoadedApk cached in ActivityThread#mResourcePackages is
updated using the ApplicationInfo passed in. This creates unexpected
problems when using APIs that expect to be able to read resources from
a previous version of a package after that package has been updated.
With this change, contexts requested through
Context#createPackageContext and Context#createApplicationContext will
will have an underlying LoadedAPK that is tied to the version of the
package represented by the ApplicationInfo. If createPackageContext
is invoked before a package updates and then after a package updates,
the two contexts will have different underlying LoaddApks.
The ActivityThread#mPackages and ActivityThread#mResourcePackages now
only hold LoadedAPKs of that were created using ApplicationInfos that
were sent to this process from system_server in order to run the
application. Whenever a newer version of an ApplicationInfo is
delivered from system_server for one of these packages, the previously
cached LoadedAPK will be updated using the new ApplicationInfo. This
will usually be because of an overlay change or "don't kill" package
upgrade.
Bug: 188059515
Test: atest FrameworksCoreTests:ContextTest
Change-Id: Iea54abf38449c9d8ab9dae16d36d95cbb4d7d8b0
After the introduction of the uses-native-library tag,
sharedLibraryFiles might contain native library names such as
"lib_aion_buffer.so". The old method makePath in the LoadedApk class was
looking for APK paths under the assumption that all the paths in
sharedLibraryFiles are APK paths. Parsing on the results of makePaths
could lead to app crashes because the results are not valid APK paths.
This CL fixes that.
BUG: 190787130
Test: manual
Change-Id: I2b3d439f8edda7ef27e1106046cf8c0b88d755d9
Bug: 186778818
This makes two changes to PropertyInvalidatedCache.
1. disableLocal() now disables all current and future caches that use
the same name (not the necessarily the same property) , in the
local process. Previously, disableLocal() only disabled a single
cache instance, but the intent was always to disable all instances
of the same cache in the process.
disableInstance() is available with the old behavior.
2. A bypass() method has been added. If bypass() returns true,
query() will skip the cache and go straight to the binder call as
though the cache had been disabled. The default implementation
always returns false. Caches can override the implementation to
avoid caching selected queries.
These changes specifically address the problem of caches that are
created dynamically and which should be disabled in the local
process.
A unit-test is added for PropertyInvalidatedCache. This is not a
complete test because test processes are not allowed to set system
properties. The unit-test will be improved in the future by modifying
PropertyInvalidatedCache to use an invalidation mechanism other than
system properties.
Manual test: boot a phone with a baseline build and with the build
under test and verified that the list of disabled caches is the same.
Use 'dumpsys cacheinfo' to get the cache status.
Test: atest
* FrameworksServicesTests:UserManagerServiceCreateProfileTest
Change-Id: I9f604b872911290e4e3d8a58b3e28e328b2000a9
Fix an issue in existing implementation where the API will
throw exception when called on a device without DO or PO: a
slight tweak of semantics such that when the API is called by
a regular app, return the device-wide policy regardless which
user the caller is from.
Bug: 190024751
Test: manual with modifed TestDPC on unmanaged device.
Change-Id: I227d01ec275bc0a074a3789bab194c76fc72b5b8
There could be more than one authority in a published provider.
Make sure the waiting acquireProvider() calls are notified
for each of the published authorities.
Fixes: 186333995
Test: atest MultiAuthorityTest
Manual: Start a work profile app while work profile is stopped
Verify that the app starts faster than the 20 second
timeout for acquireProvider()
Change-Id: Iaad58949debeead6ea477aa440b13ba4ddc1198e
Do not assume mMainColors and mAllColors contain the same
color since recent changes modified that.
Update equals and hashCode as well to account for this.
Bug: 191391779
Bug: 191374703
Test: atest WallpaperColorsTest
Change-Id: I8c7775055a2360ec3a91cee76a42d14a143ec7fb
DevicePolicyManagerInternal is not set when the device doesn't have
the device_admin feature, but some methods are still needed in that
scenario (like notifyUnsafeOperationStateChanged() on automotive).
Fixes: 190395562
Test: manual verification
Test: atest FrameworksServicesTests:DevicePolicyManagerTest FrameworksServicesTests:DevicePolicyManagerServiceMigrationTest
Change-Id: I48271b828ff01c4e4f3e0365410a7a745f1b0a1d
For provisioned device
- Remove the check for the current user is the same as the primary user
- Check for whether the caller is device owner and the current user is
affiliated with the device
Bug: 185426804
Test: manual test with AAOS build with device owner setup and request
bugreport from TestDPC
Change-Id: I78066979fd54b480433ef9ba5144ca666c601591
This reverts commit 90153d67e0.
Reason for revert: Temporary fix no longer needed; this was only added until an updated prebuilt for the referenced package was merged
Bug: 171506470
Test: none
Change-Id: Ibd3fec1d2ecd505693b4cf89ee8323eb8a50a604
Starting with API level 31, the subscriberId is applicable
for the wifi network. Considering applications may use
null or an empty string as subscriberId (for instance, cts),
frameworks create MATCH_WIFI_WILDCARD NetworkTemplate when querying
wifi network with null or an empty string which is the behavior before
API level 31.
Bug: 188915450
Test: atest -c NetworkStatsManagerTest
Test: atest -c NetworkUsageStatsTest
Merged-In: I084b69903f8ba7a6225b312560752e8508938714
Change-Id: I084b69903f8ba7a6225b312560752e8508938714
After changing the default behavior of the back button in S, we should
update the javadocs to reflect the change.
We also make a recommendation for developers to call through to the
super implementation to maintain consistency in navigation patterns
throughout the platform, especially for things like splash screens.
Bug: 186142540
Bug: 188832670
Test: None
Change-Id: I1c71250b26bec743be15f4ac95965ef046dcf4f3
We used to register the DexLoadReporter after the main class loader
was created. That was done to avoid superfluous reports of the app's
primary apks (since we already know about them).
However that also means that if the app would start as an isolated
process we would miss this signal in the DexManager.
Make sure we get signals for isolated processes by registering the
reporter before we create the main class loader.
Test: manual, using chrome and maps go
adb shell cmd package compile -m speed-profile com.android.chrome
adb shell am start -n \
com.google.android.apps.mapslite/com.google.maps.lite.twa.MapsLiteTwaLauncherActivity
adb shell dumpsys package dexopt
(confirm that chrome is used by an isolated process)
adb shell cmd package compile -m speed-profile com.android.chrome
(confirm that chrome is speed compiled - or verify, based on the device
setting)
Bug: 163018062
Merged-In: I5d683ae85b3973cc2011dd33b4cb14837b18005f
Change-Id: I5d683ae85b3973cc2011dd33b4cb14837b18005f
(cherry picked from commit 875888eff3)
The permission SCHEDULE_EXACT_ALARM state changes at the following
boundaries:
1. App-op: This gets toggled by the user via Settings.
2. Deny-list: Packages can be added to the deny list via DeviceConfig
APIs.
3. Package changes: A package's manifest may changes when it gets
updated.
In both cases 1 and 2, if alarm manager detects a permission change
from revoked to granted, it sends the
ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED broadcast to the
app.
If it detects a permission change from granted to revoked, it kills
all the processes within the hosting uid.
In all three cases, when the permssion changes from granted to revoked,
all the exact alarms scheduled by the relevant package are removed.
Package updates are treated differently as they require processes to
restart anyway. The broadcast is not needed in this case as there
are no alarms expected to have been lost by a previous revocation, and
apps can always use ACTION_MY_PACKAGE_REPLACED for post-update setup as
usual.
All this only applies to packages that have the change
REQUIRE_EXACT_ALARM_PERMISSION enabled.
Also changed canScheduleExactAlarms to return false if the change is not
enabled for the calling package.
Test: atest FrameworksMockingServicesTests:AlarmManagerServiceTest
atest CtsAlarmManagerTestCases
Bug: 179541791
Bug: 187206399
Change-Id: Icd68275701f2804be65b3a10a7dd81bbf6e2a0bb
