Convert JAR to AAR

An Android project may require an AAR when a supplied library is distributed as a JAR but also needs Android resources, manifest entries, or library metadata. The conversion packages the existing JVM classes in an Android library container; it does not automatically turn desktop Java code into Android-compatible code.

What the JAR format is

A JAR (Java ARchive) is a ZIP-based package containing JVM .class files, resources, metadata, and optionally a manifest that identifies an executable main class. Java and Kotlin libraries, desktop applications, Maven, Gradle, IntelliJ IDEA, and Android Studio commonly use JAR files.

A JAR can be used directly by an Android project when its bytecode and dependencies are Android-compatible. It does not inherently provide Android resources, an Android library manifest, consumer R8 rules, native libraries, or Android-specific packaging metadata.

What the AAR format is

An AAR (Android ARchive) is the Android Gradle Plugin's library archive format. It is also a ZIP file, normally containing classes.jar and AndroidManifest.xml, with optional res/, assets/, jni/, prefab/, lint.jar, proguard.txt, and resource-symbol files.

An AAR can deliver Android resources, manifest declarations, native libraries, consumer shrinker rules, and compiled library code as one Android library artifact. Gradle merges those components into an application. The archive does not automatically contain external Maven dependencies; those are normally declared in the publication metadata or supplied separately.

How to package a JAR as an AAR

Inspect the JAR first

List its contents with the JDK tool before packaging it:

jar tf vendor.jar

Confirm that it contains library classes rather than a desktop application, and check its Java bytecode level. Android's D8 compiler can process supported Java bytecode, but classes that call desktop-only APIs such as AWT, Swing, or unavailable JDK modules will not become usable on Android through packaging alone.

Minimal wrapper for a pure Java library

For a JAR that needs no Android source code, resources, or additional manifest declarations, create an AAR directory containing the JAR under the required name classes.jar and a manifest:

mkdir aar-temp
cp vendor.jar aar-temp/classes.jar
printf '%s\n' '<manifest xmlns:android="http://schemas.android.com/apk/res/android" />' > aar-temp/AndroidManifest.xml
(cd aar-temp && zip -r ../vendor.aar classes.jar AndroidManifest.xml)

On Windows, JDK jar or 7-Zip can create the ZIP archive: add classes.jar and AndroidManifest.xml at the archive root, then save it as vendor.aar. Do not place them inside an extra directory.

This is a packaging operation, not a compilation or dependency conversion. If the JAR also needs Android resources, add them at the AAR root under res/; add application assets under assets/ and required declarations to AndroidManifest.xml.

Use an Android library module for Android additions

1. In Android Studio, choose File → New → New Module → Android Library, and select an appropriate minimum SDK.
2. Put Android source, resources, assets, and manifest declarations in the module's src/main directories.
3. Add the original JAR as a compile-time dependency if the module's code calls it:

dependencies {
    implementation files('libs/vendor.jar')
}

For Kotlin DSL, use implementation(files("libs/vendor.jar")). Building the module with ./gradlew :mylibrary:assembleRelease creates an AAR at a path such as mylibrary/build/outputs/aar/mylibrary-release.aar.

A standard Android library build does not generally embed a local JAR dependency inside the resulting AAR. The dependency remains separate, so a consumer may need the original JAR. To distribute one archive, either use the minimal wrapper when no additional compiled Android code is needed, merge the JAR into classes.jar with a custom packaging task, or use a maintained fat-AAR Gradle plugin after verifying its compatibility with the project's Android Gradle Plugin version. A fat-AAR solution can create duplicate classes and dependency conflicts.

Compatibility and quality checks

Renaming vendor.jar to vendor.aar is invalid because an AAR expects the compiled library under classes.jar plus an Android manifest. Check the archive with unzip -l vendor.aar or 7-Zip.

Match the library's bytecode level with the Android build's Java and Kotlin compatibility settings. Check its transitive dependencies, required manifest permissions or components, native libraries, resource references, and consumer R8 rules; a manual wrapper cannot generate missing information.

Test the AAR in a separate Android application using compatible Android Gradle Plugin, compile SDK, and minimum SDK versions. If the library contains only Android-compatible Java classes and no Android-specific content, distributing the original JAR may be simpler than producing an AAR.

Online and desktop tools

There is no dependable general-purpose online JAR-to-AAR converter because the correct result depends on Android resources, manifest declarations, dependencies, and bytecode compatibility. Avoid uploading proprietary libraries to web archive services. Use Android Studio with the Android Gradle Plugin for module builds, and the JDK jar command or 7-Zip for transparent local archive packaging.