Package Name — wat is het, omgekeerde domeinnotatie en vereisten

Wat is Package Name in Android

Package Name — is een unieke tekenreeks die Android gebruikt om de applicatie op besturingssysteemniveau te identificeren. Het komt overeen met het veld package in het AndroidManifest.xml-bestand en het veld applicationId in het build.gradle-bestand van de applicatiemodule. Zonder een unieke Package Name is installatie van de applicatie op het apparaat van de gebruiker onmogelijk.

Doel van Package Name

Op het apparaat fungeert Package Name als sleutel voor het beheer van applicaties: het systeem slaat gegevens, instellingen en cache van elke applicatie op in de map /data/data/[packageName]. Twee applicaties met dezelfde identificatie kunnen niet naast elkaar bestaan — bij een poging een duplicaat te installeren, stelt het systeem voor de bestaande te verwijderen.

Package Name en Application ID

In Android Gradle Plugin versie 0.11+ is er een scheiding ontstaan tussen Package Name (in het manifest) en Application ID (in build.gradle). Application ID is de werkelijke identificatie van de applicatie voor het systeem en Google Play. Package Name in het manifest wordt gebruikt voor het oplossen van resources en het genereren van de R-klasse. Het wordt aanbevolen ze voor de eenvoud hetzelfde te houden.

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

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

Het veld applicationIdSuffix maakt het mogelijk een achtervoegsel aan Application ID toe te voegen voor verschillende compilatieconfiguraties. De debug-versie kan identificatie com.example.app.debug hebben, waardoor deze naast de productieversie kan worden geïnstalleerd voor parallel testen.

Naamgevingsregels voor Package Name

Google Play stelt strikte regels voor Package Name die bij publicatie moeten worden nageleefd. De identificatie moet uniek zijn op de schaal van de hele winkel, voldoen aan syntactische vereisten en het beleid voor het gebruik van handelsmerken niet schenden.

Syntactische vereisten

Package Name mag alleen Latijnse letters (A-Z, a-z), cijfers (0-9), punten (.) en het underscore-teken (_) bevatten. Maximale lengte — 150 tekens. Elk segment tussen punten moet met een letter beginnen. Koppeltekens, spaties en speciale tekens zijn verboden door de regels van Google Play.

Vereisten voor uniekheid

Uniekheid van Package Name — is een absolute vereiste van Google Play Store. Als een andere applicatie de gekozen identificatie al gebruikt, wordt publicatie geweigerd. Google geeft identificaties van verwijderde applicaties niet vrij, daarom is de keuze van de eerste Package Name een kritieke beslissing voor elk ontwikkelproject.

Omgekeerde domeinnotatie en conventies

Omgekeerde domeinnotatie — is een naamgevingsstandaard waarbij de domeinnaam van het bedrijf in omgekeerde volgorde wordt geschreven: com.example in plaats van example.com. Een dergelijk systeem garandeert de globale uniciteit van identificaties, omdat elke domeinnaam per definitie uniek is.

Standaard prefixen

Ontwikkelaars gebruiken meestal het prefix dat overeenkomt met de TLD van hun domein: com voor commerciële organisaties, org voor non-profitorganisaties, io voor technologische projecten, net voor netwerkdiensten en oplossingen. Voor persoonlijke projecten is het gebruik van com.github.username of com.email toegestaan.

• com.company.app — standaardformaat voor commerciële applicaties
• org.company.app — voor non-profit en open-source projecten
• io.company.app — populair onder startups en SaaS-producten
• com.github.username — voor persoonlijke projecten op GitHub

Conventies voor multiplatformprojecten

Voor applicaties die op iOS en Android worden uitgebracht, wordt aanbevolen dezelfde identificatie op beide platforms te gebruiken. Dit vereenvoudigt de integratie met Firebase, AppsFlyer, Adjust en andere analysesystemen die aan de projectidentificatie zijn gekoppeld. Bijvoorbeeld, com.mycompany.myapp is Bundle ID op iOS en Package Name op Android.

Package Name configureren in een Android-project

Package Name configureren in een Android-project omvat het wijzigen van applicationId in build.gradle en de bijbehorende mapstructuur van Java/Kotlin-code. Android Studio biedt hulpmiddelen voor het refactoren van Package Name, maar voor complexe projecten wordt stapsgewijze migratie aanbevolen.

Mapstructuur en Package Name

// Bestandspad komt overeen met 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)
    }
}

In Kotlin en Java moet Package Name in bronbestanden overeenkomen met de mapstructuur. Bij het wijzigen van Package Name in build.gradle moeten bestanden naar de juiste mappen worden verplaatst en moeten alle package- en import-declaraties worden bijgewerkt. Android Studio kan dit automatisch doen via Refactor -> Move, maar voor grote projecten met tientallen bestanden wordt aanbevolen het resultaat na refactoring te controleren.

Als het project Data Binding, View Binding of Hilt gebruikt, heeft het wijzigen van Package Name ook invloed op gegenereerde klassen. Binding-klassen worden gemaakt op basis van de Package Name van de module en de layout-map. Na het wijzigen van de identificatie moet het project opnieuw worden gebouwd om alle gegenereerde verwijzingen bij te werken. Het wordt aanbevolen een clean build uit te voeren na het wijzigen van Package Name om fouten door gecachede oude verwijzingen te voorkomen.

In Gradle 7.0+ is ondersteuning voor namespace in build.gradle toegevoegd, die package in AndroidManifest.xml heeft vervangen voor het genereren van de R-klasse en resources. Application ID blijft echter de werkelijke identificatie van de applicatie voor het systeem en Google Play. Dit maakt het mogelijk verschillende applicationId en namespace te hebben, wat handig is voor bibliotheekmodules, waarbij namespace vast is en de publieke identificatie tijdens compilatie kan veranderen.

Voor projecten met modulaire architectuur kan het wijzigen van Package Name van één module imports in andere modules beïnvloeden. Als de datamodule het pakket com.example.data heeft en de domainmodule gebruikt zijn klassen, werk dan na het wijzigen van de identificatie de imports in alle afhankelijke modules bij. De Gradle-plugin voor Android versie 8.0+ vereenvoudigt dit proces door automatische generatie van namespace uit build.gradle.

Package Name controleren via code

De huidige Application ID kan worden verkregen via de BuildClass-klasse: BuildConfig.APPLICATION_ID. Dit is handig voor voorwaardelijke logica in code, koppeling aan de omgeving of het weergeven van de identificatie op debug-schermen. BuildConfig wordt automatisch gegenereerd op basis van build.gradle.

// Application ID ophalen tijdens runtime
val packageName = BuildConfig.APPLICATION_ID
val packageManager = packageManager
val appInfo = packageManager.getPackageInfo(packageName, 0)

println("App-versie: ${appInfo.versionName} (${appInfo.versionCode})")
println("Pakket: $packageName")

Package Name wijzigen na publicatie

Package Name wijzigen na publicatie van de applicatie in Google Play — is een operatie die het creëren van een volledig nieuw product betekent. Het systeem staat niet toe een bestaande applicatie met een andere Package Name bij te werken, daarom is de beslissing om de identificatie te wijzigen gelijk aan het opnieuw starten van het project in de winkel.

Gevolgen van het wijzigen van Package Name

Bij het wijzigen van Package Name gaan verloren: alle beoordelingen en recensies, installatiestatistieken, integratie met Google Services (indien niet overgedragen), verwijzingen naar Firebase-project (vereist het maken van een nieuwe google-services.json). Gebruikers krijgen geen automatische update — ze zien een nieuwe applicatie in de winkel.

• Beoordelingen en recensies — blijven bij de oude applicatie, worden niet overgedragen
• Installatiestatistieken — worden gereset voor de nieuwe Package Name
• Firebase-projecten — vereisen een nieuwe configuratie van google-services.json en het opnieuw instellen van alle services
• Gebruikers — krijgen geen automatische update, moeten apart worden geïnformeerd

Wanneer is het wijzigen van Package Name gerechtvaardigd

Package Name wijzigen kan gerechtvaardigd zijn bij rebranding van het bedrijf, het overzetten van de applicatie naar een ander ontwikkelaarsaccount of bij het maken van een aparte versie voor een andere regio. In elk geval wordt aanbevolen gebruikers via de oude applicatie te informeren en een migratieplan met gegevensoverdracht voor te bereiden. Zonder migratieplan verliezen gebruikers de toegang tot gekochte inhoud, abonnementen en opgeslagen applicatiegegevens. Migratie omvat het overbrengen van de database en bestanden via SharedPreferences of Room.

Voordat u Package Name wijzigt, moet u controleren of de nieuwe identificatie uniek is en voldoet aan de naamgevingsregels. Maak een nieuwe applicatie in Google Play met de nieuwe Package Name en publiceer deze als een apart product. Voeg in de beschrijving van de oude applicatie een link naar de nieuwe toe. Overweeg het gebruik van Google Play Custom Store Listing om gebruikers door te verwijzen.