Sideloading

Definition

Sideloading is installing an app onto a device from a source other than the platform's official app store, such as an APK file, a debug build pushed over ADB, an enterprise distribution channel, or an alternative app marketplace.

Sideloading is usually discussed as a security topic, but its sharpest practical effect is on measurement: the official store is also the component that carries the install referrer, so removing the store removes the deterministic link between a click and an install. This is why deferred deep linking appears broken in QA on almost every Android team — the test build was sideloaded, and the signal it depends on was never sent.

What counts as a sideload, on each platform

Android has always permitted this behind a per-source "install unknown apps" permission. iOS did not, until the Digital Markets Act obliged Apple to allow alternative app marketplaces and web distribution for users in the EU — which is the reason a previously iOS-only assumption, that every install came from the App Store, no longer holds even there.

Which attribution signals survive

The pattern in that table is the useful takeaway: everything the *store* mediates disappears, and everything the *link* or *your own server* mediates survives. Verified links keep working because verification is a handshake between assetlinks.json on your domain and the signing certificate of the installed package — Play is not party to it.

val client = InstallReferrerClient.newBuilder(context).build()

client.startConnection(object : InstallReferrerStateListener {
    override fun onInstallReferrerSetupFinished(responseCode: Int) {
        when (responseCode) {
            InstallReferrerClient.InstallReferrerResponse.OK -> {
                val details = client.installReferrer
                // A sideload can still reach OK on a device that has
                // Play installed — with an empty referrer string. Treat
                // blank as "no attribution", not as an organic install
                // you can report with confidence.
                if (details.installReferrer.isBlank()) {
                    markUnattributed(reason = "referrer_empty")
                } else {
                    attribute(details.installReferrer)
                }
            }
            // Play Store app absent, or too old to serve the API.
            InstallReferrerClient.InstallReferrerResponse.FEATURE_NOT_SUPPORTED ->
                markUnattributed(reason = "no_play_store")
            InstallReferrerClient.InstallReferrerResponse.SERVICE_UNAVAILABLE ->
                retryLater()
            InstallReferrerClient.InstallReferrerResponse.DEVELOPER_ERROR ->
                logConfigurationBug()
        }
        client.endConnection()
    }

    override fun onInstallReferrerServiceDisconnected() = retryLater()
})

The QA trap, and the signing key that breaks verification

Two failures dominate real reports, and both are artefacts of sideloading rather than bugs in the link setup.

The first is deferred deep linking that never resolves in testing. Every build QA installs — over ADB, from a CI artefact, from a shared APK — is a sideload with no install referrer, so a deferred link has nothing to match on and the app opens cold on its home screen. The setup is correct; the test is invalid. Validate deferred behaviour from an internal testing track on Play, where the install genuinely comes from the store, and treat ADB builds as suitable only for testing the routing half.

The second is App Links that verify from Play and fail when sideloaded. Verification compares the SHA-256 fingerprint of the installed package's signing certificate against the fingerprints listed in your assetlinks.json. A Play-distributed build is signed by Play App Signing; a locally built APK is signed by your debug or upload key. Different certificate, different fingerprint, no match — so the domain fails to verify and the link opens in the browser.

# Where did this package actually come from?
# "com.android.vending" means Play. Anything else is a sideload.
adb shell pm list packages -i | grep com.example.app

# Why the domain will not verify: compare this fingerprint against
# every sha256_cert_fingerprints entry in your assetlinks.json.
# List the debug key, the upload key AND the Play App Signing key.
keytool -list -v -keystore ~/.android/debug.keystore   -alias androiddebugkey -storepass android -keypass android   | grep 'SHA256:'

# The device's own verdict on each declared host.
adb shell pm get-app-links com.example.app

# Legacy only: some SDKs still listen for the old broadcast, which
# Play stopped sending in 2020. Useful to exercise your handler on
# a sideloaded build; it proves nothing about production.
adb shell am broadcast -a com.android.vending.INSTALL_REFERRER   -n com.example.app/.InstallReferrerReceiver   --es "referrer" "utm_source=test&utm_campaign=local"

For the EU marketplace case on iOS, the thing to know is that AdAttributionKit was designed with alternative distribution in mind and can attribute installs originating from an alternative app marketplace, whereas SKAdNetwork cannot. If any meaningful share of your installs will arrive that way, that difference is a concrete reason to move off SKAdNetwork rather than a theoretical one.