Package Name — ما هو، تدوين النطاق العكسي والمتطلبات

ما هو Package Name في Android

Package Name هو سلسلة فريدة يستخدمها Android لتحديد التطبيق على مستوى نظام التشغيل. يتوافق مع حقل package في ملف AndroidManifest.xml وحقل applicationId في ملف build.gradle لوحدة التطبيق. بدون Package Name فريد، يستحيل تثبيت تطبيق على جهاز المستخدم.

غرض Package Name

على الجهاز، يعمل Package Name كمفتاح لإدارة التطبيقات: يخزن النظام البيانات والإعدادات والذاكرة المؤقتة لكل تطبيق في الدليل /data/data/[packageName]. لا يمكن لتطبيقين بهما نفس المعرّف التعايش — عند محاولة تثبيت تطبيق مكرر، يطلب النظام إزالة الموجود.

Package Name و Application ID

في Android Gradle Plugin الإصدار 0.11+، تم إدراج فصل بين Package Name (في البيان) و Application ID (في build.gradle). Application ID هو معرّف التطبيق الفعلي للنظام و Google Play. يستخدم Package Name في البيان لحل الموارد وتوليد فئة R. يوصى بإبقائهما متطابقين للبساطة.

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

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

يسمح حقل applicationIdSuffix بإضافة لاحقة إلى Application ID لتكوينات بناء مختلفة. يمكن أن يكون للإصدار التصحيحي المعرف com.example.app.debug، مما يسمح بتثبيته بجانب الإصدار الإنتاجي للاختبار المتوازي.

قواعد تسمية Package Name

Google Play يفرض قواعد صارمة لـ Package Name يجب اتباعها عند النشر. يجب أن يكون المعرّف فريدًا عبر المتجر بأكمله، ويتوافق مع المتطلبات النحوية، ولا ينتهك سياسات العلامات التجارية.

المتطلبات النحوية

Package Name يمكن أن يحتوي فقط على حروف لاتينية (A-Z, a-z)، وأرقام (0-9)، ونقطة (.)، وشرطة سفلية (_). الحد الأقصى للطول هو 150 حرفًا. يجب أن يبدأ كل قطاع بين النقاط بحرف. الشرطات والمسافات والأحرف الخاصة محظورة بقواعد Google Play.

متطلبات الفرادة

الفرادة لـ Package Name هي متطلب مطلق لمتجر Google Play. إذا كان تطبيق آخر يستخدم المعرّف المحدد، سيتم رفض النشر. Google لا تُفرج عن معرّفات التطبيقات المحذوفة، لذا فإن اختيار أول Package Name هو قرار حاسم لكل مطور.

تدوين النطاق العكسي والاتفاقيات

تدوين النطاق العكسي هو معيار تسمية حيث يكتب اسم نطاق الشركة بترتيب عكسي: com.example بدلاً من example.com. يضمن هذا النظام الفرادة العالمية للمعرّفات لأن كل اسم نطاق فريد بطبيعته.

البوادئ القياسية

يستخدم المطورون عادةً بادئة تتوافق مع TLD لنطاقهم: com للمؤسسات التجارية، org للمنظمات غير الربحية، io للمشاريع التكنولوجية، net لخدمات الشبكات والحلول. وبالنسبة للمشاريع الشخصية، يمكن استخدام com.github.username أو com.email.

• com.company.app — تنسيق قياسي للتطبيقات التجارية
• org.company.app — للمشاريع غير الربحية ومفتوحة المصدر
• io.company.app — شائع بين الشركات الناشئة ومنتجات SaaS
• com.github.username — للمشاريع الشخصية على GitHub

اتفاقيات للمشاريع متعددة المنصات

بالنسبة للتطبيقات المنشورة على iOS و Android، يوصى باستخدام نفس المعرّف على كلتا المنصتين. يبسط هذا التكامل مع Firebase و AppsFlyer و Adjust وأنظمة تحليل أخرى التي ترتبط بمعرّف المشروع. على سبيل المثال، com.mycompany.myapp سيكون Bundle ID على iOS و Package Name على Android.

تكوين Package Name في مشروع Android

تكوين Package Name في مشروع Android يتضمن تغيير applicationId في build.gradle وهيكل الدليل المقابل لكود Java/Kotlin. يوفر Android Studio أدوات لإعادة هيكلة Package Name، ولكن للمشاريع المعقدة يوصى بالترحيل التدريجي.

هيكل الدليل و Package Name

// يتوافق مسار الملف مع 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)
    }
}

في Kotlin و Java، يجب أن يتوافق Package Name في ملفات المصدر مع هيكل الدليل. عند تغيير Package Name في build.gradle، يجب نقل الملفات إلى الأدلة المقابلة وتحديث جميع تصريحات package و import. يمكن Android Studio القيام بذلك تلقائيًا عبر Refactor -> Move، ولكن للمشاريع الكبيرة بعشرات الملفات، يوصى بالتحقق من النتيجة بعد إعادة الهيكلة.

إذا كان المشروع يستخدم Data Binding أو View Binding أو Hilt، فإن تغيير Package Name سيؤثر أيضًا على الفئات المولّدة. تُنشأ فئات الربط بناءً على Package Name للوحدة ودليل layout. بعد تغيير المعرّف، ستحتاج إلى إعادة بناء المشروع لتحديث جميع المراجع المولّدة. يوصى بإجراء بناء نظيف بعد تغيير Package Name لتجنب أخطاء المراجع القديمة المخزنة مؤقتًا.

في Gradle 7.0+، تم إدراج دعم لـ namespace في build.gradle، والذي حل محل حقل package في AndroidManifest.xml لأغراض توليد فئة R والموارد. في نفس الوقت، يظل applicationId هو معرّف التطبيق الفعلي للنظام و Google Play. يسمح هذا بوجود applicationId و namespace مختلفين، وهو أمر مفيد لوحدات المكتبات حيث يكون namespace ثابتًا بينما يمكن أن يتغير المعرّف العام أثناء البناء.

للمشاريع ذات الهيكل الوحداتي، قد يؤثر تغيير Package Name لوحدة واحدة على عمليات الاستيراد في الوحدات الأخرى. إذا كانت وحدة data تحتوي على حزمة com.example.data ووحدة domain تستخدم فئاتها، بعد تغيير المعرّف، قم بتحديث عمليات الاستيراد في جميع الوحدات التابعة. يُبسط Android Gradle Plugin الإصدار 8.0+ هذه العملية من خلال التوليد التلقائي لـ namespace من build.gradle.

التحقق من Package Name عبر الكود

للحصول على Application ID الحالي، استخدم الفئة BuildConfig: BuildConfig.APPLICATION_ID. هذا مفيد للمنطق الشرطي في الكود، الارتباط بالبيئة أو عرض المعرّف في شاشات التصحيح. يتولّد BuildConfig تلقائيًا بناءً على build.gradle.

// الحصول على Application ID في وقت التشغيل
val packageName = BuildConfig.APPLICATION_ID
val packageManager = packageManager
val appInfo = packageManager.getPackageInfo(packageName, 0)

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

تغيير Package Name بعد النشر

تغيير Package Name بعد نشر تطبيق على Google Play هو عملية تعني إنشاء منتج جديد بالكامل. لا يسمح النظام بتحديث تطبيق موجود بـ Package Name مختلف، لذا فإن قرار تغيير المعرّف يعادل إعادة تشغيل المشروع في المتجر.

عواقب تغيير Package Name

عند تغيير Package Name، تُفقد: جميع التقييمات والمراجعات، إحصائيات التثبيت، تكامل Google Services (إذا لم يتم الترحيل)، روابط مشروع Firebase (يتطلب إنشاء google-services.json جديد). لن يتلقى المستخدمون تحديثًا تلقائيًا — سيرون التطبيق الجديد في المتجر.

• التقييمات والمراجعات — تبقى مع التطبيق القديم، لا تُنقل
• إحصائيات التثبيت — تتم إعادة تعيينها لـ Package Name الجديد
• مشاريع Firebase — تتطلب تكويناً جديدًا لـ google-services.json وإعادة تكوين جميع الخدمات
• المستخدمون — لا يتلقون تحديثات تلقائية، يجب إشعارهم بشكل منفصل

متى يكون تغيير Package Name مبررًا

تغيير Package Name قد يكون مبررًا أثناء إعادة تسمية الشركة، نقل التطبيق إلى حساب مطور آخر، أو عند إنشاء إصدار منفصل لمنطقة أخرى. في أي حال، قبل التغيير، يوصى بإشعار المستخدمين من خلال التطبيق القديم وإعداد خطة ترحيل مع نقل البيانات. بدون خطة ترحيل، سيفقد المستخدمون الوصول إلى المحتوى المشترى والاشتراكات وبيانات التطبيق المحفوظة. تشمل الترحيل نقل قاعدة البيانات والملفات عبر SharedPreferences أو Room.

قبل تغيير Package Name، تأكد من أن المعرّف الجديد فريد ويتوافق مع قواعد التسمية. أنشئ تطبيقًا جديدًا في Google Play بـ Package Name الجديد وانشره كمنتج منفصل. في وصف التطبيق القديم، أضف رابطًا للتطبيق الجديد. فكر في استخدام Google Play Custom Store Listing لتوجيه المستخدمين.