Per API council feedback update the call identification name, details,
description and app name to use CharSequence.
Test: Update apis, run tests.
Bug: 123241094
Merged-In: I42df17506535c1dd598ffd61a44cb0d0440b8159
Change-Id: I42df17506535c1dd598ffd61a44cb0d0440b8159
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 fix introduced a painful crash that ends up disabling accessibility
services for certain users.
This happens when a client of AccessibilityCache tries to add a node, with the same id as a node previously in the cache, but fewer children, where the removed child is not in the cache.
This is because, when children are removed, and a the node is updated, the cache tries to clear the child trees. But if the child is not in the cache, the cache clears the whole tree. Every node is recycled.
Then the original node being replaced is attempted to be recycled again, and voila crash.
The fix also didn't fix the original issue based on the discussion in
b/114133438.
The risk for this is pretty low, since nothing was built on top of this.
This reverts commit 2f69c16c3d.
Bug: 124676705
Test: Tested to see if above usecase still happens.
Change-Id: I8a39698c4532a1613ba47e1c6ca70201cd496212
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
Previously, the plan was for android.test.base to be removed from the
bootclasspath in P, i.e. in the same release as org.apache.http.legacy.
Any apps that targeted < P were to have the android.test.base library
added to their app classpath in order to maintain backwards
compatibility.
Unfortunately, it was not possible to remove android.test.base from P
and instead it is being removed from Q. This update prepares for that
by updating the backwards compatibility support and its tests to add
the android.test.base library to apps that target < Q.
The affected code is only used at runtime when
REMOVE_ATB_FROM_BCP=true.
Bug: 73711752
Test: atest FrameworksCoreTests with and without REMOVE_ATB_FROM_BCP=true
Change-Id: I76b40dad14193cd174114a351b1350c18d647bed
On 9/28 CL https://googleplex-android-review.git.corp.google.com/5116913 was checked into pi-dev. Merge was bad(couple of lines were lost during merge).
https://b.corp.google.com/issues/35655737#comment34
Adding LOCK_SCREEN_ALLOW_PRIVATE_NOTIFICATIONS and LOCK_SCREEN_SHOW_NOTIFICATIONS to SETTINGS_TO_BACKUP array. This fixes apct/framework/presubmit test failure.
Bug: 35655737
Bug: 118674794
Test: presubmit unit tests
Change-Id: I2e9cc95e8827e72ef3c09910d4d3e089bde375e5
Merged-In: I421c7487955ee339f88e3957c973375d0f87e2ff
(cherry picked from commit 33a11bd0e3)
When touchpad capture is enabled, events still are received via
onGenericMotionEvent. As pointer capture sends events via
onCapturedPointerEvent, this patch changes the callback used by
captured touchpads to also be onCapturedPointerEvent.
Make events from a captured touchpad cause the device to leave touch
mode. Captured mice cause the device to exit touch mode through
the virtual dpad which is mapped to it due to being
derived from SOURCE_CLASS_TRACKBALL.
Test: Write an app that starts pointer capture on a device with a
touchpad. Events from touchpad should be received via
onCapturedPointerEvent.
Test: Using the captured touchpad in the first test should cause the
view to be focusable even when not in touch mode.
Change-Id: If6fa94c66f1d9395a13fd5f31f642567256dd818
Replaces the link with the new API name, createInsecureL2capChannel.
Bug: 70683224
Test: Compile
Change-Id: I9580d90722f8b0c0146a902bb5fcace4ef58d421
Merged-In: Ia06e1fffd814671289a1caebd5962aedc18a28d7
A lot of unresolved link errors showing up after go/ag/5172152.
Test: m -j docs with -lerror enabled
Bug: b/116163454
Change-Id: I74d1f75e0f00015410a63e13103c28a9c84b4fe0
Classes that are used in framework.jar cannot be linked in NetworkStack,
as the framework takes precedence in the classpath. This prevents the
networkstack from using these classes due to the hidden API usage
detection.
Do the following:
- jarjar any shared source file between framework and NetworkStack, so
the version in the NetworkStack uses a different package.
- Move any shared class not used in the NetworkStack to services.net
The CL uses jarjar on the app copy and not the framework classes, as
the framework cannot be updated without an OTA, and non-network stack
specific classes should not be renamed because of the network stack.
Test: atest FrameworksNetTests NetworkStackTests
Test: flashed svelte build, WiFi works
Bug: 124033493
Change-Id: I85d888b756adc28c36638913632bfdfdbf0e0486
