Retrieval of the system and system UI themes should be done with the
ResourcesManager lock held to ensure the theme retrieved has the new
overlays applied.
Bug: 189100984
Test: manual
Change-Id: Ibe27ec745ea5a914d3d05e393598a336d96a55e6
* changes:
Quantize image to 128 colors instead of 5
Quantizer improvements
Sort colors from high count => low count
Don't interpolate image input to quantizer
Cache set wallpaper as PNG instead of JPEG
Only rescale wallpaper if its > display height
Quantizing an image to five colors results in an extreme amount of
averaging of colors, leading to low chroma colors and erasing colors
from the image that the eye gravitates towards.
Coupled with a change to ensure there's still a broadly accurate signal
of a given cluster's population of the image, via summing the population
of all the clusters close to the hue of the cluster, and with proof that
having this many data points doesn't lead to instability in results,
we gain access to a much larger variety of colors. This gives room to
add heuristics to avoid 'bad' colors, as well as increase the
number of colorful colors we offer.
Bug: 189931209
Test: Test tons and tons of wallpapers over a couple days.
Change-Id: Ifc2d9393039194c151920536b9217ae9636ff0d6
The original versions of these quantizers landed a couple months back,
and they were fine. Since then, we've had several opportunities to
iterate on them. This change lands improvements from those iterations.
TL;DR: 18% faster, big bug fix to WSMeans, code is cleaner (hopefully)
- QuantizerMap indexes an image's pixels, 'unique-ing' them by reducing
the pixel array to a map with keys of colors, and values of population.
This allows other quantizers to operate much more quickly: instead of
working on each pixel individually, they're able to operate in bulk.
- QuantizerWu uses flat arrays instead of 3D arrays and is more
understandable IMHO.
- QuantizerWsmeans has speed improvements, most importantly, it has a
big bug fix. When a Kmeans-based quantizer algo starts, it must first
assign the pixels to any one of the starting clusters. The original
implementation decided what cluster to assign a pixel to by finding the
cluster closest to the pixel. However, the algo terminates if no pixels
moved after one iteration of the algorithm, and since the pixels were
already in the cluster closest to them, the algo would immediately
terminate before it actually figured out where the cluster moved to
after pixels were assigned to it, and had a chance to move pixels around
based on that.
- Funnily enough, even though this _should_ mean Wsmeans got a lot
slower since it has to do more iterations, it is actually 16% faster
Additionally, during review of this CL:
An accidental dependency on iteration order of a Set was introduced,
causing inconsistent initialization of the mPoints array, creating
inconsistent results from the quantizer.
Removing the dependency on hashes of float[], and avoiding Maps
altogether, removes a dependency on hash codes of pointers that existed
during review, making it easier to have verifiable consistency across
iterations. This also improves speed slightly, from 55 ms to 39 ms
(tested on sunfish, first 9 wallpapers in Landscapes, City Scapes, and
Art categories, and averaged)
Bug: 189931209
Test: ran performance tests with VariationalKMeansQuantizer,
the previous Celebi = Wu + Wsmeans quantizer, and the new Celebi =
new Wu + new Wsmeans quantizers, over 100 iterations. Wu speed is
roughly the same, Wsmeans is 18%. Verified quantizer output is stable
for the same input pixels, run 100,000 times for each of two wallpapers.
Change-Id: I3324d29860c098ea1fd602b8d4197837e732f4f1
The colors were being sorted by population ascending, sorting by
population descending fixes a long-standing flaky test that became
a 100% reproducible failure once scaling fixes were introduced.
The test failure that caught this is CTS' WallpaperManagerTest's method
wallpaperColors_secondary. It creates a bitmap that is mostly red, with
a smaller area of blue.
Before the set of 4 CLs in this topic, when the wallpaper was downscaled
by WallpaperManager, it introduced new colors to the wallpaper due to
bilinear filtering and JPEG compression. With the new colors introduced
by scaling, the least popular color was blue enough to pass
WallpaperManagerTest's wallpaperColors_primary method, and the 2nd least
popular color was red enough to pass wallpaperColors_secondary.
With CLs for consistent image input to quantizers, namely 2 CLs, cache
wallpaper as PNG instead of JPEG, and only rescale the wallpaper if it
is greater than the display height, the scaling/JPEG artifacts are not
introduced, which then exposes the bug that primary/secondary were the
least popular/2nd least popular colors in the image, instead of the
most popular/2nd most popular, as intended.
Bug: 188373181
Test: atest CtsAppTestCases:android.app.cts.WallpaperManagerTest
#wallpaperColors_secondary --, use helper methods to store
the bitmap after downscaling to confirm introduction of new colors
before other CLs in this topic, use go/monetstudio to confirm
quantization results from that downscaled image. Check test against
all 4 CLs, confirm test starts failing once "Only rescale wallpaper if
its > display height" CL is introduced.
Change-Id: I143f824fbd961b81604d427a0570b3a171bdeb79
With `false`, nearest neighbor is used during scaling, with `true`,
bilinear interpolation is used. Bilinear interpolation can introduce
colors that weren't in the original image (ex. overemphasizing red/brown
highlights in a mostly B+W image of the Mandolorian). Better to avoid
that.
Bug: 189931209
Test: Test tons and tons of wallpapers over a couple days.
Change-Id: I425f95793ca593dbbc5008ef59f4baedaea318a6
To handle the case where an app sends a notification directly
to a custom channel, and to properly show priority markings
on conversation tiles
Test: atest; manually ensure convo tiles are marked as priority
Fixes: 184709662
Change-Id: I8f9b6169943da5670bc09fd16bbe692fd43d2cf6
When DPM.setAlwaysOnVpn is called with package=null, it resets
any VPN configured by the user. With this change it won't happen
anymore: it will only reset VPN configuration if it was previously
configured by the admin.
If an admin actually wants to remove any user configured VPN, they
can enforce DISALLOW_CONFIG_VPN restriction which will remove any
user VPNs and will prevent the user from configuring a new one.
+ Also make sure that when the DPC removes an always-on VPN
configuration, the package loses ability to start VPN until the
user authorizes it again.
Bug: 139823667
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: Ia703015b4e8d7eaf156358d7eb000d6f58d32238
This is to allow 3p apps to query the state of the policy so they
can show appropriate UX to the user in case the app's interaction
with the plugged-in USB devices is disrupted by the admin policy.
Bug: 190024751
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Change-Id: I829ff84256e0288b88c11add53da312ee2bc2558
Provide a method ActivityOptions#setSplashscreenStyle to specify
splash screen style if needed.
If not set, the default option will be empty-style splash screen, so
without any other change, the activity launched from systemui with
ActivityOptions will become empty style splash screen.
Bug: 188023621
Bug: 189293785
Test: manual test start application from Launcher and Notification.
Change-Id: I299320db8f32fbd835c7ec0acaad3df3486a13f5
Make sure that even transient package-associated state is cleared when
the package is uninstalled, and provide a testing hook for instrumenting
global rate limits appropriately to high-rate test sequences.
Bug: 190019349
Test: atest CtsAppTestCases:android.app.cts.ServiceTest
Test: atest CtsAppTestCases:android.app.cts.NotificationManagerTest
Change-Id: Ic38157c6f21bcf09bcf74de591e41dc64f7bf0f7
Logging wasn't quite right in the case of deferred FGS notification in
various ordering scenarios.
Bug: 189926836
Test: atest CtsStatsdAtomHostTestCases:android.cts.statsdatom.statsd.UidAtomTests#testForegroundServiceState
Change-Id: I650730db9e01faa90a36a73b486464ab5b179fc6
* originally fixed in ag/14189045
* regressed in ag/14140988
Bug: 185920837
Test: post conversation notifications, and look at badge or face pile background; should match notification background
Change-Id: I8ef77901ed9d43eccf89dcc1f3905f0dbb38851f
* "Headerless" notifications no longer capped at 88dp. This allows DecoratedCustomViewStyle content to be sized larger than 48dp, but all that sizing is now controlled by the max heights for the entire notification, which is enforced by the ExpandableNotificationRow, rather than the layout.
* Reduce the max heads up height to 136dp (down by 7dp). For standard headerless templates, this won't have any effect, because they would never get that tall. For HUNs with decorated custom content this reduces the custom content area to 96dp without actions (to match RVC) and 56dp with actions (up slightly from 48dp in RVC).
* Fixed a bug where the snooze button would be bound when viewType=NORMAL, which only affected messaging style, and was hiding a layout bug if the snooze setting was enabled.
* Fixed a bug with the action margin on messaging notifications appearing in the collapsed state and causing oversized notifications.
Fixes: 189937886
Test: significant manual testing with notify and notify2, especially with HUNs
Change-Id: I775a0bb29944922581d01f237dbbc5580ced00c4
Attribution source is the abstraction to capture the data
flows for private data across apps. Checking permissions
for an attribution source does this for all apps in the
chain that would receive the data as well as the relevant
app ops are checked/noted/started as needed.
Teach speech recognition service about attribution
chains. If an implementation does nothing the OS
would enforce permisisons and do blame as always.
This apporach leads to double blaming and doesn't
support attribition chains where app calls into
the default recognizer which calls into the on
device recognizer (this nests recursively). If the
implementer takes advantage of the attribution chain
mechanims the permissions for the entire chain are
checked at mic access time and all apps are blamed
only once.
Fixed a few bugs around finishing ops for attribution
chains. Also ensured that any app death in a started
attribution chain would lead to finishing the op for
this app
bug: 158792096
Test: (added tests for speech reco)
atest CtsMediaTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Merged-In: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
ag/13330774 removed the requirement & added tests; this updates the
javadoc around it.
Bug: 189175840
Test: treehugger
Change-Id: I5c8fc35607c79a6e70e8245d8662d66d5e884fa1
A number of scenarios involving both FGS and non-FGS notification
operations were not yet working as intended. This CL lands the
following behaviors:
* notify() to update the notification content during an FGS's
notification deferral period now respects the new Notification's
deferral policy rather than forcing immediate display. An app can now
choose whether to force immediate display, or to have the new content be
what eventually appears at the end of the deferral period, by using the
same builder API as controls the deferral policy for startForeground().
* If an app posts a notification via notify() then adopts that
notification with new content (i.e. uses the same notification ID) in a
call to startForeground(), there is now no deferral: the existing
notification is always updated immediately, regardless of the
notification's or the service's configuration viz deferral policy.
* Fixed a latent bug when the app called notify() to update the
notification after startForeground(), then the service was killed for
memory and relaunched. The notification might have been reposted with
stale content.
* Adjusted the metrics handling to more accurately express "was display
of the notification content for this transition to the FGS mode
deferred?"
Bug: 178406514
Bug: 185771298
Bug: 187860135
Test: atest CtsAppTestCases:android.app.cts.ServiceTest
Test: atest CtsAppTestCases:NotificationManagerTest
Change-Id: Ieb62f7195eb619c1769e3c1bd518cb6a7b6e4b7c
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
This provides a new request type for AssistDataRequester, ASSIST_CONTEXT_CONTENT. Using this prevents ActivityTaskManagerService from sending the potentially large AssistStructure when it isn't necessary.
Bug: 189164641
Test: Manual (confirmed the new call worked as expected on Pixel 3A)
Change-Id: I5cec15c88c52f8319808aee474cc2351f2fa931a
Apps were able to bypass BAL and BG-FGS restrictions by retrieving their
own notifications and firing their PI since those were allowlisted for
those operations.
Now we strip the token that granted them that ability
from notifications returned via NM.getActiveNotifications(), which
returns the notifications of the caller.
Notifications returned via notification listener APIs still contain such
token, as they should.
Bug: 185388103
Bug: 169821287
Test: atest -d android.app.cts.NotificationManagerTest#testActivityStartFromRetrievedNotification_isBlocked
Change-Id: I2ede0d639a560f6acacec3864a0a7d23af152ba5
We can guarantee that LaunchActivityItem will queue before
ActivityConfigurationChangeItem.
But ActivityConfigurationchangeItem#preExecute() still has the
opportunity to execute before LaunchActivityItem#execute(). And at this
time, ActivityClientRecord has not been created.
This CL create ActivityClientRecord early in
LaunchActivityItem#preExecute() and store in a new list of
ActivityThread. Thus others can guarantee to get the
ActivityClientRecord in preExecute().
Bug: 187691892
Test: atest TransactionExecutorTests
Change-Id: Ib40270345223c5c6e76333803faf98937c5527f9
