Native Android SDK: Remote Control, Device Telemetry and Crash Reporting

A production checklist for adding remote access control, compact telemetry and the standalone crash reporter to Kotlin and Java Android apps.

Updated · 9 min read

Add the official Maven Central package

Use the published uk.devguard:android-sdk artifact from Maven Central rather than a local module copy. Pin an explicit version in your Gradle files, resolve it in CI, and keep the same coordinate in release notes so support teams can match a production build to a known SDK release.

Create a dedicated DevGuard project for each Android application package name. Store the project identifier and master secret in your approved secret store or CI vault. Never commit production secrets to source control, and never reuse a single project across unrelated client apps.

  • Confirm the Gradle coordinate matches the version shown on the DevGuard docs page.
  • Resolve the dependency in a release-mode assemble task before shipping.
  • Keep debug and production DevGuard projects separate.
  • Record who owns the project after client handover.

Initialize protection early in the application lifecycle

Initialize the SDK before UI that depends on access status is shown. A common pattern is to start protection from Application.onCreate or an early activity entry point, then gate the main experience on the current remote status. Treat active, warning and locked as first-class application states instead of scattering ad-hoc checks across fragments.

Signed heartbeat responses help the client detect tampering between the service and the SDK. Leave signature verification enabled in production and keep any development bypass flags off by default.

Choose heartbeat, sync and offline behavior deliberately

Configure how often devices check in, how long a cached decision remains valid and whether the app fails open or closed when the control service cannot be reached. Freelancer delivery builds often prefer a reversible pause with a professional lock screen, while regulated environments may require a stricter offline policy.

Test airplane mode, captive portals and background-to-foreground refresh on physical devices. Emulators alone are not enough for radio timing, OEM battery restrictions or Play integrity edge cases.

Wire crash reporting without duplicating vault loggers

Native Android ships a standalone crash-reporter module alongside the licensing SDK. Capture uncaught exceptions with enough build metadata to triage releases, but avoid attaching tokens, passwords or full user records. Keep local diagnostic vault logging separate from cloud crash telemetry so privacy settings stay understandable.

Verify symbolication and ProGuard mapping uploads for release builds. A controlled test crash in a staging project should appear in the Admin crash views before you rely on the pipeline in production.

Android release verification checklist

Exercise active, warning and locked states on at least one phone and one tablet form factor. Confirm unlock keys, on-device messages, version overrides and status refresh after process death. Re-run the checks after upgrading AGP, Kotlin or the DevGuard SDK.

After launch, monitor device check-ins and crash groups, review team permissions and rehearse the restore procedure. Remote control is production-ready only when the team can reverse a change safely and explain the user impact.

Review official SDK documentation