AAB — یہ کیا ہے، APK سے فرق اور کام کرنے کا اصول

AAB کیا ہے

AAB (Android App Bundle) ایک اشاعتی فارمیٹ ہے جسے Google نے Google Play کے ذریعے تقسیم کے لیے APK کے متبادل کے طور پر تیار کیا ہے۔ AAB کے اندر .aab ایکسٹینشن کے ساتھ ایک ZIP آرکائیو ہے جس میں مرتب کردہ کوڈ، وسائل اور میٹا ڈیٹا ہوتا ہے۔ کلیدی فرق: AAB براہ راست ڈیوائس پر انسٹال نہیں ہوتا۔

یہ کیسے کام کرتا ہے

ڈیویلپر AAB کو Google Play Console پر اپ لوڈ کرتا ہے۔ جب صارف ایپلیکیشن انسٹال کرنے کی کوشش کرتا ہے، Google Play ڈیوائس کنفیگریشن کا تجزیہ کرتا ہے: اسکرین کثافت (DPI)، CPU آرکیٹیکچر، زبان اور Android ورژن۔ اس تجزیہ کی بنیاد پر، صرف ضروری اجزاء پر مشتمل ایک کم سے کم APK تیار کیا جاتا ہے۔

اختیار کی تاریخ

Google نے 2018 میں I/O کانفرنس میں AAB متعارف کرایا۔ اگست 2021 سے، Google Play پر تمام نئی ایپلیکیشنز کے لیے یہ فارمیٹ لازمی ہو گیا ہے۔ موجودہ ایپلیکیشنز APK استعمال جاری رکھ سکتی ہیں، لیکن نئی ایپلیکیشنز صرف AAB میں شائع ہونی چاہئیں۔

AAB APK سے کیسے مختلف ہے

AAB اور APK کے درمیان فرق بنیادی ہے: APK ایک مکمل انسٹالیشن فائل ہے جو انسٹال کرنے کے لیے تیار ہے۔ AAB ایک کنٹینر ہے جس میں سورس اجزاء ہوتے ہیں جسے پروسیسنگ کی ضرورت ہوتی ہے۔

APK Google Play سے باہر (ویب سائٹس، ای میل یا کارپوریٹ MDM سسٹم کے ذریعے) تقسیم کے لیے موزوں ہے۔ AAB Google Play کے بنیادی ڈھانچے سے منسلک ہے اور براہ راست انسٹال نہیں کیا جا سکتا۔ AAB کی جانچ کے لیے bundletool ٹول استعمال کیا جاتا ہے جو مقامی مشین پر APK جنریشن کو نقل کرتا ہے۔

AAB فائل کا ڈھانچہ

AAB کا اندرونی ڈھانچہ APK سے ملتا جلتا ہے لیکن اس میں ماڈیولز اور ان کے انحصار کو بیان کرنے کے لیے اضافی ڈائریکٹریاں اور فائلیں ہوتی ہیں۔

بنیادی ماڈیول (base)

base ماڈیول AAB کا لازمی جزو ہے۔ اس میں مرکزی کوڈ، وسائل اور ایپلیکیشن مینی فیسٹ ہوتا ہے۔ بنیادی ماڈیول کے بغیر ایپلیکیشن نہیں بنائی جا سکتی۔ دیگر تمام ماڈیولز اختیاری ہیں اور Dynamic Delivery کے ذریعے منسلک ہوتے ہیں۔

Protobuf فارمیٹ

AAB کنفیگریشن XML کی بجائے Protocol Buffers (protobuf) استعمال کرتی ہے۔ .pb فائلیں زیادہ کمپیکٹ ہوتی ہیں اور Google کے سرور بنیادی ڈھانچے کے ذریعے تیزی سے پارس کی جاتی ہیں۔ bundletool ٹول ڈیبگنگ کے لیے protobuf کو پڑھنے کے قابل فارمیٹ میں تبدیل کرتا ہے۔

Dynamic Delivery اور ایپلیکیشن ماڈیولز

Dynamic Delivery وہ کلیدی ٹیکنالوجی ہے جس پر AAB مبنی ہے۔ یہ صارف کو ایپلیکیشن کے صرف وہ حصے فراہم کرنے کی اجازت دیتی ہے جو ان کی ڈیوائس اور زبان سے مطابقت رکھتے ہیں، نیز ضرورت پڑنے پر اضافی ماڈیولز لوڈ کرنے کی بھی اجازت دیتی ہے۔

ماڈیولز کی اقسام

Install-time ماڈیولز انسٹالیشن کے دوران بنیادی APK کے ساتھ لوڈ ہوتے ہیں۔ Conditional ماڈیولز صرف شرائط پوری ہونے پر فراہم کیے جاتے ہیں — مثال کے طور پر، 4K اسکرینوں کے لیے مواد والا ماڈیول۔ On-demand ماڈیولز ایپلیکیشن کے اندر صارف کی درخواست پر لوڈ ہوتے ہیں۔

Play Asset Delivery (PAD)

بڑے وسائل (2 GB تک) کے لیے OBB فائلوں کی بجائے Play Asset Delivery استعمال کیا جاتا ہے۔ PAD اسی تین ترسیلی طریقوں کو سپورٹ کرتا ہے: install-time، fast-follow (انسٹالیشن کے فوراً بعد) اور on-demand۔

// SplitInstallManager کے ذریعے آن ڈیمانڈ ماڈیول لوڈ کرنا
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Module installed")
    }

Gradle میں ماڈیول کنفیگریشن

ہر متحرک ماڈیول کو ترسیل کی قسم بتاتے ہوئے ایک علیحدہ build.gradle فائل میں بیان کیا جاتا ہے۔ ایک ماڈیول میں بنیادی ایپلیکیشن سے آزاد اپنے وسائل، کوڈ اور مینی فیسٹ ہو سکتے ہیں۔

Gradle کے ذریعے AAB بنانا

AAB کی تعمیر Android Gradle Plugin کے ذریعے bundleRelease (یا bundleDebug) ٹاسک سے کی جاتی ہے۔ نتیجہ build/outputs/bundle/ ڈائریکٹری میں .aab فائل ہوتا ہے۔

تعمیراتی کنفیگریشن

AAB بنانے کے لیے کسی خاص کنفیگریشن کی ضرورت نہیں ہے — Android Gradle Plugin ڈیفالٹ طور پر بنڈلز کو سپورٹ کرتا ہے۔ بس assemble کی بجائے bundle ٹاسک بتائیں۔

// build.gradle.kts — دستخط کے ساتھ AAB بنانا
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// ٹاسک: ./gradlew bundleRelease

bundletool کے ذریعے مقامی جانچ

Google مقامی مشین پر AAB سے APK تیار کرنے کے لیے bundletool ٹول فراہم کرتا ہے۔ کمانڈ `bundletool build-apks --bundle=app.aab --output=app.apks` مختلف ڈیوائس کنفیگریشنز پر جانچ کے لیے APK کا ایک سیٹ بناتی ہے۔

bundletool AAB کو کھول سکتا ہے، اس کی کنفیگریشن دکھا سکتا ہے اور Google Play Console پر اپ لوڈ کرنے سے پہلے دستخط کی سالمیت کی تصدیق کر سکتا ہے۔ ڈیبگنگ کے لیے، کمانڈ `bundletool dump manifest --bundle=app.aab` استعمال کی جاتی ہے جو بنیادی ماڈیول کا مینی فیسٹ دکھاتی ہے۔

AAB میں سپلٹ کنفیگریشن

ڈیفالٹ طور پر، AAB وسائل کو تین جہتوں میں تقسیم کرتا ہے: زبان، اسکرین کثافت (density) اور CPU آرکیٹیکچر (abi)۔ ڈیویلپر build.gradle میں کسی بھی تقسیم کو غیر فعال کر سکتا ہے — مثال کے طور پر، اگر ایپلیکیشن صرف انگریزی سپورٹ کرتی ہے۔ تقسیم کو غیر فعال کرنے کا مطلب ہے کہ تمام متغیرات کے وسائل بنیادی APK میں شامل ہوں گے۔

وسائل کی اصلاح — AAB خود بخود PNG کو معیار کے نقصان کے بغیر WebP میں تبدیل کرتا ہے، غیر استعمال شدہ وسائل کو کمپریس کرتا ہے اور ڈپلیکیٹ سٹرنگز کو ہٹاتا ہے۔ یہ اصلاحیں حتمی APK بناتے وقت Google Play کی طرف سے لاگو کی جاتی ہیں۔ نتیجتاً، صارف کو مکمل آرکائیو سے 15–25% چھوٹا APK ملتا ہے۔

Google Play پر AAB شائع کرنا

Google Play Console میں AAB شائع کرنے کا عمل صرف اپ لوڈ کی گئی فائل کے فارمیٹ میں APK سے مختلف ہے۔ کنسول .aab قبول کرتا ہے، اس کی ساخت، دستخط اور ماڈیول کنفیگریشن کی جانچ کرتا ہے، پھر ہر ڈیوائس کی قسم کے لیے APK تیار کرتا ہے۔

App Signing by Google Play

AAB اپ لوڈ کرتے وقت، Google Play دستخطی کلیدوں کا انتظام سنبھال لیتا ہے۔ ڈیویلپر upload کلید سے دستخط شدہ پیکج اپ لوڈ کرتا ہے، اور Google تیار کردہ APK کو اپنی کلید سے دوبارہ دستخط کرتا ہے۔ یہ کلید کی گردش اور keystore کھو جانے پر رسائی کی بحالی کو آسان بناتا ہے۔

ریلیز سے پہلے کی جانچ

Google Play Console ایک بلٹ ان AAB ٹیسٹ فراہم کرتا ہے: آپ کسی مخصوص ڈیوائس کے لیے تیار کردہ APK ڈاؤن لوڈ کر سکتے ہیں یا Internal Testing، Closed Alpha اور Open Beta ٹریکس کے ذریعے اندرونی جانچ چلا سکتے ہیں۔

عام AAB مسائل اور ان کا حل

AAB میں منتقلی مسائل پیدا کر سکتی ہے، خاص طور پر بہت سے متحرک ماڈیولز یا پیچیدہ وسائل کی کنفیگریشن والے پروجیکٹس میں۔

ماڈیول کنفیگریشن کی غلطیاں

اگر کوئی متحرک ماڈیول بنیادی ماڈیول کے وسائل کو غلط نام سے ریفرنس کرتا ہے، تو Google Play تصدیق کے مرحلے پر AAB کو مسترد کر دیتا ہے۔ حل — تعمیر سے پہلے lint چیک استعمال کریں اور تمام ماڈیولز کو مقامی طور پر bundletool کے ذریعے جانچیں۔

زبان کی تقسیم اور کارکردگی پر اثر

زبان کے لحاظ سے تقسیم ایپلیکیشن کے آغاز کو سست کر سکتی ہے اگر موجودہ لوکیل کے وسائل متحرک طور پر لوڈ ہوتے ہیں۔ Google کی سفارش ہے کہ اگر 10 سے کم زبانیں ہوں تو تقسیم نہ کریں، یا سب سے مشہور زبانوں کے لیے install-time استعمال کریں۔

تیسرے فریق SDK کے ساتھ مطابقت

کچھ SDK (تجزیہ، اشتہار، نقشے) کو مکمل مینی فیسٹ اور وسائل تک رسائی درکار ہوتی ہے۔ منتقلی سے پہلے AAB مطابقت کی جانچ ایک لازمی مرحلہ ہے۔ زیادہ تر بڑے SDK (Firebase، Google Ads، Crashlytics) 2022 سے AAB کو مکمل طور پر سپورٹ کرتے ہیں۔ مطابقت کی تصدیق کے لیے --validate پرچم کے ساتھ bundletool استعمال کیا جاتا ہے جو سرور سائیڈ APK جنریشن کو نقل کرتا ہے۔

AAB ورژننگ

AAB بنیادی ماڈیول مینی فیسٹ سے versionCode استعمال کرتا ہے۔ APK کے برعکس، AAB ہر ماڈیول کے لیے علیحدہ versionCode بھی سپورٹ کرتا ہے — یہ مکمل دوبارہ انسٹالیشن کے بغیر ایپلیکیشن کے انفرادی حصوں کو اپ ڈیٹ کرنے کی اجازت دیتا ہے۔ Dynamic Delivery انسٹال شدہ ماڈیولز کو ٹریک کرتا ہے اور Google Play کے ذریعے اپ ڈیٹس کے دوران صرف تبدیل شدہ اجزاء فراہم کرتا ہے۔

AAB مانیٹرنگ اور تجزیہ

Google Play Console ہر AAB کے لیے تفصیلی تجزیہ فراہم کرتا ہے: کتنے APK تیار ہوئے، کون سی تقسیم مانگی گئی، فی ڈیوائس اوسط ڈاؤن لوڈ سائز کیا ہے۔ Android Vitals تیار کردہ APK کی کارکردگی کے میٹرکس دکھاتا ہے۔ یہ ڈیٹا تقسیم کی کنفیگریشن کو بہتر بنانے اور مختلف ڈیوائس کیٹیگریز کے لیے ڈاؤن لوڈ سائز کم کرنے میں مدد کرتا ہے۔