Tweak AppComponentFactory.instantiateClassLoader() API to accept
ApplicationInfo as an argument instead of an independent getter.
Bug: 124800390
Bug: 111342996
Test: atest CtsClassLoaderFactoryPathClassLoaderTestCases
Test: atest CtsClassLoaderFactoryInMemoryDexClassLoaderTestCases
Change-Id: I4a4d5af842446a5060083c88a0ac5bec014c0c55
(it was accidentally being called twice due to a bad git merge)
Fixes: 125628737
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I260e33942855e7355fd531fb05baf699e9961a89
Clarify usage of Activity.onKeyLongPress(..). It is not obvious at
all that onKeyDown should be used in order for OnKeyLongPress to work.
Direct readers to the other api to make sure that this nuance is not
missed.
Bug: 21451760
Test: atest KeyEventInjectionTest
Change-Id: Ic73f6fe06b2108a3967ac590d22acfb283a700e1
To return current foregroundServiceType if the service has become a
foreground service.
If service become foreground service by calling Service.startForeground(int,
Notification, int type), the returned type is the type specified.
If the no-type version Service.startForeground(int, Notification) is called.
the returned type is foregroundServiceType specified in manifest.
If no foregroundServiceType specified in manifest, the returned type is
zero.
If the service is not a foreground service, the returned type is zero.
Bug: 124517685
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerProcessStateTest.java#testFgsLocation
Change-Id: Ibcc4431429a90aab92a5533e296fb104b4add9e6
* changes:
Changed Content Catpure workflow so it notifies when multiple changes are made.
Improved how Content Capture events are flushed when activity is resumed / paused.
Not sure about the car mode dialer and call companion app roles yet,
so leaving them out for now.
Bug: 125936031
Test: build
Change-Id: Ibe34256ea3c8c0514a7c97c641935c79c7da8d0d
Test: atest CtsContentCaptureServiceTestCases # which was updated to listen to the new events
Test: m update-api
Fixes: 125395044
Change-Id: Ie1ed5d9badaa64ff0921226a1c08bd5e3cbf07d8
We were flushing right after the activity resumed, but the relevant events (views added / removed)
were not generated yet, which made such flushes useless.
This CL changes the workflow to flush them after the ViewRoot finishes doing its work.
Test: atest CtsContentCaptureServiceTestCases
Bug: 125395044
Bug: 122315042
Change-Id: I05bf27069b00c285643b2d23ad6708a6ad7bc8f3
The initial behavior cop^H^H^H based on Autofill, which only closes the session when the activity
finishes. But for content capture we must always close the session when the activity is stopped.
Test: manual verification
Fixes: 125628737
Change-Id: I064d4ace97721dd8fb20075c02e1f059ecbf942a
Context
=======
The "time zone updates via APK" feature was implemented in O-MR1 to enable
devices to take time zone updates via an APK update and without needing
an OTA. RulesManagerService is an important part of the time zone updates via
APK feature. When RulesManagerService was implemented things were simple; there
was a copy of time zone data in /system. A new (optional) copy was introduced
in /data that could be managed / updated by the RulesManagerService.
Since there were only two copies the /system copy was referred to as the
"system" data.
With the introduction of the runtime APEX and time zone data APEX things
have become more complicated. Android devices can have time zone data in
several places:
1 The copy in /system/usr/share/zoneinfo/ is partially complete and remains
for legacy usecases, e.g. binaries that "know" about the /system path and
cannot be updated, or binaries which run before /apex paths are mounted.
2 The copy in /apex/com.android.runtime/ is a complete set of time zone
data that can be used by libraries on the device.
3 The copy in /apex/com.android.tzdata/ is the "overlay" copy for use when
the time zone data APEX can be updated. For devices that can take APEX
updates it will be present and is expected to start with the same version as
present in /apex/com.android.runtime. Note: Nothing in the code *requires*
this copy to be present but it is expected to be present in most cases.
RulesManagerService is being kept around for devices that may not have the
capability of updating their APEX files but which still want to update time
zone data without taking an OTA. It is assumed that RulesManagerService will
*only* be turned on in these situations and *not* when the time zone
data in /apex/com.android.tzdata/ might actually be updated independently of
the copy in /apex/com.android.runtime/.
The RulesManagerService therefore adds the fourth copy of the data that *could*
be present:
4 The copy /data/misc/zoneinfo/ managed by RulesManagerService.
Important libraries / binaries on device know about all 4 copies and
prioritize them in order 4, 3, 2, 1. i.e. the libraries will use the
first copy of data found in that order.
In scenarios where RulesManagerService is disabled, 4 will not be present
and therefore 3 will be used (or 2 if 3 is also not present).
In scenarios where RulesManagersService is enabled, 4 is present iff an
APK update has been received. It is assumed that *if* /apex/com.android.tzdata/
is present, it contains the same version of tz data as in
/apex/com.android.runtime/, will never be updated, and can therefore
be ignored by RulesManagerService.
The changes
===========
This commit and others in the same topic do the following:
1) Change RulesManagerService references to "system" data to "base" data in a
valiant attempt to limit confusion until it can be removed.
2) Switch RulesManagerService over from using the data in
/system/usr/share/zoneinfo/ as base data to the data in
/apex/com.android.runtime/. As part of this change, the RulesManagerService
can now use the tz_version file to identify the version of tzdb in "base"
rather than reading the header of the tzdata file, so that is done
here too.
3) Update imports neccessary to meet pre-upload check requirements.
Note: tzdatacheck, an independent binary that manages time zone data
after OTA, was updated to use /apex/com.android.runtime/ instead of
/system/usr/share/zoneinfo/ in commit c6a2737e0861472d1726ed472708d7762ab1e802.
Bug: 119293618
Bug: 113373927
Test: atest FrameworksCoreTests:android.app.timezone
Test: atest FrameworksServicesTests:com.android.server.timezone
Test: CTS: run cts-dev -m CtsLibcoreTestCases -t libcore.libcore.timezone.ZoneInfoDBTest
Test: CTS: run cts-dev -m CtsLibcoreTestCases -t libcore.libcore.icu.TimeZoneIntegrationTest
Change-Id: Idabe245c7ad337938c202b1796ce9d89ec68bbd6
After ag/5760456, we can remove the parameter secondaryDisplaysShowing
since it becomes meaningless.
Fix: 123373363
Test: atest ActivityManagerMultiDisplayTests
atest ActivityManagerDisplayKeyguardTests
atest ActivityManagerDisplayLockedKeyguardTests
atest KeyguardTests
Change-Id: I5ab5753985bc570bb730b4c7f801cdc263cc1858
This is much slower than the old way as we need to call into a different
process. On the other hand this handles the following cases correctly:
- foreground / background permissions
- pre-M apps
- split permissions
Test: CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testPermissionGrant,testPermissionPolicy,testPermissionMixedPolicies,testPermissionAppUpdate,testPermissionGrantPreMApp
Change-Id: I5cd139ad29e5b77b77b02e12c75eb774984a7759
Bug: 124128308
- Allow an app to change policy_fixed permissions
- Disallow apps >= Q to change the polic_fixed flag
Bug: 124128308
Test: Changed permissions that were policy_fixed
Change-Id: Ia94bae1b993bd8a18c93f866df2114c740fa17bd
Added a new test method to allow the client to wait until input windows
have been propagated to InputFlinger before proceeding to inject input.
This ensures that the inject is called when all windows have been set
up.
Bug: 123041491
Test: ListPopupWindowTest, PopupMenuTest
Change-Id: I42abfa4ea23a14ae1a003c6ee8976cc466f1d5af
Relating to frameworks/base
Bug: 120484642
Test: manual - test setting and unlocking passwords/pins/patterns.
automated - about 20 failing due to an issue in the test code.
Change-Id: I57aa530ca2db1a026c56b66f5b4c91172f2667f6
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Merged-In: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
Prior to this CL we were just caching whether the service supported compatibility mode for the app,
but now we're also caching the logging level and whether the app is whitelisted for augmented
autofill - although right now the augmented autofill info is not used, it will allow us to trigger
it in the scenarios where autofill is disabled for the app.
Bug: 123099842
Bug: 123100824
Test: atest CtsAutoFillServiceTestCases:AugmentedLoginActivityTest \
CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest
atest CtsAutoFillServiceTestCases # sanity check, although still flaky
Change-Id: Iaf8ea6634ca94e5e61131890ec17c96c2fbb329a
Priv-app can use it to enable / disable AppDetailsActivity of an app
Bug: 124378857
Test: Able to compile
Change-Id: I3122d7c1a18362cecdcea17b14d21b7c0ce12754
Content Capture for an activity and/or package is only available when the Content Capture service
explicitly whitelists it. As the whitelist is kept at system-server level, it's better to fetch that
info when the application is started and cache it locally, so we can optimize the
ContentCaptureManager APIs to return quickly when it's disabled.
This CL also caches other values such as the buffer parameters.
Test: atest CtsContentCaptureServiceTestCases
Bug: 120494182
Bug: 121202151
Change-Id: I9d5211bca496ffa85ba9efc2a7bb32411834b787
