This broadcast was previously used to notify Managed Provisioning
that data sharing restrtiction has changed, this is no longer handled
in Managed Provisioning and is now handled in DPMS.
Fixes: 177221010
Test: N/A
Change-Id: I4e3fbb94c41f944afb41e226c06d1fffcc8bc264
There's no way for devs to check whether the user has
disabled or enabled bubbles at the feature level. This
adds an API for devs to make this query.
Test: atest NotificationManagerTest NotificationManagerServiceTest
Bug: 171162184
Change-Id: I3b201e8267f36b45473987db773c08663b8d8126
Create a user-agnostic package-level last time used usage stats for app
hibernation. Usage is updated when USER_INTERACTION or
APP_COMPONENT_USED event reported. Also moved checkAndGetTimeLocked and
convertToSystemTimeLocked methods up to UsageStatsService class and
refactored usages.
Bug: 183142974
Test: atest CtsUsageStatsTestCases:UsageStatsTest
Test: atest UsageStatsServiceTest
Test: atest UserUsageStatsServiceTest
Change-Id: I93d8653bb92b98af8f6b57156eb1139fbd7e562a
* Change Notification.isColorized() to return false if the given color is COLOR_DEFAULT. This removes an odd, inconsistent, and likely unused state.
* Remove config_tintNotificationsWithTheme which we're not going to be using to reduce the color palette complexity.
* Change ensureColors() to use the theme's primary/secondary text colors.
* Numerous simplifications in logic that fall out from these changes.
Bug: 181048615
Test: atest NotificationComparatorTest NotificationTest AppOpsCoordinatorTest NotificationGutsManagerTest NotificationManagerServiceTest NotificationBuilderTest
Change-Id: Ie49cc9f3f9ea01685ae026587e2d1cdb96391eb2
- Distinguish between PROVISIONING_TRIGGER_PERSISTENT_DEVICE_OWNER
and PROVISIONING_TRIGGER_MANAGED_ACCOUNT
- Explain difference between
PROVISIONING_MODE_MANAGED_PROFILE_ON_PERSONAL_DEVICE and
PROVISIONING_MODE_MANAGED_PROFILE
- Improve deprecation message for ACTION_PROVISION_MANAGED_DEVICE
Test: compiled
Fixes: 179709752
Change-Id: Id56316982581cf98dab78ef0b09c9243960d2893
This method isn't used anywhere and its functionality is superseded by onConversationRemoved, which handles deleted conversations.
Test: atest NotificationManagerServiceTest
Bug: 169349809
Change-Id: Iad7f592e71ecf425930e31873088a02e298380b3
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
This CL exposes an API that allows system clock time suggestions from an
external clock / time source to be made. The nature of "external" could
be highly form-factor specific. Example, times obtained via the VHAL for
Android Auto OS.
Bug: 157504928
Bug: 177079827
Test: atest android.app.time
CTS-Coverage-Bug: 182275086
Change-Id: I3527e3827a03c1df73fdc1e00c815ad5971a92ca
