Android engine · 0.1.0 pre-release

Evaluate the runtime
engine locally.

The plugin is not on the Gradle Plugin Portal yet, so evaluation resolves it from Maven Local. One plugin line, no initialization code, no source changes in your app.

1. Resolve from Maven Local

settings.gradle.kts

Until public distribution, ask for an evaluation build, publish it to your local Maven repository, and let Gradle look there first.

settings.gradle.kts

pluginManagement {
    repositories {
        mavenLocal()
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

2. Apply the plugin

app/build.gradle.kts

Application modules only. Applying it to a library module fails the build by design.

app/build.gradle.kts

plugins {
    id("com.android.application")
    id("com.apparmorx.security") version "0.1.0"
}

3. Build a release

Configuration Cache supported

Terminal

./gradlew assembleRelease --configuration-cache

The build verifies the signed policy, rewrites supported bytecode, bundles the native engine for arm64-v8a and x86_64, audits the merged manifest, and fails if required protection is missing from the packaged APK.

4. Read the report

Build outputs, not your source

build/reports/apparmorx

build/reports/apparmorx/protection-report-release.html
build/reports/apparmorx/security-audit-release.sarif

The HTML report is self-contained and script-free: verdict, active layers, overrides, and payload digests. The SARIF 2.1.0 file is ready for GitHub Code Scanning or SonarQube.

Choose a protection profile

With no configuration you get STANDARD. Any explicit override weaker than the profile is flagged as WEAKENED in the report.

Protection profiles
Profile	Response to a confirmed threat	Firewall	Startup gate
DEVELOPMENT	Observe and record only	Off	Off
STANDARD (default)	Block screen	On	Off
HARDENED	Block screen	On	Fail-closed

build.gradle.kts

security {
    profile.set("HARDENED")   // DEVELOPMENT | STANDARD | HARDENED
}

Rules every profile follows

Debuggable variants never enforce a response, so your own debugger cannot lock you out. Unavailable or indeterminate evidence never triggers enforcement unless you opt in. Configuration findings, such as cleartext traffic being permitted, are advisory and never block users. No profile kills the process by default.

Why does my release build on an emulator look flagged?

The emulator probe is expected to report an emulator. Test release behavior on a real device, or use the DEVELOPMENT profile.

What does this not do?

It does not make a compromised device trustworthy and does not replace server-side authorization. See what was tested and where it stops.

See the evidence Request an evaluation build