The permission SCHEDULE_EXACT_ALARM state changes at the following
boundaries:
1. App-op: This gets toggled by the user via Settings.
2. Deny-list: Packages can be added to the deny list via DeviceConfig
APIs.
3. Package changes: A package's manifest may changes when it gets
updated.
In both cases 1 and 2, if alarm manager detects a permission change
from revoked to granted, it sends the
ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED broadcast to the
app.
If it detects a permission change from granted to revoked, it kills
all the processes within the hosting uid.
In all three cases, when the permssion changes from granted to revoked,
all the exact alarms scheduled by the relevant package are removed.
Package updates are treated differently as they require processes to
restart anyway. The broadcast is not needed in this case as there
are no alarms expected to have been lost by a previous revocation, and
apps can always use ACTION_MY_PACKAGE_REPLACED for post-update setup as
usual.
All this only applies to packages that have the change
REQUIRE_EXACT_ALARM_PERMISSION enabled.
Also changed canScheduleExactAlarms to return false if the change is not
enabled for the calling package.
Test: atest FrameworksMockingServicesTests:AlarmManagerServiceTest
atest CtsAlarmManagerTestCases
Bug: 179541791
Bug: 187206399
Change-Id: Icd68275701f2804be65b3a10a7dd81bbf6e2a0bb
c3f067c103