Revert submission 11618534-rename-resources
Reason for revert: Possible cause of ~20 test failues, see b/158441669
Reverted Changes:
I5b5b6699f:Use permissionController name rather than hardcode...
I47105cb3a:Remove hardcoding of permission controller package...
I70a43c216:Use aapt2 flag --rename-resources-package in soong...
I60c7f60e9:Use overriden id for resource getIdentifier
Ie8e1c7a9e:Remove resource getIdentifier workaround
Change-Id: Ifdf120ab407db9057810129c3c7bd873524d9129
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
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
soong renames the package name in the resource table, so it no longer
needs to be accessed based on the base package name.
Test: forrest
Bug: 147434671
Change-Id: I5b5b6699f720ad8798d36467e88c8d8ddb52c9ee
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
