Installation Android < 9

[cen-cgeier]

Je ne sais pas si il y a une volonté de rendre occtax-mobile fonctionnel pour les version d'Android < 9 mais voici un problème que je rencontre avec un des téléphones de terrain de ma structure.

Version de l'application Version d'Occtax-mobile affectée par le bug : 2.0.1 Version de GeoNature utilisée : 2.9.2

Terminal et Version Android Marque et modèle du terminal : Samsung galaxy Note 4 Version d'Android : 6.0.1

Description du bug et comportement attendu Installation de l'application via l'apk : OK Au lancement de l'application, celle-ci se referme immédiatement avant de pouvoir afficher quoi que ce soit (page de paramètre). Comportement attendu : Ouverture de l'application sur la page de paramètre pour une définition de l'url geonature ainsi que l'url taxhub.

Logs

14:54:15.914 INFO: [fr.geonature.occtax.MainApplication] starting fr.geonature.occtax2... 14:54:15.915 INFO: [fr.geonature.occtax.MainApplication] logs directory: '/storage/emulated/0/Android/data/fr.geonature.occtax2/logs' 14:54:15.915 INFO: [fr.geonature.occtax.MainApplication] internal storage: 'MountPoint(mountPath=/storage/emulated/0, storageType=INTERNAL)' 14:54:15.916 INFO: [fr.geonature.occtax.MainApplication] external storage: 'MountPoint(mountPath=/storage/3533-3732, storageType=EXTERNAL)' 14:54:15.970 ERROR: [fr.geonature.occtax.MainApplication$TinylogUncaughtExceptionHandler] java.lang.NoClassDefFoundError: Failed resolution of: Ljava/time/Duration; at fr.geonature.datasync.auth.worker.CheckAuthLoginWorker$Companion.enqueueUniquePeriodicWork-SxA4cEA(CheckAuthLoginWorker.kt:98) at fr.geonature.datasync.auth.worker.CheckAuthLoginWorker$Companion.enqueueUniquePeriodicWork-SxA4cEA$default(CheckAuthLoginWorker.kt:90) at fr.geonature.occtax.MainApplication.checkAuthLogin(MainApplication.kt:80) at fr.geonature.occtax.MainApplication.onCreate(MainApplication.kt:48) at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1036) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6317) at android.app.ActivityThread.access$1800(ActivityThread.java:221) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1860) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:158) at android.app.ActivityThread.main(ActivityThread.java:7225) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120) Caused by: java.lang.ClassNotFoundException: Didn't find class "java.time.Duration" on path: DexPathList[[zip file "/data/app/fr.geonature.occtax2-1/base.apk"],nativeLibraryDirectories=[/data/app/fr.geonature.occtax2-1/lib/arm, /vendor/lib, /system/lib]] at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56) at java.lang.ClassLoader.loadClass(ClassLoader.java:511) at java.lang.ClassLoader.loadClass(ClassLoader.java:469) ... 14 more

[DonovanMaillard]

Bonjour,

On aimerait bien... malheureusement, la gestion des différentes versions d'Android, de ses dérivés selon la marque du terminal (qui modifient l'OS pour certains), et la multitude des configurations possibles font qu'on ne peut pas maintenir une compatibilité sur les versions trop anciennes d'Android.

Peut-être que ce soucis en particulier serait simple à traiter (?) mais la gestion des droits d'accès au stockage, les accès au GPS etc ont du pas mal changer en 6 versions majeures.

[camillemonchicourt]

Je ne sais plus si on a une version minimale que l'on gère ou pas. Je sais pas si on est compatible avec Android 8 et 9 ? Mais en effet la 6 ça devient lointain ça. :-)

[DonovanMaillard]

sur la 7 ça ne fonctionne pas non plus (GPS, en revanche l'appli se lance) et sur la 9 aux dernières nouvelles, on fonctionne. 8.... mystère

[DonovanMaillard]

mais de mémoire, dès la mise en place des presta PNV pour occtax mobile, le cahier des charges commencait à Android 7 car il y avait des gros changements par rapport à la 6

Celà dit, les applications mobiles dont les dernières releases fonctionnent sur Android 6 doivent commencer à se faire rares !

[sgrimault]

Bonjour,

Effectivement, certaines parties du code utilise des fonctionnalités un peu trop récentes pour les anciennes versions d'Android (notamment l'API Duration non disponible). Pour offrir un "meilleur" support, ça implique de devoir implémenter 2 "versions" pour chaque portion de code pouvant poser problème : La première exploitant les dernières APIs et nouveautés, la seconde en se basant sur du "legacy". La maintenance s'en retrouve aussi affectée surtout lors des montées de version des dépendances tierces et SDK Android. À chaque montée de version, le "legacy" s'en trouvera plus ou moins affecté jusqu'au jour où son support ne peut plus être garanti.

Le dernier point était aussi le chantier sur le support d'Android 11 qui impliquait pas mal de choses…, notamment sur les accès à l'espace de stockage externe. La partie "legacy" sur cette partie du code à pris cher…

Pour information, le min SDK fixé actuellement dans le code est resté sur l'API 21 (cible : Android 5), ce qui est déjà un non sens car l'application est de facto non fonctionnelle sur cette version d'Android. En ciblant par exemple l'API 24 (cible : Android 7), ou l'API 26 (cible : Android 8) ça permettrait déjà d'éliminer du code "legacy" inutile afin de pouvoir utiliser des APIs plus récentes.

La question maintenant est jusqu'à quelle version d'Android on peut offrir un support, sachant que plus l'éventail est étendu, plus long seront les phases de tests. Pour ma part, je peux assurer à minima Android 9 jusqu'à 11, sachant qu'idéalement il faudrait appliquer un minimum de tests sur de vrais terminaux (de Android 7 ou 8 à priori ? jusqu'aux dernières versions).

[camillemonchicourt]

Actuellement il le semble qu'il n'est pas utile d'aller en dessous de la version 8. Sinon la version 9, si la 8 pose trop de soucis.

[DonovanMaillard]

Comme Camille, pour moi on doit garantir la version 9 jusqu'à 12 (et non plus 11). Et tant que l'implication est faible, maintenir jusqu'à la 8 tant que c'est possible

[cen-cgeier]

Effectivement, Android 6 date un peu et certains de nos outils de terrains aussi ^^' Merci à tous pour ces retours, ça m'a permis d'y voir un peu plus claire sur la compatibilité d'occtax-mobile avec de notre flotte. Pour les anciens téléphones qui le permettent, savez-vous si un root d'Android 9 permettrait de rendre occtax-mobile fonctionnelle ?

[DonovanMaillard]

jamais testé à ma connaissance... à priori, j'imagine que oui. Mais à priori, je pense qu'il faut tester un peu au cas par cas selon le mobile utilisé.

[sgrimault]

Comme Camille, pour moi on doit garantir la version 9 jusqu'à 12 (et non plus 11). Et tant que l'implication est faible, maintenir jusqu'à la 8 tant que c'est possible

Donc on acte le fait que "Occtax" n'est compatible qu'à partir de Android 8 ? J'ai fais quelque tests via un émulateur sur Android 8 avec succès.

[camillemonchicourt]

Oui on a testé sur des terminaux en Android 8 et ça fonctionnait bien. Si on peut supporter depuis la version 8, cela me semble très bien.

[sgrimault]

Ok merci pour ton retour, je vais donc le fixer dans le manifest pour la prochaine version.

[sgrimault]

La version minimale requise est Android 8.0, fixée officiellement avec la version 2.3.0.