Guide de démarrage Android

En quelques minutes, votre app Android lira un vrai feature flag — mis en cache durablement, sûr hors ligne, avec l’identité d’appareil créée et stockée pour vous.

Requiert minSdk 26 (Android 8.0). Kotlin, avec les coroutines comme seule famille de dépendances.

1. Installez

Le SDK vit dans un dépôt public sur GitHub — consommez-le comme une dépendance source : clonez FortressFlag_SDK_android au tag v1.0.0 et ajoutez-le à votre projet comme un included build Gradle, dont le module de bibliothèque est fortressflag.

git clone --branch v1.0.0 https://github.com/FortressFlag/FortressFlag_SDK_android

2. Démarrez le SDK

Une fois, au démarrage de l’app — votre Application.onCreate est l’endroit naturel :

import com.fortressflag.sdk.Configuration
import com.fortressflag.sdk.Environment
import com.fortressflag.sdk.FortressFlag

FortressFlag.start(
    context,
    Configuration(
        sdkKey = "ffc_prod_…",                // depuis l’écran Clés SDK de votre projet
        environment = Environment.PRODUCTION,
    ),
)

Le SDK charge immédiatement les valeurs en cache et interroge les changements en arrière-plan. La clé est une clé client — elle est embarquée dans votre app par conception.

3. Lisez un flag

if (FortressFlag.isEnabled("new-checkout", default = false)) {
    // afficher le nouveau tunnel de paiement
}

stringValue et numberValue lisent les flags multivariés de la même façon, et chaque lecture est servie depuis la mémoire — pas d’E/S, pas de réseau, quel que soit le thread depuis lequel vous appelez.

C’est tout — votre flag est en ligne. Basculez-le dans le tableau de bord et l’app suit lors de son prochain polling.

Si FortressFlag est en panne, votre app ne l’est pas

isEnabled, stringValue et numberValue ne lèvent jamais d’exception. Chaque lecture retombe sur les dernières valeurs que cet appareil a réellement vues — y compris lors des exécutions précédentes, via le cache durable — puis sur la valeur par défaut de votre point d’appel. Une panne n’atteint jamais vos utilisateurs.

Deux faits de plateforme, avant qu’ils n’atteignent une facture

FortressFlag facture par appareil, et Android a deux faits à connaître d’emblée :

• L’identité est par app aujourd’hui. Si un utilisateur exécute trois de vos apps sur un téléphone, cela compte actuellement jusqu’à trois appareils — les apps Android ne partagent pas encore une identité FortressFlag comme peut le faire une famille d’apps iOS.
• Désinstaller votre app efface l’identité. Android efface les données de l’app adossées au Keystore à la désinstallation, donc une réinstallation crée une nouvelle identité — et compte comme un nouvel appareil. (Cela diffère d’iOS, où le trousseau persiste.)

L’identité elle-même est créée aléatoirement et pseudonyme — jamais dérivée de ANDROID_ID ni d’aucun identifiant matériel. Et les émulateurs créent une identité sim_ : flags servis normalement, jamais facturés.

Où aller ensuite

• Comment les flags arrivent à votre app — ce que fait le polling en arrière-plan
• Identité d’appareil et facturation — toute l’histoire de l’identité
• Ciblage — servez des valeurs différentes à des appareils différents