CVE-2024-0017 AI-generated analysis
platform/packages/apps/Camera2, CameraActivity location/EXIF handling
Camera2's CameraActivity.shouldUseNoOpLocation() now returns true (use a no-op location) for a capture intent with no calling package (launched via startActivity rather than startActivityForResult). Otherwise it evaluates Camera2's own package permissions, instead of returning false whenever getCallingPackage() was null.
Root cause
shouldUseNoOpLocation() decides whether captured images get valid location in EXIF by checking the calling package's ACCESS_FINE_LOCATION grant. It relied on getCallingPackage(), which per the code comment is only set when the activity is started through startActivityForResult. When it returned null, the function returned false (do not use no-op location). A capture intent sent with plain startActivity also gives a null calling package. Per the commit message, Camera2 therefore unconditionally granted location to such starters, whatever location permission they held.
How the fix works
- src/com/android/camera/CameraActivity.java:shouldUseNoOpLocation(): when getCallingPackage() is null and isCaptureIntent() is true, return true (use no-op location).
- src/com/android/camera/CameraActivity.java:shouldUseNoOpLocation(): when getCallingPackage() is null and it is not a capture intent, set callingPackage to mAppContext.getPackageName(). The existing requestedPermissions / REQUESTED_PERMISSION_GRANTED loop then evaluates Camera2's own ACCESS_FINE_LOCATION grant instead of short-circuiting to false.
Completeness
- Covers the null-calling-package branch for both the capture-intent and the non-capture-intent cases. The non-null calling package path (startActivityForResult) is unchanged and still checks the caller's ACCESS_FINE_LOCATION grant.
- The new protection depends entirely on isCaptureIntent(). Its implementation and the intent actions it covers are not in the material, so the code shown does not tell whether every externally triggerable capture action is treated as a capture intent.
- The code after the permission loop (including the behaviour when packageInfo is null because getPackageInfo throws) is not shown, so the fallback for an unresolvable package is unknown.
Behavior changes
- When Camera2 is started with a capture intent via startActivity (no calling package), shouldUseNoOpLocation() now returns true, per the commit message so that location is not passed for this case.
- When Camera2 is started without a capture intent and with no calling package, the result now depends on Camera2's own ACCESS_FINE_LOCATION grant (the function returns false if it is granted) instead of always returning false.
Per major
- Android 14: same fix; commit 6dff83d2279f in android-security-14.0.0_r4, and all 5 patched lines are present at android-security-14.0.0_r29.
- Android 15: not affected per bulletin; the patched region is fully present (5/5 lines) at android-security-15.0.0_r17.
- Android 16: not affected per bulletin; 3/5 patched lines present at android-security-16.0.0_r8. The material does not show why the region differs.
- Android 17: not affected per bulletin; 3/5 patched lines present at android-security-17.0.0_r1. The material does not show why the region differs.
Unknowns
- Implementation of isCaptureIntent() and the set of intent actions it recognises.
- How the result of shouldUseNoOpLocation() is consumed, and whether location tagging settings or Camera2's permissions also gate it.
- The return value after the permission loop and the fallback when getPackageInfo fails.
- What changed in the patched region in Android 16/17 (only 3/5 lines match).