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--align-file-size Produces APK file sized as multiples of 4K bytes. 54 55--verity-enabled Whether to enable the verity signature algorithm for the 56 v2 and v3 signature schemes. 57 58--min-sdk-version Lowest API Level on which this APK's signatures will be 59 verified. By default, the value from AndroidManifest.xml 60 is used. The higher the value, the stronger security 61 parameters are used when signing. 62 63--max-sdk-version Highest API Level on which this APK's signatures will be 64 verified. By default, the highest possible value is used. 65 66--rotation-min-sdk-version Lowest API Level for which an APK's rotated signing 67 key should be used to produce the APK's signature. The 68 original signing key for the APK will be used for all 69 previous platform versions. Specifying a value <= 32 70 (Android Sv2) will result in the original V3 signing block 71 being used without platform targeting. By default, 72 rotated signing keys will be used with the V3.1 signing 73 block which supports Android T+. 74 75--rotation-targets-dev-release The specified rotation-min-sdk-version is intended 76 for a platform release under development. During development 77 of a new platform, the API Level of the previously released 78 platform is used as the API Level of the development 79 platform until the SDK is finalized. This flag allows 80 targeting signing key rotation to a development platform 81 with API Level X while preventing the rotated key from being 82 used on the latest release platform with API Level X. 83 84--debuggable-apk-permitted Whether to permit signing android:debuggable="true" 85 APKs. Android disables some of its security protections 86 for such apps. For example, anybody with ADB shell access 87 can execute arbitrary code in the context of a debuggable 88 app and can read/write persistently stored data of the 89 app. It is a good security practice to not sign 90 debuggable APKs with production signing keys, because 91 such APKs puts users at risk once leaked. 92 By default, signing debuggable APKs is permitted, for 93 backward compatibility with older apksigner versions. 94 95--lineage Signing certificate history to use in the event that 96 signing certificates changed for an APK using APK 97 Signature Scheme v3 supported signing certificate 98 rotation. This object may be created by the apksigner 99 "rotate" command. If used, all signers used to sign the 100 APK must be present in the signing lineage, 101 and if v1 or v2 signing is enabled, the first (oldest) 102 entry in the lineage must have a signer provided, so that 103 it can be used for those v1 and/or v2 signing. Multiple 104 signers are not supported when using APK Signature Scheme 105 v3, so multiple signers input will correspond to different 106 points in the lineage and will be used on older platform 107 versions when the newest signer in the lineage is 108 unsupported. 109 An APK previously signed with a SigningCertificateLineage 110 can also be specified; the lineage will then be read from 111 the signed data in the APK. 112 113--deterministic-dsa-signing When signing with the DSA signature algorithm, 114 whether to use the deterministic version as specified in 115 RFC 6979. 116 117--append-signature Appends the current signature to any signatures that 118 already exist within the APK. This option can be used 119 when an APK is signed by multiple independent signers to 120 allow each to add their own signature without needing to 121 share their private key. This option can also be used to 122 preserve existing key / value blocks that exist within the 123 APK signing block. 124 125-h, --help Show help about this command and exit 126 127 128 PER-SIGNER OPTIONS 129These options specify the configuration of a particular signer. To delimit 130options of different signers, use --next-signer. 131 132--next-signer Delimits options of two different signers. There is no 133 need to use this option when only one signer is used. 134 135--v1-signer-name Basename for files comprising the JAR signature scheme 136 (aka v1 scheme) signature of this signer. By default, 137 KeyStore key alias or basename of key file is used. 138 139--stamp-signer The signing information for the signer of the source stamp 140 to be included in the APK. 141 142--signer-for-min-sdk-version <SDK> Requires an int value indicating the minimum 143 SDK version for which this signing config should be used 144 to produce the APK's signature. The value should be >= 28 145 (Android P), and any value <= 32 will apply to Android P 146 through Sv2 (SDK versions 28 - 32); since the V3.0 147 signature scheme does not support verified SDK version 148 targeting, only a single signing config <= 32 can be 149 specified. 150 151--signer-lineage The lineage to be used for the current SDK targeted 152 signing config. 153 154 PER-SIGNER SIGNING KEY & CERTIFICATE OPTIONS 155There are two ways to provide the signer's private key and certificate: (1) Java 156KeyStore (see --ks), or (2) private key file in PKCS #8 format and certificate 157file in X.509 format (see --key and --cert). 158 159--ks Load private key and certificate chain from the Java 160 KeyStore initialized from the specified file. NONE means 161 no file is needed by KeyStore, which is the case for some 162 PKCS #11 KeyStores. 163 164--ks-key-alias Alias under which the private key and certificate are 165 stored in the KeyStore. This must be specified if the 166 KeyStore contains multiple keys. 167 168--ks-pass KeyStore password (see --ks). The following formats are 169 supported: 170 pass:<password> password provided inline 171 env:<name> password provided in the named 172 environment variable 173 file:<file> password provided in the named 174 file, as a single line 175 stdin password provided on standard input, 176 as a single line 177 A password is required to open a KeyStore. 178 By default, the tool will prompt for password via console 179 or standard input. 180 When the same file (including standard input) is used for 181 providing multiple passwords, the passwords are read from 182 the file one line at a time. Passwords are read in the 183 order in which signers are specified and, within each 184 signer, KeyStore password is read before the key password 185 is read. 186 187--key-pass Password with which the private key is protected. 188 The following formats are supported: 189 pass:<password> password provided inline 190 env:<name> password provided in the named 191 environment variable 192 file:<file> password provided in the named 193 file, as a single line 194 stdin password provided on standard input, 195 as a single line 196 If --key-pass is not specified for a KeyStore key, this 197 tool will attempt to load the key using the KeyStore 198 password and, if that fails, will prompt for key password 199 and attempt to load the key using that password. 200 If --key-pass is not specified for a private key file key, 201 this tool will prompt for key password only if a password 202 is required. 203 When the same file (including standard input) is used for 204 providing multiple passwords, the passwords are read from 205 the file one line at a time. Passwords are read in the 206 order in which signers are specified and, within each 207 signer, KeyStore password is read before the key password 208 is read. 209 210--pass-encoding Additional character encoding (e.g., ibm437 or utf-8) to 211 try for passwords containing non-ASCII characters. 212 KeyStores created by keytool are often encrypted not using 213 the Unicode form of the password but rather using the form 214 produced by encoding the password using the console's 215 character encoding. apksigner by default tries to decrypt 216 using several forms of the password: the Unicode form, the 217 form encoded using the JVM default charset, and, on Java 8 218 and older, the form encoded using the console's charset. 219 On Java 9, apksigner cannot detect the console's charset 220 and may need to be provided with --pass-encoding when a 221 non-ASCII password is used. --pass-encoding may also need 222 to be provided for a KeyStore created by keytool on a 223 different OS or in a different locale. 224 225--ks-type Type/algorithm of KeyStore to use. By default, the default 226 type is used. 227 228--ks-provider-name Name of the JCA Provider from which to request the 229 KeyStore implementation. By default, the highest priority 230 provider is used. See --ks-provider-class for the 231 alternative way to specify a provider. 232 233--ks-provider-class Fully-qualified class name of the JCA Provider from which 234 to request the KeyStore implementation. By default, the 235 provider is chosen based on --ks-provider-name. 236 237--ks-provider-arg Value to pass into the constructor of the JCA Provider 238 class specified by --ks-provider-class. The value is 239 passed into the constructor as java.lang.String. By 240 default, the no-arg provider's constructor is used. 241 242--key Load private key from the specified file. If the key is 243 password-protected, the password will be prompted via 244 standard input unless specified otherwise using 245 --key-pass. The file must be in PKCS #8 DER format. 246 247--cert Load certificate chain from the specified file. The file 248 must be in X.509 PEM or DER format. 249 250 251 JCA PROVIDER INSTALLATION OPTIONS 252These options enable you to install additional Java Crypto Architecture (JCA) 253Providers, such as PKCS #11 providers. Use --next-provider to delimit options of 254different providers. Providers are installed in the order in which they appear 255on the command-line. 256 257--provider-class Fully-qualified class name of the JCA Provider. 258 259--provider-arg Value to pass into the constructor of the JCA Provider 260 class specified by --provider-class. The value is passed 261 into the constructor as java.lang.String. By default, the 262 no-arg provider's constructor is used. 263 264--provider-pos Position / priority at which to install this provider in 265 the JCA provider list. By default, the provider is 266 installed as the lowest priority provider. 267 See java.security.Security.insertProviderAt. 268 269 270 EXAMPLES 271 2721. Sign an APK, in-place, using the one and only key in keystore release.jks: 273$ apksigner sign --ks release.jks app.apk 274 2751. Sign an APK, without overwriting, using the one and only key in keystore 276 release.jks: 277$ apksigner sign --ks release.jks --in app.apk --out app-signed.apk 278 2793. Sign an APK using a private key and certificate stored as individual files: 280$ apksigner sign --key release.pk8 --cert release.x509.pem app.apk 281 2824. Sign an APK using two keys: 283$ apksigner sign --ks release.jks --next-signer --ks magic.jks app.apk 284 2855. Sign an APK using PKCS #11 JCA Provider: 286$ apksigner sign --provider-class sun.security.pkcs11.SunPKCS11 \ 287 --provider-arg token.cfg --ks NONE --ks-type PKCS11 app.apk 288 2896. Sign an APK using a non-ASCII password KeyStore created on English Windows. 290 The --pass-encoding parameter is not needed if apksigner is being run on 291 English Windows with Java 8 or older. 292$ apksigner sign --ks release.jks --pass-encoding ibm437 app.apk 293 2947. Sign an APK on Windows using a non-ASCII password KeyStore created on a 295 modern OSX or Linux machine: 296$ apksigner sign --ks release.jks --pass-encoding utf-8 app.apk 297 2988. Sign an APK with rotated signing certificate: 299$ apksigner sign --ks release.jks --next-signer --ks release2.jks \ 300 --lineage /path/to/signing/history/lineage app.apk 301