AAB چیست، تفاوت با APK و نحوه عملکرد

AAB چیست

AAB (Android App Bundle) — قالبی برای انتشار است که توسط Google به عنوان جایگزین APK برای توزیع از طریق Google Play توسعه یافته است. داخل AAB یک بایگانی ZIP با پسوند .aab شامل کد کامپایل‌شده، منابع و فراداده است. تفاوت کلیدی: AAB مستقیماً روی دستگاه نصب نمی‌شود.

اصول کار

توسعه‌دهنده AAB را در Google Play Console بارگذاری می‌کند. وقتی کاربر سعی می‌کند برنامه را نصب کند، Google Play پیکربندی دستگاه را تجزیه و تحلیل می‌کند: تراکم صفحه (DPI)، معماری CPU، زبان و نسخه اندروید. بر اساس این تحلیل، یک APK حداقلی حاوی فقط اجزای ضروری تولید می‌شود.

تاریخچه پیاده‌سازی

Google AAB را در سال ۲۰۱۸ در کنفرانس I/O معرفی کرد. از آگوست ۲۰۲۱، این قالب برای همه برنامه‌های جدید در 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 است. این ماژول شامل کد اصلی، منابع و مانیفست برنامه است. بدون ماژول base برنامه نمی‌تواند ساخته شود. همه ماژول‌های دیگر اختیاری هستند و از طریق Dynamic Delivery متصل می‌شوند.

فرمت protobuf

پیکربندی AAB به جای XML از Protocol Buffers (protobuf) استفاده می‌کند. فایل‌های .pb فشرده‌تر هستند و توسط زیرساخت سرور Google سریع‌تر تجزیه می‌شوند. ابزار bundletool protobuf را برای اشکال‌زدایی به قالبی خوانا تبدیل می‌کند.

Dynamic Delivery و ماژول‌های برنامه

Dynamic Delivery — فناوری کلیدی است که AAB بر اساس آن ساخته شده است. این فناوری به کاربر فقط آن بخش‌هایی از برنامه را تحویل می‌دهد که با دستگاه و زبان او مطابقت دارد و همچنین امکان بارگذاری ماژول‌های اضافی را بر اساس درخواست فراهم می‌کند.

انواع ماژول‌ها

ماژول‌های Install-time همراه با APK پایه در هنگام نصب بارگذاری می‌شوند. ماژول‌های Conditional فقط در صورت تحقق شرایط تحویل داده می‌شوند — مثلاً ماژولی با مواد برای صفحه‌نمایش‌های ۴K. ماژول‌های On-demand به درخواست کاربر در داخل برنامه بارگذاری می‌شوند.

Play Asset Delivery (PAD)

برای منابع بزرگ (تا ۲ گیگابایت) به جای فایل‌های OBB از Play Asset Delivery استفاده می‌شود. PAD از همان سه حالت تحویل پشتیبانی می‌کند: install-time، fast-follow (بلافاصله پس از نصب) و on-demand.

// بارگذاری ماژول on-demand از طریق SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

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

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "ماژول نصب شد")
    }

پیکربندی ماژول در Gradle

هر ماژول پویا با یک فایل build.gradle جداگانه با تعیین نوع تحویل توصیف می‌شود. ماژول می‌تواند منابع، کد و مانیفست مستقل خود را داشته باشد که از برنامه پایه مستقل هستند.

ساخت AAB از طریق Gradle

ساخت AAB از طریق Android Gradle Plugin با وظیفه bundleRelease (یا bundleDebug) انجام می‌شود. نتیجه — یک فایل .aab در دایرکتوری build/outputs/bundle/.

پیکربندی ساخت

برای ساخت 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 ابزار bundletool را برای تولید APK از AAB روی ماشین محلی ارائه می‌دهد. دستور `bundletool build-apks --bundle=app.aab --output=app.apks` مجموعه‌ای از APKها را برای آزمایش روی پیکربندی‌های مختلف دستگاه ایجاد می‌کند.

bundletool همچنین می‌تواند AAB را باز کند، پیکربندی آن را نمایش دهد و یکپارچگی امضا را قبل از بارگذاری در Google Play Console بررسی کند. برای اشکال‌زدایی از دستور `bundletool dump manifest --bundle=app.aab` استفاده می‌شود که مانیفست ماژول پایه را نشان می‌دهد.

پیکربندی تقسیمات در AAB

به طور پیش‌فرض، AAB منابع را بر اساس سه بعد تقسیم می‌کند: زبان (language)، تراکم صفحه (density) و معماری CPU (abi). توسعه‌دهنده می‌تواند هر تقسیمی را در build.gradle غیرفعال کند — مثلاً اگر برنامه فقط از زبان انگلیسی پشتیبانی می‌کند. غیرفعال کردن تقسیم به این معنی است که منابع برای همه گزینه‌ها در APK پایه قرار می‌گیرند.

Resource optimisation — AAB به طور خودکار PNG را بدون افت کیفیت به WebP تبدیل می‌کند، منابع استفاده‌نشده را فشرده می‌کند و رشته‌های تکراری را حذف می‌کند. این بهینه‌سازی‌ها در سمت Google Play هنگام تولید APK نهایی اعمال می‌شوند. در نتیجه کاربر APK را ۱۵–۲۵٪ کوچک‌تر از بایگانی کامل دریافت می‌کند.

انتشار AAB در Google Play

فرآیند انتشار AAB در Google Play Console فقط از نظر فرمت فایل بارگذاری‌شده با APK متفاوت است. کنسول .aab را می‌پذیرد، ساختار، امضا و پیکربندی ماژول‌های آن را بررسی می‌کند و سپس برای هر نوع دستگاه APK تولید می‌کند.

App Signing by Google Play

هنگام بارگذاری AAB، Google Play مدیریت کلیدهای امضا را بر عهده می‌گیرد. توسعه‌دهنده بسته امضا شده با کلید upload را بارگذاری می‌کند و Google APKهای تولید شده را با کلید خود دوباره امضا می‌کند. این کار چرخش کلیدها و بازیابی دسترسی در صورت گم شدن keystore را ساده می‌کند.

آزمایش قبل از انتشار

Google Play Console یک آزمایش داخلی AAB ارائه می‌دهد: می‌توان APK تولید شده برای یک دستگاه خاص را دانلود کرد یا آزمایش داخلی را از طریق trackهای Internal Testing، Closed Alpha و Open Beta اجرا کرد.

مشکلات رایج با AAB و راه‌حل آنها

انتقال به AAB ممکن است به‌ویژه در پروژه‌های با تعداد زیادی ماژول پویا یا پیکربندی پیچیده منابع مشکلاتی ایجاد کند.

خطاهای پیکربندی ماژول

اگر یک ماژول پویا به منابع ماژول پایه با نام نادرست ارجاع دهد، Google Play AAB را در مرحله بررسی رد می‌کند. راه‌حل — استفاده از بررسی lint قبل از ساخت و آزمایش همه ماژول‌ها از طریق bundletool به صورت محلی.

تقسیمات زبانی و کاهش عملکرد

تقسیم بر اساس زبان می‌تواند راه‌اندازی برنامه را کند کند اگر منابع برای منطقه فعلی به صورت پویا بارگذاری شوند. توصیه Google — اگر زبان‌ها کمتر از ۱۰ عدد هستند تقسیم نکنید یا برای محبوب‌ترین زبان‌ها از install-time استفاده کنید.

سازگاری با SDKهای شخص ثالث

برخی SDKها (تحلیل، تبلیغات، نقشه‌ها) نیاز به دسترسی به مانیفست کامل و منابع دارند. بررسی سازگاری با AAB یک گام اجباری قبل از مهاجرت است. اکثر SDKهای بزرگ (Firebase، Google Ads، Crashlytics) از سال ۲۰۲۲ به طور کامل از AAB پشتیبانی می‌کنند. برای بررسی سازگاری از bundletool با پرچم --validate استفاده می‌شود که تولید APK سمت سرور را شبیه‌سازی می‌کند.

نسخه‌گذاری AAB

AAB از versionCode از مانیفست ماژول پایه استفاده می‌کند. برخلاف APK، AAB همچنین از versionCode جداگانه برای هر ماژول پشتیبانی می‌کند — این امکان به‌روزرسانی بخش‌های جداگانه برنامه را بدون نصب کامل فراهم می‌کند. Dynamic Delivery ماژول‌های نصب شده را ردیابی می‌کند و فقط اجزای تغییر یافته را هنگام به‌روزرسانی از طریق Google Play تحویل می‌دهد.

مانیتورینگ و تحلیل AAB

Google Play Console تحلیل دقیقی برای هر AAB ارائه می‌دهد: چه تعداد APK تولید شده، کدام تقسیمات مورد نیاز بوده، میانگین اندازه دانلود بر اساس دستگاه‌ها چقدر است. Android Vitals معیارهای عملکرد APKهای تولید شده را نشان می‌دهد. این داده‌ها به بهینه‌سازی پیکربندی تقسیمات و کاهش اندازه دانلود برای دسته‌های مختلف دستگاه کمک می‌کند.