# Prerequisites

Three things every consumer app needs before calling `Octet.start(...)`:

1. A **registered app** so the SDK can bootstrap by attestation.
2. **Privacy declarations** in your app bundle (iOS `Info.plist`) or runtime permission grants (Android).
3. A **minimum platform version**.

---

## 1. Register your app

In 2.0 the SDK gets its license by proving the app's identity at first launch, not by carrying a key.

Sign up for an Octet account at [sdk.octetproof.com/signup](https://sdk.octetproof.com/signup), then register your app identities at [sdk.octetproof.com/apps](https://sdk.octetproof.com/apps). The link in your onboarding email lands there. In the **Add an app identity** dialog:

- **iOS:** your bundle id and Apple Team ID.
- **Android:** your package name and signing-certificate SHA-256. Use the dialog's separate **Debug** and **Release** certificate fields: a Debug cert registers a sandbox identity, a Release cert a production one. Avoid the single-certificate quick-register box on the signup page for Android, which writes one cert to both slots, so a debug build would take a paid production slot.

The first valid attestation from your app binds the identity to your account. A developer dashboard at `dashboard.octetproof.com` is on the way. `/apps` is the live surface today. See [Attested bootstrap](/docs/v2.0/concepts/attested-bootstrap/) for how the handshake works.

**iOS.** Enable the **App Attest** capability for your app id. The SDK produces an App Attest attestation at first launch and an assertion on later launches.

**Android.** The SDK uses hardware **key attestation**: the device's TEE or StrongBox certificate chain is verified against Google's hardware-attestation root. No Google Cloud project is required. (The backend also checks Google's public keybox-revocation list to reject revoked devices, an unauthenticated fetch that needs no project or credentials.)

**Local development, CI, and simulators.** An emulator, a CI runner, and a locally built debug app have no hardware attestation. Use a **sandbox bypass token**. Register your Debug certificate under an app at `/apps` (the Debug field creates a sandbox identity), then mint a sandbox token for it there, choosing a 7-, 14-, 30-, or 90-day lifetime. It is revocable. Pass the token as `OctetConfig.sandboxBypassToken`. It looks like `octet_sbx_...`. A store or release build cannot use one: the SDK refuses a sandbox token outside a debug or simulator build, and the server refuses it for a production app.

The SDK reports a count of active devices and nothing else: no identity, no coordinates. See [pricing](https://octetproof.com/pricing).

---

## 2. Platform privacy declarations

### iOS: `Info.plist` keys

Add these to your app's `Info.plist`. Without them, the iOS runtime crashes on first launch with a privacy-sensitive-data error that names the missing key.

#### Required

```xml
<key>NSLocationWhenInUseUsageDescription</key>
<string>This app uses your location to verify and prove your location
to services that request it.</string>

<key>NSMotionUsageDescription</key>
<string>This app uses motion data to detect when you're stationary or
moving, which improves the confidence of location proofs.</string>
```

`NSMotionUsageDescription` is required. The SDK touches `CMMotionActivityManager` immediately during `Octet.start(...)`, and Apple requires the usage description before any code accesses that API. Read-only access also counts.

The strings are user-facing. The copy above is a safe default. Rewrite in your product's voice if you prefer.

#### Required only if you enable background location

If your app needs proofs while backgrounded, also add:

```xml
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>This app uses background location to continue generating
location proofs while you're not actively using it.</string>

<key>UIBackgroundModes</key>
<array>
    <string>location</string>
</array>
```

Without these the SDK silently falls back to foreground-only operation when the app is backgrounded. The SDK itself does not crash. Proofs stop generating until the app returns to foreground.

### Android: runtime permissions

The SDK's `AndroidManifest.xml` declares the permissions the on-demand foreground proof flow uses: location, motion, foreground service, internet, and wake-lock. Manifest-merge propagates these into your app, so you do not copy them into your own manifest.

The SDK's manifest declares only the permissions the foreground proof flow uses, so `ACCESS_BACKGROUND_LOCATION` is not bundled. To generate proofs while the app is backgrounded, declare `ACCESS_BACKGROUND_LOCATION` in your own manifest.

You still request the runtime permissions from the user:

| Permission | When to request | Notes |
|---|---|---|
| `ACCESS_FINE_LOCATION` | Before `Octet.start(...)`. | SDK refuses to start without it. |
| `ACTIVITY_RECOGNITION` | Before `Octet.start(...)`. | Android 10+ (API 29+). Motion-classification features degrade gracefully if denied. Request it for full proof confidence. |
| `ACCESS_BACKGROUND_LOCATION` | After `ACCESS_FINE_LOCATION` is granted, only if you need background proofs. | Declare it in your own manifest first. The SDK does not merge it. Android 10+ prompts for it separately. |

---

## 3. Minimum platform versions

| Platform | Minimum | Toolchain |
|---|---|---|
| iOS | 16.0 | Xcode 15+, Swift 5.9+ |
| Android | API 30 (Android 11) | Android Studio Hedgehog (2023.1.1)+, JDK 17, Kotlin 2.1+ |

---

Next: the [iOS Quick Start](/docs/v2.0/getting-started/ios-quickstart/) or [Android Quick Start](/docs/v2.0/getting-started/android-quickstart/).