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
App streaming is when the device starts an app on a virtual display and sends a video stream of the app to nearby devices. The policy specifies options in which app streaming is supported. The default policy is streaming only to devices with the same managed account.
Bug: 179910177
Test: Builds successfully
Change-Id: I1a9424d0de524a0cdfcc00b2bc39196e7f231480
Notification streaming is sending notification data from pre-installed apps to nearby devices. The policy specifies options in which notification streaming is supported. The default policy is streaming notifications only to devices with the same managed account.
Bug: 179910174
Test: Builds successfully
Change-Id: I96a9c67aab1d27eb0527add51adc019bd98b64b4
Also replace all usages of TempAllowListType defined in
PowerWhitelistManager with the newly added reference in
PowerExemptionManager.
Fixes: 183053095
Test: atest ActivityManagerFgsBgStartTest#testTempAllowListType
Test: atest PowerExemptionTest
Test: atest BroadcastOptionsTest
Change-Id: I2f47ca99d4dfa8f267bb029d2934f0f765b0c594
With this change we allow system packages with the new permission to
override ChangeIds specifically annotated as Overridable to set
overrides even on non-debuggable builds.
Bug: 174043039
Bug: 175874108
CTS-Coverage-Bug: 180396382
Test: atest FrameworksServicesTests:CompatConfigTest
Test: atest FrameworksServicesTests:PlatformCompatTest
Change-Id: Ib8d5d83b5fd62acb5808d10f5c413616f29ee65c
Currently when COPE PO sets a maximum managed profile time off
policy, it is sufficient for the user to turn the profile on
briefly to reset the timer, which technically allows the user
to circumvent the policy, doing so repeatedly.
With this change DPC can control when the timer gets reset by
acknowledging compliance explicitly.
By default, the behavior is the same as before unless the DPC
overrides DAR#onComplianceAcknowledgementRequired in which case
it will have to call DPM.acknowledgeDeviceCompliant when the
timer can be safely reset, e.g. after a successful policy sync.
Bug: 181943978
Test: atest OrgOwnedProfileOwnerTest#testWorkProfileMaximumTimeOff_complianceRequiredBroadcastDefault
Test: atest OrgOwnedProfileOwnerTest#testWorkProfileMaximumTimeOff_complianceRequiredBroadcastOverride
Test: atest OrgOwnedProfileOwnerTest#testWorkProfileMaximumTimeOff
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I6efea53aad8097c047f1e3ebf62b421dc32214e6
The constants will allow mainline modules to declare whether
they should be uninstalled or not during the provisioning
process.
Bug: 179653892
Test: compiled
Change-Id: Id7de12204b2e9481935cc5a56831ab4899b3dfb6
In this way, we can clarify the owners and it is easier to maintain.
Also refactor to move WindowContext creation logic to ContextImpl.
Test: atest WindowContext WindowContextTests WindowContextPolicyTests
Bug: 159767464
Bug: 152193787
Change-Id: I78432aa18aa97e001f5a9a04321109e456fd137b
Also sets lastAccessTime = now for running ops
Test: atest PermissionIndicatorAppOpUsageTest
Bug: 172868375
Change-Id: I2a616f624640e0f219e33d6fa8ebf55559e24e1a
Apps can now request either immediate visibility or deferral explicitly,
versus the previous iteration's immediate-or-default only.
Bug: 179290175
Test: ApiDemos foreground service exercise
Test: atest CtsAppTestCases:ServiceTest
Test: atest CtsAppTestCases:NotificationManagerTest
Change-Id: I0b4d11a7483d2407758c810cf4a77a2e45bb737f
This CL adds a new permission called SUGGEST_EXTERNAL_TIME that
gates TimeManager.suggestExternalTime calls.
The new permission is marked as 'privileged' as protection level. This
could result in third party apps preinstalled on the system image to
potentially get this permission. This is OK for the following reasons:
- OEM coordination is needed to grant 3P apps this permission, so
adding "privileged" doesn't introduce significant risk.
- This permission/API doesn't guarantee that the suggested timestamp
will immediately be used as the new system timestamp. The system must
be configured so that the external time source has a higher priority
than other time sources (e.g. GNSS) for the external time suggestion to
be used. This configuration is also done by the OEM. That introduces
significant roadblock for a malicious app to do anything useful with
this permission.
- More importantly, apps can set system time directly using
TimeManager.setTime() which requires SET_TIME permission. This
permission is also signature|privileged, so this change is consistent
with it.
Bug: 157504928, 177079827
CTS-Coverage-Bug: 182275086
Test: atest android.app.time
Change-Id: I0098ab7565b647fb220d39575f0616d2a47bdc89
* changes:
Request new Bluetooth runtime permissions.
Default grants for "Nearby devices" permission.
Add BLUETOOTH_SCAN and BLUETOOTH_CONNECT app ops
Split new NEARBY_DEVICES permissions
Define new NEARBY_DEVICES permission group
Android Framework needs to know for each RestoreSet provided by
BackupTransport the properties of the transport (e.g. device-to-device
transport, encryption) that was used to obtain the data in the restore
set in question.
Bug: 182986784
CTS-Coverage-Bug: 183441953
Test: atest FullBackupRulesHostSideTest
Change-Id: I07bc2d4eb3837390ea3b0aee769d143ab153335d
