Konwertuj JAR na AAR

Projekt Android może wymagać AAR, gdy dostarczana biblioteka jest dystrybuowana jako JAR, ale wymaga również zasobów Android, wpisów w manifeście lub metadanych biblioteki. Konwersja pakuje istniejące klasy JVM w kontenerze biblioteki Android; nie konwertuje automatycznie kodu Java dla komputerów desktopowych na kod zgodny z Android.

Czym jest format JAR

JAR (Java ARchive) to pakiet oparty na ZIP, zawierający pliki JVM .class, zasoby, metadane i opcjonalnie manifest identyfikujący wykonywalną klasę główną. Biblioteki Java i Kotlin, aplikacje desktopowe, Maven, Gradle, IntelliJ IDEA oraz Android Studio często używają plików JAR.

JAR może być używany bezpośrednio przez projekt Android, gdy jego bytecode i zależności są zgodne z Android. Sam z siebie nie zapewnia zasobów Android, manifestu biblioteki Android, reguł R8 dla aplikacji korzystającej z biblioteki, bibliotek natywnych ani metadanych pakowania specyficznych dla Android.

Czym jest format AAR

AAR (Android ARchive) to format archiwum biblioteki Android używany przez Android Gradle Plugin. Jest to również plik ZIP, zwykle zawierający classes.jar i AndroidManifest.xml, a opcjonalnie także res/, assets/, jni/, prefab/, lint.jar, proguard.txt oraz pliki symboli zasobów.

AAR może dostarczać zasoby Android, deklaracje manifestu, biblioteki natywne, reguły shrinkera dla aplikacji korzystającej z biblioteki oraz skompilowany kod biblioteki jako jeden artefakt biblioteki Android. Gradle scala te komponenty w aplikacji. Archiwum nie zawiera automatycznie zewnętrznych zależności Maven; są one zwykle deklarowane w metadanych publikacji lub dostarczane oddzielnie.

Jak spakować JAR jako AAR

Najpierw sprawdź JAR

Przed spakowaniem wyświetl jego zawartość za pomocą narzędzia JDK:

jar tf vendor.jar

Upewnij się, że zawiera klasy biblioteki, a nie aplikację desktopową, i sprawdź poziom jego bytecode. Kompilator D8 firmy Android może przetwarzać obsługiwany bytecode Java, ale klasy wywołujące API dostępne wyłącznie na komputerach desktopowych, takie jak AWT, Swing lub niedostępne moduły JDK, nie staną się użyteczne na Android dzięki samemu pakowaniu.

Minimalny wrapper dla biblioteki pure Java

W przypadku JAR, który nie wymaga kodu źródłowego Android, zasobów ani dodatkowych deklaracji manifestu, utwórz katalog AAR zawierający JAR pod wymaganą nazwą classes.jar oraz 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)

W systemie Windows narzędzie JDK jar lub 7-Zip może utworzyć archiwum ZIP: dodaj classes.jar i AndroidManifest.xml w katalogu głównym archiwum, a następnie zapisz je jako vendor.aar. Nie umieszczaj ich w dodatkowym katalogu.

Jest to operacja pakowania, a nie kompilacja ani konwersja zależności. Jeśli JAR wymaga również zasobów Android, dodaj je w katalogu głównym AAR, w res/; zasoby aplikacji dodaj w assets/, a wymagane deklaracje — w AndroidManifest.xml.

Użyj modułu biblioteki Android do dodania elementów Android

1. W Android Studio wybierz File → New → New Module → Android Library i wybierz odpowiednią minimalną wersję SDK.
2. Umieść kod źródłowy Android, zasoby, zasoby aplikacji oraz deklaracje manifestu w katalogach src/main modułu.
3. Dodaj oryginalny JAR jako zależność czasu kompilacji, jeśli kod modułu go wywołuje:

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

W przypadku Kotlin DSL użyj implementation(files("libs/vendor.jar")). Zbudowanie modułu za pomocą ./gradlew :mylibrary:assembleRelease tworzy AAR w ścieżce takiej jak mylibrary/build/outputs/aar/mylibrary-release.aar.

Standardowe kompilowanie biblioteki Android zasadniczo nie osadza lokalnej zależności JAR w wynikowym AAR. Zależność pozostaje oddzielna, więc użytkownik biblioteki może potrzebować oryginalnego JAR. Aby dystrybuować jedno archiwum, użyj minimalnego wrappera, gdy nie jest potrzebny dodatkowy skompilowany kod Android, scal JAR z classes.jar za pomocą niestandardowego zadania pakowania albo użyj utrzymywanego pluginu Gradle fat-AAR po sprawdzeniu jego zgodności z wersją Android Gradle Plugin używaną w projekcie. Rozwiązanie fat-AAR może powodować duplikowanie klas i konflikty zależności.

Kontrole zgodności i jakości

Zmiana nazwy vendor.jar na vendor.aar jest nieprawidłowa, ponieważ AAR wymaga skompilowanej biblioteki w classes.jar oraz manifestu Android. Sprawdź archiwum za pomocą unzip -l vendor.aar lub 7-Zip.

Dopasuj poziom bytecode biblioteki do ustawień zgodności Java i Kotlin używanych podczas kompilowania Android. Sprawdź jej zależności przechodnie, wymagane uprawnienia lub komponenty manifestu, biblioteki natywne, odwołania do zasobów oraz reguły R8 dla aplikacji korzystającej z biblioteki; ręczny wrapper nie może wygenerować brakujących informacji.

Przetestuj AAR w oddzielnej aplikacji Android, używając zgodnych wersji Android Gradle Plugin, compile SDK i minimum SDK. Jeśli biblioteka zawiera wyłącznie klasy Java zgodne z Android i nie zawiera treści specyficznych dla Android, dystrybuowanie oryginalnego JAR może być prostsze niż tworzenie AAR.

Narzędzia online i desktopowe

Nie istnieje niezawodny, uniwersalny konwerter JAR-to-AAR online, ponieważ prawidłowy wynik zależy od zasobów Android, deklaracji manifestu, zależności i zgodności bytecode. Unikaj przesyłania zastrzeżonych bibliotek do internetowych usług archiwizacyjnych. Do budowania modułów używaj Android Studio z Android Gradle Plugin, a do przejrzystego lokalnego pakowania archiwów — polecenia JDK jar lub 7-Zip.