Making device risk explainable.

THE PROBLEM

A single flag hides the reasoning.

DeviceTrust is my independent work on device intelligence for Android. The engineering problem is to collect useful integrity indicators and make the resulting assessment understandable to the team integrating it.

A product needs to know what contributed to a risk assessment. It also needs room to choose its response: the tolerance for an emulator in a development workflow can differ from the tolerance in a sensitive customer journey.

SDK DESIGN

Keep evidence separate from interpretation.

I built a coroutine-based Kotlin API with native C++/NDK checks. The checks cover root artifacts, runtime instrumentation, emulator indicators, and system integrity, including bootloader and platform security state.

The SDK exposes weighted signals and versioned evidence alongside a score and risk level. Consumers can inspect the inputs, tune thresholds, implement a policy, or collect evidence without local scoring. That separation gives integration teams control over how they interpret the result.

ENGINEERING DECISIONS

Make the integration contract explicit.

The public API keeps assessment asynchronous. File and system inspection run on an I/O dispatcher, and the host can call the SDK from a lifecycle-aware coroutine.

The packaging includes consumer R8 rules and native binaries for ARM64, ARMv7, x86, and x86_64. These details are part of the SDK’s integration surface: native checks need to remain usable across the architectures and optimized builds that consumers ship.

Configurable policy is also a tradeoff. It lets a team adapt the assessment to its product, but the team still needs to validate its thresholds against representative devices and its own risk requirements.

val deviceTrust = DeviceTrust.create(
    policy = DefaultTrustPolicy(
        reviewThreshold = 30,
        highRiskThreshold = 70,
    )
)

viewModelScope.launch {
    val assessment = deviceTrust.assess()
    _state.update { it.copy(assessment = assessment) }
}

SECURITY BOUNDARIES

Be precise about what the evidence can establish.

Local checks have a limit: an attacker controlling the operating system can alter what the application observes. A risk score therefore represents the collected indicators; it cannot establish that a device is trustworthy.

Sensitive authorization decisions belong on the server, where the application can combine these signals with server-verified Play Integrity results and account or request context. Detailed evidence also needs deliberate logging, retention, and privacy choices.

RESULT & NEXT STEPS

An inspectable SDK, with room for validation.

The repository provides the Android library, a Compose sample application, and unit-test and build instructions. The concrete output is an integration that exposes both its evidence and its policy choices.

I’m presenting this as an SDK design and implementation case study. Measured detection accuracy, false-positive rates, and production fraud outcomes would need a defined evaluation set and deployment evidence. Those are the next pieces of validation to establish.