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
