Android Platform Notes#

Android-specific configuration concerns that don’t fit cleanly into the layer-by-layer pages but matter for a production HAAPI integration. Each note is short and stands alone.

HttpURLConnection includes a cookie manager that’s used to maintain potentially long-lived sessions between client and server. The framework does not install one automatically — you choose the policy.

// Accept all cookies (most permissive)
CookieHandler.setDefault(CookieManager(null, CookiePolicy.ACCEPT_ALL))

// Or accept only cookies from the original server (default policy)
CookieHandler.setDefault(CookieManager())

Set the policy in your Application.onCreate before any HAAPI requests fire. For the underlying HTTP-integration detail, see HTTP Integration (Android Only).

android:allowBackup for Risk Assessment#

android:allowBackup defaults to true on modern Android. Risk-assessment integrations rely on persisted device context surviving backup-and-restore for continuity:

<application
    android:name=".ClientApplication"
    android:allowBackup="true"
    ...>

If your app’s security posture requires allowBackup="false", expect that fresh installs after factory reset or device migration lose risk-assessment context history. Some integrations cope by re-establishing context from scratch; others (typically those relying on long-running device fingerprints) don’t. Test the end-to-end backup-and-restore path before disabling allowBackup. See How to Integrate Risk Assessment.

Manifest Registration#

The UIWidget’s manifest declares HaapiFlowActivity and the redirect entry point, and merges into your app’s manifest, so you do not declare either. Your app module provides the redirect values as manifest placeholders:

android {
    defaultConfig {
        manifestPlaceholders += [huiRedirectScheme: "com.example.app", huiRedirectHost: "haapi"]
    }
}

The build fails without them. For a verified App Link, also override the hui_redirect_path_prefix string resource; see Redirect URI for both formats.

HaapiFlowActivity returns tokens to the screen that started it, so it is not exported:

  • Start it for a result from your own app with HaapiFlowActivity.Contract; see Flow Lifecycle. Started without a result request, it finishes with RESULT_CANCELED before making any request.
  • Never declare it with android:exported="true". That declaration fails the manifest merge; remove the attribute rather than overriding it with tools:replace.
  • Do not add intent filters to it. Redirects reach the flow through the redirect entry point, which the placeholders configure.

A declaration that only sets android:theme, for modal-presentation styling, keeps working — see Presentation Options.

Attestation requires pairing your app’s package name and signing-certificate SHA-256 with the OAuth client on the Curity Identity Server, plus an assetlinks.json published at https://<your-domain>/.well-known/:

<application ...>
    <meta-data
        android:name="asset_statements"
        android:resource="@string/asset_statements" />
</application>
<string name="asset_statements" translatable="false">
    [{\"include\": \"https://idsvr.example.com/.well-known/assetlinks.json\"}]
</string>

Get your app’s signing certificate SHA-256 with ./gradlew signingReport. See Quickstart — Android Step 5 for the full pairing procedure.

Exchanging the Authorization Code#

With token binding enabled, exchange the authorization code before starting another authentication flow. The code belongs to the flow that produced it, so beginning a new one first makes the exchange fail and the user has to sign in again. Calling fetchAccessToken straight after the flow completes, as the UI Layer does, always satisfies this.

Related: UI Layer Configuration · HTTP Integration · How to Integrate Risk Assessment

Was this helpful?