Lower minSdk to 29 (Android 10) — closes #2

[ShubhamJ010]

Summary

Implements issue #2: lower minSdk from 34 (Android 14) to 29 (Android 10) so ssJanitor supports older devices, including custom ROMs / hardware stuck on Android 10–12.

Backward-compatible screenshot detection already used MediaStore + ContentObserver (the API-29 columns RELATIVE_PATH / IS_PENDING), so the real work was making the foreground service, permissions, and deletion model valid across the API 29–36 range.

Changes

• Build — minSdk 34 → 29 (app/build.gradle.kts).
• Manifest — Add READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE (maxSdk=32); keep specialUse + subtype (tolerated on older platforms, only used at runtime on API 34+).
• Foreground service — ScreenshotDetectionService now passes FOREGROUND_SERVICE_TYPE_SPECIAL_USE only on API 34+ (was >= Q, which crashed the FGS on 29–33).
• Permissions — New StoragePermissions helper: SDK-aware storage check and request (uses READ_EXTERNAL_STORAGE below 33, READ_MEDIA_IMAGES on 33+).
• Cleanup — ScreenshotCleanupWorker: silent background deletion gated to API 30+ (needs All-Files); manual/notification deletes via createDeleteRequest still work on 29+.
• UI — HomeScreen: uses the StoragePermissions helper; isAllFilesManager is now honest below API 30.
• Docs — README, docs/features.md, docs/development.md, fastlane listing, and CHANGELOG updated to Android 10+ with the API-29 auto-cleanup caveat.

Bugs fixed

• Permanent "Permissions Required" trap on API 29–32 — the old code always checked/requested READ_MEDIA_IMAGES (which doesn't exist below 33), so those devices could never grant storage access and detection never started.
• Foreground-service crash on API 29–33 — passing SPECIAL_USE to startForeground while the manifest didn't declare it threw SecurityException in onCreate.
• isAllFilesManager lie on API 29 — it was hardcoded true below API 30 even though All-Files doesn't exist there, masking that silent auto-cleanup can't run.

Verification

• ./gradlew assembleDebug and assembleRelease both BUILD SUCCESSFUL (including R8 minification and lintVital).
• Merged manifests confirm minSdkVersion="29", READ/WRITE_EXTERNAL_STORAGE, and retained specialUse.
• ⚠️ Runtime behavior across API 29–34 (detection, permission prompts, auto-cleanup on 30+) should still be verified on the emulator matrix per docs/development.md before merge.

Closes #2

[ShubhamJ010]

Review of PR #4 (Lower minSdk to 29). Overall the build/manifest/foreground-service changes are solid and CI is green. One blocking bug re-introduces the exact permission trap this PR targets, plus minor nits.\n\n## ⛔ Blocking: storage-permission result handling still hardcoded to READ_MEDIA_IMAGES (API 29-32)\n\napp/src/main/java/dev/sj010/ssjanitor/ui/screens/home/HomeScreen.kt:150-151\nkotlin\nhasStoragePermission =\n permissions[Manifest.permission.READ_MEDIA_IMAGES] ?: hasStoragePermission\n\nThe request path correctly uses StoragePermissions.requiredStoragePermission() (so on API 29-32 it asks for READ_EXTERNAL_STORAGE), but the result reader only looks up READ_MEDIA_IMAGES. RequestMultiplePermissions returns results keyed by the permissions actually requested, so on API 29-32 the map contains READ_EXTERNAL_STORAGE, not READ_MEDIA_IMAGES. The lookup returns null and falls back to the stale hasStoragePermission (still false).\n\nNet effect: on Android 10-12 a user can grant storage access, but the UI never leaves the "Permissions Required" state and keeps re-prompting — the exact trap the PR claims to fix. (hasStoragePermission is also not re-read on ON_RESUME, so returning to the app won't recover.)\n\nSuggested fix — re-query the helper instead of peeking the map:\nkotlin\nhasStoragePermission = StoragePermissions.hasStoragePermission(context)\n\n(or read permissions[StoragePermissions.requiredStoragePermission()]).\n\n## 🔸 Minor nits (non-blocking)\n1. isAllFilesManager returns true below API R (HomeScreen.kt:83-87). It hides the non-existent All-Files UI on API 29, which is the right UX, but the name now means "no grant needed" rather than "has grant". Add a comment/name tweak so future readers don't invert it.\n2. BootReceiver.goAsync() (BootReceiver.kt:13-20) calls finish() at the end without try/finally. If startDetectionService()/setReminderAlarm() throws, the pending result is never finished and the broadcast can be killed. Wrap in try/finally.\n3. deleteScreenshots API 29 path returns at the first RecoverableSecurityException (ScreenshotRepository.kt:118-120) and abandons remaining URIs. Fine for the single-screenshot notification delete, but a batch call on API 29 would stop early; consider collecting the intent sender and deleting the rest.\n\n## ✅ Looks good\n- minSdk 34→29, manifest maxSdk=32 storage perms, retained specialUse subtype — correct.\n- Foreground service passes type 0 below API 34 (was the crash source) and SPECIAL_USE only on 34+ — correct.\n- ScreenshotCleanupWorker gating silent deletion to API 30+ (All-Files) while manual/notification deletes work on 29+ — correct and well documented.\n- AlarmManager reminder with setExactAndAllowWhileIdle + canScheduleExactAlarms() fallback, re-armed on boot — correct.\n- CleanupSchedulerReminderTest covers lead-time clamping and past-time cases.\n\nPlease fix the result-handling bug and this is good to merge.