* 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.
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
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
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
This change dispatches TaskInfo directly for some methods
which currently only pass taskId. This eliminates the need
for second binder call to search for the TaskInfo.
See also: ag/6306456
Bug: 124058588
Bug: 123631242
Test: atest WmTests:TaskStackChangedListenerTest
Change-Id: I2e4c458f2a1ae684ef8d9f6a4ab2fbcfe13570b5
"adb shell svc system-server wait-for-crash" will block until the process dies.
Bug: 124022170
Test: Manual
- Run "adb shell svc system-server wait-for-crash" on multiple terminals
- Make sure open FDs aren't increasing by checking /proc/`pid system_server`/fd
- adb shell killall system_server
- All the "adb shell svc system-server wait-for-crash" should finish.
Change-Id: I203d001cd296d506ebf9f5a70b97e05e5769961a
Change the exitFreeformMode to toggleFreeformMode. Now the original
maximize button will work as maximize/restore button.
Test: go/wm-smoke
Test: Manual test.
Bug: 117075771
Bug: 124475503
Change-Id: I268d053ed0e665b8ac5e56019c6ae8f8b7ee1317
This CL should fix application startup regression for Vulkan
detected by "Hermetic Startup: EmptyActivity" test.
EGL drivers are loaded in a temp thread to leave more time
in RenderThread for other work. Loading EGL drivers
on the RenderThread may cause a perf regression.
Test: Ran cold-dropcache-test test.
Bug: 122659224
Bug: 123361175
Change-Id: I8ca818e98fac196a41d079be15594caca5cb1bab
Supplement some comment to let developer know how to use new API
WallpaperInfo#supportsMultipleDisplays.
Also add a nullability annotation and comment for
WallpaperService.Engine#getDisplayContext.
Fix: 124302009
Fix: 123661589
Test: Build pass and read comment.
Change-Id: Id6040eff12495838f21f539b7c68d6743c9baf74
Update javadoc to say that setPermittedInputMethods only restricts the
IMEs inside the profile when called by a Profile Owner. In the past, a
Profile Owner could restrict the IMEs used across the entire device.
Change-Id: If1df3509327ef131a21db5645d9e2378622800e6
Bug: 124291520
Test: atest android.admin.cts.DevicePolicyManagerTest
StatusBarWindowView is the root of the StatusBar window
and handles all key events at dispatchKeyEvent
All keys dispatched to the StatusBar window flow through
StatusBarWindowView#dispatchKeyEvent. A BACK key event
is forwarded to StatusBar.onBackPressed()
If StatusBar#canPanelBeCollapsed() is false, the action is
passed to BubbleController which forwards to the expanded
bubble by calling to ActivityView#performBackPress().
Bug: 123631742
Test: manual, go/bubbles-app
Change-Id: I0ccafc02f876c973ebc267055162621109b2dcc0
In this configuration the tests will only be triggered by changes
to services/devicepolicy/** and core/java/android/app/admin/**, so
we won't be able to catch breakages coming from the rest of the tree
with a single CL precision. But let's see which parts are causing
the most breakages and add them later.
Bug: 124653467
Test: atest --test-mapping core/java/android/app/admin:postsubmit
Test: atest --test-mapping services/devicepolicy:postsubmit
Change-Id: I58f87fff4b5b5e3e4fb8a333dd6ac4dd4100b587
InputForwarder was used by ActivityView. InputForwarder is not used by
anyone now.
Bug: 120675821
Test: Manual test with ActivityViewTest
Test: atest CtsActivityManagerDeviceTestCases:ActivityViewTest
Change-Id: I6bd2338c921e6dfb1dfe357decb878d558df8bfd