Fix camera capture crash on devices with lower RAM - #4635
Open
xkello wants to merge 1 commit into
Open
Conversation
Coverage Report for CI Build 30919175200Coverage increased (+0.01%) to 59.147%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions2 previously-covered lines in 2 files lost coverage.
Coverage Stats
💛 - Coveralls |
📦 Build Artifacts Ready
|
Withalion
reviewed
Aug 10, 2026
| } | ||
|
|
||
| takePictureIntent.putExtra("__RESULT__", "takePictureIntent__RESULT__"); | ||
| startForegroundService(new Intent(this, CameraForegroundService.class)); |
Collaborator
There was a problem hiding this comment.
Shouldn't the CameraForegroundService be started before this one gets created in AndroidUtils::callCamera?
Comment on lines
+200
to
+209
| if (cameraFile != null) { | ||
| try { | ||
| Uri photoURI = FileProvider.getUriForFile(this, | ||
| "uk.co.lutraconsulting.fileprovider", cameraFile); | ||
| revokeUriPermission(photoURI, | ||
| Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION); | ||
| } catch (IllegalArgumentException e) { | ||
| // cameraFile isn't covered by file_paths.xml -- nothing was granted, nothing to revoke | ||
| } | ||
| } |
Collaborator
There was a problem hiding this comment.
I would remove this as well
Comment on lines
+24
to
+29
| * Runs in the app's default process (unlike PositionTrackingService, which deliberately | ||
| * runs in its own :trackingThread) for as long as CameraActivity is waiting on the external | ||
| * camera app, to raise this process's priority and make it much less likely to be picked by | ||
| * the OS's low-memory killer while the (often heavy) OEM camera stack is in the foreground. | ||
| * This is a mitigation, not a guarantee -- under severe enough memory pressure the process can | ||
| * still be killed, which is what CameraActivity's saved-instance-state resume handles. |
Collaborator
There was a problem hiding this comment.
Suggested change
| * Runs in the app's default process (unlike PositionTrackingService, which deliberately | |
| * runs in its own :trackingThread) for as long as CameraActivity is waiting on the external | |
| * camera app, to raise this process's priority and make it much less likely to be picked by | |
| * the OS's low-memory killer while the (often heavy) OEM camera stack is in the foreground. | |
| * This is a mitigation, not a guarantee -- under severe enough memory pressure the process can | |
| * still be killed, which is what CameraActivity's saved-instance-state resume handles. | |
| * Runs in the app's default process for as long as CameraActivity is waiting on the external | |
| * camera app, to raise this process's priority and make it much less likely to be killed while the camera | |
| * is in the foreground. | |
| * This is a mitigation, not a guarantee -- under severe enough memory pressure the process can | |
| * still be killed, which is what CameraActivity's saved-instance-state resume handles. |
| .setContentIntent(pendingIntent) | ||
| .build(); | ||
|
|
||
| if (Build.VERSION.SDK_INT >= 35) { // Android 15 (Vanilla Ice Cream) -- FOREGROUND_SERVICE_TYPE_SHORT_SERVICE |
Collaborator
There was a problem hiding this comment.
Suggested change
| if (Build.VERSION.SDK_INT >= 35) { // Android 15 (Vanilla Ice Cream) -- FOREGROUND_SERVICE_TYPE_SHORT_SERVICE | |
| if (Build.VERSION.SDK_INT >= 35) { |
Comment on lines
+68
to
+71
| // Not START_STICKY: if this service alone gets killed there is nothing useful to resume -- | ||
| // it holds no state, it only exists to keep the process's priority elevated while | ||
| // CameraActivity waits on startActivityForResult(). | ||
| return START_NOT_STICKY; |
Collaborator
There was a problem hiding this comment.
Suggested change
| // Not START_STICKY: if this service alone gets killed there is nothing useful to resume -- | |
| // it holds no state, it only exists to keep the process's priority elevated while | |
| // CameraActivity waits on startActivityForResult(). | |
| return START_NOT_STICKY; | |
| // if this service alone gets killed there is nothing useful to resume, it only exists to | |
| // keep the process's priority elevated while CameraActivity waits on startActivityForResult(). | |
| return START_NOT_STICKY; |
Comment on lines
+96
to
+105
| // Explicitly grant URI permission to every app that can resolve this intent. | ||
| // Required because the URI is passed via EXTRA_OUTPUT rather than setData(), | ||
| // and some OEM camera apps (confirmed: Motorola) don't reliably honor the | ||
| // FLAG_GRANT_* flags in that case. | ||
| List<ResolveInfo> resolvedActivities = getPackageManager() | ||
| .queryIntentActivities(takePictureIntent, PackageManager.MATCH_DEFAULT_ONLY); | ||
| for (ResolveInfo resolveInfo : resolvedActivities) { | ||
| grantUriPermission(resolveInfo.activityInfo.packageName, photoURI, | ||
| Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION); | ||
| } |
Collaborator
There was a problem hiding this comment.
I have mixed feelings about this and it feels sloppy
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
On some devices with heavy OEM camera stacks (confirmed on Motorola, 4GB RAM), tapping "add photo" -> camera reliably crashed the app. Root cause, confirmed via multiple
adb logcatcaptures: launching the OS camera app spikes system-wide memory pressure, and Android'slowmemorykillerkills our own backgrounded process moments later - before the user can even take the photo. It's a silent OS process kill, not a Java exception (noFATAL EXCEPTIONin any capture).Fixes: #2784
What changed
CameraActivity.javagrantUriPermission()/revokeUriPermission()for the captureFileProviderURI - some OEM camera apps (confirmed: Motorola) don't reliably honorFLAG_GRANT_*flags when the URI is passed viaEXTRA_OUTPUTrather thansetData().onSaveInstanceState()/resume branch inonCreate()- if the process is killed and recreated by Android to redeliver a pending camera result, resume from the savedtargetPath/cameraFileinstead of relaunching the capture or losing track of the file.cameraFileinonActivityResult()- fails cleanly instead of aNullPointerExceptionif state wasn't restored.CameraForegroundService.java(new)oom_score_adj) for the duration the OS camera is in front, making the kill significantly less likely in the first place.AndroidManifest.xmlCameraForegroundService(foregroundServiceType="shortService",stopWithTask="true").Behaviour
Before: on affected devices, opening the camera from a form would kill the app outright - the project reloads from scratch and the in-progress edit is lost.
After: the process is kept in a protected priority tier for as long as the camera is open, verified directly via
adb-oom_score_adjstays at0/50during the camera wait, versus the700tier every observed kill happened at. If the process is still killed under extreme memory pressure,CameraActivitynow resumes and completes the capture correctly instead of crashing or silently corrupting the saved file.Before fix: #2784 (comment)
After fix:
screen-20260804-164203.mp4
TLDR @Withalion
Camera crash on some devices = OS killing our process under memory pressure while the OEM camera app is open, not a code bug. Fix is two-layered:
CameraForegroundServicereduces the odds of the kill (confirmed viaoom_score_adjmeasurement, not just crash/no-crash testing), andCameraActivity's save/resume logic makes it non-destructive if the kill happens anyway. No new user-facing UI - the foreground service's notification is intentionally not requested/shown (POST_NOTIFICATIONSnot requested), since the user doesn't need to know this is happening.