Mobile Platform Internals & Resource Management Questions

Approach summary (mobile dev perspective)
I’d build a hybrid client-driven + server-assisted sync that tolerates OS background limits, unreliable networks, and app updates by combining platform background APIs, push wake-ups, idempotent server endpoints, robust retry/backoff, deterministic conflict resolution, and strong observability.

Client scheduling (Android / iOS)

• Android: Use WorkManager with setRequiredNetworkType and ExpeditedWork when possible; mark tasks as unique by name so OS coalesces them. Respect Doze by using JobScheduler/WorkManager which the OS honors.
• iOS: Use BackgroundTasks (BGAppRefreshTask/BGProcessingTask) for periodic sync; use NSURLSession background uploads for large ops.
• Both: Attempt opportunistic sync when app foregrounds or network becomes available via Network callbacks.

Push wake-ups

• Use high-priority FCM / APNs silent pushes to trigger short sync windows. Include a minimal payload (sync type + server change token). Fallback: notify user to open app when silent push blocked.

Retry, backoff, jitter

• Exponential backoff with randomized jitter (full jitter) for retries. Cap max backoff and switch to server-driven retry-after when provided. Persist retry state across app restarts and updates.

Server: idempotency & change tracking

• All write endpoints accept idempotency-token (UUID) and return operation id + status.
• Server maintains logical change log / incremental sync tokens and tombstones for deletes. Support snapshot/version numbers for clients to request deltas.

Conflict resolution

• Prefer CRDTs for mergeable domain data. Otherwise: combine server-authoritative resolution (merge rules), last-writer-wins with vector clocks or per-field merges. Surface unresolved conflicts to client UI for user resolution when semantics require.

App updates & schema migrations

• Versioned payloads, feature flags, and server-side backward compatibility. Client includes schema version; server returns migration hints or rejects with clear error to trigger upgrade.

Observability

• Emit metrics: sync success/failure rates, latency, retries, conflict counts. Log per-operation ids, idempotency tokens, and device ids (hashed). Trace end-to-end with distributed tracing (trace id in pushes/requests). Alert on rising failure/conflict trends and long delta lag. Provide dashboards and debug endpoints for forced re-sync.

Why this works
Combines platform-friendly scheduling, minimizes wasted work via idempotency and tokens, reduces user-visible conflicts via merge strategies, and gives ops the signal to detect and remediate sync problems.

Situation & goal
Design an end-to-end program (automated + manual) so regulators can verify location/contacts are accessed only when declared — before every release.

High-level approach

• Prevent: static checks to ensure declarations exist and code doesn’t call APIs anonymously.
• Detect: runtime instrumentation in CI and prod debug builds to record actual API calls and prompts.
• Prove: generate signed audit artifacts (reports, screenshots, logs, SBOM).

Automated CI checks

• Manifest/Info.plist rule: fail if required keys missing or extra keys present.
  • Android: verify AndroidManifest.xml contains only declared uses-permission and rationale strings.
  • iOS: verify Info.plist has NSLocation*UsageDescription and NSContactsUsageDescription matching policy.
• Source-scan: run static analyzer + custom grep/AST rules to flag direct calls to LocationManager, FusedLocationProvider, ContactsContract, CNContactStore, and popular libs. Example CI step: run a Kotlin/Swift AST script that errors on blacklisted API usage outside guarded wrappers.
• Lint rules: add Android Lint and SwiftLint custom checks to enforce use of permission-wrapper functions.

Static analysis & policy enforcement

• Implement single permission-wrapper APIs (e.g., RequestLocation(), RequestContacts()) — require annotation @PermissionGate.
• Static analyzer enforces that only annotated wrappers call OS permission APIs. Use tools:
  • Android: ErrorProne or custom ASM/ktlint plugin.
  • iOS: SourceKit/clang-tidy script to find un-wrapped calls.
• Check that runtime prompt strings equal approved compliance text (regex compare to approved list).

Runtime monitoring (CI + release)

• In CI:
  • Instrumented UI tests (Espresso/XCUITest) that exercise flows and capture prompt screenshots and accessibility labels for consent.
  • Inject debug wrappers that log: timestamp, caller stack, permission type, decision, and purpose tag. Store logs as artifact.
• In release/debug builds:
  • Lightweight telemetry (privacy-preserving, hashed IDs) that records permission grants/uses and purpose tags, with user opt-out. Use local logs for auditable builds.
• Implement method interception:
  • Android: ProGuard rules + wrapper around FusedLocationProvider and ContentResolver; prohibit reflection to bypass.
  • iOS: Use function interposition in debug builds or method swizzling in Obj-C/Swift to log CNContactStore and CLLocationManager accesses.

Manual testing

• QA checklist and flows that must be executed: first-run flows, background access, denied-then-grant, edge OS versions.
• Capture:
  • Screenshots of OS prompts on typical devices (iOS 14/15+, Android 11+).
  • Screen recordings of full flows.
  • Repro steps and device logs (adb logcat / Console) collected into the release folder.

Audit artifact generation

• For each build produce signed bundle with:
  • Permission matrix CSV: declared permissions vs. code-flagged usages vs. runtime-use events.
  • Prompt screenshots and hashes.
  • Instrumented test results and logs (stack traces for each access).
  • Static-analysis report listing files and line numbers for permission API calls.
  • SBOM and third-party libs list.
• Automate packaging and GPG-sign artifact; upload to compliance storage with retention policy.

Verification & metrics

• Gate release by failing CI if:
  • Any runtime log shows permission use without matching declaration/purpose.
  • Static scan finds unwrapped API usage.
  • Prompt strings differ from approved text.
• Track KPIs: number of flagged accesses, time-to-fix, coverage of instrumented flows.

Trade-offs & safeguards

• Minimize runtime overhead by enabling heavy instrumentation only in CI/debug; use sampling/aggregation in production.
• Ensure telemetry is privacy-preserving and regulator-approved.

This combination of enforced wrapper patterns, static/AST checks, CI instrumented tests, runtime interception, curated manual flows, and signed audit artifacts provides determinism and reproducible evidence that location and contacts are only accessed as declared.

Strategy Overview

Perform an incremental, background-safe migration: add versioning, transform in chunks off-main-thread, track progress, and support rollback/atomic switches.

Steps

• Data versioning

  • Add a schema/version table or metadata key (e.g., DB_VERSION = 2).
  • Ship schema-first (add new columns/tables) so old and new models coexist.

• Incremental background job

  • Start a background WorkManager (Android) / BGTask + OperationQueue (iOS) to transform rows in batches (e.g., 1k–10k).
  • Use transactions per batch to keep ACID and reduce lock time.
  • Kotlin example (Room):

// run inside coroutine Dispatcher.IO
db.withTransaction {
  val rows = dao.fetchBatch(oldCursor, batchSize)
  dao.insertNew(rows.map { transform(it) })
  dao.markMigrated(rows.map { it.id })
  updateProgress()
}

• Swift/CoreData: use a private NSManagedObjectContext with performBackgroundTask and save per-batch.

• Non-blocking startup

  • On app launch, check DB_VERSION. If migration pending, allow app to run on old data but disable dependent features or show degraded UI. Start background job immediately.

• User notifications / progress UI

  • Expose progress via LiveData/Flow (Android) or NotificationCenter/Combine (iOS). Show lightweight progress bar or system notification for long migrations. Offer "Pause on cellular" or "Migrate now" option.

• Ensuring ACID & safe rollback

  • Use transactions per batch; write transformed rows to new tables first, then mark old rows as migrated. Only when all batches complete, flip DB_VERSION and delete old schema in a final transaction.
  • Keep a migration journal table recording batch checkpoints. On failure, the job restarts from last checkpoint; partial writes are rolled back by transaction.
  • For catastrophic failure, keep a copy/backup of DB file before starting (or rely on WAL + atomic file replace). Final schema removal should be atomic.

Trade-offs & Notes

• Batch size tuned by device memory/CPU.
• Background execution limits differ (iOS stricter) — schedule tasks accordingly and surface to user when required.
• Test extensively on low-end devices and interrupted flows.

Plan summary — goals

• Move user media to MediaStore / app-specific storage so files remain accessible under scoped storage.
• Preserve/accessibility: update app DB to map old absolute paths → content:// URIs, support third-party libs expecting file paths via FileProvider or temp copies.
• Maintain backward compatibility (API <29), avoid data loss.

Steps

1. Audit & requirements

   • Enumerate file types (images, video, documents), count, total size.
   • Decide targets: MediaStore (images/video/audio) vs SAF/app-specific for others.

2. Migration mechanics

   • Run migration off-main-thread with progress + resumable checkpoints.
   • For each legacy file:
     • Insert into MediaStore (or SAF) and stream-copy bytes, verify checksum/size.
     • On success, delete original.
     • Record mapping old_path → new_content_uri in a migration table; update app DB atomically (transaction).

Kotlin example — insert image into MediaStore and copy:

val values = ContentValues().apply {
  put(MediaStore.Images.Media.DISPLAY_NAME, file.name)
  put(MediaStore.Images.Media.MIME_TYPE, "image/jpeg")
  put(MediaStore.Images.Media.RELATIVE_PATH, "Pictures/MyApp")
}
val uri = contentResolver.insert(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, values)!!
contentResolver.openOutputStream(uri).use { out ->
  FileInputStream(file).use { input -> input.copyTo(out) }
}

3. Handling content URIs & third-party integrations

• Prefer storing content:// URIs in DB. When consumer needs filesystem path:
  • Use FileProvider to expose a streamed temporary file (create temp in cache, write contentResolver.openInputStream(uri), expose via FileProvider.getUriForFile). Grant URI permission intent flags for share.
  • For libraries needing File object (not URI), create temp file and pass its File path; ensure deletion after use.

4. Backward compatibility

• API 29: set requestLegacyExternalStorage=true temporarily to ease migration; ensure migration complete before removing.
• Use runtime branching:
  • if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) use MediaStore/SAF/content URIs
  • else continue using legacy paths.
• For devices <Q, keep original paths and sync mapping.

5. Edge cases & safety

• Handle name collisions by appending suffix.
• Resume after interruption using migration table and checksum comparisons.
• Preserve EXIF/meta when copying.
• Ensure permissions: READ/WRITE_EXTERNAL_STORAGE where required; request MANAGE_EXTERNAL_STORAGE only if absolutely necessary and justify to Play.

6. Rollout strategy

• Phased rollout with telemetry, small % first, validate migration success rates; provide in-app recovery (retry) and manual export.

Result: users keep their media intact, app uses modern APIs, third-party compatibility via FileProvider/temp files, and no data loss via verify-then-delete and mapping table.

Clarify goal & constraints
Track couriers only while a delivery session is active, minimize battery, comply with iOS/Android background limits and privacy rules.

High-level architecture

• Mobile client (iOS, Android) collects & batches locations → secure API gateway → backend ingestion + real-time websocket for dispatcher UI.
• Session manager controls start/stop, consent, and visibility.

iOS (CoreLocation)

• Use CLLocationManager with .startUpdatingLocation for foreground; for background use allowsBackgroundLocationUpdates = true and requestAlwaysAuthorization only if necessary.
• Desired accuracy: kCLLocationAccuracyNearestTenMeters or bestForNavigation only if in-vehicle.
• Update frequency: requestLocation intervals ~5–15s while moving; rely on distanceFilter (10–50m).
• Batching: accumulate locations, send when count/time threshold or on network change.
• Respect energy: use significantLocationChanges or visit monitoring when idle.

Android (FusedLocationProvider)

• Use FusedLocationProviderClient with LocationRequest.PRIORITY_HIGH_ACCURACY for active delivery; set interval 5–15s, smallestDisplacement 10–50m.
• Run as foreground service with Notification during active session to satisfy background execution.
• Batching: use setMaxWaitTime() to allow OS batching, send in batches.

Battery-saving techniques

• Adaptive sampling: higher rate when speed > X, else lower.
• Geofencing to wake/resume tracking near pickup/dropoff.
• Backoff when no movement; use hardware batching and Wi‑Fi/cell fallback when GPS unavailable.
• Compress/send deltas and use exponential backoff for network failures.

User-visible & privacy

• Android: persistent foreground notification showing session state and quick “Stop tracking”.
• iOS: present clear rationale in permission dialogs and Settings link; show in-app session UI and allow user to stop.
• Only request Always/Background location when essential; provide data retention policy, minimal retention, TLS, and disclose in privacy policy.

Compliance

• Handle OS prompts, explain use-cases, honor user revocation by stopping background updates, and log consent timestamps.