Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.3-alpha.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-28 11:32:26 +02:00
parent 1223a705c0
commit 8cbd686f47
5 changed files with 434 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
VERSION
View File

@@ -1 +1 @@
0.1.3-alpha.2 0.1.3-alpha.3

211
deltas/0.1.3/alpha.3.md Normal file
View File

@@ -0,0 +1,211 @@
<!-- file: deltas/0.1.3/alpha.3.md -->
<!-- version: 1 -->
# Delta 0.1.3-alpha.3 — natif, packaging, distribution et validation Android
## Baseline
Ce delta s'applique après :
```text
0.1.3-alpha.2
+ history/0.1.3/alpha.2.md PASS
+ commit/push complet de la tranche alpha.2
```
Il ne doit pas être appliqué avant l'intégration du history `alpha.2`.
## Objet
Réviser le profil Android uniquement sur les responsabilités conditionnelles démontrées par Games et confirmées par la documentation Android officielle courante : NDK/ABI/code natif, Android Lint, niveaux de tests, APK/AAB, installation/smokes device/AVD et compatibilité 16 KB lorsque le package ou le canal de distribution l'exigent réellement.
Cette tranche ne crée aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` séparé. Elle ne modifie ni Tauri `0.1.4`, ni Games `0.1.5`.
## Modifications
### Version
`VERSION` devient :
```text
0.1.3-alpha.3
```
### Plan Android
`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md` passe en révision interne `3` et enregistre :
- le `PASS` opérateur réel de `alpha.2` ;
- l'absence de fix avant `alpha.3` ;
- les sources Android officielles vérifiées le `2026-09-28` pour native/ABI, Lint, tests, packaging, Google Play et 16 KB ;
- le caractère évolutif des exigences de canal telles que `targetSdk` et les échéances de publication ;
- la cohérence de la preuve Games 16 KB sans la transformer en gate PGR locale ;
- le scope exact de `alpha.3` ;
- le maintien de la décision finale d'artefacts supplémentaires dans `beta.1`.
### Profil Android
`docs/rules/610-ANDROID.md` passe en révision interne `5`.
La révision :
- rend NDK et ABI conditionnels à la présence de bibliothèques natives directes ou transitives ;
- refuse toute version NDK ou liste d'ABI universelle et distingue compilation native, présence dans le package et preuve runtime ;
- inclut les SDK/bibliothèques natives précompilés dans le contrat de compatibilité du package final ;
- garde JNI, Rust, SDL, `cargo ndk` et les choix Games hors du profil Android général ;
- introduit une section Android Lint qui impose une exécution explicite et ciblée lorsqu'elle est applicable, sans supposer qu'un build ordinaire l'exécute ;
- précise les frontières JVM unit / instrumented / smoke device-AVD et la sélection proportionnée des matrices ;
- distingue l'APK installable de l'AAB de distribution et interdit d'utiliser un AAB seul comme preuve runtime ;
- impose de revalider les politiques évolutives du canal de distribution au moment de la release concernée ;
- normalise la compatibilité 16 KB uniquement lorsqu'il existe du code natif et qu'elle est requise par la plateforme ou le canal ;
- demande alors une preuve adaptée sur les bibliothèques 64 bits, le package APK/AAB et, lorsque nécessaire, un environnement runtime 16 KB ;
- conserve les versions AGP/NDK et les commandes précises comme moyens de preuve/toolchain, non comme minima PGR génériques.
## Vérification officielle utilisée
La vérification courante effectuée avant préparation du delta couvre :
```text
Support 16 KB page sizes
Android ABIs
Improve your code with lint checks
Test from the command line
Build your app from the command line
Meet Google Play's target API level requirement
```
Elle confirme notamment, au `2026-09-28` :
- Google Play demande depuis le `2026-08-31` API `36+` pour les nouvelles applications et mises à jour Android ordinaires, avec des règles distinctes pour certains form factors ; cette valeur reste une politique Play datée, pas un default Android PGR ;
- les applications Google Play ciblant API `35+` doivent supporter les pages `16 KB` sur appareils 64 bits et la documentation courante annonce le `2027-02-01` comme échéance à partir de laquelle les mises à jour non compatibles ne pourront plus être publiées ;
- une application sans code natif direct ou transitif n'a pas de réalignement ELF à effectuer ; une application native doit vérifier aussi ses bibliothèques tierces précompilées ;
- les moyens officiels de preuve couvrent les segments ELF, `zipalign -P 16` pour l'APK, l'alignement déclaré dans l'AAB via `bundletool` et, lorsque pertinent, un test sur environnement 16 KB ;
- AGP `8.5.1+` et NDK `r28+` facilitent le chemin standard actuel mais ne deviennent pas des minima PGR universels ;
- Lint doit être lancé explicitement ; les tests locaux JVM et instrumentés ont des environnements et des responsabilités distincts ;
- un APK est directement installable, tandis qu'un AAB sert à la distribution et n'est pas une preuve runtime par lui-même.
## Validation opérateur
Après application du history `PASS`, commit/push de `alpha.2`, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.1.3-alpha.3'
git cat-file -e HEAD:history/0.1.3/alpha.2.md
test -f history/0.1.3/alpha.2.md
test -f deltas/0.1.3/alpha.3.md
test ! -e history/0.1.3/alpha.3.md
grep -A2 '^## Statut$' history/0.1.3/alpha.2.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 3 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
grep -Fx '<!-- version: 5 -->' docs/rules/610-ANDROID.md
python3 -B -m unittest discover -s tests -v
python3 -B scripts/audit_markdown_headers.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B scripts/audit_markdown_tables.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B scripts/audit_markdown_links.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B - <<'PYGATE'
from pathlib import Path
import re
history = Path('history/0.1.3/alpha.2.md').read_text(encoding='utf-8')
assert re.search(r'## Statut\s+PASS\s', history)
android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 5 -->')
for phrase in (
'## NDK, ABI et code natif',
'bibliothèques natives précompilées ou apportées par un SDK',
'compilation native',
'packaging',
'runtime',
'## Android Lint',
'PGR MUST NOT supposer qu\'un build Gradle ordinaire exécute Lint automatiquement.',
'JVM unit',
'instrumented / integration',
'smoke device / AVD',
'Un AAB n\'est pas directement une preuve d\'installation ou d\'exécution sur device.',
'## Pages mémoire 16 KB et packaging natif',
'Google Play',
'API `35` ou supérieur',
'`zipalign -P 16`',
'`bundletool`',
):
assert phrase in android, phrase
assert 'PGR ne fixe ni version NDK ni liste universelle d\'ABI.' in android
assert 'PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.' in android
assert 'targetSdk` minimal' in android
plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
for phrase in (
'## Décision après `alpha.2`',
'La gate opérateur de `alpha.2` est `PASS`',
'### Vérification Android officielle courante pour `alpha.3`',
'depuis le `2026-08-31`',
'à partir du `2027-02-01`',
'### Scope arrêté pour `alpha.3`',
'Aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` n\'est créé.',
):
assert phrase in plan, phrase
assert not Path('docs/validation/006-ANDROID_VALIDATION.md').exists()
assert not Path('history/0.1.3/alpha.3.md').exists()
for forbidden in (
'NDK MUST être r28',
'MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86',
'targetSdk MUST être 36',
):
assert forbidden not in android, forbidden
print('0.1.3 alpha.3 Android native/distribution audit: clean (conditional native ownership, lint/tests/package boundaries and 16 KB policy verified)')
PYGATE
git diff --check
git add VERSION \
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
docs/rules/610-ANDROID.md \
deltas/0.1.3/alpha.3.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history est :
```text
M VERSION
A deltas/0.1.3/alpha.3.md
M docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
M docs/rules/610-ANDROID.md
```
La revue qualitative doit confirmer que :
- aucune valeur Games (NDK `r28c`, quatre ABI, SDL3, Rust/JNI) n'est devenue une règle Android générale ;
- une application sans code natif n'hérite d'aucune gate NDK/ABI/ELF artificielle ;
- une dépendance native précompilée est couverte par la même preuve package que le code natif du projet ;
- Android Lint, tests JVM, tests instrumentés, package, install et smoke restent des preuves distinctes et proportionnées ;
- un AAB n'est pas traité comme un artefact directement installable ;
- la règle 16 KB est conditionnelle, fondée sur la politique officielle courante et ne fige ni date ni version d'outil comme default PGR durable ;
- le profil exige de revalider les politiques de distribution évolutives plutôt que de conserver aveuglément une valeur `targetSdk` datée ;
- PGR ne prétend pas avoir reconstruit les APK/AAB Games pendant cette tranche documentaire ;
- aucun contrat Android séparé, skeleton, audit ou owner spécialisé n'a été créé uniquement pour remplir la release ;
- Tauri `0.1.4` et l'adoption Games `0.1.5` restent hors scope.
## Transition
### PASS
Produire `history/0.1.3/alpha.3.md`, puis préparer `0.1.3-beta.1` pour la réconciliation du profil Android révisé contre Games, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md` et `400-VALIDATION.md`.
La beta doit décider explicitement si `610-ANDROID.md` et les owners existants suffisent. Si un artefact fonctionnel supplémentaire devient réellement nécessaire, déclencher un REPLAN vers une tranche alpha dédiée au lieu de l'ajouter en beta.
### FAIL
Consigner le diagnostic réel dans `history/0.1.3/alpha.3.md` et rester dans `alpha.3.fix.N` sauf REPLAN justifié. Le fix MUST rester borné au natif, packaging, distribution et validation Android et ne doit pas absorber Tauri `0.1.4` ou l'adoption Games `0.1.5`.

48
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md --> <!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md -->
<!-- version: 2 --> <!-- version: 3 -->
# Plan 0.1.3 — réévaluation pratique Android # 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. 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` ## 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. 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.

99
docs/rules/610-ANDROID.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/610-ANDROID.md --> <!-- file: docs/rules/610-ANDROID.md -->
<!-- version: 4 --> <!-- version: 5 -->
# Profil Android # 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. 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 ```text
arm64-v8a compilation native
armeabi-v7a → la bibliothèque est produite pour l'ABI
x86_64
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 ## Niveaux de tests Android
@@ -255,20 +274,22 @@ PGR distingue au moins trois niveaux de preuve Android lorsqu'ils sont applicabl
```text ```text
JVM unit 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 instrumented / integration
→ comportement nécessitant le framework Android → test exécuté sur device ou émulateur avec le framework Android
smoke device / AVD 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 ## Ordre de validation Android
@@ -318,20 +339,54 @@ PGR distingue les rôles des principaux artefacts :
```text ```text
APK debug APK debug
→ développement et smokes ordinaires → développement, installation directe et smokes ordinaires
APK release APK release
→ validation d'un package release installable lorsque nécessaire → validation d'un package release installable lorsque nécessaire
AAB 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 ## Validation et futurs audits PGR

98
history/0.1.3/alpha.3.md Normal file
View File

@@ -0,0 +1,98 @@
<!-- file: history/0.1.3/alpha.3.md -->
<!-- version: 1 -->
# History 0.1.3-alpha.3 — natif, packaging, distribution et validation Android
## Statut
PASS
La gate opérateur de `0.1.3-alpha.3` exécutée le `2026-09-28` est propre. Les responsabilités Android conditionnelles liées au code natif, aux ABI, à Lint, aux niveaux de tests, au packaging APK/AAB, aux smokes device/AVD et à la compatibilité 16 KB sont validées sans fix.
## Intégration de `alpha.2`
Avant la gate `alpha.3`, l'opérateur a intégré le history `PASS` de `alpha.2`, puis commit/push la tranche :
```text
commit local observé 1223a70 0.1.3-alpha.2
push origin/master eaa9c39..1223a70
```
Le history `history/0.1.3/alpha.2.md` est donc présent dans `HEAD` avant validation de `alpha.3`.
## Contrôles d'identité
Les contrôles opérateur ont confirmé :
```text
VERSION 0.1.3-alpha.3
history/0.1.3/alpha.2.md présent dans HEAD et PASS
deltas/0.1.3/alpha.3.md présent
history/0.1.3/alpha.3.md absent pendant la gate
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md version 3
docs/rules/610-ANDROID.md version 5
```
## Tests Python
La suite complète a affiché :
```text
Ran 48 tests in 0.760s
OK
```
Soit `48/48` tests `PASS`.
## Audits Markdown
Les trois audits documentaires sont propres :
```text
Markdown header audit: clean (256 file(s))
Markdown table audit: clean (11 table(s), 256 file(s))
Markdown link audit: clean (323 local link(s), 256 file(s))
```
## Audit Android natif/distribution `alpha.3`
Le contrôle structurel de la tranche a affiché :
```text
0.1.3 alpha.3 Android native/distribution audit: clean (conditional native ownership, lint/tests/package boundaries and 16 KB policy verified)
```
Il a notamment confirmé :
- NDK et ABI restent conditionnels à la présence de bibliothèques natives directes ou transitives ;
- PGR ne fixe ni version NDK ni liste universelle d'ABI ;
- compilation native, présence dans le package et preuve runtime restent trois niveaux de preuve distincts ;
- Android Lint est une gate explicite et ne doit pas être supposé exécuté par un build Gradle ordinaire ;
- tests JVM, tests instrumentés et smokes device/AVD restent distincts et proportionnés ;
- un AAB est un artefact de distribution et ne constitue pas à lui seul une preuve d'installation ou d'exécution ;
- la compatibilité 16 KB est conditionnelle au code natif, au package et au canal de distribution réellement concernés ;
- aucune version AGP/NDK, valeur `targetSdk`, liste d'ABI ou commande Games n'est devenue un minimum PGR universel ;
- aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` séparé n'a été créé ;
- Tauri `0.1.4` et l'adoption Games `0.1.5` restent hors scope.
## Hygiène Git et scope observé
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le scope indexé observé est exactement :
```text
M VERSION
A deltas/0.1.3/alpha.3.md
M docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
M docs/rules/610-ANDROID.md
```
## Décision
`0.1.3-alpha.3` est validée `PASS`.
La tranche suivante reste `0.1.3-beta.1`, dédiée à la réconciliation du profil Android révisé contre Games et les owners `400`, `520`, `522` et `600`, ainsi qu'à la décision finale sur les artefacts Android supplémentaires.
Si `610-ANDROID.md` et les owners existants suffisent, la beta doit consigner explicitement qu'aucun artefact supplémentaire n'est nécessaire. Si une lacune fonctionnelle impose au contraire un nouvel owner, contrat, template, skeleton ou audit, elle doit déclencher un REPLAN vers une tranche alpha dédiée plutôt que l'introduire opportunément en beta.