No change to logic, only docs.
This clarifies the docs for onShowCustomView. This @links to
FLAG_FULLSCREEN, reminds the developer they must override both
onShowCustomView and onHideCustomView, and provides guidance for
CustomViewCallback.
Bug: 143247282
Test: make -j4 docs
Change-Id: I64de3723674da5c138438921cc8232c4bf2a3d98
And also pre-grant it to all apps that currently get any storage
permission pre-granted
Test: atest SplitPermissionTest
m -j gts && gts-tradefed run commandAndExit gts-dev -m GtsPermissionTestCases --test=com.google.android.permission.gts.DefaultPermissionGrantPolicyTest#testDefaultGrantsWithRemoteExceptions
Manual testing:
All combinations of
- App targetSdk = 28 and 29 (and 22 for extra credit)
- App having the <uses-permission> tag for
ACCESS_MEDIA_LOCATION or not
- Upgrade from P->Q-QPR and from vanilla Q->Q-QPR
Further upgrade of targetSdk from 28->29 while on Q-QPR
==> All permission behavior should make sense. Sometimes there
are weird, but expected behaviors. Hence we need to
collect the results and then look at the unexpected ones.
See SplitPermissionTest for some tests I added for the
location-background permission which was split from
the fine/coarse-location permissions
Fixes: 141048840,140961754
Change-Id: Ib9f50d25c002036f13cf2d42fc4d1b214f20920c
(cherry picked from commit ac7b10c135)
RFC2109 has been obsolete for a long time, and the docs aren't very
clear what exactly the RFC has to do with CookieManager; the RFC is
about HTTP and it's not immediately clear how this would apply to a Java
API.
Update the reference to the current cookie spec (and hyperlink it), and
clarify the text to explain that the HTTP header formats from the RFC
are the formats used to get/set set cookies.
Fixes: 143086151
Test: make ds-docs
Change-Id: I5e5838d3435b74516847b63e485fdd93810284aa
AWARE_TAP_PAUSE_GESTURE_COUNT is the number of times the user
has used the Motion Sense tap gesture to pause media. This number
is used to determine whether to show the "Tap to pause media"
contextual tooltip.
AWARE_TAP_PAUSE_TOUCH_COUNT is the number of times the user has
touched the device to pause media instead of using the Motion Sense
tap gesture (Motion Sense and tap gesture must be active for this value
to increment). This number is also used to determine whether to show the
"Tap to pause media" contextual tip.
We back up these counts so that users moving to new devices with Motion
Sense will not be given these contextual tips again if they already know
how to use the feature.
Test: manual
Bug: 138296598
Change-Id: I702719fb7cec8b6be9dff91d212a00fb26129957
Merged-In: I702719fb7cec8b6be9dff91d212a00fb26129957
(cherry picked from commit a6e468831a)
ag/9372503 put the order of reading preCreated from a UserInfo parcel
in the wrong spot. We fix it here.
Test: none
Merged-In: I4502e901ff2aac977c584fa8c5a3d1263be33572
Change-Id: I4502e901ff2aac977c584fa8c5a3d1263be33572
(cherry picked from commit e80af14d33)
Initial user creation is slow because the system must prepare per-user data (like storage and
permissions) whose cost is proportional to the number of pre-installed apps. On automovive's
reference implementation, it can take more than 10s, which is a bad user experience.
This change lets OEMs pre-create some users , so that high initial-creation cost is "paid" during
the initial boot. On automotive, it improves the creation of an additional user (or guest user)
in about 7s (from ~17s to 9s).
Bug: 111451156
Bug: 132111956
Bug: 140750212
Bug: 140868593
Test: manual verification
Test: atest FrameworksServicesTests:UserControllerTest#testStartTemplateUser_background
Merged-In: I81de1b5376dc9c42b63be8853d7204c88826401f
Change-Id: I81de1b5376dc9c42b63be8853d7204c88826401f
(cherry picked from commit c1ca4410e1)
We had accidental usages of the PermissionChecker for cases where no
private data was provided to the app but the checkPermission API on
the latter also did blame data access on the app. The PermissionChecker
was designed to handle IPC calls and not for generic API checks.
To avoid future accidental incorrect PermissionChecker usages this
change renames the existing APIs of the latter to clearly indicate
that they should be used for data delivery and also adds sibling
methods for doing the same permission checks for preflight purposes.
Also the documentation is improved to furhter assist developers.
In addition, this change fixes accidental permission checker usages
that blame when they should not by using the new preflight flavor
of the permission check APIs.
Test:
atest com.android.settingslib.location.RecentLocationAppsTest
atest CtsPermissionTestCases
added: LocationAccessCheckTest#notificationOnlyForAccessesSinceFeatureWasEnabled
added: LocationAccessCheckTest#noNotificationIfFeatureDisabled
added: LocationAccessCheckTest#noNotificationIfBlamerNotSystemOrLocationProvider
added: LocationAccessCheckTest#testOpeningLocationSettingsDoesNotTriggerAccess
bug:141028068
Merged-In: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
Change-Id: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
Instead of doing lazy serialization of SKP on the
background executor serialize to a byte[] immediately
at callback invocation. This ensures no potential
for later mutations, race conditions, or wrong-thread issues
at the expense of potentially impacting app rendering performance.
However it seems preferable for a debug-only tool to be a slow
instead of very crashy.
Bug: 141772764
Test: test app
Change-Id: I3316d49970b96f1c59bb0a28ff7335db608e539e
Test: Verified that the flag could be modified with
adb shell settings put secure...
Bug: 141380252
Change-Id: Ifa24b688a487482e5b02689c1046d85423f73280
