There is a case in Bubble that we might release a un-initialized
TaskEmbedder while calling ActivityView.release() (ex. create a bubble
and don't expand it and then dismiss it) which will cause an exception.
Allow ActivityView.release() to be called at anytime and check the
initialization state before calling TaskEmbedder.release().
Bug: 155417004
Test: 1. Add bubbles and don't expands them then dimiss them
2. Check logs.
Change-Id: I583ddd36f407c908cb63c109834940fc91c8d130
This provides a signal for MediaProvider to whitelist access for full
external storage access.
Here is an overview of how the flow looks like:
1. When app is started within instrumentation with --no-isolated-storage
flag, ActivityManagerService will grant OP_NO_ISOLATED_STORAGE to that
package.
2. MediaProvider will note the OP_NO_ISOLATED_STORAGE app op as fallback
in case app doesn't have MANAGE_EXTERNAL_STORAGE permissions.
3. When instrumentation finishes, ActivityManagerService will change
mode of OP_NO_ISOLATED_STORAGE app op to MODE_ERRORED.
Test: atest ExternalStorageHostTest
Bug: 149894531
Change-Id: I51cd87e5e887b887fd8ac7a1a7ffff208266ffa8
If the user is not unlocked, log at the warning level instead of error
to reduce logspam from non-direct boot aware providers.
Fixes: 148747075
Test: manual (observe logs before and after user unlock)
Change-Id: Icd0fb23982a78fb413f329da93b2ce01d37aca2a
Remove the debug code for feature:
1. Background started FGS while-in-use permission restriction
2. Foreground service type camera and microphone.
Bug: 158579189
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerApi29Test.java
atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
atest cts/tests/app/src/android/app/cts/ActivityManagerProcessStateTest.java
Change-Id: I9669db918af3740509a090c3075d93588110cea1
Previously we add uid to PendingStartActivityUids at activity start.
Now we also add uid to PendingStartActivityUids at activity resumed
because we can not wait for updateOomAdj() to be run by a runnable that
WindowManager send to DisplayThread at activity resumed.
At ActivityManagerService.getProcessStatesAndOomScoresForPIDs(), if the
ProcessRecord is in PendingStartActivityUids, we hard code the
ProcessRecord to be PROCESS_STATE_TOP and FOREGROUND_APP_ADJ, ahead of
result of updateOomAdj() the comes later.
Bug: 155143386, 157180494
Test: Reproduce steps of 155143386, swipe between GCA and
Snapchat, camera access is allowed after swipe.
Change-Id: Ia11b0e3400e4df851b250beb01dcfda43580668b
The offset was computed based off the offset represented by
the most recent historical file while we have to use the time
this file was written.
Also now we persist the history on reboot and shutdown,
significantly minimizing the possibility of data loss.
Added test API to emulate reboot of the history to allow for
precise and tightly controlled test to prevent flakes due to
boot time deviations.
Test: atest android.app.appops.cts.HistoricalAppopsTest#testRebootHistory
Fixes:156853195
Change-Id: I4142371f8bc2b1d710cc8c300e7e79cb03764c04
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
(cherry picked from commit 3cc489b7f3)
Currently ResourcesManager iterates over all of its weak references to
Resources objects and calls Reference#get to determine if the object
has been garbage collected. This method of pruning WeakReferences
causes reference locks to be acquired in the native layer and causes
lock contention when "references are being processed" by the garbage
collector.
This change uses a ReferenceQueue to determine if a reference has been
garbage collected which should improve performance of
ResourcesManager#getResources when the system is under memory pressure.
By only removing garbage collected references when creating new
Resources objects, the lists grow larger and are periodically pruned
rather than attempting to prune entries from the list every getResources
invocation.
Bug: 157575833
Test: used debugger to observe pruning happening correctly
hange-Id: I3277e80edfa441d24de165e738d33c4fac6b4121
Change-Id: I3277e80edfa441d24de165e738d33c4fac6b4121
Currently when loading implicit layers from apks, NativeLoaderNamespace
doesn't allow to dlopen the binaries if they come from apks from
/vendor/app. Implicit layers ship within /vendor/app should work like
other implicit layers. This patch extracts the construction of library
paths of the implicit layers and includes those paths when
NativeLoaderNamespace is created as the part of the permitted library
paths.
Bug: b/157832445
Test: atest android.gputools.cts.CtsRootlessGpuDebugHostTest
Test: setup debug layer and use adb logcat to check vulkan loader output
Change-Id: Ie2ca989bcab890578b5aa540d07f2aee2a0182bd
Launcher needs to distinguish display changes
that result naturally vs apps that launch
in a fixed portrait/landscape rotation during
the quickstep gesture.This callback helps anticipate
if a subseqent onDisplayChanged() will
have resulted from a natural rotation or not.
Bug: 154580671
Change-Id: I59ee7985a9f367e8fc5826c08476c1a25d1426b0
A launching activity with fixed rotation may get information from
a Display object which is associated with application resources.
In order to let the display size and rotation are consistent with
the activity configuration, the override configuration of activity
will update to the display adjustments of application resources.
Fixes: 157558894
Test: AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
Change-Id: I7f72d838170a5f588bb8dd279ae081d1a3ddba95
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
