Package Name — ano ito, reverse domain notation at mga kinakailangan

Ano ang Package Name sa Android

Package Name — ay isang natatanging string na ginagamit ng Android upang kilalanin ang application sa antas ng operating system. Ito ay tumutugma sa field na package sa AndroidManifest.xml file at sa field na applicationId sa build.gradle file ng module ng application. Kung walang natatanging Package Name, ang pag-install ng application sa device ng user ay imposible.

Layunin ng Package Name

Sa device, ang Package Name ay nagsisilbing susi para sa pamamahala ng mga application: ang system ay nag-iimbak ng data, setting, at cache ng bawat application sa direktoryo na /data/data/[packageName]. Dalawang application na may parehong identifier ay hindi maaaring magkasabay — sa pagtatangkang mag-install ng duplicate, iminumungkahi ng system na tanggalin ang umiiral na.

Package Name at Application ID

Sa Android Gradle Plugin bersyon 0.11+, lumitaw ang paghihiwalay sa pagitan ng Package Name (sa manifest) at Application ID (sa build.gradle). Ang Application ID ay ang aktwal na identifier ng application para sa system at Google Play. Ang Package Name sa manifest ay ginagamit para sa paglutas ng mga resource at pagbuo ng R class. Inirerekomenda na panatilihin silang pareho para sa pagiging simple.

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

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

Ang field na applicationIdSuffix ay nagbibigay-daan sa pagdagdag ng suffix sa Application ID para sa iba't ibang configuration ng compilation. Ang debug version ay maaaring magkaroon ng identifier na com.example.app.debug, na nagpapahintulot sa pag-install nito sa tabi ng production version para sa parallel testing.

Mga patakaran sa pagpapangalan ng Package Name

Google Play ay nagtatakda ng mahigpit na mga patakaran para sa Package Name na dapat sundin sa pag-publish. Ang identifier ay dapat na natatangi sa buong tindahan, tumugon sa mga kinakailangan sa syntax, at hindi lumabag sa patakaran sa paggamit ng trademark.

Mga kinakailangan sa syntax

Package Name ay maaari lamang maglaman ng mga letrang Latin (A-Z, a-z), numero (0-9), tuldok (.), at underscore (_). Ang maximum na haba — 150 character. Bawat segment sa pagitan ng mga tuldok ay dapat magsimula sa isang letra. Ang mga gitling, puwang, at espesyal na character ay ipinagbabawal ng mga patakaran ng Google Play.

Mga kinakailangan sa pagiging natatangi

Pagiging natatangi ng Package Name — ay isang ganap na kinakailangan ng Google Play Store. Kung ang ibang application ay gumagamit na ng napiling identifier, ang pag-publish ay tatanggihan. Hindi pinapalaya ng Google ang mga identifier ng mga tinanggal na application, kaya ang pagpili ng unang Package Name ay isang kritikal na desisyon para sa bawat proyekto ng developer.

Reverse domain notation at mga kasunduan

Reverse domain notation — ay isang pamantayan sa pagpapangalan kung saan ang domain name ng kumpanya ay isinusulat sa reverse order: com.example sa halip na example.com. Ang ganitong sistema ay ginagarantiyahan ang pandaigdigang pagiging natatangi ng mga identifier, dahil ang bawat domain name ay sa kahulugan ay natatangi.

Mga karaniwang prefix

Ang mga developer ay karaniwang gumagamit ng prefix na tumutugma sa TLD ng kanilang domain: com para sa komersyal na organisasyon, org para sa non-profit, io para sa teknolohikal na proyekto, net para sa mga serbisyo at solusyon sa network. Para sa personal na proyekto, ang paggamit ng com.github.username o com.email ay pinapayagan.

• com.company.app — karaniwang format para sa komersyal na application
• org.company.app — para sa non-profit at open-source na proyekto
• io.company.app — sikat sa mga startup at produkto ng SaaS
• com.github.username — para sa personal na proyekto sa GitHub

Mga kasunduan para sa multi-platform na proyekto

Para sa mga application na inilalabas sa iOS at Android, inirerekomenda na gamitin ang parehong identifier sa parehong platform. Pinapasimple nito ang pagsasama sa Firebase, AppsFlyer, Adjust, at iba pang analytics system na nakatali sa identifier ng proyekto. Halimbawa, ang com.mycompany.myapp ay magiging Bundle ID sa iOS at Package Name sa Android.

Pag-configure ng Package Name sa Android project

Pag-configure ng Package Name sa Android project ay kinabibilangan ng pagbabago ng applicationId sa build.gradle at ng kaukulang istraktura ng direktoryo ng Java/Kotlin code. Ang Android Studio ay nagbibigay ng mga tool para sa refactoring ng Package Name, ngunit para sa kumplikadong proyekto, inirerekomenda ang unti-unting paglipat.

Istraktura ng direktoryo at Package Name

// Ang path ng file ay tumutugma sa 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)
    }
}

Sa Kotlin at Java, ang Package Name sa source file ay dapat tumugma sa istraktura ng direktoryo. Kapag binabago ang Package Name sa build.gradle, ang mga file ay dapat ilipat sa mga kaukulang direktoryo at lahat ng deklarasyon ng package at import ay dapat i-update. Ang Android Studio ay maaaring gawin ito nang awtomatiko sa pamamagitan ng Refactor -> Move, ngunit para sa malalaking proyekto na may dose-dosenang file, inirerekomenda na suriin ang resulta pagkatapos ng refactoring.

Kung ang proyekto ay gumagamit ng Data Binding, View Binding o Hilt, ang pagbabago ng Package Name ay makakaapekto rin sa mga nabuong klase. Ang mga Binding class ay nilikha batay sa Package Name ng module at layout directory. Pagkatapos ng pagbabago ng identifier, kakailanganing muling itayo ang proyekto upang i-update ang lahat ng nabuong reference. Inirerekomenda na magsagawa ng clean build pagkatapos baguhin ang Package Name upang alisin ang mga error dahil sa naka-cache na lumang reference.

Sa Gradle 7.0+, lumitaw ang suporta para sa namespace sa build.gradle, na pumalit sa package sa AndroidManifest.xml para sa mga layunin ng pagbuo ng R class at resources. Gayunpaman, ang applicationId ay nananatiling aktwal na identifier ng application para sa system at Google Play. Ito ay nagpapahintulot na magkaroon ng magkaibang applicationId at namespace, na kapaki-pakinabang para sa library modules, kung saan ang namespace ay naayos at ang pampublikong identifier ay maaaring magbago sa compilation.

Para sa mga proyekto na may modular na arkitektura, ang pagbabago ng Package Name ng isang module ay maaaring makaapekto sa mga import sa ibang mga module. Kung ang data module ay may package na com.example.data at ang domain module ay gumagamit ng mga klase nito, pagkatapos ng pagbabago ng identifier, i-update ang mga import sa lahat ng umaasang module. Ang Gradle plugin para sa Android bersyon 8.0+ ay pinapasimple ang prosesong ito sa pamamagitan ng awtomatikong pagbuo ng namespace mula sa build.gradle.

Pagsusuri ng Package Name sa pamamagitan ng code

Ang kasalukuyang Application ID ay maaaring makuha sa pamamagitan ng BuildConfig class: BuildConfig.APPLICATION_ID. Ito ay maginhawa para sa conditional logic sa code, pag-binding sa kapaligiran, o pagpapakita ng identifier sa debug screens. Ang BuildConfig ay awtomatikong nabuo batay sa build.gradle.

// Pagkuha ng Application ID sa runtime
val packageName = BuildConfig.APPLICATION_ID
val packageManager = packageManager
val appInfo = packageManager.getPackageInfo(packageName, 0)

println("Bersyon ng app: ${appInfo.versionName} (${appInfo.versionCode})")
println("Package: $packageName")

Pagbabago ng Package Name pagkatapos ng pag-publish

Pagbabago ng Package Name pagkatapos ng pag-publish ng application sa Google Play — ay isang operasyon na nangangahulugang paggawa ng isang ganap na bagong produkto. Hindi pinapayagan ng system na i-update ang umiiral na application na may ibang Package Name, kaya ang desisyon na baguhin ang identifier ay katumbas ng muling pagsisimula ng proyekto sa tindahan.

Mga kahihinatnan ng pagbabago ng Package Name

Sa pagbabago ng Package Name, nawawala: lahat ng rating at review, istatistika ng pag-install, pagsasama sa Google Services (kung hindi nailipat), mga reference sa Firebase project (nangangailangan ng paggawa ng bagong google-services.json). Ang mga user ay hindi makakatanggap ng awtomatikong update — makikita nila ang bagong application sa tindahan.

• Rating at review — nananatili sa lumang application, hindi naililipat
• Istatistika ng pag-install — nire-reset para sa bagong Package Name
• Firebase projects — nangangailangan ng bagong configuration ng google-services.json at muling pag-configure ng lahat ng serbisyo
• Mga user — hindi nakakatanggap ng awtomatikong update, kailangang ipaalam nang hiwalay

Kailan makatwiran ang pagbabago ng Package Name

Pagbabago ng Package Name ay maaaring maging makatwiran sa rebranding ng kumpanya, paglipat ng application sa ibang developer account, o paggawa ng hiwalay na bersyon para sa ibang rehiyon. Sa anumang kaso, bago ang pagbabago, inirerekomenda na ipaalam sa mga user sa pamamagitan ng lumang application at maghanda ng plano sa paglipat na may paglilipat ng data. Kung walang plano sa paglipat, ang mga user ay mawawalan ng access sa biniling nilalaman, subscription, at naka-save na data ng application. Kasama sa paglipat ang paglilipat ng database at file sa pamamagitan ng SharedPreferences o Room.

Bago baguhin ang Package Name, siguraduhin na ang bagong identifier ay natatangi at sumusunod sa mga patakaran sa pagpapangalan. Gumawa ng bagong application sa Google Play na may bagong Package Name at i-publish ito bilang isang hiwalay na produkto. Sa paglalarawan ng lumang application, magdagdag ng link sa bago. Isaalang-alang ang paggamit ng Google Play Custom Store Listing para sa pag-redirect ng mga user.