0.0.2-alpha.5
This commit is contained in:
3
RULES.md
3
RULES.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: RULES.md -->
|
||||
<!-- version: 8 -->
|
||||
<!-- version: 9 -->
|
||||
|
||||
# Index normatif Project Governance Rules
|
||||
|
||||
@@ -82,6 +82,7 @@ Familles actuellement actives :
|
||||
- [`docs/rules/510-RUST_CARGO.md`](docs/rules/510-RUST_CARGO.md) — profil Rust/Cargo : workspace, manifests, dépendances, lints, API, formatage, tests et validation spécialisée.
|
||||
- [`docs/rules/520-JAVA_MAVEN_GRADLE.md`](docs/rules/520-JAVA_MAVEN_GRADLE.md) — profil Java et spécialisations Maven/Gradle : toolchain LTS, structure, dépendances, tests et validation de build.
|
||||
- [`docs/rules/600-PLATFORMS.md`](docs/rules/600-PLATFORMS.md) — contrat commun des profils plateforme et de leur compatibilité de target/runtime.
|
||||
- [`docs/rules/610-ANDROID.md`](docs/rules/610-ANDROID.md) — profil Android : structure, toolchain/SDK, compatibilité, packaging, configuration locale et validation plateforme.
|
||||
|
||||
Le modèle de composition et d'ownership des profils est défini dans [`docs/architecture/003-RULE_PROFILE_MODEL.md`](docs/architecture/003-RULE_PROFILE_MODEL.md).
|
||||
|
||||
|
||||
142
deltas/0.0.2/alpha.5.md
Normal file
142
deltas/0.0.2/alpha.5.md
Normal file
@@ -0,0 +1,142 @@
|
||||
<!-- file: deltas/0.0.2/alpha.5.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.2-alpha.5 — profil plateforme Android
|
||||
|
||||
## Baseline
|
||||
|
||||
Version attendue avant application :
|
||||
|
||||
```text
|
||||
0.0.2-alpha.4.fix.1
|
||||
```
|
||||
|
||||
Le history `history/0.0.2/alpha.4.fix.1.md` MUST avoir été appliqué et committé avant ce delta.
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.0.2-alpha.5
|
||||
```
|
||||
|
||||
## Objet
|
||||
|
||||
Matérialiser le premier profil plateforme de PGR :
|
||||
|
||||
```text
|
||||
docs/rules/610-ANDROID.md
|
||||
```
|
||||
|
||||
La tranche consolide les règles Android réutilisables sans absorber les spécialisations Rust/JNI ou Tauri.
|
||||
|
||||
## Frontières retenues
|
||||
|
||||
Le profil Android possède notamment :
|
||||
|
||||
- la structure Android dans un dépôt mono- ou multi-plateforme ;
|
||||
- Java comme défaut applicatif PGR lorsque rien n'impose un autre langage ;
|
||||
- la matrice AGP / Gradle / JDK ;
|
||||
- la séparation `compileSdk` / `targetSdk` / `minSdk` ;
|
||||
- `VERSION` / `versionName` / `versionCode` ;
|
||||
- configuration locale, signing et secrets ;
|
||||
- modules et dépendances Android ;
|
||||
- ABI lorsqu'un code natif existe, sans définir JNI ;
|
||||
- niveaux de tests Android et ordre de validation ;
|
||||
- manifest, permissions et ressources ;
|
||||
- APK/AAB et packaging de distribution.
|
||||
|
||||
Restent hors scope :
|
||||
|
||||
```text
|
||||
Rust / Android / JNI
|
||||
Tauri desktop
|
||||
Tauri mobile
|
||||
Web / WASM
|
||||
```
|
||||
|
||||
Ces compositions ne doivent pas être introduites implicitement dans `610-ANDROID.md`.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
RULES.md
|
||||
docs/rules/000-README.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
docs/rules/610-ANDROID.md
|
||||
deltas/0.0.2/alpha.5.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = "0.0.2-alpha.5"
|
||||
|
||||
test -f docs/rules/610-ANDROID.md
|
||||
test -f deltas/0.0.2/alpha.5.md
|
||||
|
||||
grep -F 'Les profils Rust/JNI et Tauri ne sont pas définis ici.' docs/rules/610-ANDROID.md
|
||||
grep -F 'Dans un dépôt multi-plateforme où une zone Android distincte est nécessaire' docs/rules/610-ANDROID.md
|
||||
grep -F 'Java est le langage applicatif Android par défaut du profil PGR' docs/rules/610-ANDROID.md
|
||||
grep -F 'Android Gradle Plugin' docs/rules/610-ANDROID.md
|
||||
grep -F 'PGR MUST NOT déduire une hausse de `minSdk`' docs/rules/610-ANDROID.md
|
||||
grep -F '`versionCode` est un compteur Android monotone distinct du SemVer.' docs/rules/610-ANDROID.md
|
||||
grep -F '`local.properties` est un fichier local Android typique' docs/rules/610-ANDROID.md
|
||||
grep -F 'Les secrets de signature ne sont jamais versionnés.' docs/rules/610-ANDROID.md
|
||||
grep -F 'Une ABI annoncée comme supportée doit disposer d' docs/rules/610-ANDROID.md
|
||||
grep -F 'JVM unit' docs/rules/610-ANDROID.md
|
||||
grep -F '`AndroidManifest.xml` MUST déclarer uniquement les permissions' docs/rules/610-ANDROID.md
|
||||
grep -F 'APK debug' docs/rules/610-ANDROID.md
|
||||
grep -F 'PGR lui-même ne contient actuellement aucun projet Android' docs/rules/610-ANDROID.md
|
||||
|
||||
grep -F '610-ANDROID.md' RULES.md
|
||||
grep -F '610-ANDROID.md' docs/rules/000-README.md
|
||||
|
||||
python3 -B scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
|
||||
git diff --check
|
||||
|
||||
git add VERSION RULES.md docs/rules/000-README.md docs/rules/610-ANDROID.md deltas/0.0.2/alpha.5.md
|
||||
|
||||
git diff --cached --check
|
||||
|
||||
git status --short
|
||||
```
|
||||
|
||||
La sortie attendue avant ajout du history est :
|
||||
|
||||
```text
|
||||
M RULES.md
|
||||
M VERSION
|
||||
A deltas/0.0.2/alpha.5.md
|
||||
M docs/rules/000-README.md
|
||||
A docs/rules/610-ANDROID.md
|
||||
```
|
||||
|
||||
Revue opérateur complémentaire :
|
||||
|
||||
- confirmer que le profil reste Android général et n'absorbe ni JNI ni Tauri ;
|
||||
- confirmer que `compileSdk`, `targetSdk` et `minSdk` restent des contrats distincts ;
|
||||
- confirmer que l'usage d'une toolchain moderne ne relève pas automatiquement `minSdk` ;
|
||||
- confirmer que `versionCode` reste un compteur Android distinct de SemVer ;
|
||||
- confirmer que les secrets et configurations locales restent hors Git ;
|
||||
- confirmer que les niveaux de preuve unit/instrumented/smoke ne sont pas confondus ;
|
||||
- confirmer qu'aucune validation Android réelle n'est revendiquée pour PGR lui-même en l'absence de projet Android.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Créer et appliquer séparément `history/0.0.2/alpha.5.md`, committer la tranche, puis passer à `0.0.2-beta.1` pour la réconciliation des profils.
|
||||
|
||||
### FAIL
|
||||
|
||||
Rester dans `0.0.2-alpha.5.fix.M` jusqu'à correction. Un REPLAN n'est nécessaire que si la correction révèle un élargissement substantiel du scope.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/000-README.md -->
|
||||
<!-- version: 9 -->
|
||||
<!-- version: 10 -->
|
||||
|
||||
# Index des règles PGR
|
||||
|
||||
@@ -19,6 +19,7 @@ Les règles générales actuellement nécessaires restent dans `RULES.md`. La fa
|
||||
- [`510-RUST_CARGO.md`](510-RUST_CARGO.md) — profil Rust/Cargo et règles réutilisables propres à cet écosystème.
|
||||
- [`520-JAVA_MAVEN_GRADLE.md`](520-JAVA_MAVEN_GRADLE.md) — profil Java et spécialisations de build Maven/Gradle.
|
||||
- [`600-PLATFORMS.md`](600-PLATFORMS.md) — contrat commun des profils plateforme.
|
||||
- [`610-ANDROID.md`](610-ANDROID.md) — profil plateforme Android et règles réutilisables de compatibilité, packaging et validation.
|
||||
|
||||
Le modèle transversal d'ownership, d'applicabilité et de composition est décrit dans [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).
|
||||
|
||||
|
||||
316
docs/rules/610-ANDROID.md
Normal file
316
docs/rules/610-ANDROID.md
Normal file
@@ -0,0 +1,316 @@
|
||||
<!-- file: docs/rules/610-ANDROID.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Profil Android
|
||||
|
||||
## Rôle
|
||||
|
||||
Ce document possède les règles réutilisables propres à la plateforme Android.
|
||||
|
||||
Il complète [`600-PLATFORMS.md`](600-PLATFORMS.md) et, lorsqu'un projet Android utilise Java/Gradle, [`520-JAVA_MAVEN_GRADLE.md`](520-JAVA_MAVEN_GRADLE.md).
|
||||
|
||||
Une contrainte Android plus spécifique MAY raffiner les règles générales Java ou Gradle dans le seul scope Android lorsqu'une matrice AGP/Gradle/JDK, un SDK ou une contrainte de distribution l'impose.
|
||||
|
||||
Les profils Rust/JNI et Tauri ne sont pas définis ici. Ils constituent des compositions plus spécialisées et MUST NOT contaminer le profil Android général.
|
||||
|
||||
## Structure du projet
|
||||
|
||||
Pour un dépôt exclusivement Android, les conventions Android normales restent prioritaires et la racine du dépôt MAY être directement le projet Gradle.
|
||||
|
||||
Dans un dépôt multi-plateforme où une zone Android distincte est nécessaire, PGR SHOULD utiliser la racine :
|
||||
|
||||
```text
|
||||
Android/
|
||||
```
|
||||
|
||||
Cette racine est alors un chemin de plateforme stable. Elle ne doit pas être renommée arbitrairement en `android/`, `mobile/` ou autre uniquement par préférence locale.
|
||||
|
||||
Une structure multi-plateforme peut par exemple contenir :
|
||||
|
||||
```text
|
||||
project/
|
||||
├── VERSION
|
||||
├── crates/
|
||||
├── Web/
|
||||
└── Android/
|
||||
├── settings.gradle
|
||||
├── build.gradle
|
||||
├── gradle.properties
|
||||
├── gradlew
|
||||
├── gradlew.bat
|
||||
└── gradle/
|
||||
```
|
||||
|
||||
Les noms et fichiers exacts restent soumis au projet Android réellement utilisé ; PGR ne crée pas de niveau `Android/` artificiel dans un dépôt qui est déjà exclusivement Android.
|
||||
|
||||
## Langage applicatif et logique de build
|
||||
|
||||
Java est le langage applicatif Android par défaut du profil PGR lorsqu'aucune API, framework ou contrainte réelle n'impose un autre choix.
|
||||
|
||||
Kotlin MAY être utilisé lorsqu'une API, un framework ou une intégration l'exige réellement.
|
||||
|
||||
Groovy DSL ou Kotlin DSL MAY être utilisés par Gradle comme langage de configuration. Leur présence dans le build ne transforme pas Kotlin ou Groovy en langage applicatif du projet.
|
||||
|
||||
Les fichiers Gradle SHOULD rester aussi déclaratifs et courts que raisonnablement possible. Une logique de build importante SHOULD être possédée par une abstraction ou un plugin identifiable plutôt que devenir du code produit caché dans un script Gradle.
|
||||
|
||||
Les annotations fonctionnelles Android ou de frameworks restent autorisées lorsqu'elles constituent le mécanisme officiel de l'API concernée.
|
||||
|
||||
## Matrice AGP / Gradle / JDK
|
||||
|
||||
Un projet Android MUST exprimer une chaîne de build compatible.
|
||||
|
||||
La matrice conceptuelle est :
|
||||
|
||||
```text
|
||||
Android Gradle Plugin
|
||||
↕
|
||||
Gradle
|
||||
↕
|
||||
JDK LTS
|
||||
```
|
||||
|
||||
PGR MUST NOT imposer globalement une version Gradle, AGP ou JDK uniquement parce qu'elle est utilisée par un autre projet Android.
|
||||
|
||||
La contrainte applicable peut être :
|
||||
|
||||
```text
|
||||
minimum
|
||||
range min..max
|
||||
version exacte / pin
|
||||
latest compatible
|
||||
```
|
||||
|
||||
Le projet choisit la forme la moins restrictive qui reste réellement compatible avec sa stack.
|
||||
|
||||
Le JDK suit le profil Java : dernière LTS compatible par défaut, LTS plus ancienne lorsqu'une contrainte Android ou de framework l'impose, non-LTS uniquement par exception justifiée.
|
||||
|
||||
Lorsque le Gradle Wrapper est retenu, ses fichiers requis sont versionnés et sa version doit satisfaire la matrice réelle AGP/Gradle/JDK.
|
||||
|
||||
## `compileSdk`, `targetSdk` et `minSdk`
|
||||
|
||||
Ces trois valeurs représentent des contrats différents.
|
||||
|
||||
`compileSdk` définit l'API Android utilisée pour compiler. Il MAY être récent afin de permettre l'usage des APIs et outils actuels.
|
||||
|
||||
`targetSdk` déclare le niveau de comportement Android pour lequel l'application a été adaptée. Il MUST respecter les exigences applicables au canal de distribution réellement visé.
|
||||
|
||||
`minSdk` définit la plus ancienne version Android que le produit promet de pouvoir installer et exécuter.
|
||||
|
||||
PGR MUST NOT déduire une hausse de `minSdk` d'une hausse de `compileSdk` ou `targetSdk`.
|
||||
|
||||
`minSdk` SHOULD rester aussi bas que raisonnablement supportable tant que cela ne compromet pas une capacité nécessaire, une dépendance imposée, la sécurité ou une maintenance raisonnable.
|
||||
|
||||
Une hausse de `minSdk` est un changement de compatibilité utilisateur et MUST être explicitement justifiée.
|
||||
|
||||
## `VERSION`, `versionName` et `versionCode`
|
||||
|
||||
Lorsqu'une application Android appartient au même release train que le projet, le fichier PGR `VERSION` reste la version SemVer canonique de cette unité de release.
|
||||
|
||||
`versionName` est un miroir technique de cette version lorsqu'elle doit représenter la même release à l'utilisateur ou au canal de distribution.
|
||||
|
||||
`versionCode` est un compteur Android monotone distinct du SemVer.
|
||||
|
||||
PGR MUST NOT confondre `versionCode` avec `VERSION` ou `versionName`.
|
||||
|
||||
Pour une application publiée, `versionCode` MUST NOT diminuer. Lorsqu'un dépôt publie plusieurs applications indépendantes, chaque application MAY posséder son propre compteur versionné.
|
||||
|
||||
Le projet MAY stocker ce compteur dans un fichier explicite tel que :
|
||||
|
||||
```text
|
||||
Android/app/VERSION_CODE
|
||||
```
|
||||
|
||||
si cela correspond à son architecture.
|
||||
|
||||
PGR SHOULD NOT imposer une formule dérivant automatiquement `versionCode` du SemVer sans décision explicite du projet.
|
||||
|
||||
Un futur audit read-only MAY vérifier séparément :
|
||||
|
||||
```text
|
||||
VERSION ↔ versionName
|
||||
VERSION_CODE ↔ configuration Android
|
||||
```
|
||||
|
||||
lorsqu'un projet ou skeleton réel fournit des fichiers à contrôler. Cet audit ne doit jamais modifier les versions.
|
||||
|
||||
## Configuration locale
|
||||
|
||||
`local.properties` est un fichier local Android typique et SHOULD rester hors Git lorsqu'il contient des chemins machine tels que l'emplacement du SDK.
|
||||
|
||||
PGR MUST NOT utiliser `local.properties` comme source normative de configuration partagée du projet.
|
||||
|
||||
Si l'outil ou l'IDE régénère intégralement ce fichier, aucun fichier exemple n'est nécessaire.
|
||||
|
||||
Lorsqu'une propriété locale obligatoire n'est pas automatiquement reproductible, un template MAY être fourni conformément aux règles générales PGR.
|
||||
|
||||
La même politique s'applique aux fichiers locaux analogues tels que `keystore.properties`, `user.properties` ou des variantes `*.local.properties` lorsqu'ils contiennent des valeurs propres à la machine ou à l'utilisateur.
|
||||
|
||||
## Signing et secrets
|
||||
|
||||
Les secrets de signature ne sont jamais versionnés.
|
||||
|
||||
Sont notamment interdits dans Git, les deltas, histories, prompts et documentation :
|
||||
|
||||
```text
|
||||
release keystore
|
||||
private signing key
|
||||
passwords
|
||||
credentials
|
||||
service account secret
|
||||
```
|
||||
|
||||
Une configuration versionnée MAY référencer des variables ou propriétés telles que :
|
||||
|
||||
```text
|
||||
RELEASE_KEYSTORE
|
||||
RELEASE_KEY_ALIAS
|
||||
```
|
||||
|
||||
mais MUST NOT contenir leurs valeurs privées.
|
||||
|
||||
Le debug keystore généré automatiquement est local.
|
||||
|
||||
Le signing de release ne doit pas être requis pour une validation ordinaire de développement sauf lorsque la tranche valide précisément la distribution ou la signature finale.
|
||||
|
||||
## Modules Android
|
||||
|
||||
Les modules Android SHOULD être nommés par responsabilité.
|
||||
|
||||
Des noms tels que :
|
||||
|
||||
```text
|
||||
app
|
||||
common
|
||||
game-reflex
|
||||
game-snake
|
||||
```
|
||||
|
||||
peuvent être légitimes lorsque ces responsabilités existent réellement.
|
||||
|
||||
Des noms opaques tels que `module1`, `module2`, `misc` ou `utils2` SHOULD NOT servir de structure durable.
|
||||
|
||||
Un module partagé doit posséder une responsabilité commune réelle ; il ne doit pas devenir un dépôt générique de code sans owner.
|
||||
|
||||
## Dépendances Android
|
||||
|
||||
Les dépendances Android doivent rester minimales et explicites.
|
||||
|
||||
Une dépendance officielle et étroite SHOULD être préférée à un framework beaucoup plus large lorsqu'une petite capability suffit.
|
||||
|
||||
À l'inverse, PGR SHOULD NOT réimplémenter une API de plateforme, un protocole standard ou une primitive de sécurité uniquement pour éviter une dépendance officielle appropriée.
|
||||
|
||||
Une BOM ou un mécanisme officiel de gestion de versions MAY être utilisé lorsqu'il réduit réellement les incompatibilités. Il ne doit pas entraîner l'ajout automatique de toute une famille de dépendances non utilisées.
|
||||
|
||||
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
|
||||
|
||||
Un projet Android purement Java peut ne posséder aucune règle ABI spécifique.
|
||||
|
||||
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.
|
||||
|
||||
Exemples possibles :
|
||||
|
||||
```text
|
||||
arm64-v8a
|
||||
armeabi-v7a
|
||||
x86_64
|
||||
```
|
||||
|
||||
PGR ne fixe pas une liste universelle d'ABI.
|
||||
|
||||
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 règles JNI elles-mêmes appartiennent à un profil spécialisé et restent hors de ce document.
|
||||
|
||||
## Niveaux de tests Android
|
||||
|
||||
PGR distingue au moins trois niveaux de preuve Android lorsqu'ils sont applicables :
|
||||
|
||||
```text
|
||||
JVM unit
|
||||
→ logique ne nécessitant pas le runtime Android
|
||||
|
||||
instrumented / integration
|
||||
→ comportement nécessitant le framework Android
|
||||
|
||||
smoke device / AVD
|
||||
→ application ou package réel 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 instrumenté ne remplace pas automatiquement un smoke du package final.
|
||||
|
||||
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.
|
||||
|
||||
## Ordre de validation Android
|
||||
|
||||
Une validation Android ordinaire SHOULD progresser du ciblé vers le plus coûteux :
|
||||
|
||||
```text
|
||||
format applicable
|
||||
↓
|
||||
audits read-only applicables
|
||||
↓
|
||||
compilation module ciblé
|
||||
↓
|
||||
lint Android ciblé
|
||||
↓
|
||||
unit tests ciblés
|
||||
↓
|
||||
assemble/package lorsque nécessaire
|
||||
↓
|
||||
install
|
||||
↓
|
||||
smoke
|
||||
```
|
||||
|
||||
Les tests globaux, l'instrumentation large, les bundles de release, les matrices multi-ABI et les smokes multi-device sont sélectionnés lorsque le scope ou la phase de release l'exige réellement.
|
||||
|
||||
Les commandes exactes appartiennent à la matrice du projet ou du skeleton qui possède un Android build réel.
|
||||
|
||||
`clean` reste une opération de maintenance et ne doit pas précéder automatiquement chaque gate.
|
||||
|
||||
## Manifest et ressources
|
||||
|
||||
`AndroidManifest.xml` MUST déclarer uniquement les permissions et capabilities réellement nécessaires.
|
||||
|
||||
Une permission sensible ne doit pas être ajoutée « au cas où ». Son introduction constitue un changement significatif qui doit être visible dans le delta et, lorsque pertinent, dans la documentation de release.
|
||||
|
||||
`src/main/res/` reste la source canonique des ressources Android d'un module standard.
|
||||
|
||||
Dans un projet multi-plateforme, des assets réellement partagés MAY vivre dans un owner commun hors d'Android si leur consommation est définie clairement.
|
||||
|
||||
PGR SHOULD NOT maintenir manuellement plusieurs copies divergentes du même asset source dans des arborescences de plateforme différentes.
|
||||
|
||||
## APK, AAB et artefacts de distribution
|
||||
|
||||
PGR distingue les rôles des principaux artefacts :
|
||||
|
||||
```text
|
||||
APK debug
|
||||
→ développement et smokes ordinaires
|
||||
|
||||
APK release
|
||||
→ validation d'un package release installable lorsque nécessaire
|
||||
|
||||
AAB
|
||||
→ artefact de distribution lorsque le canal cible l'exige
|
||||
```
|
||||
|
||||
La phase de release 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.
|
||||
|
||||
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é.
|
||||
|
||||
## Validation et futurs audits PGR
|
||||
|
||||
Les catégories générales et l'autorité du gate restent possédées par [`400-VALIDATION.md`](400-VALIDATION.md).
|
||||
|
||||
PGR lui-même ne contient actuellement aucun projet Android à compiler, installer ou exécuter. Cette tranche ne prétend donc pas valider AGP, Gradle, SDK, AVD, APK ou AAB réels.
|
||||
|
||||
Aucun audit Android spécialisé n'est créé uniquement pour remplir le profil.
|
||||
|
||||
Lorsqu'un skeleton ou projet concret fournira les fichiers nécessaires, des audits monotâches MAY vérifier des propriétés structurelles stables telles que la cohérence de version, la présence d'une configuration locale ignorée ou une matrice de compatibilité explicitement déclarée. Ces audits restent read-only et ne remplacent jamais Gradle, Android Lint, l'installation ou les smokes.
|
||||
104
history/0.0.2/alpha.5.md
Normal file
104
history/0.0.2/alpha.5.md
Normal file
@@ -0,0 +1,104 @@
|
||||
<!-- file: history/0.0.2/alpha.5.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.2-alpha.5 — profil plateforme Android
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La tranche `0.0.2-alpha.5` a été validée par l'opérateur. Le premier profil plateforme Android est matérialisé sans absorber les spécialisations Rust/JNI, Tauri ou Web différées.
|
||||
|
||||
## Baseline
|
||||
|
||||
La correction précédente `0.0.2-alpha.4.fix.1` a été enregistrée `PASS`, puis committée et poussée sous le commit observé :
|
||||
|
||||
```text
|
||||
368dedb
|
||||
```
|
||||
|
||||
Version validée après application de `alpha.5` :
|
||||
|
||||
```text
|
||||
0.0.2-alpha.5
|
||||
```
|
||||
|
||||
## Validation opérateur observée
|
||||
|
||||
La version et les fichiers attendus ont été confirmés :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = "0.0.2-alpha.5"
|
||||
test -f docs/rules/610-ANDROID.md
|
||||
test -f deltas/0.0.2/alpha.5.md
|
||||
```
|
||||
|
||||
Les contrats principaux du profil Android ont été retrouvés, notamment :
|
||||
|
||||
```text
|
||||
Les profils Rust/JNI et Tauri ne sont pas définis ici.
|
||||
Dans un dépôt multi-plateforme où une zone Android distincte est nécessaire
|
||||
Java est le langage applicatif Android par défaut du profil PGR
|
||||
Android Gradle Plugin
|
||||
PGR MUST NOT déduire une hausse de `minSdk`
|
||||
`versionCode` est un compteur Android monotone distinct du SemVer.
|
||||
`local.properties` est un fichier local Android typique
|
||||
Les secrets de signature ne sont jamais versionnés.
|
||||
Une ABI annoncée comme supportée doit disposer d'une preuve adaptée.
|
||||
JVM unit
|
||||
`AndroidManifest.xml` MUST déclarer uniquement les permissions
|
||||
APK debug
|
||||
PGR lui-même ne contient actuellement aucun projet Android
|
||||
```
|
||||
|
||||
La navigation vers `610-ANDROID.md` a été retrouvée depuis `RULES.md` et `docs/rules/000-README.md`.
|
||||
|
||||
L'audit Markdown PGR a réussi :
|
||||
|
||||
```text
|
||||
Markdown table audit: clean (2 table(s), 61 file(s))
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
Le scope Git observé avant le présent history est exactement :
|
||||
|
||||
```text
|
||||
M RULES.md
|
||||
M VERSION
|
||||
A deltas/0.0.2/alpha.5.md
|
||||
M docs/rules/000-README.md
|
||||
A docs/rules/610-ANDROID.md
|
||||
```
|
||||
|
||||
## Revue qualitative
|
||||
|
||||
Le profil validé conserve les frontières prévues :
|
||||
|
||||
- Android possède les contraintes de plateforme, SDK, packaging, signing et compatibilité de target ;
|
||||
- Java/Gradle restent possédés par le profil langage/build et sont seulement raffinés lorsque la plateforme impose une contrainte ;
|
||||
- `compileSdk`, `targetSdk` et `minSdk` restent trois contrats distincts ;
|
||||
- une toolchain moderne ne relève pas automatiquement `minSdk` ;
|
||||
- `versionCode` reste un compteur Android distinct du SemVer ;
|
||||
- les niveaux `JVM unit`, instrumentation/intégration et smoke device/AVD ne sont pas confondus ;
|
||||
- aucune validation Android réelle n'est revendiquée pour PGR lui-même en l'absence d'un projet Android à compiler ou exécuter.
|
||||
|
||||
## Résultat
|
||||
|
||||
`0.0.2-alpha.5` est validée `PASS`.
|
||||
|
||||
Les trois profils technologiques retenus pour `0.0.2` sont maintenant matérialisés :
|
||||
|
||||
```text
|
||||
510 — Rust / Cargo
|
||||
520 — Java / Maven / Gradle
|
||||
610 — Android
|
||||
```
|
||||
|
||||
La tranche suivante autorisée est :
|
||||
|
||||
```text
|
||||
0.0.2-beta.1
|
||||
```
|
||||
|
||||
Elle est consacrée à leur réconciliation, à la vérification des owners/scopes/overrides et à la navigation. Aucun nouveau profil technologique majeur n'est autorisé en beta sans REPLAN.
|
||||
Reference in New Issue
Block a user