skip to content

In Appium on Android, what do the appium:noSign and appium:useKeystore capabilities control?

level: middleimportance: must knowfreq 47%

answer

  1. no profile, but signatures still matter
  2. the driver may re-sign your APK
  3. appium-adb has a default certificate
  4. noSign skips, useKeystore redirects

basics

~20 s

Both act on the Android app under test, not on a test agent. By default the drivers can re-sign the build with appium-adb's bundled certificate; appium:noSign skips that step, and appium:useKeystore keeps it but signs with your own keystore instead.

solid answer

~40 s

Android has no provisioning profile, so nothing has to be authorised for a particular handset, but signatures still have to line up. `appium-adb` ships a bundled default certificate, and the UiAutomator2 driver re-signs the app under test with it when a certificate check on the artifact fails. `appium:noSign` turns that off, so the artifact is installed exactly as you handed it over. `appium:useKeystore` keeps the signing and redirects it to a keystore you supply through `appium:keystorePath`, `appium:keystorePassword`, `appium:keyAlias` and `appium:keyPassword`. The Espresso driver shows why any of this matters: it requires the app under test and its test package to share a signature.

code

json · 14 lines
json
{
  "capabilities": {
    "alwaysMatch": {
      "platformName": "Android",
      "appium:automationName": "UiAutomator2",
      "appium:useKeystore": true,
      "appium:keystorePath": "/keys/snowplough-dispatch.keystore",
      "appium:keystorePassword": "${KEYSTORE_PASSWORD}",
      "appium:keyAlias": "dispatch-ci",
      "appium:keyPassword": "${KEY_PASSWORD}"
    },
    "firstMatch": [{}]
  }
}

go deeper

for a junior

Know that Android signing in an Appium session is about the app under test rather than a test agent, and that appium:noSign and appium:useKeystore are the two switches involved.

for a middle

Explain the default: the Android drivers check the app's certificate and re-sign the APK through appium-adb when that check fails. Be able to say what each of the four keystore capabilities supplies.

for a senior

Show when you refuse the default re-sign, such as a signature-dependent feature or a release-candidate artifact, and what you configure instead so the lane still installs a build you trust.

for a principal

Own the policy on which certificate a test lane may use, and whether results gathered on a re-signed build are acceptable evidence for the decision the suite exists to inform.

## Android has no provisioning profile, and still cares about signatures Nothing on an Android device has to be authorised for that particular handset the way an Apple build does. There is no provisioning profile, no per-device entitlement, no team identity to configure. What Android does have is that **every APK carries a signature**, and several things in an automation session are decided by which certificate produced it. That is why `appium-android-driver` declares a small signing capability set, namely `useKeystore`, `keystorePath`, `keystorePassword`, `keyAlias`, `keyPassword` and `noSign`, all sent with the `appium:` vendor prefix. It is also why *Android needs no signing configuration* is one of the more expensive things to believe about an Appium lane. ## The default: the drivers may re-sign your build `appium-adb`, the library the Android drivers use to talk to the device, ships a **bundled default certificate** and can sign an APK with it. The UiAutomator2 driver uses that facility: it checks the certificate on the app under test and, when the check fails, re-signs the artifact before installing it. Nothing in the session asked for this. It is the convenience path, and it stays invisible because the snowplough dispatch app installs and behaves as expected. The consequence is worth stating plainly: left alone, the APK on the device may not be the APK your build produced. ## What the two capabilities actually do - `appium:noSign` turns the signing step off. The artifact is installed exactly as handed over, carrying whatever signature it already had. - `appium:useKeystore` keeps the signing but redirects it: instead of the bundled default certificate, the drivers sign with a keystore you own. - `appium:keystorePath`, `appium:keystorePassword`, `appium:keyAlias` and `appium:keyPassword` are the four values that make `appium:useKeystore` usable, namely where the keystore file is, how to open it, which key inside it, and that key's own password. They are alternatives rather than a stack. One says *do not sign*; the other says *sign, but with mine*. | Setting | Certificate on the installed APK | Reach for it when | | --- | --- | --- | | neither capability set | the drivers' bundled default, if the check failed | you do not care which certificate the build carries | | `appium:noSign` | whatever the artifact already had | the run must be evidence about the exact build | | `appium:useKeystore` plus the keystore four | your own key | you want a known, stable certificate that is not the drivers' | ## Why the signature matters: the Espresso case The Espresso driver requires the app under test and its test package to share a signature. Espresso runs as instrumentation inside the application's own process, and the platform will not let a test package instrument an application it does not match. So on an Espresso lane the signature is not paperwork; it is the precondition for the session existing at all, and the drivers' re-signing is doing load-bearing work whenever the pair did not already agree. That also makes `appium:noSign` a decision rather than a tidy-up on such a lane: switching it on over an app and a test package that do not already match removes the very fix-up that was making them agree. ## The other platform, so the contrast is not lost On iOS the signing capabilities act on the **test agent**, not on the app under test. `appium:xcodeOrgId`, `appium:xcodeSigningId` and `appium:updatedWDABundleId` decide how WebDriverAgent is signed so a real Apple device will run it, and the XCUITest driver never re-signs your application. Android is the reverse: no agent-signing capability of that shape, and a driver that may quietly re-sign the app under test. Both platforms sign; each signs a different artifact for a different reason. ## How to choose for a given lane 1. If the lane runs Espresso, understand the signature relationship first. Either let the drivers re-sign, or supply builds whose app and test package already match. 2. If the run has to be evidence about a specific artifact, set `appium:noSign` and hand the drivers a build already signed the way you want it. 3. If several lanes need the same known certificate, set `appium:useKeystore` with the four keystore capabilities, and keep the key itself out of the capability payload by injecting it at run time. ## What this is not - It is not release signing. Producing the shipping build of the snowplough dispatch app, and managing the certificates that go with it, belongs to release tooling rather than to a session's capabilities. - It is not the on-device helper server's own packaging. How the Android drivers build and install their helper components is a separate subject; these capabilities are about the app under test. - It is not a provisioning profile by another name. Nothing here authorises the app for a particular device, because Android has no such concept to satisfy.

  • What happens on an Android lane if you set appium:noSign and the certificate does not match?
    The drivers install the artifact untouched, so the mismatch survives into the session. On a plain UiAutomator2 lane that is usually fine, because nothing needed the certificates to agree. On an Espresso lane it is not, because that driver needs the app under test and its test package to share a signature.
  • Does an Appium Android session need anything like an iOS provisioning profile?
    No. Android has no per-device profile to satisfy, so nothing has to be authorised for a particular handset. Every APK still carries a signature, and that signature is what the drivers act on, which is a different question from whether the platform will run the app at all.

It is the re-keying a locksmith does when two doors have to open with one key: the drivers re-sign the app so the harness and the app answer to the same key.

saying these in an interview costs you the question

  • Says Android needs no signing configuration at all
  • Thinks appium:useKeystore signs a test agent rather than the app
  • Believes appium:noSign makes an unsigned APK installable
  • Confuses Android keystore capabilities with an iOS provisioning profile
  • Claims an Espresso run works when app and test package signatures differ
  • Ignores that a re-signed APK is no longer the artifact that was built