Package Name — définition, notation de domaine inversé et exigences

Qu’est-ce que Package Name dans Android

Package Name est une chaîne unique qu’Android utilise pour identifier une application au niveau du système d’exploitation. Elle correspond au champ package dans le fichier AndroidManifest.xml et au champ applicationId dans le fichier build.gradle du module de l’application. Sans un Package Name unique, il est impossible d’installer une application sur l’appareil de l’utilisateur.

Objectif du Package Name

Sur l’appareil, le Package Name sert de clé pour la gestion des applications : le système stocke les données, les paramètres et le cache de chaque application dans le répertoire /data/data/[packageName]. Deux applications avec le même identifiant ne peuvent pas coexister — en tentant d’installer un doublon, le système invite à supprimer l’application existante.

Package Name et Application ID

Dans Android Gradle Plugin version 0.11+, une séparation a été introduite entre Package Name (dans le manifeste) et Application ID (dans build.gradle). L’Application ID est l’identifiant réel de l’application pour le système et Google Play. Le Package Name dans le manifeste est utilisé pour la résolution des ressources et la génération de la classe R. Il est recommandé de les garder identiques pour simplifier.

// build.gradle (Module: app)
android {
    defaultConfig {
        applicationId "com.example.myapplication"
        minSdkVersion 24
        targetSdkVersion 34
        versionCode 1
        versionName "1.0"
    }

    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }
    }
}

Le champ applicationIdSuffix permet d’ajouter un suffixe à l’Application ID pour différentes configurations de build. Une version debug peut avoir l’identifiant com.example.app.debug, permettant de l’installer aux côtés de la version de production pour des tests parallèles.

Règles de nommage du Package Name

Google Play établit des règles strictes pour le Package Name à respecter lors de la publication. L’identifiant doit être unique dans tout le store, respecter les exigences syntaxiques et ne pas violer les politiques de marques déposées.

Exigences syntaxiques

Le Package Name ne peut contenir que des lettres latines (A-Z, a-z), des chiffres (0-9), un point (.) et un tiret bas (_). La longueur maximale est de 150 caractères. Chaque segment entre les points doit commencer par une lettre. Les traits d’union, espaces et caractères spéciaux sont interdits par les règles de Google Play.

Exigences d’unicité

L’unicité du Package Name est une exigence absolue du Google Play Store. Si une autre application utilise déjà l’identifiant sélectionné, la publication sera rejetée. Google ne libère pas les identifiants des applications supprimées, donc choisir le premier Package Name est une décision critique pour chaque développeur.

Notation de domaine inversé et conventions

La notation de domaine inversé est un standard de nommage où le nom de domaine de l’entreprise est écrit en ordre inversé : com.example au lieu de example.com. Ce système garantit l’unicité globale des identifiants car chaque nom de domaine est intrinsèquement unique.

Préfixes standards

Les développeurs utilisent généralement un préfixe correspondant au TLD de leur domaine : com pour les organisations commerciales, org pour les organisations à but non lucratif, io pour les projets technologiques, net pour les services et solutions réseau. Pour les projets personnels, com.github.username ou com.email est acceptable.

• com.company.app — format standard pour les applications commerciales
• org.company.app — pour les projets à but non lucratif et open-source
• io.company.app — populaire parmi les startups et produits SaaS
• com.github.username — pour les projets personnels sur GitHub

Conventions pour les projets multiplateformes

Pour les applications publiées sur iOS et Android, il est recommandé d’utiliser le même identifiant sur les deux plateformes. Cela simplifie l’intégration avec Firebase, AppsFlyer, Adjust et autres systèmes d’analyse qui se lient à l’identifiant du projet. Par exemple, com.mycompany.myapp sera le Bundle ID sur iOS et le Package Name sur Android.

Configurer Package Name dans un projet Android

La configuration du Package Name dans un projet Android implique la modification de l’applicationId dans build.gradle et de la structure de répertoires du code source Java/Kotlin correspondante. Android Studio fournit des outils de refactorisation du Package Name, mais pour les projets complexes, une migration étape par étape est recommandée.

Structure de répertoires et Package Name

// Le chemin du fichier correspond au Package Name
// com/example/myapp/MainActivity.kt

package com.example.myapp

import android.os.Bundle
import androidx.activity.ComponentActivity

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
    }
}

Dans Kotlin et Java, le Package Name dans les fichiers source doit correspondre à la structure de répertoires. Lors du changement du Package Name dans build.gradle, vous devez déplacer les fichiers vers les répertoires correspondants et mettre à jour toutes les déclarations package et import. Android Studio peut le faire automatiquement via Refactor -> Move, mais pour les grands projets avec des dizaines de fichiers, il est recommandé de vérifier le résultat après la refactorisation.

Si le projet utilise Data Binding, View Binding ou Hilt, le changement du Package Name affectera également les classes générées. Les classes de binding sont créées en fonction du Package Name du module et du répertoire layout. Après avoir changé l’identifiant, vous devrez reconstruire le projet pour mettre à jour toutes les références générées. Il est recommandé d’effectuer une clean build après le changement du Package Name pour éviter les erreurs dues aux anciennes références en cache.

Dans Gradle 7.0+, la prise en charge de namespace dans build.gradle a été introduite, remplaçant le champ package dans AndroidManifest.xml pour la génération de la classe R et des ressources. Pendant ce temps, applicationId reste l’identifiant réel de l’application pour le système et Google Play. Cela permet d’avoir des applicationId et namespace différents, ce qui est utile pour les modules de bibliothèque où le namespace est fixe tandis que l’identifiant public peut changer lors du build.

Pour les projets avec une architecture modulaire, le changement du Package Name d’un module peut affecter les imports dans d’autres modules. Si le module data a le package com.example.data et que le module domain utilise ses classes, après le changement d’identifiant, mettez à jour les imports dans tous les modules dépendants. Android Gradle Plugin version 8.0+ simplifie ce processus avec la génération automatique de namespace depuis build.gradle.

Vérifier Package Name via le code

Pour obtenir l’Application ID actuelle, utilisez la classe BuildConfig : BuildConfig.APPLICATION_ID. C’est pratique pour la logique conditionnelle dans le code, la liaison à l’environnement ou l’affichage de l’identifiant dans les écrans de debug. BuildConfig est généré automatiquement en fonction de build.gradle.

// Obtenir l’Application ID à l’exécution
val packageName = BuildConfig.APPLICATION_ID
val packageManager = packageManager
val appInfo = packageManager.getPackageInfo(packageName, 0)

println("App version: ${appInfo.versionName} (${appInfo.versionCode})")
println("Package: $packageName")

Modifier Package Name après publication

Modifier le Package Name après avoir publié une application sur Google Play est une opération qui signifie créer un tout nouveau produit. Le système ne permet pas de mettre à jour une application existante avec un Package Name différent, donc décider de changer l’identifiant équivaut à redémarrer le projet dans le store.

Conséquences du changement de Package Name

Lors du changement de Package Name sont perdus : toutes les notes et avis, les statistiques d’installation, l’intégration Google Services (si non migrée), les liens du projet Firebase (nécessite la création d’un nouveau google-services.json). Les utilisateurs ne recevront pas de mise à jour automatique — ils verront la nouvelle application dans le store.

• Notes et avis — restent avec l’ancienne application, non transférés
• Statistiques d’installation — réinitialisées pour le nouveau Package Name
• Projets Firebase — nécessitent une nouvelle configuration google-services.json et une reconfiguration de tous les services
• Utilisateurs — ne reçoivent pas de mises à jour automatiques, doivent être notifiés séparément

Quand le changement de Package Name est justifié

Changer le Package Name peut être justifié lors d’un changement de marque de l’entreprise, du transfert de l’application vers un autre compte développeur, ou de la création d’une version séparée pour une autre région. Dans tous les cas, avant le changement, il est recommandé d’informer les utilisateurs via l’ancienne application et de préparer un plan de migration avec transfert de données. Sans plan de migration, les utilisateurs perdront l’accès au contenu acheté, aux abonnements et aux données sauvegardées de l’application. La migration inclut le transfert de la base de données et des fichiers via SharedPreferences ou Room.

Avant de changer le Package Name, assurez-vous que le nouvel identifiant est unique et respecte les règles de nommage. Créez une nouvelle application dans Google Play avec le nouveau Package Name et publiez-la comme un produit séparé. Dans la description de l’ancienne application, fournissez un lien vers la nouvelle. Envisagez d’utiliser Google Play Custom Store Listing pour rediriger les utilisateurs.