# Apprentissage FireViewer sur Android

> **Périmètre du SDK :** les dépendances 2.16.1 ci-dessous correspondent aux essais historiques sur émulateur. Ce SDK n’est pas qualifié sur téléphone ARM ni pour des pages 16 Ko. Le [runtime Flex reconstruit de Vision Dataset Studio](https://github.com/unicornwhodev/vision-dataset-studio/blob/65e4620/docs/FLEX_16K.md) et sa suite de base sont des preuves distinctes. [Conserver l’original et poursuivre l’apprentissage](../docs/CONTINUOUS_LEARNING.md).

Les fichiers `models/*_learning/model.tflite` contiennent les signatures exécutables `infer`, `train`, `save` et `restore`. Les têtes d'adaptation sont entraînables localement ; les réseaux visuels restent figés. Le modèle livré démarre avec ses poids source et une adaptation identité, sans les mises à jour synthétiques utilisées pour les tests.

Utiliser les deux dépendances de même version :

```kotlin
implementation("org.tensorflow:tensorflow-lite:2.16.1")
implementation("org.tensorflow:tensorflow-lite-select-tf-ops:2.16.1")
```

`OnDeviceLearning.kt` fournit les appels, la sauvegarde atomique, les empreintes SHA-256 et la vérification des checkpoints. Exécuter ces opérations dans un travail de fond avec CPU, XNNPACK désactivé. Le mélange LiteRT 2.2 / Select TF Ops 2.16 n'est pas la configuration qualifiée. Les résultats Android exacts figurent dans `reports/fireviewer-completion.json` et les journaux joints ; les essais hôte sont séparés des essais Android. Un émulateur ne mesure pas la vitesse sur téléphone ARM.

## Images et cibles de détection

Chaque image est un tableau float `[1][3][H][W]` RGB. Appliquer la normalisation de `android_model_config.json`. Les images d'un même dataset peuvent avoir des tailles différentes et sont traitées individuellement. YOLO accepte des côtés multiples de 32. Les autres architectures redimensionnent dans le graphe vers leur grille interne ; les coordonnées de sortie sont rapportées à la taille de l'entrée `x`.

Pour les détecteurs, `y` contient 100 lignes `[x1,y1,x2,y2,classe,présente]`, aplaties en 600 floats. Les coordonnées sont normalisées dans l'image présentée au modèle, après prétraitement. `classe` indexe les labels du contrat. `présente=1` indique une annotation validée ; les lignes inutilisées sont nulles. Une image explicitement négative utilise toutes les lignes nulles. Une image sans annotation connue doit être exclue de l'apprentissage. `DetectorTargets.kt` construit et vérifie ce tableau.

```kotlin
val imageInputs: Map<String, Any> = mapOf("x" to nchwImage)
OnDeviceLearning(modelFile, labelSchemaSha256, threads = 1).use { session ->
    if (previousGeneration != null) session.restore(previousGeneration)
    val loss = session.train(imageInputs, reviewedTargets, learningRate = 0.001f)
    val predictions = session.infer(imageInputs)
    val generation = session.save(checkpointRoot, datasetRevision, reviewedSamplesSeen)
}
```

Les adaptations modifient les scores des classes et les boîtes des propositions disponibles. Elles ne créent pas de propositions absentes du détecteur figé. Changer le nombre de classes nécessite de reconstruire la tête avec les scripts fournis.

## DINOv3 : quatre tâches

`infer` renvoie `segmentation_logits`, `point_logits`, `presence_logits` et `abstention_logits`. Appliquer une sigmoïde pour obtenir les probabilités. Les cartes restent sur la grille 448 × 448 ; remettre les cartes et points à l'échelle de l'image d'origine.

Pour `train`, `y` est `[1,3,448,448]` : masque de segmentation, carte de pointage, puis masque des pixels valides. Redimensionner les masques binaires au plus proche voisin et préparer le pointage sur cette même grille. Fournir aussi dans `inputs` :

- `presence` : float `[1,2]`, ordre `flame_visible`, `smoke_visible`.
- `abstention` : float `[1]`.
- `supervision` : float `[4]`, ordre segmentation, pointage, abstention, présence ; 1 si la tâche est annotée, 0 sinon.

Passer ces entrées auxiliaires à `train` uniquement. Une absence d'annotation n'est pas un label négatif. Les adaptateurs de sortie des quatre tâches sont entraînables ; DINOv3 et le décodeur DPT restent figés.

## Reprendre et continuer

Chaque génération sauvegarde les paramètres entraînables, les moments SGD et le compteur d'étapes. Son `receipt.json` contient l'empreinte du modèle, celle du schéma de labels, la révision du dataset, le nombre d'exemples vus et les empreintes des fichiers. `CURRENT` désigne la dernière génération complète. `restore` refuse un autre modèle, un autre schéma de labels ou un fichier modifié. Les anciennes générations permettent un retour arrière.

Conserver les annotations humaines, l'ordre ou la graine d'échantillonnage et un ensemble de rejeu mêlant anciens et nouveaux exemples. Reprendre cet ordre à partir du compteur sauvegardé. Les checkpoints ne remplacent pas ces données. Évaluer un candidat sur des images réservées avant de l'activer ; les tests d'exécution ne mesurent ni la précision ni l'oubli catastrophique. En cas de perte non finie, restaurer la dernière génération valide.

Les scripts et ce SDK sont livrés avec les modèles. Cette livraison ne modifie pas le code de l'application Android en cours de travail dans un autre dossier.

## Reproduire le contrôle Android

Avec JDK 21, Kotlin 2.2.10 et Android SDK (plateforme 36, build-tools 36.0.0), définir `JAVA_HOME`, `KOTLIN_HOME` et `ANDROID_SDK_ROOT`, puis lancer `python3 prepare_runtime_check.py` dans ce dossier. Le script télécharge les AAR 2.16.1, compile le SDK et produit `training-check.jar` et `lib/` pour l'émulateur x86_64. Copier ces fichiers et le modèle dans `/data/local/tmp/vds-fire-training` avec `adb push`.

```sh
adb shell 'CLASSPATH=/data/local/tmp/vds-fire-training/training-check.jar LD_LIBRARY_PATH=/data/local/tmp/vds-fire-training/lib:/system/lib64:/vendor/lib64 app_process /data/local/tmp/vds-fire-training FireDetectorRuntimeCheck /data/local/tmp/vds-fire-training/model.tflite /data/local/tmp/vds-fire-training/checkpoints 1 128'
```

La dernière ligne `ANDROID_FIRE_TRAINING_PASS` signifie que toutes les assertions ont réussi. Ce programme utilise des cibles synthétiques et des checkpoints distincts ; il ne réécrit pas le fichier modèle. Le paramètre final fixe la hauteur de test, et la seconde image est rectangulaire. Le test final YOLO a été exécuté avec 64 et 96 pixels, en complément de la première version testée avec 128 et 192 pixels.