Instead of requiring the DEVICE_ADMIN feature, we accept either
the feature or the appropriate permission.
Bug: 133240910
Test: Manual testing
Verify that API executes when on a device without DEVICE_ADMIN
when the caller has the LOCK_DEVICE permission.
Change-Id: I30bd0dc81d9d7b7ed5503a926066caffb389b9c0
The camera API, MediaStore.ACTION_IMAGE_CAPTURE requires apps to pass
a content:// URI with write permissions to the camera. Unfortunately,
apps haven't been doing this and we only started hitting problems in R
for two reasons:
1. The FileUriExposedException that should crash apps when they try to
share file:// URIs acroos binder is skipped. This is because, the
image_capture intent is passed across binder as a field in a
ChooserActivity Intent and the child intents are not checked for
file URI exposed
2. Prior to R, when camera gets a file:// URI, camera issues a file
open(2) in its process. This open(2) succeeds because the camera had
write_external_storage permission which gave it write access to all
files on external storage
Now, camera targets R and (2) fails because camera does not have write
access to files owned by other apps. To workaround, we do the
following in the apps process when it targets < R:
a. When we detect a file:// URI for the camera in an Intent, we create
the file on disk if it is not already created.
b. Scan the file to insert it in the database and retrieve a
content:// URI
c. Replace the file:// URI with the content URI in the image_capture
intent
This works because, the system will ensure the camera is granted write
access to the content URI.
Test: Manual
Bug: 156336269
Change-Id: I4849ff5e806a8207650ff7534846c36ecdc6d3c0
The change to use the overridden package name in the resources table
won't be included in the current release.
Test: Compile
Bug: 147434671
Change-Id: I9acbf921814088dfaba485d9acc845da650caf87
In ContextImpl, we checked the flag "mIsAssociatedWithDisplay" to
identify if a context can access a display or not. The flag wasn't
passed from outer context, and it leads to an issue that context
which created from #createConfigurationContext from display context
failed to obtain display instance.
This CL passes mIsAssociatedWithDisplay from outer context and
also add test to verify the behavior.
fixes: 157719118
Test: atest ContextTest ContextAccessTest
Change-Id: Ibeb2a08c75f90304e12dcf99293c84409c5eea34
Leanback devices go through the regular assist launch path now
so this workaround code is dead.
Test: make checkbuild
Bug: 157564688
Change-Id: I625c1ca03df9350f181219fe87d0d0c4f1e56e0f
Often a permission check in the app's process is an indicative of a
security issue since the app could work around it. Permission checks
should be done on system_server.
This errorprone warning checks for invocations of
Context.checkPermission() in any class inside android.app package and
emits a warning if it finds one. I also added a @SuppressWarnings for
one such call that has a todo and it and seems like an already tracked
workaround. The other call found by the checker is tracked in
b/157548188.
I also found that errorprone was not running for framework-minus-apex,
so I added the plugin to the relevant build rule. Let me know if this is
not the way to go!
Test: build/soong/soong_ui.bash --make-mode framework-minus-apex
RUN_ERROR_PRONE=true
Bug: 157626959
Change-Id: Ieb94f2f43722837c8354ac66474797f4f338ae16
Per https://developer.android.com/guide/topics/ui/picture-in-picture
After app requests enterPictureInPictureMode and receives onPause
callback, it will continue playback if isInPictureInPictureMode is true.
However, with ag/11273366, isInPictureInPictureMode will now return true
after the new configuration is dispatched to app, which happens after onPause.
This may cause app, following the guidance, to cease playback in PiP mode.
Fixes this by setting the internal mIsInPictureInPictureMode earlier
right in enterPictureInPictureMode
Video: http://go/recall/-/aaaaaabFQoRHlzixHdtY/fVRqG7UWoKkQQhFxPkzcUt
Bug: 156924033
Test: manually enter PiP from Twitch
Change-Id: I8e0865076fcb756cfa5db39901f460ab5ad69b99
d85bed510, Adding support for cross-task hero transition, When running
cross-task, only play the enter animation, but the judgment for start
exit transition with shared element is broken. For the case on the issue,
when the exit transition completes, the activity is on the top of task,
it is not allowed to execute return transition.
This CL modifies the condition to allow the return transition. For start
exit back transition, the isReturning is always true. We can use it to
decide if it is allowed to play the return transition.
Bug: 137838129
Test: atest ActivityTransitionTest
Manual testing on ApiDemos with Activity transition
Change-Id: Iaa6a875dbe305f6356887616b797dc45e76a4b56
