Modification de l'applicationId

[PaulLabruyere]

Bonjour à toustes,

Picardie Nature est en train de développer une application de saisie customisée, connectée à la BDD GeoNature picarde Clicnat, à partir de la version 2.6.0 de Occtax mobile. Un passage à la version 2.7 est envisagé dès que notre instance GeoNature sera à jour.

L'application "Clicnat mobile" en elle même est terminée, mais il reste un problème à résoudre : il n'est pas possible d'avoir deux applications Occtax mobile installée sur un même appareil. En effet, même si deux fichiers apk ont été générés séparément, à partir de codes sources différents (pas la même version et/ou customisation du code source), il semble que le terminal considère qu'il s'agit de la même application.

Nous avons essayé de modifier le champ applicationId dans le fichier occtax/build.gradle pour le distinguer de l'id d'origine (fr.geonature.occtax2) :

android {

    defaultConfig {
        applicationId "fr.geonature.clicnatapp"

    }

et nous indiquons la même valeur côté BDD, dans le champ gn_commons.t_mobile_apps.package.

Le build et l'installation se passent bien. Dans les fichiers du téléphone, on trouve bien un dossier Android/data/fr.geonature.clicnatapp.

Mais au moment d'installer une autre application GN (ici celle de l'ARB Île-de-France 👋), l'installation plante avec cette erreur :

En installant séparément l'appli IDF, le dossier créé s'appelle pourtant Android/data/fr.geonature.occtax2.

J'ouvre donc ce ticket avec un double objectif :
Demander de l'aide !
Il n'est sans doute pas suffisant de simplement modifier le applicationId de l'application, mais n'étant pas familier du développement Android, je ne sais pas comment faire.

Ouvrir la discussion
Il nous semble utile de pouvoir avoir plusieurs applications Occtax mobile sur un même appareil. En effet, un utilisateur de passage qui souhaiterait télécharger l'application "locale" ne devrait pas avoir à désinstaller l'application en usage dans sa région. Des utilisateurs évoluant sur des régions limitrophes possédant chacune son appli peuvent aussi avoir l'usage des deux applications alternativement.

Il semble également contre-intuitif de modifier l'URL de GeoNature renseignée dans les paramètres, et d'utiliser une seule application pour se connecter à plusieurs BDD, avec des différences potentielles de versions, de nomenclatures... La configuration de l'application (settings.json) peut également avoir été pensée pour une zone géographique et une instance GN particulières. Il nous apparaît préférable de garder deux applis distinctes.

Toutefois nous avons conscience que ce problème ne se pose pas partout, ou en tous cas pas de la même façon. Il n'y a pas de raison d'installer plusieurs Occtax sur les terminaux "professionnels" des agents des parcs nationaux par exemple. La possibilité de modifier l'identité de l'application doit donc rester optionnelle.

Il serait bienvenu de documenter la marche à suivre pour modifier l'identité de l'application, au même titre que la procédure visant à modifier le nom ou l'identité visuelle de l'appli. Ainsi, les structures voulant développer leur propre app pourraient le faire "proprement" si l'application est à destination d'un public relativement large.

Cette modification pose toutefois un certain nombre de questions : signature de l'apk, suivi des mises à jour (l'identifiant doit rester stable dans le temps), probablement d'autres auxquelles je n'ai pas pensées.

Merci d'avance pour votre aide et vos contributions !

Paul Labruyère
Picardie Nature

[DonovanMaillard]

Bonjour Paul

En effet ça risque de ne pas suffir (la BDD a le même nom etc), je pense que @sgrimault pourra donner davantage d'infos là dessus mais en effet, il faudra des compétences en développement mobile je pense.

En revanche, la prochaine version de Android (voire la derniere sortie je ne sais pas) avait normalement dans les tuyax le fait de pouvoir installer plusieurs fois le meme package qu'on pouvait configurer differemment (typiquement pour ces applications métiers, les entreprises qui bossent avec différentes filiales etc). A voir ou ca en est, si c'est déjà possible ou non, mais ca pourrait répondre à votre besoin sans mettre les mains dans le moteur.

[camillemonchicourt]

Oui on en avait pas mal parlé avec @DonovanMaillard, je ne sais plus si c'est dans un ticket.

L'idée était déjà de faire en sorte que l'on puisse avoir une seule application Occtax-mobile et switcher d'un GeoNature à un autre en modifiant son URL dans les paramètres.

Ça fonctionne à peu prêt, mais il me semble qu'il faudrait ajuster quelques trucs pour que cela soit vraiment opérationnel. Notamment supprimer bien toutes les données locales si on change l'URL de l'instance GeoNature pour bien relancer un téléchargement complet.

Bien sur, pourrait rester le soucis que la version d'Occtax-mobile d'une instance GeoNature ne soit pas la même que celle attendue sur l'autre. Ça ça reste un soucis, mais là aussi on pourrait ajouter des contrôles pour mieux gérer ce cas, mais ça devient un peu complexe en effet.

Le fait de pouvoir plusieurs versions de l'application sur un même terminal n'est pas prévu ni supporté.
A voir comme dit @DonovanMaillard ce qui peut être fait au niveau des nouvelles possibilités natives d'Android, ou alors si il faut investir dans cela avec des développements au niveau d'Occtax-mobile lui-même.

[DonovanMaillard]

A priori dans la version 14 de android sortie il y a déjà un petit moment, il est possible d'aller dans les paramètres > Application > Cloner les applications pour créer une seconde instance d'une appli. Je ne sais pas si pour autant on peut en créer plus de 2 , si elles peuvent avoir des versions différentes etc. Mais c'est une solution à tester

[sgrimault]

Bonjour @PaulLabruyere,

Oui, il suffit simplement de modifier la valeur de applicationId par "fr.geonature.clicnatapp" sous defaultConfig dans le fichier occtax/build.gradle.
Puis ensuite de personnaliser le nom de l'application en modifiant app_name dans le fichier occtax/src/main/res/values/strings.xml, comme suit :

<string name="app_name" translatable="false">Clicnat</string>

Concernant la personnalisation, j'avais ajouté une petite note (qui date un peu), vous la trouverez ici :
https://github.com/PnX-SI/gn_mobile_core/blob/develop/docs/styles_themes.adoc

Je suppose que vous avez généré et utilisé votre propre keystore pour signer l'application ?
Concernant l'erreur, il faudrait voir déjà si l'APK généré est bien conforme, notamment au niveau du package name qui doit correspondre à la valeur de applicationId . Pour cela, il y a l'utilitaire aapt fourni avec les outils du SDK Android :

aapt dump badging /chemin/vers/mon/fichier.apk

[sgrimault]

J'ai pu faire un build en partant de la version 2.6.2 de "Occtax" en changeant son package name et son nom et l'installer sur un terminal qui possède déjà une version de "Occtax" (plus récente).

[sgrimault]

Par contre, il peut y avoir un conflit au niveau des permissions fixées notamment au niveau du module de synchronisation. Ce module reste "générique" mais garde toujours les mêmes définitions sur les permissions pour accéder au ContentProvider. Donc si deux applications cohabitent, il faudrait sans doute pouvoir surcharger ces définitions (cf. https://github.com/PnX-SI/gn_mobile_core/blob/develop/commons/src/main/AndroidManifest.xml et https://github.com/PnX-SI/gn_mobile_occtax/blob/develop/occtax/src/main/AndroidManifest.xml#L78)

[PaulLabruyere]

Bonjour, et merci pour vos réponses :)

L'application d'origine était générée en debug, donc l'apk n'était même pas signé ! Malheureusement je viens de faire le test en rebuildant l'application en mode release et en la signant avec un fichier keystore généré pour l'occasion, et j'ai toujours le même souci.

J'avais bien changé le app_name, dans le fichier de ma flavor occtax/src/clicnat/res/values/strings.xml mais qui surcharge celui du main/ il me semble.

Quand j'analyse les deux apk, j'ai bien des noms de package différents :

$ aapt dump badging clicnat_mobile.apk
package: name='fr.geonature.clicnatapp' versionCode='3200' versionName='2.6.0.3200' compileSdkVersion='33' compileSdkVersionCodename='13'
...
application-label:'Clicnat'
(idem pour toutes les locales)

En revanche les deux ont leurs permissions en commun, et notamment celles du module sync

uses-permission: name='fr.geonature.sync.permission.READ'
uses-permission: name='fr.geonature.sync.permission.WRITE'

Je vois aussi dans les "logs" du build une ligne qui m'interpelle :

> Task :occtax:processClicnatReleaseMainManifest
package="fr.geonature.occtax" found in source AndroidManifest.xml: [...]/occtax/src/main/AndroidManifest.xml.
Setting the namespace via a source AndroidManifest.xml's package attribute is deprecated.
Please instead set the namespace (or testNamespace) in the module's build.gradle file, as described here: https://developer.android.com/studio/build/configure-app-module#set-namespace
This migration can be done automatically using the AGP Upgrade Assistant, please refer to https://developer.android.com/studio/build/agp-upgrade-assistant for more information.

et effectivement dans le fichier en question

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="fr.geonature.occtax">

dans le code source il y a pas mal de fichier qui commencent par un package fr.geonature.occtax donc j'imagine que lors du build le code est compilé dans le "namespace" indiqué par ce param. Est-ce que le conflit entre les deux applis ne pourrait pas venir de ce "namespace" en commun ?

J'ai essayé de changer le nom pour mettre le même que l'applicationId, évidemment ça ne compile plus. Si je renome le package dans un fichier donné, le fichier en question compile à nouveau. J'hésite à modifier tous les fichiers (sed -r), encore une fois étant complètement novice en dév mobile je ne veux pas jouer à l'apprenti sorcier... D'autant que visiblement les autres sous-modules ont aussi leur namespace (fr.geonature.commons, fr.geonature.datasync, fr.geonature.mountpoint, fr.geonature.viewpager) : faudrait-il les modifier aussi pour éviter les conflits ?

[sgrimault]

Oui, la définition du package dans le fichier occtax/src/main/AndroidManifest.xml est obsolète mais il ne faut pas confondre le nom du package au niveau des classes (ici fr.geonature.occtax que l'on retrouve dans le répertoire des sources du projet occtax/src/main/java/fr/geonature/occtax) du package name de l'application (ici fr.geonature.occtax2). Même chose pour les modules (bibliothèques) de l'application comme commons, datasync, maps, etc.
Il ne faut modifier que la valeur de l'attribut applicationId dans le fichier occtax/build.gradle.
Pour moi, le souci vient de la définition des permissions au niveau du ContentProvider qui reste par défaut avec le nom d'un ancien module (renommé entre-temps datasync) dans le projet gn_mobile_core. Si on installe deux versions de l'application (donc avec un package name différent), elles vont partager la même définition des permissions définis au niveau du ContentProvider. Je n'ai pas eu le problème en faisant mon test car l'application d'exemple a été signée avec le même keystore que l'application "officielle". Mais il y aura sans doute des effets de bords, surtout lors de la récupération des données (comme les taxons) car on aura deux instances du ContentProvider (mais avec un authority différent) qui partagent les mêmes définitions des permissions...

Je vais faire cette correction lors d'une prochaine release pour pouvoir suivre le nom du package de l'application (ou du moins que l'on puisse la surcharger facilement).

Pour votre version, il faudrait faire le test suivant qui consiste à modifier la déclaration du ContentProvider dans le fichier occtax/src/main/AndroidManifest.xml comme suit :

<provider
  android:name="fr.geonature.commons.data.MainContentProvider"
  android:authorities="${applicationId}.provider"
  android:exported="true"
  android:readPermission="${applicationId}.provider.permission.READ"
  android:writePermission="${applicationId}.provider.permission.WRITE" />

Et de modifier aussi le fichier commons/src/main/AndroidManifest.xml comme suit :

<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android">

    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="${applicationId}.provider.permission.READ" />
    <uses-permission android:name="${applicationId}.provider.permission.WRITE" />

    <permission
        android:name="${applicationId}.provider.permission.READ"
        android:protectionLevel="signature" />
    <permission
        android:name="${applicationId}.provider.permission.WRITE"
        android:protectionLevel="signature" />

</manifest>

Si cela ne fonctionne pas, ce serait de tester dans un premier temps avec des valeurs en dur et donc de remplacer ${applicationId} par fr.geonature.clicnatapp.

[PaulLabruyere]

Re !

J'ai fait les modifs que tu conseillais @sgrimault et désormais tout fonctionne correctement :)

Les persmissions ont bien été renommées dans l'APK :

$ aapt dump badging clicnat_mobile_release.apk
package: name='fr.geonature.clicnatapp' versionCode='3200' versionName='2.6.0.3200' compileSdkVersion='33' compileSdkVersionCodename='13'
...
uses-permission: name='fr.geonature.clicnatapp.provider.permission.READ'
uses-permission: name='fr.geonature.clicnatapp.provider.permission.WRITE'
...
application-label:'Clicnat'

Et l'application peut être installée à côté d'un Occtax standard.

L'application Clicnat a l'air de fonctionner correctement avec les permissions renommées, j'ai demandé à des collègues de tester l'appli IDF.

Merci encore pour votre aide ! Est-ce que tu veux que je commit la modif des AndroidManifest pour abstraire le nom de l'application ?

[camillemonchicourt]

Merci encore pour votre aide ! Est-ce que tu veux que je commit la modif des AndroidManifest pour abstraire le nom de l'application ?

Bien sur, toute contribution, toute PR est toujours bienvenue ! ❤️

[sgrimault]

Bonjour @PaulLabruyere,

Ok très bien 🙂
Oui, tu peux faire une PR (il y en a même deux à faire) :

• La première dans gn_mobile_core pour la branche develop
• La seconde dans gn_mobile_occtax pour la branche develop

Merci

[sgrimault]

@PaulLabruyere,
Merci pour les PRs, je vous ai fais un petit retour concernant celle coté gn_mobile_core.

[camillemonchicourt]

Fait dans la 2.7.1