Bug: 197740038
Test: Force stock android animation on a pixel phone in
BootAnimation.cpp. (Remember to disable dynamic coloring.) Check stock android animation.
Change-Id: I3c3979c344a351ec261bb12127cff971d6050367
Test: Flash the updated animation to device. Reboot and check if the
animation shows up.
Bug:199179989
Fixes:199179989
Change-Id: Ic2a2496efcaca4b6ae90c167498b8cd794b46bea
This CL allows dynamic color boot animations to render graphics in shades of white.
Bug: 190093578
Test: adb shell stop; adb shell start. Complete reboot to see the full
sequence (including the loader part)
Change-Id: I672a49aff90fa04daa4bdd6fd3c0b5497cc1a115
Otherwise the sysprops would not be loaded yet and accessing them would
return empty strings.
Though unlikely, this is not 100% safe because boot color sysprops
are not guaranteed to be loaded by the time zips are loaded. A TODO
here is to understand boot steps and their timing implications so
that we can fully avoid the race condition.
Bug: 190093578
Test: adb shell setprop persist.bootanim.color(1-4), then reboot phone.
Change-Id: I603da080b1732a436a10dbaca6f2be9f158124dc
This reverts commit ad9cf52df9.
Reason for revert: Fixing broken atv test
Test: atv atp test tv/platform/simple_boot_test
Bug: 190093578
Change-Id: I9d6ecb6024ce49eef8007458b0d9bf0ff24906c7
This reverts commit 2ded80094e.
Reason for revert: Working on fixing the regression that happened on Wembly, so we can resume feature work.
Change-Id: I9a624beffdaf97f131046fd4441a251ed3a448ad
Test: adb shell /system/bin/bootanimation
Bug: 190093578
(cherry picked from commit 8eedc0293d)
If for some reason there are a lot of fabricated overlays in the
resources cache, the binder limit of the list of fabricated overlay
infos could exceed the maximum binder transaction size. Rather than
return all of the frro infos in one transactions, register an iterator
with the native idmap2d service and use multiple binder transactions
to iterate through all of the frros.
Bug: 192948522
Test: Toggle device theme colors several times and observe frro cache
Reboot device and observe old frros are deleted
Change-Id: I5e9cf3ae9d1d45eda683c24141a0cd4e4301e02f
Any symbols exported from the executable override everything else in
every linker namespace. Previously, app_process exported the
signal/sigchain API, but that interposition is now handled by
libsigchain.so.
Bug: http://b/190100879
Test: `nm -D --defined-only app_process{32,64}` shows no symbols
Change-Id: I1ab1fc700c34e91535c3e679a471debbb4eb71e3
(cherry picked from commit 6b86dfb159)
Teach the overlay manager to ask the idmap service to pretty print the
contents of each idmap file as part of OMS dump. This creates a single
entry point for dumping both OMS and idmap data, and circumvents the
problem of accessing the idmap service if it has been killed due to
inactivity.
Example idmap section:
---- 8< ----
IDMAP OF com.android.theme.color.sand
Paths:
target path : /system/framework/framework-res.apk
overlay path : /product/overlay/AccentColorSand/AccentColorSandOverlay.apk
Debug info:
W failed to find resource 'string/accent_color_overlay'
Mapping:
0x0106006e -> 0x7f010000 (color/accent_device_default_dark -> color/accent_device_default_dark)
0x01060070 -> 0x7f010001 (color/accent_device_default_light -> color/accent_device_default_light)
---- >8 ----
Bug: 189963636
Test: adb exec-out dumpsys
Test: adb exec-out cmd overlay dump
Test: adb exec-out cmd overlay dump <overlay-identifier>
Change-Id: I9de6ba646ad4714c9d0f0d8081fbf632577107e7
Re-order the serialization of an FRRO and creation of the backing file.
This prevents a dangling (empty) file if the serialization fails.
Bug: 189963636
Test: manual: cmd overlay fabricate <bad parameters>, verify no file created in /data/resource-cache
Change-Id: I1af88c6d2d1c3a881beecfb50ccaf541a249f39b
When an application is incrementally installed, and a resources
operation fails due to the resources not being fully present,
the app should crash instead of swallowing the error and
returning default values to not alter the experience of
using the application.
Disable IncFsFileMap protections on ApkAssets that are a part of the
application that is running (base and splits).
Bug: 187220960
Test: atest ResourcesHardeningTest
Change-Id: Ibc67aca688720f983c7c656f404593285a54999b
Revert "Remove storage app data isolation checking in CTS"
Revert submission 14325408-enable_storage_iso_2
Reason for revert: b/187939590
Reverted Changes:
I6391b7381:Change mounting storage data and obb flag to on by...
Ic2f3d1be2:Remove storage app data isolation checking in CTS
Iffa8339b1:Change mounting storage data and obb flag to on by...
Bug: 187939590
Bug: 148049767
Change-Id: I7fa2947593d0fe743def804bf4f7b57920978e40
Change mounting storage data and obb flag to on by default
Test: unbundled/launcher/nexus_unit_test_multi_device_platform
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Test: atest AdoptableHostTest
Test: pass cts/cts_postsubmit_cf_stable-cloud-tf
Bug: 148049767
Change-Id: Iffa8339b10427bea96aa90030463ed18c96eafce
The test config takes longer than 15mins to run. Move it to a dedicated
group for running slow presubmit Test Mapping test.
Some more context is in the referenced bug, e.g, b/174495337
The group will work exactly the same as presubmit for now.
Bug: 174654670
Bug: 174495337
Test: none
Change-Id: I71b6e5b285d0f12b43bf5312f9cde814d2f5f7da
Change https://r.android.com/1667508 adds nullability annotations to
the core platform APIs which broke this code with the error:
javadoc: error - In doclet class com.google.doclava.Doclava, method
start has thrown an exception
java.lang.reflect.InvocationTargetException
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
androidx.annotation.RecentlyNonNull not found
Bug: 183938110
Bug: 185929373
Test: m checkbuild
Change-Id: I83e3071f851720a9f719cb226f0e84fd731a8f37
Merged-In: I83e3071f851720a9f719cb226f0e84fd731a8f37
Seeing 100 while booting is not finished, or seeing eg 90 while booting
is not finished isn't user-friendly.
Test: update ART module, see percent progress
Change-Id: I5509c83f661f937f00a7d28c789df509e3528a37
Change https://r.android.com/1667508 adds nullability annotations to
the core platform APIs which broke this code with the error:
javadoc: error - In doclet class com.google.doclava.Doclava, method
start has thrown an exception
java.lang.reflect.InvocationTargetException
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
androidx.annotation.RecentlyNonNull not found
Bug: 183938110
Test: m checkbuild
Change-Id: I83e3071f851720a9f719cb226f0e84fd731a8f37
Merged-In: I83e3071f851720a9f719cb226f0e84fd731a8f37
Allow bootanimation to play if the boot is quiescent and the system
property ro.bootanim.quiescent.enabled is set to true.
This allows the bootanimation to become visible if the display is
turned on during the bootanimation. If OEMs want this behavior and the
device implements suppression of video/audio during quiescent boot,
they can set the system property
ro.bootanim.quiescent.enabled.
Bug: 185118020
Test: PRODUCT_PRODUCT_PROPERTIES += ro.bootanim.quiescent.enabled=true
adb reboot quiescent
Spam `adb shell input keyevent POWER` during boot
Test: Repeat the above test with the property set to 0
Change-Id: I54a4ad552704106ca06c4992fed4a2d501aa3fa5
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
Revert submission 13469849-turn_on_iso-sc-dev
Reason for revert: Failing existing CTS b/182843583
Reverted Changes:
If819ee161:Change mounting storage data and obb to on by defa...
I46a095448:Change mounting storage data and obb to on by defa...
Change-Id: I7b33baebe150ab78551c7b4368320f056cdcbceb
