AppArmorX
Skip to content

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
ProfileResponse to a confirmed threatFirewallStartup gate
DEVELOPMENTObserve and record onlyOffOff
STANDARD (default)Block screenOnOff
HARDENEDBlock screenOnFail-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 evidenceRequest an evaluation build