1USAGE: apksigner sign [options] apk 2 3This signs the provided APK, stripping out any pre-existing signatures. Signing 4is performed using one or more signers, each represented by an asymmetric key 5pair and a corresponding certificate. Typically, an APK is signed by just one 6signer. For each signer, you need to provide the signer's private key and 7certificate. 8 9 10 GENERAL OPTIONS 11 12--in Input APK file to sign. This is an alternative to 13 specifying the APK as the very last parameter, after all 14 options. Unless --out is specified, this file will be 15 overwritten with the resulting signed APK. 16 17--out File into which to output the signed APK. By default, the 18 APK is signed in-place, overwriting the input file. 19 20-v, --verbose Verbose output mode 21 22--v1-signing-enabled Whether to enable signing using JAR signing scheme (aka v1 23 signing scheme) used in Android since day one. By default, 24 signing using this scheme is enabled based on min and max 25 SDK version (see --min-sdk-version and --max-sdk-version). 26 27--v2-signing-enabled Whether to enable signing using APK Signature Scheme v2 28 (aka v2 signing scheme) introduced in Android Nougat, 29 API Level 24. By default, signing using this scheme is 30 enabled based on min and max SDK version (see 31 --min-sdk-version and --max-sdk-version). 32 33--v3-signing-enabled Whether to enable signing using APK Signature Scheme v3 34 (aka v3 signing scheme) introduced in Android P, 35 API Level 28. By default, signing using this scheme is 36 enabled based on min and max SDK version (see 37 --min-sdk-version and --max-sdk-version). Multiple 38 signers are not supported when using v3 signing, but 39 multiple signers may be provided in conjunction with the 40 "lineage" option to make sure that the app is signed by 41 an appropriate signer on all supported platform versions. 42 43--v4-signing-enabled Whether to enable signing using APK Signature Scheme v4 44 (aka v4 signing scheme) introduced in Android 11, 45 API Level 30. By default, signing using this scheme is 46 enabled based on min and max SDK version (see 47 --min-sdk-version and --max-sdk-version). 48 49--force-stamp-overwrite Whether to overwrite existing source stamp in the 50 APK, if found. By default, it is set to false. It has no 51 effect if no source stamp signer config is provided. 52 53--verity-enabled Whether to enable the verity signature algorithm for the 54 v2 and v3 signature schemes. 55 56--min-sdk-version Lowest API Level on which this APK's signatures will be 57 verified. By default, the value from AndroidManifest.xml 58 is used. The higher the value, the stronger security 59 parameters are used when signing. 60 61--max-sdk-version Highest API Level on which this APK's signatures will be 62 verified. By default, the highest possible value is used. 63 64--debuggable-apk-permitted Whether to permit signing android:debuggable="true" 65 APKs. Android disables some of its security protections 66 for such apps. For example, anybody with ADB shell access 67 can execute arbitrary code in the context of a debuggable 68 app and can read/write persistently stored data of the 69 app. It is a good security practice to not sign 70 debuggable APKs with production signing keys, because 71 such APKs puts users at risk once leaked. 72 By default, signing debuggable APKs is permitted, for 73 backward compatibility with older apksigner versions. 74 75--lineage Signing certificate history to use in the event that 76 signing certificates changed for an APK using APK 77 Signature Scheme v3 supported signing certificate 78 rotation. This object may be created by the apksigner 79 "rotate" command. If used, all signers used to sign the 80 APK must be present in the signing lineage, 81 and if v1 or v2 signing is enabled, the first (oldest) 82 entry in the lineage must have a signer provided, so that 83 it can be used for those v1 and/or v2 signing. Multiple 84 signers are not supported when using APK Signature Scheme 85 v3, so multiple signers input will correspond to different 86 points in the lineage and will be used on older platform 87 versions when the newest signer in the lineage is 88 unsupported. 89 An APK previously signed with a SigningCertificateLineage 90 can also be specified; the lineage will then be read from 91 the signed data in the APK. 92 93-h, --help Show help about this command and exit 94 95 96 PER-SIGNER OPTIONS 97These options specify the configuration of a particular signer. To delimit 98options of different signers, use --next-signer. 99 100--next-signer Delimits options of two different signers. There is no 101 need to use this option when only one signer is used. 102 103--v1-signer-name Basename for files comprising the JAR signature scheme 104 (aka v1 scheme) signature of this signer. By default, 105 KeyStore key alias or basename of key file is used. 106 107--stamp-signer The signing information for the signer of the source stamp 108 to be included in the APK. 109 110 PER-SIGNER SIGNING KEY & CERTIFICATE OPTIONS 111There are two ways to provide the signer's private key and certificate: (1) Java 112KeyStore (see --ks), or (2) private key file in PKCS #8 format and certificate 113file in X.509 format (see --key and --cert). 114 115--ks Load private key and certificate chain from the Java 116 KeyStore initialized from the specified file. NONE means 117 no file is needed by KeyStore, which is the case for some 118 PKCS #11 KeyStores. 119 120--ks-key-alias Alias under which the private key and certificate are 121 stored in the KeyStore. This must be specified if the 122 KeyStore contains multiple keys. 123 124--ks-pass KeyStore password (see --ks). The following formats are 125 supported: 126 pass:<password> password provided inline 127 env:<name> password provided in the named 128 environment variable 129 file:<file> password provided in the named 130 file, as a single line 131 stdin password provided on standard input, 132 as a single line 133 A password is required to open a KeyStore. 134 By default, the tool will prompt for password via console 135 or standard input. 136 When the same file (including standard input) is used for 137 providing multiple passwords, the passwords are read from 138 the file one line at a time. Passwords are read in the 139 order in which signers are specified and, within each 140 signer, KeyStore password is read before the key password 141 is read. 142 143--key-pass Password with which the private key is protected. 144 The following formats are supported: 145 pass:<password> password provided inline 146 env:<name> password provided in the named 147 environment variable 148 file:<file> password provided in the named 149 file, as a single line 150 stdin password provided on standard input, 151 as a single line 152 If --key-pass is not specified for a KeyStore key, this 153 tool will attempt to load the key using the KeyStore 154 password and, if that fails, will prompt for key password 155 and attempt to load the key using that password. 156 If --key-pass is not specified for a private key file key, 157 this tool will prompt for key password only if a password 158 is required. 159 When the same file (including standard input) is used for 160 providing multiple passwords, the passwords are read from 161 the file one line at a time. Passwords are read in the 162 order in which signers are specified and, within each 163 signer, KeyStore password is read before the key password 164 is read. 165 166--pass-encoding Additional character encoding (e.g., ibm437 or utf-8) to 167 try for passwords containing non-ASCII characters. 168 KeyStores created by keytool are often encrypted not using 169 the Unicode form of the password but rather using the form 170 produced by encoding the password using the console's 171 character encoding. apksigner by default tries to decrypt 172 using several forms of the password: the Unicode form, the 173 form encoded using the JVM default charset, and, on Java 8 174 and older, the form encoded using the console's charset. 175 On Java 9, apksigner cannot detect the console's charset 176 and may need to be provided with --pass-encoding when a 177 non-ASCII password is used. --pass-encoding may also need 178 to be provided for a KeyStore created by keytool on a 179 different OS or in a different locale. 180 181--ks-type Type/algorithm of KeyStore to use. By default, the default 182 type is used. 183 184--ks-provider-name Name of the JCA Provider from which to request the 185 KeyStore implementation. By default, the highest priority 186 provider is used. See --ks-provider-class for the 187 alternative way to specify a provider. 188 189--ks-provider-class Fully-qualified class name of the JCA Provider from which 190 to request the KeyStore implementation. By default, the 191 provider is chosen based on --ks-provider-name. 192 193--ks-provider-arg Value to pass into the constructor of the JCA Provider 194 class specified by --ks-provider-class. The value is 195 passed into the constructor as java.lang.String. By 196 default, the no-arg provider's constructor is used. 197 198--key Load private key from the specified file. If the key is 199 password-protected, the password will be prompted via 200 standard input unless specified otherwise using 201 --key-pass. The file must be in PKCS #8 DER format. 202 203--cert Load certificate chain from the specified file. The file 204 must be in X.509 PEM or DER format. 205 206 207 JCA PROVIDER INSTALLATION OPTIONS 208These options enable you to install additional Java Crypto Architecture (JCA) 209Providers, such as PKCS #11 providers. Use --next-provider to delimit options of 210different providers. Providers are installed in the order in which they appear 211on the command-line. 212 213--provider-class Fully-qualified class name of the JCA Provider. 214 215--provider-arg Value to pass into the constructor of the JCA Provider 216 class specified by --provider-class. The value is passed 217 into the constructor as java.lang.String. By default, the 218 no-arg provider's constructor is used. 219 220--provider-pos Position / priority at which to install this provider in 221 the JCA provider list. By default, the provider is 222 installed as the lowest priority provider. 223 See java.security.Security.insertProviderAt. 224 225 226 EXAMPLES 227 2281. Sign an APK, in-place, using the one and only key in keystore release.jks: 229$ apksigner sign --ks release.jks app.apk 230 2311. Sign an APK, without overwriting, using the one and only key in keystore 232 release.jks: 233$ apksigner sign --ks release.jks --in app.apk --out app-signed.apk 234 2353. Sign an APK using a private key and certificate stored as individual files: 236$ apksigner sign --key release.pk8 --cert release.x509.pem app.apk 237 2384. Sign an APK using two keys: 239$ apksigner sign --ks release.jks --next-signer --ks magic.jks app.apk 240 2415. Sign an APK using PKCS #11 JCA Provider: 242$ apksigner sign --provider-class sun.security.pkcs11.SunPKCS11 \ 243 --provider-arg token.cfg --ks NONE --ks-type PKCS11 app.apk 244 2456. Sign an APK using a non-ASCII password KeyStore created on English Windows. 246 The --pass-encoding parameter is not needed if apksigner is being run on 247 English Windows with Java 8 or older. 248$ apksigner sign --ks release.jks --pass-encoding ibm437 app.apk 249 2507. Sign an APK on Windows using a non-ASCII password KeyStore created on a 251 modern OSX or Linux machine: 252$ apksigner sign --ks release.jks --pass-encoding utf-8 app.apk 253 2548. Sign an APK with rotated signing certificate: 255$ apksigner sign --ks release.jks --next-signer --ks release2.jks \ 256 --lineage /path/to/signing/history/lineage app.apk 257