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

0.3.3-0-pre.4

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-21 10:47:57 +02:00
parent 5854ac3d07
commit b605874bea
10 changed files with 226 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/development/006-ANDROID_RUST_NATIVE_BUILD.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/development/006-ANDROID_RUST_NATIVE_BUILD.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Build Rust Android natif
@@ -54,15 +54,17 @@ Le projet Android natif n'impose pas `JAVA_HOME`. Le JDK courant du shell/IDE ex
`cargo-ndk` détecte le NDK désigné pour le sous-processus via `ANDROID_NDK_HOME`. La tâche Gradle résout cette valeur à partir de `ANDROID_HOME` ou `ANDROID_SDK_ROOT` et de `androidNdkVersion`; aucun `ANDROID_NDK_HOME` global n'est requis.
## État 0.3.3-0-pre.3
## État 0.3.3-0-pre.4
La preuve mono-ABI de `0-pre.2` a validé que `assembleDebug` déclenche correctement le build Rust/SDL3 ARM64 sans orchestrateur Python préalable.
`0-pre.3` élargit ce même graphe à :
`0-pre.3` a validé le graphe sur les deux ABI 64 bits. `0-pre.4` élargit le même mécanisme à la matrice Android complète encore supportée :
```text
arm64-v8a
armeabi-v7a
x86_64
x86
```
pour Snake et Reflex :
@@ -70,8 +72,10 @@ pour Snake et Reflex :
```text
:<game>:assembleDebug
-> buildDebugSasedevRustArm64V8a
-> buildDebugSasedevRustArmeabiV7a
-> buildDebugSasedevRustX8664
-> deux sources jniLibs générées
-> buildDebugSasedevRustX86
-> quatre sources jniLibs générées
-> APK Debug universal
```
@@ -92,15 +96,15 @@ java -version
(cd Android && gradle :game-reflex-poc:assembleDebug)
```
Il ne faut pas appeler `scripts/build_android_rust.py` avant ces tâches. Le script Python historique reste temporairement versionné jusqu'à la fermeture complète du chemin natif en `0-pre.4`.
Il ne faut pas appeler `scripts/build_android_rust.py` avant ces tâches. Le script Python historique reste temporairement versionné jusqu'à la fermeture complète du chemin natif en `0-pre.5`, après preuve du chemin release/AAB.
Les outputs natifs restent sous `Android/<module>/build/` et ne sont jamais versionnés.
## Smoke appareil
Le premier APK universal doit être inspecté mécaniquement avant installation. Il doit contenir exactement les couples attendus pour `arm64-v8a` et `x86_64`, sans dépendre de `armeabi-v7a` ou `x86`.
L'APK universal doit être inspecté mécaniquement avant installation. Il doit contenir les deux bibliothèques natives pour chacune des quatre ABI : `arm64-v8a`, `armeabi-v7a`, `x86_64` et `x86`.
Le plan prévoit ensuite un smoke sur l'AVD x86_64 disponible et sur l'appareil ARM64 réel. Ces smokes attestent le packaging multi-ABI ; ils ne changent pas le `minSdk`, qui reste un axe séparé et sera consolidé avec l'AAB/compatibilité dans `0-pre.4`.
Le smoke réel reste effectué sur les architectures matériellement disponibles : AVD x86_64 et appareil ARM64. Les ABI 32 bits sont néanmoins exigées au build et dans l'APK ; leur exécution réelle dépend de la disponibilité d'un appareil/AVD 32 bits. Ces smokes ne changent pas le `minSdk`, qui reste un axe séparé et sera consolidé avec l'AAB/compatibilité dans `0-pre.5`.
## Exception FFI Rust

28
docs/plans/003-V0_3_3_ANDROID_NATIVE_MULTI_ABI_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/003-V0_3_3_ANDROID_NATIVE_MULTI_ABI_PLAN.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Plan 0.3.3 — Android SDL3 natif multi-ABI et packaging Gradle
@@ -43,8 +43,8 @@ targetSdk 36
minSdk candidat 21
NDK 28.2.13676358 / r28c
SDL3 3.4.16
ABI par défaut arm64-v8a + x86_64
armeabi-v7a différée sans besoin produit mesuré
ABI par défaut arm64-v8a + armeabi-v7a + x86_64 + x86
ABI historiques pas de armeabi/mips/mips64 : retirées des toolchains modernes
APK test universal multi-ABI
AAB artefact de distribution cible
splits ABI hors chemin par défaut
@@ -88,7 +88,7 @@ La future logique commune doit couvrir au minimum :
4. linkage Rust contre la SDL extraite ;
5. invocation de `cargo ndk` avec `CARGO_NDK_PLATFORM=21` ;
6. mapping strict de chaque module vers exactement une feature `snake` ou `reflex` ;
7. build des ABI demandées, `arm64-v8a` et `x86_64` par défaut ;
7. build des quatre ABI Android encore supportées : `arm64-v8a`, `armeabi-v7a`, `x86_64` et `x86` ;
8. staging de `libSDL3.so` et `libgame_android_entrypoint.so` dans un répertoire `jniLibs` généré ;
9. branchement de ce répertoire à la variante Android avant packaging ;
10. inputs/outputs Gradle assez précis pour un rebuild incrémental ;
@@ -101,9 +101,11 @@ Le projet Android natif déclare `minimumGradleVersion=9.6.0` et refuse au charg
Le support CPU et le support de versions Android restent deux axes séparés.
`arm64-v8a` est la cible productive obligatoire. `x86_64` est la cible AVD obligatoire de la matrice de développement. Ces deux ABI doivent être présentes dans l'APK universal de validation et dans l'AAB tant qu'aucune décision ultérieure ne restreint la distribution.
`0-pre.4` révise la politique ABI : le projet vise le maximum raisonnable de compatibilité matérielle, y compris les architectures 32 bits encore supportées. La matrice obligatoire devient `arm64-v8a`, `armeabi-v7a`, `x86_64` et `x86`.
`armeabi-v7a` n'est pas introduite par défaut : elle ne permet pas de descendre sous API 21 avec SDL3, agrandit la matrice et ne répond à aucun besoin utilisateur mesuré à ce stade.
`arm64-v8a` reste la cible appareil productive principale et `x86_64` la cible AVD principale, mais elles ne constituent plus à elles seules le contrat de packaging. `armeabi-v7a` et `x86` sont également construites et packagées afin de conserver la compatibilité avec du matériel plus ancien.
Les ABI abandonnées par les toolchains Android modernes (`armeabi`, `mips`, `mips64`) restent hors contrat : les réintroduire exigerait une toolchain historique/forkée et ne correspondrait plus au pipeline Android courant.
Le plancher OS candidat est Android 5.0 / API 21. La version doit tenter un smoke sur API 21 si une image exploitable est raisonnablement disponible. À défaut, elle teste la plus ancienne API localement disponible et consigne explicitement la lacune ; elle ne transforme pas un smoke absent en validation fictive.
@@ -127,7 +129,7 @@ Pendant les tranches d'implémentation, les validations restent ciblées : audit
Les smokes de packaging deviennent plus larges seulement quand le jalon produit un artefact installable :
- APK universal : inspection ARM64/x86_64 + AVD x86_64 + appareil ARM64 ;
- APK universal : inspection des quatre ABI + AVD x86_64 + appareil ARM64 ; les ABI 32 bits sont fumées seulement si un device/AVD compatible est disponible ;
- compatibilité basse : AVD API 21 si raisonnablement disponible, sinon plus ancienne API disponible avec écart documenté ;
- AAB : inspection du bundle et des bibliothèques natives, y compris compatibilité 16 KB ;
- beta/RC : gate workspace large planifiée, rebuild reproductible et smokes finaux.
@@ -154,7 +156,13 @@ Retirer le wrapper natif introduit pour la preuve `0-pre.2`, déclarer et contr
La factorisation commune étant réduite au mapping `module -> feature`, ajouter Reflex comme second consommateur avec les mêmes deux ABI, sans nouvelle architecture.
### `0-pre.4` — AAB, minSdk et fermeture du chemin historique
### `0-pre.4` — matrice ABI Android complète
Étendre Snake et Reflex aux quatre ABI encore supportées par Android NDK/SDL3/Rust : `arm64-v8a`, `armeabi-v7a`, `x86_64`, `x86`. Produire des APK Debug universal et vérifier mécaniquement les huit bibliothèques attendues par application.
Les smokes matériels restent ciblés sur les environnements disponibles ; l'absence d'un device/AVD 32 bits ne doit pas être transformée en fausse preuve runtime.
### `0-pre.5` — AAB, minSdk et fermeture du chemin historique
Ajouter/valider le chemin `bundleRelease` sans secret, inspecter le bundle et la compatibilité 16 KB, exécuter la stratégie de smoke du plancher Android et supprimer `scripts/build_android_rust.py` si toutes ses responsabilités ont effectivement migré.
@@ -176,7 +184,7 @@ Promotion mécanique de la RC validée. Aucun changement fonctionnel ou architec
## Sizing
Le scope reste raisonnable pour une seule version si les quatre prereleases conservent leurs frontières verticales. Les zones susceptibles de forcer un split de version sont uniquement une incompatibilité profonde de `cargo-ndk` avec AGP/Gradle, une SDL3 AAR non exploitable par Prefab comme prévu, ou une exigence produit nouvelle pour le 32 bits.
Le scope reste raisonnable pour une seule version avec cinq prereleases techniques avant beta, la nouvelle `0-pre.4` isolant volontairement l'extension 32 bits du packaging AAB/16 KB. Les zones susceptibles de forcer un split de version sont uniquement une incompatibilité profonde de `cargo-ndk` avec AGP/Gradle, une SDL3 AAR non exploitable par Prefab comme prévu, ou une incompatibilité effective d'une des deux ABI 32 bits encore supportées.
Un simple besoin de `.fix.N` après validation ne remet pas ce sizing en cause.
@@ -206,7 +214,7 @@ La politique a été révisée après validation de `0-pre.2` : le projet Androi
`0.3.3` peut entrer en RC lorsque :
- un build Gradle Android natif n'exige plus `scripts/build_android_rust.py` ;
- Snake produit un APK universal ARM64/x86_64 par un seul chemin Gradle ;
- Snake et Reflex produisent un APK universal contenant `arm64-v8a`, `armeabi-v7a`, `x86_64` et `x86` par un seul chemin Gradle ;
- l'AAB de distribution est constructible sans secret embarqué ;
- les bibliothèques natives finales sont vérifiées pour la contrainte 16 KB ;
- le minSdk soutenu et la preuve de smoke disponible sont documentés sans surpromesse ;

25
docs/studies/025-V0_3_3_ANDROID_NATIVE_MULTI_ABI_AUDIT.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/studies/025-V0_3_3_ANDROID_NATIVE_MULTI_ABI_AUDIT.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Audit Android SDL3 natif multi-ABI pour 0.3.3
@@ -152,7 +152,7 @@ Source officielle : <https://developer.android.com/guide/practices/page-sizes>.
Cette contrainte renforce le maintien de NDK r28c. La validation AAB doit inclure un contrôle d'alignement/compatibilité des bibliothèques natives, et un smoke 16 KB peut être ajouté si une image d'émulateur adéquate est raisonnablement disponible.
## ABI retenues pour le chemin par défaut
## ABI retenues pour le chemin par défaut lors du cadrage initial
Les deux ABI de base proposées sont :
@@ -173,18 +173,35 @@ Raisons :
`x86` 32 bits n'est pas retenue dans la matrice de base.
### Révision décidée après validation de 0-pre.3
Après la preuve `arm64-v8a + x86_64`, la politique produit a été explicitement élargie : le projet doit tenter de supporter le maximum d'architectures Android encore prises en charge par la toolchain moderne, y compris anciennes. La matrice cible devient donc :
```text
arm64-v8a
armeabi-v7a
x86_64
x86
```
Cette révision ne prétend pas réintroduire `armeabi`, `mips` ou `mips64`, retirées des toolchains Android modernes. Elle augmente la couverture CPU sans changer le plancher OS SDL3, qui reste API 21. La décision normative actualisée est portée par le plan `0.3.3` et les documents Android durables.
## APK universal, AAB et splits
Pour les tests locaux, la cible est un APK Debug universal contenant les deux ABI retenues :
Après la révision de scope, la cible locale est un APK Debug universal contenant les quatre ABI retenues :
```text
lib/arm64-v8a/libSDL3.so
lib/arm64-v8a/libgame_android_entrypoint.so
lib/armeabi-v7a/libSDL3.so
lib/armeabi-v7a/libgame_android_entrypoint.so
lib/x86_64/libSDL3.so
lib/x86_64/libgame_android_entrypoint.so
lib/x86/libSDL3.so
lib/x86/libgame_android_entrypoint.so
```
Aucun split ABI Gradle ne doit être activé par défaut pour cet artefact : un seul APK doit pouvoir être installé sur l'appareil ARM64 et sur l'AVD x86_64.
Aucun split ABI Gradle ne doit être activé par défaut pour cet artefact : un seul APK contient les quatre variantes CPU et doit pouvoir être installé sur chaque architecture compatible. Les smokes effectifs restent limités aux appareils/AVD disponibles.
Pour la distribution, la cible est un AAB. Le format App Bundle laisse au store la génération des APK optimisés par configuration, notamment par ABI ; un AAB n'est pas lui-même un APK installable.