add patch level expiry warning popup & notification

[inthewaves]

Closes GrapheneOS/os-issue-tracker#3999
Review and merge with: GrapheneOS/platform_packages_apps_Settings#332

Implemented inside of SystemUI as a periodic JobService with a popup and notification.

Test this by building with the constant DEBUG_ALWAYS_EXPIRED set to true and then using Settings -> Security & privacy -> More security & privacy -> toggling Disable patch level expiry warnings to retrigger the check. Can also toggle with ExtSettings.USER_DISABLE_PATCH_LEVEL_EXPIRY_WARNING using adb directly:

adb shell settings put global grapheneos_patch_level_warning_disabled 1
adb shell settings put global grapheneos_patch_level_warning_disabled 0

Toggling it off will cancel the job, and toggling it on will schedule the periodic job which also runs the job and hence does an expiry check.

Updater disabled (as main user)	Updater enabled (as main user)	Updater missing (as main user) Should never happen normally

Notification Tapping will open popup	Updater disabled (as non-main user, who can't open updater)

Test: atest KeyguardViewMediatorTest (choose A for all)

Periodic patch level expiry check JobService

Periodically checks for patch level expiry, with checks occurring every CHECK_INTERVAL (currently 7 days). Since AOSP and GrapheneOS issue monthly security updates, a patch level older than one month plus EXPIRY_GRACE_PERIOD (currently 14 days) is considered expired. See getWarningStartDate for details on how the warning start date is calculated.

If expired, a system alert notification (a standard Android notification with high priority) is displayed to all users, and a popup warning (a SystemUI-style dialog that appears over everything) is shown upon the next keyguard unlock. The warnings are re-triggered at each CHECK_INTERVAL or upon device reboot. The warnings will cease once the device is updated to a build with a current patch level. The user can open the popup from the notification; doing this means the popup won't show up again for that user type on keyguard unlock.

See PatchLevelWarningDialogDelegate for the popup dialog behavior on a per-user basis.

If phone is currently being used while the expiry check goes off, only the notification will be shown. The popup is displayed upon the next keyguard unlock. The popup is extremely disruptive and we don't want to block whatever the user is actively doing.

This should never happen normally, but if Build.VERSION.SECURITY_PATCH cannot be parsed using the SECURITY_PATCH_DATE_FORMAT, the warnings will begin showing up on a weekly basis indicating that the security patch level cannot be parsed by the system.

Users can disable this warning (ExtSettings.USER_DISABLE_PATCH_LEVEL_EXPIRY_WARNING), and it can also be disabled on a per-device basis via a read-only device config (ExtSettings.DEVICE_DISABLED_PATCH_LEVEL_EXPIRY_WARNING, which is currently ro.disable_patch_level_expiry_warning) for EOL devices.

CHECK_INTERVAL

How often to check patch level. Also serves as the reminder interval once the device has an expired patch level. Currently set to 7 days.

Implicitly adds to the grace period for the first warning. Worst-case grace period is EXPIRY_GRACE_PERIOD + CHECK_INTERVAL plus Doze restrictions

e.g. if the patch level is 2025-01-05, EXPIRY_GRACE_PERIOD=2 weeks and CHECK_INTERVAL=1 week, then expiry warning starts showing up anytime in between 2 weeks and 3 weeks after the same date in the next month (i.e. 2025-02-05 + 2 to 3 weeks)

Popup dialog

Full-screen popup dialog to warn the user about their patch level being expired. Will show up on keyguard unlock and if the user taps on the system notification that also appears.

For the main / system user, it will direct them to either check updates manually and review the updater settings, or to enable the updater if it is disabled. For non-system users, it'll still display the updater status, but it'll mention automatic updates can only be managed by system user. See PeriodicPatchLevelExpiryCheck.getWarningDescriptionParagraphs for the exact strings that are used on a case-by-case basis.

The dialog is done in SystemUI. It's important that this dialog is tested so that it doesn't crash (e.g. from a upstream SystemUI change); this popup is shown automatically after a keyguard unlock, and any crashes from this dialog would crash SystemUI on an unlock as a result. It wouldn't permanently prevent the user from getting into their phone, as it's only displayed once a week for expired patch level dates (the PeriodicPatchLevelExpiryCheck job that marks the keyguard popup is not rescheduled).

The alternative to doing this in SystemUI that would maintain the show-on-unlock behavior would be to have an app that receives Intent.ACTION_USER_PRESENT broadcasts. However, this is not broadcast to to implicit receivers, so there would likely have to be an app running just to receive it. This dialog wouldn't even show up for users that regularly update, so it doesn't seem worth it. If we do ditch the behavior that it shows up on keyguard unlock and just use a non-dismissible notification that opens this full-screen dialog or an Activity, then a separate app could be feasible. However, it could result in code duplication. Doing it in SystemUI allows us to reuse other classes available here, which also makes consistency in theming super easy with future Android updates (since we're using the same code that launches SystemUI dialogs in general).

Assuming the user hasn't opened the popup from the notification, the popup dialog will only show up once after keyguard unlock for all non-system users and also once for the system user. We split it like this to compromise between two cases:

• Someone using multiple system users for themselves: It could be annoying to get the popup for every single user that they log into. But we also want to inform them that they should do updates in the main user (especially for the use case where they don't daily drive the main user)
• Sharing a phone with multiple people: The other people using the phone should be aware that the device is behind on security updates. Right now, only the owner and 1 other person will get the notification; if there are 3+ users accounts for 3+ different people, only 2 of them will be notified.

While we could expose a setting for this, it might actually encourage users to turn warnings off entirely. The user really should just update their phone! (Might be better just to have a per-user setting to indicate whether it's used by the same person as the main user, and then we read this setting. However, this approach could leak info about how the phone is used.)

We don't show buttons or links that would launch an intent when the device is not setup (in SetupWizard) or otherwise not provisioned.

We also have considerations for the screen pinning mode that can be launched via System UI as well as the fully locked mode that can be achieved on fully managed devices. No intents should be launched in locked task mode (especially because we include a web browser intent). Through testing, it doesn't seem like the popup is triggered when screen is pinned, since powering on the screen doesn't count as a keyguard unlock (i.e. whenever Intent.ACTION_USER_PRESENT would be sent out). Nevertheless, still need to be safe and check the locked task state.

[inthewaves]

A consequence of using JobScheduler: The JobService will still run periodically if SystemUI crashes, but it stops running periodically if the main user force stops the SystemUI app. The JobSchedulerService cancels jobs from apps if they're force stopped.

Seems like a simple thing is do to a regular check on unlock (1 per day) to see if job is still scheduled while the patch level expiry isn't disabled by user. The schedule here will make the dialog show up immediately if patch is expired and the job has been unexpectedly cancelled (and it has been more than 1 day since the last job schedule check on keyguard unlock).