android_uiautomator is distributed as part of the SDK and should use
-target 8 for compatibility with old JDKs.
Bug: 150153790
Bug: 162522383
Test: javap -v -cp out/target/common/obj/JAVA_LIBRARIES/android_uiautomator_intermediates/classes.jar com.android.uiautomator.core.Configurator | grep "major version"
Change-Id: I6871ab5436232ad3bffff6bd26adf2de6b3c06ff
When referring to a client (piece of software), it's better not to use
a personified pronoun, such as "his" or "their". Changed to "the".
Change-Id: I5d79e70a9135d6f1e8da493fcdd50921b9696e31
Test: none (docs-only change)
Bug: 160937339
The current secondary dex opt doesn't distinct between
opt performed and skipped, which causes unnecessary traces
purge for IORap.
Bug:161633001
Test: manually trigger bg-dexopt via 'adb shell cmd jobscheduler run -f
android 800' and check the log.
(cherry picked from commit ff800a363b)
Merged-In: Iae4fc0b6fc73707ada8895b38c3ae3f772ac2cd0
Change-Id: Iae4fc0b6fc73707ada8895b38c3ae3f772ac2cd0
Previously, when binding to the FUSE daemon from the system_server, we
depended on the main thread to deliver the service connected
message. The main thread can unfortunately be very delayed from other
services running long tasks. In some cases, we might even have
deadlocks of the following nature:
T1: vold -> storage_manager_service # mount waiting for main thread
task while holding vold lock
T2 (main thread): other_service -> vold # other task blocked on vold
lock while on the main thread.
Now we move the bind callback to a dedicated handler thread. This
allows the vold mount to complete independent of other tasks running
on the system_server main thread.
We also revert the temporary fix to unblock the retail demo use case
that uncovered this deadlock:
I8ff153f2649e3a1d05f2e3e6e382bbba8c79630c
All of this only affects the demo user and is a no-op for other users
Test: Manual
Bug: 161702661
Bug: 162209395
Change-Id: I9b6ccff5705bb78cb1ff7a31e3dd2f26d9b400c6
For non-telephony networks, this was always set to 0 before R.
In R, it is currently set to the same value as the network type.
This is incorrect because the two have different namespaces.
or example, currently, any network of type WIFI (==1) will have
a subtype of NETWORK_TYPE_GPRS (==1). Similarly, all ETHERNET
networks will have subtype NETWORK_TYPE_1XRTT, all VPN networks
will have a subtype of NETWORK_TYPE_TD_SCDMA, etd.
Bug: 161653721
Test: builds, boots
Change-Id: I07e111c1762e0021c931cefc27f193f78578748b
Inline APIs.
* limitations with multiple locales.
* limit on max number of suggestions.
* guidance on managing the order of inline suggestions when inflating.
Fixes: 161486684
Test: atest android.autofillservice.cts.inline
Change-Id: Ia560d48f95730d79bc340ff9eb0cf4a5909bf0d3
For backwards compatibility, we allow phone, system UID to
access cell identity through getServiceState. Cell broadcast
service, which is used to be part of telephony, now is running
under network stack UID. We should consider network stack UID as
trustable components like system/telephony.
Fix: 157618105
Test: Manual
Change-Id: I9b2dfc778752e130f5c7e44c4b2e45b63ac6f918
When the preferred handler of an action is saved with "always", the set
of components displayed as options to the user are saved with it. On
subsequent queries, if that set of components change, the preference is
cleared to allow the user to consider the new set. With the introduction
of app visibility filtering in R (and to a lesser extent, Instant Apps
in O), the set of apps that an app can see may be less than the set that
the system can. As a result, if the caller calls resolveIntent and
cannot see all of the apps the system can, it may reset the user
preference unexpectedly.
This change ensures that before we clear the user preference that we're
comparing against the full set of apps. As such, if we encounter a call
to the method from an app that cannot see all apps, we avoid any
mutations and instead just return the set of apps that the user can see
or the preferred app if it's part of the set they can see. If the system
calls or if the call is part of an activity start, we'll allow reset of
the preference.
Test: Manual - Install 3 cameras, verify preference only reset on start
Fixes: 157548344
Change-Id: Icb50a66500edba26c4c6c3e80a6a9c544d4d63d6
Bug: 144138979
Test: grant camera appOp and observe logging
Test: use camera app and observe logging
Change-Id: I6422b432f0d6fcf411073c0528a4ee485d46f005
(cherry picked from commit 5a7e662751)
A long timeout seems to break demo users when calling
DevicePolicyManagerService#enableSystemApp.
We soft-revert Ia8f6f121448f6b5e484fd3e8cca845fdd89afc23 just for demo
users while investigating the root cause.
Test: Manual
Bug: 161702661
Change-Id: I8ff153f2649e3a1d05f2e3e6e382bbba8c79630c
