CVE-2024-40652 AI-generated analysis
platform/packages/apps/Settings, homepage (SettingsHomepageActivity)
SettingsHomepageActivity.onCreate now reads Settings.Global.DEVICE_PROVISIONED and immediately finishes the activity when the device is not yet provisioned, so the Settings homepage cannot be used before setup completes.
Root cause
SettingsHomepageActivity.onCreate performed no check of the device provisioning state. Any launch of the activity (the commit message cites launching via ADB during Setup, or tapping the Settings launcher icon after bypassing Setup) proceeded to build the full Settings homepage regardless of whether DEVICE_PROVISIONED was set, exposing Settings functionality during the setup phase.
How the fix works
- src/com/android/settings/homepage/SettingsHomepageActivity.java:onCreate: right after super.onCreate(), read android.provider.Settings.Global.DEVICE_PROVISIONED via getContentResolver() with default 0 (so a missing value is treated as unprovisioned).
- If the value is 0, log 'Device is not provisioned, exiting Settings' at error level, call finish(), and (in the Android 14 cherry-pick 2909433f7d59) return before any of the remaining onCreate logic (embedding/managed-profile forwarding, view setup) runs.
- The Android 15 base commit 70a5a0fd353c adds the same check but without the 'return;' after finish(), and adds a Robolectric test launch_deviceUnprovisioned_finish in tests/robotests/.../SettingsHomepageActivityTest.java plus a @Before that sets DEVICE_PROVISIONED=1 for the other tests.
- The code comment marks this as an interim measure (TODO b/331254029) to be replaced by an allowlist.
Completeness
- Covers SettingsHomepageActivity and its subclasses (context shows DeepLinkHomepageActivity is an instance of it), since the check is in the shared onCreate.
- The check is only in this one activity; other Settings entry points are not touched by this diff, so whether they are reachable before provisioning is not addressed here. The TODO in the code acknowledges the gate is interim pending an allowlist.
- The check is performed once in onCreate; it reads the global setting with default 0, so it fails closed when the setting is absent.
- In the Android 15 base diff there is no 'return;' after finish(), so the rest of onCreate still executes for an unprovisioned device (the activity is marked finishing but initialization continues). The Android 14 cherry-pick includes the 'return;'.
Behavior changes
- Launching the Settings homepage while DEVICE_PROVISIONED is 0 (or unset) now closes the activity immediately and logs 'Device is not provisioned, exiting Settings' at Log.e.
- Robolectric tests for SettingsHomepageActivity now require DEVICE_PROVISIONED=1 to be set in @Before (Android 15 test change).
Per major
- Android 14: same fix: RESTRICT AUTOMERGE cherry-pick 2909433f7d59 in android-security-14.0.0_r12, with finish() followed by return; 5/5 lines present at android-security-14.0.0_r29.
- Android 15: base fix 70a5a0fd353c in android-15.0.0_r1; the shown diff lacks the 'return;' after finish() and adds a Robolectric test; 8/8 lines of the patched region present at android-security-15.0.0_r17.
- Android 16: not affected (not listed by the bulletin); the patched region is present (5/5 lines) at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin); the patched region is present (5/5 lines) at android-security-17.0.0_r1.
Unknowns
- What specific Settings functionality was reachable pre-provisioning and what privilege was gained; the material only shows the gate being added.
- Whether a later Android 15 commit (e.g. the other cherry-pick c02f4ee1936e referenced in the commit message) added the 'return;' that the base diff omits.
- Whether other Settings activities received similar provisioning gates in separate commits.