0.1.3-alpha.3

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