Comme chaque année (2020, 2019, 2018...), Google demande de relever le niveau d'API "TargetSdkVersion" des applications pour les déployer dans le Play Store. Avec la sortie de Android 11, le niveau d'API imposé pour que Google autorise le déploiement doit être à 30. Cela s'applique à partir de :
- Août 2021 pour la publication de nouvelles applications,
- Novembre 2021 pour les applications mises à jour.
Afin de générer une application avec ce niveau d'API, il faut utiliser WINDEV Mobile 26 à partir de sa version "Update 3 (déploiement en mai 2021).
Grâce aux adaptations faites dans le framework Android de WINDEV Mobile 26 "Update 3", ce changement est transparent pour les applications. L'exécution sous Android 11 ne nécessite donc pas de modification. Exceptions pour confirmer la règle :
- la demande de permission si la localisation est utilisée, ou localisation en arrière plan,
- l'emplacement des fichiers utilisés par une application.
Dans ces deux cas Google demande de modifier la façon de travailler, et donc des modifications peuvent être nécessaires dans les applications...
Cas 1 - Application qui utilise la localisation ou la localisation en arrière-plan...
Avant Android 11, les fonctions qui permettent la localisation de l'appareil demandent automatiquement deux permissions : la permission de localisation et la permission de localisation en arrière plan.
Lorsque la permission est demandée la popup suivante est affichée avec 3 choix :
- "Toujours autoriser" : la permission est accordée que l'application soit au premier plan ou en arrière plan
- "Autoriser seulement si l'appli est en cours d'utilisation" : la permission est accordée uniquement lorsque l'application est au premier plan
- "Refuser" : la localisation ne sera pas accessible.
A partir de Android 11, il n'y a plus la possibilité de demander simultanément les permissions de localisation et de localisation en arrière plan. Deux demandes distinctes doivent être faites obligatoirement :
- la demande de permission de localisation ouvre toujours une popup mais sans le choix "Toujours autoriser" :
- La demande de permission de localisation en arrière plan ouvre une fenêtre système avec le choix "Toujours autoriser", qui elle permet la localisation en arrière plan :
Comme il est difficilement compréhensible pour l'utilisateur d'une application d'enchaîner deux fenêtres liées aux permissions, les changements et nouveautés suivantes sont disponibles à partir de la version "Update 3" de WINDEV Mobile 26 :
- les fonctions qui permettent la localisation de l'appareil demandent uniquement la permission de localisation. La liste exhaustive des fonctions concernées est la suivante :
gpsInitParametre, gpsRecuperePosition, gpsSuitDeplacement, gpsEtat, gpsInfo, gpsDetectePosition, gpsDernierePosition, gpsArreteDetection, wifiInfoConnexion, wifiDetectePointAcces, reseauMobileInfoConnexion, btListePeripherique, carteSuitDeplacement,geoSuiviActive, btleListePeripherique, beaconDetecteEnArrierePlan,beaconDetectePrecis.
- les nouvelles fonctions WLangage PermissionDemande et PermissionListe et le nouveau type de variable Permission (documentation complète à paraître) permettent de gérer les permissions de l'application. De cette manière le développeur peut faire une demande de permission si cela est nécessaire.
Une application qui utilise la localisation en arrière plan doit :
- ajouter la permission ACCESS_BACKGROUND_LOCATION dans l'assistant de génération de l'AAB de l'application,
- demander explicitement la permission de localisation en arrière plan. Par exemple :
PermissionDemande(permLocalisationEnArrièrePlan, Callback)
PROCEDURE INTERNE Callback(p est une Permission)
SI p..Accordé ALORS
géoSuiviActive(...
FIN
FIN
Remarques :
- La demande de permission de localisation en arrière plan avec la fonction PermissionDemande échoue si la permission de localisation n'a pas été accordée préalablement.
- Le choix de l'utilisateur lors de la demande de permission de localisation en arrière plan peut être davantage restrictif que son choix fait lors de la demande de permission de localisation. Dans ce cas l'application sera automatiquement relancée.
- Sur les appareils avec Android 9 ou plus ancien, si la permission de localisation a été accordée à l'application, la demande de permission de localisation en arrière plan sera accordée automatiquement.
Ces nouvelles possibilités permettent de résoudre une autre problématique liée à la publication des applications sur le Play Store. En effet si l'application permet la localisation en arrière plan, Google demande pour sa publication d'afficher une fenêtre expliquant les raisons de la localisation en arrière plan, et cela avant d'effectuer la demande de permission. Sans cette demande, la publication peut être rejetée avec la réponse "Prominent disclosure not found".
Avec les fonctions Permission* il devient plus simple de mettre en place ce dialogue avec l'utilisateur de l'application.
L'application WM Sport intégrée aux exemples de la version "Update 3" de WINDEV Mobile 26 contient les adaptations nécessaires pour cette gestion des permissions.
Cas 2 - Application qui utilise des fichiers à des emplacements qui ne lui sont pas dédiés :
Avant Android 11 les applications Android peuvent sans restriction lire et écrire des fichiers (HFSQL mobile, image, xml, json, ini...) dans le stockage internet et/ou externe :
- dans les répertoires de l'application sur l'espace de stockage interne (fRepEnCours, fRepExe, fRepDonnées)
- dans les dossiers de l'espace de stockage externe :
- arborescence personnelle à partir de la racine obtenue par la fonction SysRepCarteStockage,
- dans les répertoires obtenus par la fonction SysRepStockageExterne et les constantes sseApp*,
- dans les répertoires publics : Documents, Download, Images, etc. sur le stockage externe, obtenus avec la fonction SysRepStockageExterne et les constantes ssePublic*.
- créés par d'autres applications sur le stockage externe.
A partir d'Android 11, Google applique de nouvelles règles :
- une application ne peut plus lire ou écrire de fichiers sur le stockage externe en dehors des répertoires :
- dans les répertoires publics, une application ne peut accéder (en lecture ou en écriture) qu'aux fichiers qu'elle a elle même créé.
- si l'application est supprimée puis réinstallée, elle n'aura plus accès aux fichiers créés lors de l'installation précédente dans les répertoires publics du stockage externe.
- une application ne peut plus accéder aux fichiers créés par une autre application en manipulant ces fichiers par leur chemin.
- mise à part dans les dossiers de l'application (fRepDonnées...), c'est l'utilisateur de l'application qui doit lui-même sélectionner les fichiers auxquels l'application peut accéder. C'est la fonction WLangage URISélecteur qui permettra la sélection d'un fichier, qui devra alors exclusivement être manipulé par l'URI (type de variable) renvoyée par la fonction URISélecteur.
Il est donc conseillé de vérifier que l'application utilise bien exclusivement des données dans ses répertoires (fRepEnCours, fRepExe, fRepDonnées), ou à partir d'une URI obtenue par la fonction URISélecteur.
Une application déjà déployée sur des appareils peut ouvrepasser ces régles. Par exemple pour copier un fichier qu'elle a créé précédemment dans un emplacement maintenant interdit, vers un emplacement autorisé. L'application doit pour cela être générée avec l'attribut preserveLegacyExternalStorage dans son manifeste. Cet attribut ne s'applique que pour une application déjà installée sur un appareil. Pour une nouvelle installation, ou une application désinstallée puis réinstallée, l'attribut est ignoré.
Une nouvelle permission MANAGE_EXTERNAL_STORAGE de Android 11 permet d'outrepasser ces règles pour les applications installés, réinstallées, ou nouvelles. La permission MANAGE_EXTERNAL_STORAGE doit être :
- ajouter aux permissions de l'application dans l'assistant de génération de l'AAB,
- demander explicitement par l'application avec la nouvelle fonction PermissionDemande. Par exemple :
PermissionDemande(permGestionStockageExterne, Callback)
PROCEDURE INTERNE Callback(p est une Permission)
SI p..Accordé ALORS
...
FIN
L'utilisation de la permission MANAGE_EXTERNAL_STORAGE provoque :
- l'affichage d'une fenêtre système permettant d'autoriser d'accéder à tous les fichiers sur le stockage externe sans restriction :
- une vérification de la nature de l'application par Google pour sa publication dans le Play Store. Sont autorisées à utiliser cette permission les applications de type FileManager, Antivirus ou Gestionnaire de backup.
A noter que cette restriction des accès aux fichiers a débuté avec Android 10 et le niveau d'API 29. Il y avait cependant une tolérance dont bénéficiaient les applications WINDEV Mobile grâce à l'attribut RequestLegacyexternalStorage des applications. Cet attribut est ignoré par Android 11. Si besoin il peut être supprimé d'une application via l'édition du manifeste (cf. FAQ 21 483).
Synthèse du niveau/level d'API (TargetSdkVersion) indiqué dans le manifeste des applications Android en fonction de la version de WINDEV Mobile :
Liens utiles sur le sujet :
|