Fix camera capture crash on devices with lower RAM

[xkello]

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 logcat captures: launching the OS camera app spikes system-wide memory pressure, and Android's lowmemorykiller kills 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 (no FATAL EXCEPTION in any capture).

Fixes: #2784

What changed

• CameraActivity.java
  • Explicit grantUriPermission()/revokeUriPermission() for the capture FileProvider URI - some OEM camera apps (confirmed: Motorola) don't reliably honor FLAG_GRANT_* flags when the URI is passed via EXTRA_OUTPUT rather than setData().
  • onSaveInstanceState()/resume branch in onCreate() - if the process is killed and recreated by Android to redeliver a pending camera result, resume from the saved targetPath/cameraFile instead of relaunching the capture or losing track of the file.
  • Null-guard on cameraFile in onActivityResult() - fails cleanly instead of a NullPointerException if state wasn't restored.
• CameraForegroundService.java (new)
  • Started right before the camera intent, stopped as soon as a result comes back. Keeps the process in a protected priority tier (oom_score_adj) for the duration the OS camera is in front, making the kill significantly less likely in the first place.
• AndroidManifest.xml
  • Registers CameraForegroundService (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_adj stays at 0/50 during the camera wait, versus the 700 tier every observed kill happened at. If the process is still killed under extreme memory pressure, CameraActivity now 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: CameraForegroundService reduces the odds of the kill (confirmed via oom_score_adj measurement, not just crash/no-crash testing), and CameraActivity'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_NOTIFICATIONS not requested), since the user doesn't need to know this is happening.

[github-actions]

Coverage Report for CI Build 30919175200

Coverage increased (+0.01%) to 59.147%

Details

• Coverage increased (+0.01%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 2 coverage regressions across 2 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

2 previously-covered lines in 2 files lost coverage.

File	Lines Losing Coverage	Coverage
mm/app/position/providers/simulatedpositionprovider.cpp	1	91.67%
mm/core/merginuserinfo.cpp	1	79.08%

---

Coverage Stats

Relevant Lines:	15678
Covered Lines:	9273
Line Coverage:	59.15%
Coverage Strength:	98.14 hits per line

---

💛 - Coveralls

[github-actions]

📦 Build Artifacts Ready

OS	Status	Build	Info	Workflow run
macOS Build	❌	Build failed or not found.		#7129
linux Build	📬	Mergin Maps 71551 x86_64	Expires: 02/11/2026	#7155
win64 Build	❌	Build failed or not found.		#6331
Android Build	❌	Build failed or not found.		#8440
iOS Build	❌	Build failed or not found.		#9381