apksigner - podpisuj i weryfikuj pliki APK systemu Android
apksigner [options] apk
apksigner --version
apksigner --help
Narzędzie wiersza poleceń do podpisywania plików APK Androida i sprawdzania, czy podpisy plików APK będą weryfikowane na urządzeniach z Androidem.
apk to istniejący plik do podpisania lub zweryfikowania.
apksig to projekt, który ma na celu uproszczenie podpisywania APK i sprawdzania, czy podpisy APK powinny być weryfikowane na Androidzie. apksig obsługuje podpisywanie JAR (używane przez Androida od pierwszego dnia) i APK Signature Scheme v2 (obsługiwane od Androida Nougat, poziom API 24).
Kluczową cechą apksig jest to, że wie o różnicach w logice weryfikacji podpisu APK między różnymi wersjami platformy Android. apksig może w ten sposób sprawdzić, czy podpisany plik APK ma być weryfikowany na wszystkich wersjach platformy Android obsługiwanych przez ten plik APK. Podczas podpisywania pliku APK apksig wybierze najbardziej odpowiednie algorytmy kryptograficzne w oparciu o wersje platformy Android obsługiwane przez podpisany plik APK.
sign
Spowoduje to podpisanie dostarczonego pliku APK, usuwając wszelkie istniejące wcześniej podpisy. Podpisywanie jest wykonywane przy użyciu jednego lub większej liczby podpisujących, z których każdy jest reprezentowany przez asymetryczną parę kluczy i odpowiedni certyfikat. Zazwyczaj plik APK jest podpisany tylko przez jednego sygnatariusza. Dla każdego sygnatariusza należy podać klucz prywatny i certyfikat sygnatariusza.
verify
To sprawdza, czy dostarczony plik APK zostanie zweryfikowany na Androidzie. Domyślnie sprawdza to, czy plik APK będzie weryfikowany na wszystkich wersjach platformy Android obsługiwanych przez pakiet APK (zgodnie z deklaracją przy użyciu minSdkVersion w pliku AndroidManifest.xml). Użyj opcji --min-sdk-version i/lub --max-sdk-version, aby zweryfikować plik APK pod kątem niestandardowego zakresu poziomów interfejsu API.
lineage
Modyfikuje to możliwości co najmniej jednego sygnatariusza w podanej linii SigningCertificateLineage. Można tego użyć do unieważnienia możliwości poprzedniego certyfikatu podpisywania po migracji bazy instalacji do nowego certyfikatu podpisywania.
rotate
Spowoduje to pobranie dostarczonych kluczy i utworzenie wpisu SigningCertificateLineage łączącego stary z nowym do użycia w scenariuszu rotacji kluczy przy użyciu schematu podpisu APK v3.
version
Pokaż numer wersji tego narzędzia i zamknij
help
Pokaż tę stronę użycia i wyjdź
Pełny tryb wyjściowy
Pokaż pomoc dotyczącą tego polecenia i wyjdź
Traktuj ostrzeżenia jako błędy
signPodpisz dostarczony plik APK
Plik, do którego ma zostać wysłany podpisany plik APK. Domyślnie plik APK jest podpisany na miejscu, co zastępuje plik wejściowy.
Najniższy poziom API, na którym będą weryfikowane podpisy tego pliku APK. Domyślnie używana jest wartość z pliku AndroidManifest.xml. Im wyższa wartość, tym silniejsze parametry bezpieczeństwa są używane podczas podpisywania.
Najwyższy poziom interfejsu API, na którym będą weryfikowane podpisy tego pliku APK. Domyślnie używana jest najwyższa możliwa wartość.
Czy włączyć podpisywanie przy użyciu schematu podpisywania JAR (znanego również jako schemat podpisywania v1, ten używany w Androidzie od pierwszego dnia). Domyślnie podpisywanie przy użyciu tego schematu jest włączone na podstawie minimalnej i maksymalnej wersji zestawu SDK (zobacz --min-sdk-version i --max-sdk-version).
Czy włączyć podpisywanie przy użyciu schematu podpisu APK v2 (znanego również jako schemat podpisywania v2, ten wprowadzony w Androidzie Nougat, poziom API 24). Domyślnie podpisywanie przy użyciu tego schematu jest włączone na podstawie minimalnej i maksymalnej wersji zestawu SDK (zobacz --min-sdk-version i --max-sdk-version).
per-signer optionsTe opcje określają konfigurację konkretnego sygnatariusza. Aby rozgraniczyć opcje różnych sygnatariuszy, użyj opcji --next-signer.
Ogranicza opcje dwóch różnych sygnatariuszy. Nie ma potrzeby korzystania z tej opcji, gdy używany jest tylko jeden podpisujący.
Nazwa podstawowa plików zawierających podpis schematu podpisu JAR (inaczej schemat v1) tego sygnatariusza. Domyślnie używany jest alias klucza KeyStore lub nazwa bazowa pliku klucza.
per-signer signing key & certificate optionsIstnieją dwa sposoby dostarczenia klucza prywatnego i certyfikatu osoby podpisującej: (1) Java KeyStore (patrz --ks) lub (2) plik klucza prywatnego w formacie PKCS #8 i plik certyfikatu w formacie X.509 (patrz --key i --cert).
Załaduj klucz prywatny i łańcuch certyfikatów z magazynu kluczy Java zainicjowanego z określonego pliku. BRAK oznacza, że magazyn kluczy nie potrzebuje żadnego pliku, co ma miejsce w przypadku niektórych magazynów kluczy PKCS #11.
Alias, pod którym klucz prywatny i certyfikat są przechowywane w magazynie kluczy. Należy to określić, jeśli magazyn kluczy zawiera wiele kluczy.
Hasło magazynu kluczy (patrz --ks). Obsługiwane są następujące formaty:
pass: hasło podane w wierszu
env: hasło podane w nazwanej zmiennej środowiskowej
plik: hasło podane w nazwanym pliku, jako pojedyncza linia
stdin hasło podane na standardowe wejście, jako pojedyncza linia
Do otwarcia magazynu kluczy wymagane jest hasło. Domyślnie narzędzie poprosi o podanie hasła za pomocą konsoli lub standardowego wejścia. Gdy ten sam plik (w tym standardowe wejście) jest używany do podawania wielu haseł, hasła są odczytywane z pliku po jednym wierszu na raz. Hasła są odczytywane w kolejności, w jakiej określono sygnatariuszy, a w przypadku każdego sygnatariusza hasło magazynu kluczy jest odczytywane przed odczytaniem hasła klucza.
Hasło, którym chroniony jest klucz prywatny. Domyślnie zakłada się, że klucze magazynu kluczy są chronione tym samym hasłem, co ich magazyn kluczy (patrz --ks-pass). Obsługiwane są następujące formaty:
pass: hasło podane w wierszu
env: hasło podane w nazwanej zmiennej środowiskowej
plik: hasło podane w nazwanym pliku, jako jednowierszowe hasło stdin podane na standardowe wejście, jako pojedyncza linia
Domyślnie, jeśli klucz jest chroniony hasłem, narzędzie poprosi o podanie hasła za pomocą konsoli lub standardowego wejścia. Gdy ten sam plik (w tym standardowe wejście) jest używany do podawania wielu haseł, hasła są odczytywane z pliku po jednym wierszu na raz. Hasła są odczytywane w kolejności, w jakiej określono sygnatariuszy, a w przypadku każdego sygnatariusza hasło magazynu kluczy jest odczytywane przed odczytaniem hasła klucza.
Dodatkowe kodowanie znaków (np. ibm437 lub utf-8) w przypadku haseł zawierających znaki spoza zestawu ASCII. Magazyny kluczy tworzone przez keytool są często szyfrowane nie przy użyciu postaci hasła Unicode, ale raczej przy użyciu formy utworzonej przez zakodowanie hasła przy użyciu kodowania znaków konsoli. apksigner domyślnie próbuje odszyfrować przy użyciu kilku form hasła: formularza Unicode, formularza zakodowanego przy użyciu domyślnego zestawu znaków JVM oraz, w Javie 8 i starszych, formularza zakodowanego przy użyciu zestawu znaków konsoli. W Javie 9 apksigner nie może wykryć zestawu znaków konsoli i może wymagać podania --pass-encoding, gdy używane jest hasło inne niż ASCII. --pass-encoding może być również konieczne dla KeyStore utworzonego przez keytool w innym systemie operacyjnym lub w innej lokalizacji.
Typ/algorytm magazynu kluczy do użycia. Domyślnie używany jest typ domyślny.
Nazwa dostawcy JCA, od którego należy zażądać implementacji KeyStore. Domyślnie używany jest dostawca o najwyższym priorytecie. Zobacz --ks-provider-class , aby zapoznać się z alternatywnym sposobem określania dostawcy.
W pełni kwalifikowana nazwa klasy dostawcy JCA, od którego należy zażądać implementacji magazynu kluczy. Domyślnie dostawca jest wybierany na podstawie --ks-provider-name.
Wartość do przekazania do konstruktora klasy JCA Provider określonej przez --ks-provider-class. Wartość jest przekazywana do konstruktora jako java.lang.String. Domyślnie używany jest konstruktor dostawcy bez argumentów.
Załaduj klucz prywatny z określonego pliku. Jeśli klucz jest chroniony hasłem, hasło zostanie poproszone przez standardowe wejście, chyba że określono inaczej za pomocą opcji --key-pass. Plik musi być w formacie PKCS #8 DER.
Załaduj łańcuch certyfikatów z określonego pliku. Plik musi być w formacie X.509 PEM lub DER.
verifySprawdź, czy dostarczony plik APK ma zostać zweryfikowany na Androidzie
Pokaż informacje o certyfikatach podpisywania pakietu APK
Najniższy poziom API, na którym będą weryfikowane podpisy tego pliku APK. Domyślnie używana jest wartość z pliku AndroidManifest.xml.
Najwyższy poziom interfejsu API, na którym będą weryfikowane podpisy tego pliku APK. Domyślnie używana jest najwyższa możliwa wartość.
apksigner sign --ks release.jks app.apk apksigner verify --verbose app.apk apksigner lineage --in /path/to/existing/lineage --print-certs -v apksigner rotate --out /path/to/new/file --old-signer --ks release.jks --new-signer --ks release2.jks
signPodpisz plik APK przy użyciu jedynego klucza w pliku keystore release.jks:
apksigner sign --ks release.jks app.apk
Podpisz plik APK przy użyciu klucza prywatnego i certyfikatu przechowywanych jako osobne pliki:
apksigner sign --key release.pk8 --cert release.x509.pem app.apk
Podpisz plik APK za pomocą dwóch kluczy:
apksigner sign --ks release.jks --next-signer --ks magic.jks app.apk
verifySprawdź, czy oczekuje się, że podpisy pliku APK będą weryfikowane na wszystkich platformach Android zadeklarowanych jako obsługiwane przez ten plik APK:
apksigner verify app.apk
Sprawdź, czy oczekuje się weryfikacji podpisów pakietu APK na platformach Android z interfejsem API na poziomie 15 lub wyższym:
apksigner verify --min-sdk-version 15 app.apk
lineageUsuń wszystkie możliwości poprzedniego sygnatariusza w linii:
apksigner lineage --in /path/to/existing/lineage --out /path/to/new/file --signer --ks release.jks --set-installed-data false --set-shared-uid false --set-permission false --set-rollback false --set-auth false
Wyświetl szczegóły dotyczące certyfikatów podpisywania i ich możliwości w rodowodzie:
apksigner lineage --in /path/to/existing/lineage --print-certs -v
rotateUtwórz nowy SigningCertificateLineage, aby włączyć rotację:
apksigner rotate --out /path/to/new/file --old-signer --ks release.jks --new-signer --ks release2.jks
Rozszerz istniejącą linię SigningCertificateLineage, aby ponownie obrócić po poprzedniej rotacji:
apksigner rotate --in /path/to/existing/lineage --out /path/to/new/file --old-signer --ks release2.jks --new-signer --ks release3.jks
Utwórz nowy SigningCertificateLineage z wyraźnymi możliwościami dla poprzedniego sygnatariusza:
apksigner rotate --out /path/to/new/file --old-signer --ks release.jks --set-installed-data true --set-shared-uid true --set-permission true --set-rollback false --set-auth true --new-signer --ks release2.jks
signapk(1) jar(1) zip(1) zipalign(1)
https://source.android.com/devices/tech/ota/sign_builds.html
Projekt Open Source Androida.