0.1.3-alpha.3

docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Plan 0.1.3 — réévaluation pratique Android
 
@@ -365,6 +365,52 @@ La tranche révise uniquement `610-ANDROID.md` pour :
 
 Aucun template, skeleton, audit Python ou contrat `docs/validation/` n'est créé par cette tranche.
 
+## Décision après `alpha.2`
+
+La gate opérateur de `alpha.2` est `PASS`. Les `48/48` tests Python, les trois audits Markdown, l'audit Android de base et les contrôles Git sont propres ; aucun `alpha.2.fix.N` n'est requis.
+
+`alpha.3` peut donc traiter le natif, le packaging, la distribution et la validation Android sans rouvrir les contrats de base validés en `alpha.2`.
+
+### Vérification Android officielle courante pour `alpha.3`
+
+La documentation Android officielle courante a été vérifiée le `2026-09-28` sur les responsabilités touchées par cette tranche :
+
+```text
+https://developer.android.com/guide/practices/page-sizes
+https://developer.android.com/ndk/guides/abis
+https://developer.android.com/studio/write/lint
+https://developer.android.com/studio/test/command-line
+https://developer.android.com/build/building-cmdline
+https://developer.android.com/google/play/requirements/target-sdk
+```
+
+Cette vérification confirme notamment :
+
+- les politiques de distribution sont évolutives : depuis le `2026-08-31`, Google Play demande pour les applications Android ordinaires nouvelles ou mises à jour un `targetSdk` Android 16 / API `36` ou supérieur, mais cette valeur appartient au canal Play courant et ne devient pas un default PGR universel ;
+- Android 15 introduit les devices configurés avec pages mémoire `16 KB` ; une application composée uniquement de code Java/Kotlin est déjà compatible du point de vue de l'alignement natif, tandis que toute bibliothèque native directe ou transitive impose de vérifier le package réellement livré ;
+- pour Google Play, les applications ciblant Android 15 / API `35` ou supérieur doivent supporter les pages `16 KB` sur les appareils 64 bits ; la documentation courante annonce qu'à partir du `2027-02-01`, les mises à jour non compatibles ne pourront plus être publiées ;
+- pour une application native concernée, la preuve officielle couvre les segments ELF des bibliothèques 64 bits, l'alignement ZIP de l'APK et, pour un AAB, la configuration d'alignement du bundle ; les dépendances natives précompilées font partie du même contrat ;
+- AGP `8.5.1+` et NDK `r28+` rendent aujourd'hui le chemin 16 KB standard plus direct, mais PGR n'en déduit pas de minimum global : le projet doit choisir une toolchain compatible avec ses contraintes et prouver l'artefact final ;
+- Android Lint n'est pas exécuté automatiquement par un build ordinaire : lorsqu'il est applicable, il doit être appelé explicitement sur le module/variant pertinent ;
+- les tests JVM locaux et les tests instrumentés constituent des niveaux distincts ; l'instrumentation s'exécute sur device/émulateur et ne remplace pas à elle seule l'installation/smoke d'un package final lorsque le packaging ou le runtime sont dans le scope ;
+- l'APK reste l'artefact installable adapté aux smokes directs, tandis que l'AAB est un artefact de distribution qui entraîne la génération d'APK par le canal ; un AAB seul ne constitue donc pas une preuve runtime.
+
+La preuve Games `PAGE_SIZE=16384`, `align 2**14` et `zipalign -P 16` est cohérente avec ces exigences actuelles. Elle reste une preuve historique du corpus et n'est pas rejouée dans PGR, qui ne possède aucun build Android exécutable.
+
+### Scope arrêté pour `alpha.3`
+
+La tranche révise uniquement `610-ANDROID.md` pour :
+
+1. rendre NDK et ABI strictement conditionnels à la présence de code natif et séparer sélection de toolchain, ABI déclarées et preuve du package ;
+2. inclure les bibliothèques natives précompilées ou transitives dans les preuves de compatibilité ;
+3. clarifier le rôle d'Android Lint comme gate explicite et ciblée, non implicite au build ;
+4. préciser la frontière entre tests JVM, tests instrumentés et smokes device/AVD ;
+5. distinguer APK installable et AAB de distribution sans imposer un full packaging à chaque tranche ;
+6. normaliser le contrat 16 KB de manière conditionnelle au code natif et au canal de distribution, avec revalidation obligatoire des politiques évolutives ;
+7. conserver les détails JNI, Rust, SDL3, `cargo ndk`, les quatre ABI Games et les commandes spécifiques Games hors du profil Android général.
+
+Aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` n'est créé. La décision finale sur l'absence d'artefact supplémentaire reste réservée à `beta.1` après réconciliation.
+
 ## Réévaluation initiale de `610-ANDROID.md`
 
 Le profil courant contient déjà une part importante des contrats démontrés par Games : structure conditionnelle, matrice AGP/Gradle/JDK, niveaux SDK séparés, version Android, configuration locale, signing, modules, dépendances, ABI conditionnelles, niveaux de tests, validation proportionnée, manifests/resources et artefacts APK/AAB.

docs/rules/610-ANDROID.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/610-ANDROID.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Profil Android
 
@@ -229,25 +229,44 @@ Une BOM ou un mécanisme officiel de gestion de versions MAY être utilisé lors
 
 La politique d'un lockfile Android/Gradle, lorsqu'un projet en utilise un, doit être décidée selon le besoin réel de cet écosystème et du projet. Elle n'est pas déduite automatiquement d'un autre profil.
 
-## ABI et code natif
+## NDK, ABI et code natif
 
-Un projet Android purement Java peut ne posséder aucune règle ABI spécifique.
+Un projet Android sans bibliothèque native directe ou transitive n'a pas besoin de NDK ni de matrice ABI propre au produit.
 
-Dès qu'un projet contient du code natif via NDK, C/C++, Rust ou une autre frontière native, les ABI réellement supportées MUST être déclarées explicitement.
+Dès qu'un projet contient du code natif via NDK, C/C++, Rust, un SDK précompilé ou une autre frontière native, la toolchain native réellement nécessaire et les ABI réellement supportées MUST être explicites.
 
-Exemples possibles :
+PGR ne fixe ni version NDK ni liste universelle d'ABI. La version NDK MAY être épinglée lorsqu'une reproductibilité, une dépendance ou une exigence de packaging le justifie ; elle ne doit pas être copiée depuis un autre projet par défaut.
+
+Les mécanismes tels que `abiFilters` MAY exprimer la matrice voulue lorsque Gradle/AGP les utilise. La configuration choisie doit refléter le contrat produit et le canal de distribution plutôt qu'une liste maximale par principe.
+
+Une ABI annoncée comme supportée doit disposer d'une preuve adaptée à la propriété annoncée. Il faut distinguer au minimum :
 
 ```text
-arm64-v8a
-armeabi-v7a
-x86_64
+compilation native
+→ la bibliothèque est produite pour l'ABI
+
+packaging
+→ la bibliothèque et ses dépendances natives sont présentes dans l'artefact Android attendu
+
+runtime
+→ le package pertinent s'installe et exécute le chemin critique sur un environnement représentant l'ABI / API concernée
 ```
 
-PGR ne fixe pas une liste universelle d'ABI.
+Une cross-compilation native seule ne prouve donc ni l'intégration dans l'APK/AAB, ni le lifecycle Android, ni l'exécution sur device/AVD.
 
-Une ABI annoncée comme supportée doit disposer d'une preuve adaptée. Une cross-compilation native seule ne prouve pas l'intégration dans l'APK, le lifecycle Android ni l'exécution sur device/AVD.
+Les bibliothèques natives précompilées ou apportées par un SDK font partie du package final et MUST respecter les mêmes contraintes de compatibilité que les bibliothèques produites par le projet.
 
-Les règles JNI elles-mêmes appartiennent à un profil spécialisé et restent hors de ce document.
+Les règles JNI, Rust, SDL, `cargo ndk` ou toute autre chaîne native spécialisée appartiennent à leurs owners/projets respectifs et restent hors de ce document tant qu'un profil générique séparé n'est pas justifié.
+
+## Android Lint
+
+Android Lint est une analyse statique Android distincte de la compilation et des tests.
+
+Lorsqu'un changement touche du code, des resources, un manifest, une configuration Android ou une dépendance susceptible d'être analysée par Lint, la gate SHOULD exécuter la tâche Lint du module et du variant pertinents.
+
+PGR MUST NOT supposer qu'un build Gradle ordinaire exécute Lint automatiquement. Les commandes exactes (`lint`, `lintDebug`, `lintRelease` ou équivalent) appartiennent au projet et à sa stratégie Wrapper/Gradle système.
+
+Une baseline Lint MAY être versionnée lorsqu'elle sert réellement à isoler la dette existante des nouvelles régressions. Elle ne doit pas servir à masquer silencieusement de nouveaux diagnostics applicables.
 
 ## Niveaux de tests Android
 
@@ -255,20 +274,22 @@ PGR distingue au moins trois niveaux de preuve Android lorsqu'ils sont applicabl
 
 ```text
 JVM unit
-→ logique ne nécessitant pas le runtime Android
+→ logique exécutée sur la JVM hôte sans runtime Android réel
 
 instrumented / integration
-→ comportement nécessitant le framework Android
+→ test exécuté sur device ou émulateur avec le framework Android
 
 smoke device / AVD
-→ application ou package réel dans un environnement Android
+→ application ou package réel installé et chemin critique exécuté dans un environnement Android
 ```
 
-Un test JVM MUST NOT être enregistré comme preuve d'un comportement réel d'`Activity`, de lifecycle ou de device.
+Un test JVM MUST NOT être enregistré comme preuve d'un comportement réel d'`Activity`, de lifecycle, de package ou de device.
 
-Un test instrumenté ne remplace pas automatiquement un smoke du package final.
+Un test instrumenté prouve le comportement couvert par son runner et son environnement, mais ne remplace pas automatiquement un smoke du package final lorsque la tranche modifie packaging, signing, native libraries, manifest de lancement ou installation.
 
-Un appareil physique n'est pas obligatoire pour chaque release. Il devient nécessaire lorsqu'une propriété annoncée dépend d'un matériel ou comportement qui ne peut pas être suffisamment prouvé par AVD.
+Les tâches de tests SHOULD être ciblées par module/variant lorsque cela suffit. Une matrice instrumentée ou multi-device large n'est requise que lorsqu'elle couvre un risque réellement modifié ou une phase de release qui l'exige.
+
+Un appareil physique n'est pas obligatoire pour chaque release. Il devient nécessaire lorsqu'une propriété annoncée dépend d'un matériel, d'une ABI ou d'un comportement qui ne peut pas être suffisamment prouvé par AVD.
 
 ## Ordre de validation Android
 
@@ -318,20 +339,54 @@ PGR distingue les rôles des principaux artefacts :
 
 ```text
 APK debug
-→ développement et smokes ordinaires
+→ développement, installation directe et smokes ordinaires
 
 APK release
 → validation d'un package release installable lorsque nécessaire
 
 AAB
-→ artefact de distribution lorsque le canal cible l'exige
+→ artefact de distribution lorsque le canal cible l'exige ; le canal génère ensuite les APK servis aux appareils
 ```
 
-La phase de release et le scope modifié déterminent l'artefact nécessaire.
+La phase de release, le canal de distribution et le scope modifié déterminent l'artefact nécessaire.
 
-Une alpha documentaire n'a pas besoin d'un package Android réel si aucun projet Android n'est concerné. Une release d'une application Android peut au contraire nécessiter un package ou smoke réel lorsque `versionName`, `versionCode`, signing ou packaging sont modifiés.
+Un AAB n'est pas directement une preuve d'installation ou d'exécution sur device. Lorsqu'une propriété runtime ou de packaging doit être prouvée, la gate doit aussi utiliser un APK approprié ou les APK dérivés du bundle selon le canal et le risque concernés.
 
-La promotion stable ne doit pas provoquer mécaniquement un full rebuild sans preuve invalidée ; elle doit toutefois revalider le packaging ciblé lorsque les métadonnées qui entrent dans l'artefact ont changé.
+Une alpha documentaire n'a pas besoin d'un package Android réel si aucun projet Android n'est concerné. Une release d'une application Android peut au contraire nécessiter un package ou smoke réel lorsque `versionName`, `versionCode`, signing, manifest, code natif ou packaging sont modifiés.
+
+La promotion stable ne doit pas provoquer mécaniquement un full rebuild sans preuve invalidée ; elle doit toutefois revalider le packaging ciblé lorsque les métadonnées ou composants qui entrent dans l'artefact ont changé.
+
+Les exigences telles que le niveau `targetSdk` minimal, le format de publication ou les délais de compatibilité appartiennent au canal de distribution et évoluent indépendamment de PGR. Un projet publié MUST vérifier la politique officielle courante de son canal avant une release concernée ; PGR ne transforme pas une valeur datée de Google Play en default Android universel.
+
+## Pages mémoire 16 KB et packaging natif
+
+Android supporte des appareils configurés avec des pages mémoire de `16 KB`. Cette responsabilité est conditionnelle : un projet sans bibliothèque native directe ou transitive n'a pas de segments ELF à réaligner, même s'il SHOULD tester les comportements importants sur les environnements Android qu'il prétend supporter.
+
+Lorsqu'une application contient du natif et que la plateforme ou le canal de distribution exige la compatibilité `16 KB`, le package final MUST être compatible. La preuve doit couvrir les bibliothèques natives du projet ainsi que les dépendances natives précompilées réellement embarquées.
+
+Pour Google Play, la politique officielle courante vérifiée pendant `0.1.3` impose le support `16 KB` sur appareils 64 bits aux applications ciblant Android 15 / API `35` ou supérieur. Cette politique est évolutive : le projet MUST la revalider auprès de la documentation officielle au moment où elle devient une gate de release.
+
+Une preuve de compatibilité native `16 KB` SHOULD couvrir, selon l'artefact réellement distribué :
+
+```text
+ELF 64 bits
+→ segments LOAD des bibliothèques embarquées compatibles avec l'alignement 16 KB
+
+APK
+→ alignement ZIP des bibliothèques natives vérifié sur le package final
+
+AAB
+→ configuration d'alignement du bundle vérifiée lorsque ce bundle est l'artefact de distribution
+
+runtime
+→ smoke sur device/AVD 16 KB lorsque le comportement runtime ou la distribution concernée le justifie
+```
+
+Les outils Android officiels peuvent notamment contrôler les segments ELF, `zipalign -P 16` pour un APK et l'alignement déclaré par `bundletool` pour un AAB. Ces commandes sont des moyens de preuve, pas des noms de fichiers ou chemins machine à figer dans PGR.
+
+Une toolchain récente peut fournir cette compatibilité par défaut, mais PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison. La toolchain retenue doit satisfaire la politique courante du canal et toutes les bibliothèques natives précompilées doivent être compatibles elles aussi.
+
+Un mode de compatibilité de plateforme ou le simple fait que l'application démarre sur un appareil 16 KB ne remplace pas la preuve de conformité du package natif lorsque le canal de distribution l'exige.
 
 ## Validation et futurs audits PGR