این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

پشتیبانی از چندین APK

اگر برنامه خود را در Google Play منتشر می‌کنید، باید یک Android App Bundle بسازید و آپلود کنید. وقتی این کار را انجام می‌دهید، Google Play به‌طور خودکار فایل‌های APK بهینه‌شده را برای پیکربندی دستگاه هر کاربر تولید و ارائه می‌کند، بنابراین آنها فقط کد و منابعی را که برای اجرای برنامه شما نیاز دارند دانلود می‌کنند. اگر در Google Play منتشر نمی کنید، انتشار چندین APK مفید است، اما باید خودتان هر APK را بسازید، امضا کنید و مدیریت کنید.

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

دستگاه‌های مجهز به اندروید ممکن است از چند جهت متفاوت باشند و برای موفقیت برنامه‌تان مهم است که آن را برای تعداد زیادی دستگاه‌های ممکن در دسترس قرار دهید. برنامه‌های اندروید معمولاً با ارائه منابع جایگزین برای پیکربندی‌های مختلف (مثلاً طرح‌بندی‌های مختلف برای اندازه‌های مختلف صفحه) روی اکثر دستگاه‌های سازگار با یک APK واحد اجرا می‌شوند و سیستم Android منابع مناسب را برای دستگاه در زمان اجرا انتخاب می‌کند. با این حال، در موارد معدودی، یک APK منفرد قادر به پشتیبانی از تمام پیکربندی‌های دستگاه نیست، زیرا منابع جایگزین فایل APK را بسیار بزرگ می‌کنند یا سایر چالش‌های فنی مانع از کار کردن یک APK منفرد در همه دستگاه‌ها می‌شوند.

برای کمک به انتشار برنامه خود برای هر چه بیشتر دستگاه‌ها، Google Play به شما امکان می‌دهد چندین APK را در فهرست برنامه یکسان منتشر کنید. سپس Google Play هر APK را بر اساس پشتیبانی پیکربندی که در فایل مانیفست هر APK اعلام کرده‌اید، در اختیار دستگاه‌های مناسب قرار می‌دهد.

با انتشار برنامه خود با چندین APK، می توانید:

با هر APK از فرمت های مختلف فشرده سازی بافت OpenGL پشتیبانی کنید.
با هر APK از اندازه ها و تراکم های مختلف صفحه پشتیبانی کنید.
با هر APK از مجموعه ویژگی های مختلف دستگاه پشتیبانی کنید.
با هر APK از نسخه های پلتفرم مختلف پشتیبانی کنید.
از معماری‌های مختلف CPU با هر APK پشتیبانی کنید (مانند ARM یا x86، زمانی که برنامه شما از Android NDK استفاده می‌کند).
برای دستگاه‌های سطح پایه مانند دستگاه‌هایی که Android (نسخه Go) دارند، بهینه‌سازی کنید.

در حال حاضر، اینها تنها ویژگی های دستگاهی هستند که Google Play برای انتشار چندین APK به عنوان یک برنامه پشتیبانی می کند.

توجه: برای آشنایی با آماده‌سازی و انتشار فایل‌های APK در Google Play، به مقاله پشتیبانی نسخه‌های آماده و عرضه مراجعه کنید.

چند APK چگونه کار می کنند

مفهوم استفاده از چندین APK در Google Play این است که شما فقط یک ورودی در Google Play برای برنامه خود دارید، اما دستگاه های مختلف ممکن است APK متفاوتی را دانلود کنند. این بدان معنی است که:

شما فقط یک مجموعه از جزئیات محصول (توضیحات برنامه، نمادها، تصاویر صفحه و غیره) را حفظ می کنید. این همچنین به این معنی است که نمی توانید قیمت متفاوتی را برای APK های مختلف دریافت کنید.
همه کاربران تنها یک نسخه از برنامه شما را در Google Play می‌بینند، بنابراین با نسخه‌های مختلفی که ممکن است منتشر کرده باشید که «برای رایانه‌های لوحی» یا «برای گوشی‌ها» هستند، سردرگم نمی‌شوند.
همه بررسی‌های کاربر در فهرست برنامه یکسان اعمال می‌شوند، حتی اگر کاربران دستگاه‌های مختلف ممکن است فایل‌های APK متفاوتی داشته باشند.
اگر فایل‌های APK مختلف را برای نسخه‌های مختلف Android (برای سطوح API مختلف) منتشر می‌کنید، سپس وقتی دستگاه کاربر یک به‌روزرسانی سیستمی دریافت می‌کند که او را برای APK دیگری که منتشر کرده‌اید واجد شرایط می‌کند، Google Play برنامه کاربر را به APK طراحی‌شده برای نسخه بالاتر اندروید هر گونه داده سیستمی مرتبط با برنامه حفظ می‌شود (همانطور که در به‌روزرسانی‌های عادی برنامه هنگام استفاده از یک APK منفرد).

فیلترهای پشتیبانی شده

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

فرمت های فشرده سازی بافت OpenGL
این بر اساس عنصر(های) <supports-gl-texture> فایل مانیفست شما است.
به عنوان مثال، هنگام توسعه یک بازی که از OpenGL ES استفاده می کند، می توانید یک APK برای دستگاه هایی که از فشرده سازی بافت ATI پشتیبانی می کنند و یک APK جداگانه برای دستگاه هایی که از فشرده سازی PowerVR پشتیبانی می کنند (در میان بسیاری دیگر) ارائه دهید.
اندازه صفحه نمایش (و در صورت تمایل، تراکم صفحه نمایش)
این بر اساس عنصر <supports-screens> یا <compatible-screens> فایل مانیفست شما است. شما هرگز نباید از هر دو عنصر استفاده کنید و در صورت امکان فقط باید از <supports-screens> استفاده کنید.
به عنوان مثال، می توانید یک APK ارائه دهید که از صفحه نمایش های کوچک و معمولی پشتیبانی می کند و APK دیگری که از صفحه نمایش های بزرگ و xlarge پشتیبانی می کند. برای کسب اطلاعات بیشتر در مورد ایجاد فایل‌های APK جداگانه بر اساس اندازه یا تراکم صفحه، به ساخت فایل‌های APK چندگانه بروید.
بهترین روش های زیر را برای پشتیبانی از همه اندازه های صفحه در نظر بگیرید:
- سیستم اندروید پشتیبانی قوی از برنامه‌ها برای پشتیبانی از تمام تنظیمات صفحه نمایش با یک APK ارائه می‌کند. باید از ایجاد چندین APK برای پشتیبانی از صفحه‌های مختلف خودداری کنید، مگر اینکه کاملاً ضروری باشد و در عوض از راهنمای پشتیبانی از چند صفحه‌نمایش پیروی کنید تا برنامه شما انعطاف‌پذیر باشد و بتواند با یک APK منفرد با تمام تنظیمات صفحه سازگار شود.
- به‌طور پیش‌فرض، تمام ویژگی‌های اندازه صفحه در عنصر <supports-screens> «درست» هستند، اگر آنها را در غیر این صورت اعلام نکنید. با این حال، از آنجایی که ویژگی android:xlargeScreens در Android 2.3 (سطح API 9) اضافه شده است، اگر برنامه شما android:minSdkVersion یا android:targetSdkVersion روی "9" یا بالاتر تنظیم نکند، Google Play فرض می کند که "نادرست" است.
- شما نباید هر دو عنصر <supports-screens> و <compatible-screens> را در فایل مانیفست خود ترکیب کنید. استفاده از هر دو احتمال بروز خطا به دلیل درگیری بین آنها را افزایش می دهد. برای کمک به تصمیم گیری در مورد استفاده، توزیع به صفحات خاص را بخوانید. اگر نمی توانید از استفاده از هر دو اجتناب کنید، توجه داشته باشید که برای هر گونه تضاد در توافق بین یک اندازه معین، "نادرست" برنده خواهد شد.
مجموعه ویژگی های دستگاه
این بر اساس عنصر(های) <uses-feature> فایل مانیفست شما است.
به عنوان مثال، می‌توانید یک APK برای دستگاه‌هایی که از چند لمسی پشتیبانی می‌کنند و APK دیگری برای دستگاه‌هایی که از چند لمسی پشتیبانی نمی‌کنند ارائه کنید. برای لیستی از ویژگی های پشتیبانی شده توسط پلتفرم، به مرجع ویژگی ها مراجعه کنید.
اندروید (نسخه Go)
برای هدف قرار دادن دستگاه‌های دارای Android (نسخه Go)، APK شما باید <uses-feature android:name="android.hardware.ram.low" android:required="true"> را اعلام کند، حداقل API سطح 26 را هدف قرار دهد و دارای کد نسخه بالاتر از APK نسخه غیر Go شما.
سطح API
این بر اساس عنصر <uses-sdk> فایل مانیفست شما است. شما می توانید از هر دو ویژگی android:minSdkVersion و android:maxSdkVersion برای مشخص کردن پشتیبانی از سطوح مختلف API استفاده کنید.
به عنوان مثال، می‌توانید برنامه خود را با یک APK منتشر کنید که از سطوح API 16 - 19 (Android 4.1.x - 4.4.4) پشتیبانی می‌کند - فقط با استفاده از APIهای موجود از API سطح 16 یا پایین‌تر - و APK دیگری که از سطح API 21 و بالاتر پشتیبانی می‌کند. (Android 5.0+)—با استفاده از API های موجود از سطح API 21 یا پایین تر. برای یادگیری نحوه ساخت APKهای مجزا که هر کدام محدوده متفاوتی از APIها را هدف قرار می دهند، به پیکربندی طعم های محصول بروید.
اگر از این مشخصه به عنوان عاملی برای تشخیص چندین APK استفاده کنید، APK با مقدار android:minSdkVersion بالاتر باید مقدار android:versionCode بالاتری داشته باشد. این همچنین در صورتی صادق است که دو APK بر اساس یک فیلتر پشتیبانی شده متفاوت، با پشتیبانی دستگاه خود همپوشانی داشته باشند. این تضمین می‌کند که وقتی دستگاهی به‌روزرسانی سیستم را دریافت می‌کند، Google Play می‌تواند به‌روزرسانی برنامه شما را به کاربر ارائه دهد (زیرا به‌روزرسانی‌ها بر اساس افزایش کد نسخه برنامه هستند). این الزام در بخش زیر درباره قوانین برای چندین APK بیشتر توضیح داده شده است.
به طور کلی باید از android:maxSdkVersion استفاده نکنید، زیرا تا زمانی که برنامه خود را به درستی با APIهای عمومی توسعه داده باشید، همیشه با نسخه های آینده اندروید سازگار است. اگر می‌خواهید یک APK متفاوت برای سطوح بالاتر API منتشر کنید، باز هم نیازی به تعیین حداکثر نسخه ندارید، زیرا اگر android:minSdkVersion در یک APK "16" و در APK دیگر "21" باشد، دستگاه‌هایی که از سطح API 21 پشتیبانی می‌کنند. یا بالاتر همیشه APK دوم را دریافت می کند (زیرا کد نسخه آن طبق یادداشت قبلی بالاتر است).

معماری CPU (ABI)
برخی از کتابخانه های بومی بسته های جداگانه ای را برای معماری های خاص CPU یا رابط های باینری برنامه (ABI) ارائه می دهند. به‌جای بسته‌بندی همه کتابخانه‌های موجود در یک APK، می‌توانید یک APK جداگانه برای هر ABI بسازید و فقط کتابخانه‌هایی را که برای آن ABI نیاز دارید در آن قرار دهید. برای کسب اطلاعات بیشتر در مورد ایجاد APK جداگانه بر اساس ABI هدف، به ساخت چندین APK بروید.

سایر عناصر مانیفست که فیلترهای Google Play را فعال می‌کنند - اما در بالا فهرست نشده‌اند - همچنان طبق معمول برای هر APK اعمال می‌شوند. با این حال، Google Play به شما اجازه نمی‌دهد فایل‌های APK جداگانه را بر اساس تغییرات آن ویژگی‌های دستگاه منتشر کنید. بنابراین، اگر فیلترهای فهرست شده در بالا برای هر APK یکسان باشند، نمی‌توانید چندین APK منتشر کنید (اما APKها بر اساس سایر ویژگی‌های مانیفست یا APK متفاوت هستند). برای مثال، نمی‌توانید فایل‌های APK مختلف را ارائه کنید که صرفاً در ویژگی‌های <uses-configuration> متفاوت هستند.

قوانین برای چندین APK

قبل از انتشار چندین APK برای برنامه خود، باید قوانین زیر را بدانید:

همه فایل‌های APK که برای یک برنامه منتشر می‌کنید باید نام بسته یکسانی داشته باشند و با یک کلید گواهی امضا شده باشند .
هر APK باید کد نسخه متفاوتی داشته باشد که توسط ویژگی android:versionCode مشخص شده است.
هر APK نباید دقیقاً با پشتیبانی پیکربندی APK دیگر مطابقت داشته باشد .
یعنی، هر APK باید حداقل یکی از فیلترهای پشتیبانی شده Google Play (فهرست شده در بالا) را کمی متفاوت اعلام کند.
معمولاً، APK های خود را بر اساس یک ویژگی خاص (مانند فرمت های فشرده سازی بافت پشتیبانی شده) متمایز می کنید و بنابراین، هر APK پشتیبانی از دستگاه های مختلف را اعلام می کند. با این حال، انتشار چندین APK که کمی با پشتیبانی آنها همپوشانی دارند، مشکلی ندارد. وقتی دو APK با هم همپوشانی داشته باشند (آنها برخی از تنظیمات دستگاه مشابه را پشتیبانی می کنند)، دستگاهی که در آن محدوده همپوشانی قرار می گیرد، APK را با کد نسخه بالاتر (تعریف شده توسط android:versionCode ) دریافت می کند.
نمی‌توانید APK جدیدی را فعال کنید که کد نسخه آن کمتر از APK است که جایگزین می‌شود. برای مثال، فرض کنید یک APK فعال برای اندازه‌های صفحه کوچک دارید - معمولی با کد نسخه 0400 ، سپس سعی کنید آن را با یک APK برای همان اندازه‌های صفحه با کد نسخه 0300 جایگزین کنید. این یک خطا ایجاد می کند، زیرا به این معنی است که کاربران APK قبلی نمی توانند برنامه را به روز کنند.
APK که به سطح API بالاتری نیاز دارد باید کد نسخه بالاتری داشته باشد.
این فقط زمانی صادق است که: APK ها فقط بر اساس سطوح API پشتیبانی شده متفاوت هستند (هیچ فیلتر پشتیبانی شده دیگری APK ها را از یکدیگر متمایز نمی کند) یا زمانی که APK ها از فیلتر پشتیبانی شده دیگری استفاده می کنند، اما بین APK ها در آن فیلتر همپوشانی وجود دارد. .
این مهم است زیرا دستگاه کاربر تنها در صورتی به‌روزرسانی برنامه را از Google Play دریافت می‌کند که کد نسخه APK در Google Play بالاتر از کد نسخه APK موجود در دستگاه باشد. این تضمین می‌کند که اگر دستگاهی به‌روزرسانی سیستمی را دریافت کند و سپس واجد شرایط نصب APK برای سطوح بالاتر API باشد، دستگاه به‌روزرسانی برنامه را دریافت می‌کند زیرا کد نسخه افزایش می‌یابد.
توجه: اندازه افزایش کد نسخه بی ربط است. به سادگی باید در نسخه ای که از سطوح بالاتر API پشتیبانی می کند بزرگتر باشد.
در اینجا چند نمونه آورده شده است:
- اگر یک APK که برای سطوح API 16 و بالاتر (Android 4.1.x+) آپلود کرده‌اید دارای کد نسخه 0400 باشد، یک APK برای سطوح API 21 و بالاتر (Android 5.0 و بالاتر) باید 0401 یا بالاتر باشد. در این مورد، سطح API تنها فیلتر پشتیبانی شده مورد استفاده است، بنابراین کدهای نسخه باید در ارتباط با پشتیبانی سطح API برای هر APK افزایش یابد تا کاربران هنگام دریافت به‌روزرسانی سیستم، به‌روزرسانی دریافت کنند.
- اگر یک APK دارید که برای API سطح 16 (و بالاتر) و صفحه‌های کوچک - بزرگ است، و APK دیگری برای API سطح 21 (و بالاتر) و صفحه‌های بزرگ - xlarge، کدهای نسخه باید متناسب با سطوح API افزایش یابند . در این مورد، فیلتر سطح API برای تشخیص هر APK استفاده می شود، اما اندازه صفحه نمایش نیز همینطور است. از آنجایی که اندازه‌های صفحه با هم همپوشانی دارند (هر دو APK از صفحه‌های بزرگ پشتیبانی می‌کنند)، کدهای نسخه همچنان باید مرتب باشند. این تضمین می کند که دستگاهی با صفحه نمایش بزرگ که به روز رسانی سیستم را به سطح 21 API دریافت می کند، به روز رسانی برای APK دوم دریافت می کند.
- اگر یک APK دارید که برای API سطح 16 (و بالاتر) و صفحه‌های کوچک - معمولی است، و APK دیگری برای صفحه‌های API سطح 21 (و بالاتر) و صفحه‌های بزرگ - xlarge، پس کدهای نسخه نیازی به افزایش همبستگی با سطوح API از آنجایی که در فیلتر اندازه صفحه نمایش همپوشانی وجود ندارد، هیچ دستگاهی وجود ندارد که به طور بالقوه بتواند بین این دو APK حرکت کند، بنابراین نیازی به افزایش کدهای نسخه از سطح API پایین به سطح API بالاتر نیست.
- اگر یک APK دارید که برای CPUهای API سطح 16 (و بالاتر) و ARMv7 است، و APK دیگری برای CPUهای API سطح 21 (و بالاتر) و ARMv5TE، کدهای نسخه باید متناسب با سطوح API افزایش یابند . در این مورد، فیلتر سطح API برای تشخیص هر APK استفاده می شود، اما معماری CPU نیز همینطور است. از آنجایی که یک APK با کتابخانه های ARMv5TE با دستگاه هایی که CPU ARMv7 دارند سازگار است، APK ها روی این مشخصه همپوشانی دارند. به این ترتیب، کد نسخه APK که از API سطح 21 و بالاتر پشتیبانی می‌کند باید بالاتر باشد. این تضمین می‌کند که دستگاهی با CPU ARMv7 که به‌روزرسانی سیستم را به سطح API 21 دریافت می‌کند، به‌روزرسانی برای دومین APK که برای سطح API 21 طراحی شده است، دریافت می‌کند. اما، چون این نوع به‌روزرسانی باعث می‌شود دستگاه ARMv7 از یک APK استفاده کند که از آن استفاده نمی‌کند. به طور کامل برای CPU آن دستگاه بهینه شده است، باید یک APK برای معماری ARMv5TE و ARMv7 در هر سطح API ارائه دهید تا عملکرد برنامه را در هر CPU بهینه کنید. توجه: این فقط در هنگام مقایسه فایل‌های APK با کتابخانه‌های ARMv5TE و ARMv7 اعمال می‌شود و در مقایسه با سایر کتابخانه‌های بومی اعمال نمی‌شود.

رعایت نکردن قوانین بالا منجر به بروز خطا در کنسول Google Play هنگام فعال کردن فایل‌های APK می‌شود—تا زمانی که این خطا را برطرف نکنید، نمی‌توانید برنامه خود را منتشر کنید.

درگیری‌های دیگری نیز وجود دارد که ممکن است هنگام فعال‌سازی APK‌های خود رخ دهد، اما به جای خطا، منجر به هشدار می‌شود. هشدارها می تواند ناشی از موارد زیر باشد:

وقتی یک APK را تغییر می‌دهید تا پشتیبانی از ویژگی‌های دستگاه را «کوچک‌تر» کند و هیچ APK دیگری از دستگاه‌هایی که خارج از محدوده پشتیبانی‌شده قرار می‌گیرند پشتیبانی نمی‌کنند. به عنوان مثال، اگر یک APK در حال حاضر از صفحه نمایش های کوچک و معمولی پشتیبانی می کند و شما آن را طوری تغییر دهید که فقط از صفحه نمایش های کوچک پشتیبانی کند، پس مجموعه دستگاه های پشتیبانی شده را کوچک کرده اید و برخی از دستگاه ها دیگر برنامه شما را در Google Play نمی بینند. می‌توانید با افزودن APK دیگری که از صفحه‌های نمایش با اندازه معمولی پشتیبانی می‌کند، این مشکل را حل کنید تا همه دستگاه‌هایی که قبلاً پشتیبانی می‌شدند همچنان پشتیبانی شوند.
وقتی بین دو یا چند APK "همپوشانی" وجود دارد. به عنوان مثال، اگر یک APK از اندازه صفحه نمایش کوچک، معمولی و بزرگ پشتیبانی می کند، در حالی که APK دیگری از اندازه های بزرگ و xlarge پشتیبانی می کند، یک همپوشانی وجود دارد، زیرا هر دو APK از صفحه نمایش های بزرگ پشتیبانی می کنند. اگر این مشکل را حل نکنید، دستگاه‌هایی که واجد شرایط هر دو APK هستند (دستگاه‌های صفحه نمایش بزرگ در مثال) هر کدام از APK که بالاترین کد نسخه را داشته باشد، دریافت خواهند کرد.
توجه: اگر در حال ایجاد فایل‌های APK جداگانه برای معماری‌های مختلف CPU هستید، توجه داشته باشید که یک APK برای ARMv5TE با یک APK برای ARMv7 همپوشانی دارد. یعنی یک APK طراحی شده برای ARMv5TE با یک دستگاه ARMv7 سازگار است، اما برعکس آن درست نیست (یک APK فقط با کتابخانه های ARMv7 با دستگاه ARMv5TE سازگار نیست ).

هنگامی که چنین درگیری هایی رخ می دهد، یک پیام هشدار می بینید، اما همچنان می توانید برنامه خود را منتشر کنید.

ایجاد چندین APK

هنگامی که تصمیم به انتشار چندین APK گرفتید، احتمالاً باید برای هر APK که قصد انتشار آن را دارید، پروژه های Android جداگانه ایجاد کنید تا بتوانید آنها را به طور جداگانه توسعه دهید. شما می توانید این کار را به سادگی با کپی کردن پروژه موجود خود و دادن یک نام جدید به آن انجام دهید. (در روش دیگر، ممکن است از یک سیستم ساخت استفاده کنید که می تواند منابع مختلفی مانند بافت ها را بر اساس پیکربندی ساخت خروجی دهد.)

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

هنگام ایجاد چندین پروژه برای یک برنامه، تمرین خوبی است که هر کدام را با نامی شناسایی کنید که نشان دهنده محدودیت های دستگاهی است که باید بر روی APK اعمال شود تا بتوانید به راحتی آنها را شناسایی کنید. برای مثال، «HelloWorld_21» ممکن است نام خوبی برای برنامه‌ای باشد که برای سطح API 21 و بالاتر طراحی شده است.

توجه: همه فایل‌های APK که برای یک برنامه منتشر می‌کنید باید نام بسته یکسانی داشته باشند و با همان کلید گواهی امضا شده باشند . مطمئن شوید که هر یک از قوانین مربوط به چندین APK را نیز درک کرده اید.

تخصیص کدهای نسخه

هر APK برای همان برنامه باید یک کد نسخه منحصر به فرد داشته باشد که توسط ویژگی android:versionCode مشخص شده است. هنگام انتشار چندین APK باید مراقب تخصیص کدهای نسخه باشید، زیرا هر کدام باید متفاوت باشند، اما در برخی موارد، باید یا باید بر اساس پیکربندی هایی که هر APK پشتیبانی می کند، به ترتیب خاصی تعریف شوند.

سفارش کدهای نسخه

APK که به سطح API بالاتری نیاز دارد معمولاً باید کد نسخه بالاتری داشته باشد. برای مثال، اگر دو APK برای پشتیبانی از سطوح API مختلف ایجاد کنید، APK برای سطوح بالاتر API باید کد نسخه بالاتر را داشته باشد. این تضمین می‌کند که اگر دستگاهی به‌روزرسانی سیستمی را دریافت کند و سپس واجد شرایط نصب APK برای سطوح بالاتر API باشد، کاربر اعلانی برای به‌روزرسانی برنامه دریافت می‌کند. برای اطلاعات بیشتر درباره نحوه اعمال این الزام، به بخش بالا درباره قوانین برای چندین APK مراجعه کنید.

همچنین باید در نظر داشته باشید که چگونه ترتیب کدهای نسخه ممکن است بر روی APK دریافتی کاربران شما تأثیر بگذارد، چه به دلیل همپوشانی بین پوشش APKهای مختلف یا تغییرات آتی که ممکن است در APKهای خود ایجاد کنید.

برای مثال، اگر APK های مختلفی بر اساس اندازه صفحه دارید، مانند یکی برای کوچک - معمولی و دیگری برای بزرگ - xlarge، اما زمانی را پیش بینی کنید که APK ها را به یکی برای کوچک و یکی برای معمولی - xlarge تغییر دهید، سپس باید کد نسخه بزرگ - xlarge APK بالاتر باشد. به این ترتیب، یک دستگاه با اندازه معمولی هنگام تغییر به‌روزرسانی مناسب را دریافت می‌کند، زیرا کد نسخه از APK موجود به APK جدیدی که اکنون دستگاه را پشتیبانی می‌کند افزایش می‌یابد.

همچنین، هنگام ایجاد چندین APK که بر اساس پشتیبانی از فرمت‌های فشرده‌سازی بافت OpenGL متفاوت هستند، توجه داشته باشید که بسیاری از دستگاه‌ها از چندین فرمت پشتیبانی می‌کنند. از آنجایی که دستگاهی APK را با بالاترین کد نسخه دریافت می‌کند که در پوشش بین دو APK همپوشانی وجود داشته باشد، باید کدهای نسخه را بین APK خود سفارش دهید تا APK با فرمت فشرده‌سازی ترجیحی بالاترین کد نسخه را داشته باشد. برای مثال، ممکن است بخواهید با استفاده از فرمت‌های فشرده‌سازی PVRTC، ATITC و ETC1 ساخت‌های جداگانه‌ای را برای برنامه خود انجام دهید. اگر این قالب‌ها را دقیقاً به این ترتیب ترجیح می‌دهید، APK که از PVRTC استفاده می‌کند باید بالاترین کد نسخه را داشته باشد، APK که از ATITC استفاده می‌کند دارای کد نسخه پایین‌تر و نسخه با ETC1 کمترین کد را دارد. بنابراین، اگر دستگاهی از PVRTC و ETC1 پشتیبانی می کند، APK را با PVRTC دریافت می کند، زیرا دارای بالاترین کد نسخه است.

در صورتی که فروشگاه Google Play قادر به شناسایی APK صحیح برای نصب برای دستگاه مورد نظر نباشد، ممکن است بخواهید یک APK جهانی نیز ایجاد کنید که شامل منابعی برای همه انواع مختلف دستگاهی است که می‌خواهید پشتیبانی کنید. اگر یک APK جهانی ارائه می کنید، باید کمترین versionCode به آن اختصاص دهید. از آنجایی که Google Play Store نسخه‌ای از برنامه شما را نصب می‌کند که هم با دستگاه مورد نظر سازگار است و هم دارای بالاترین versionCode است، اختصاص versionCode پایین‌تر به APK جهانی تضمین می‌کند که فروشگاه Google Play سعی می‌کند یکی از APK‌های دیگر شما را قبل از بازگشت به آن نصب کند. APK جهانی بزرگتر.

با استفاده از طرح کد نسخه

برای اینکه به فایل‌های APK مختلف اجازه داده شود تا کدهای نسخه خود را مستقل از دیگران به‌روزرسانی کنند (به عنوان مثال، وقتی یک اشکال را فقط در یک APK رفع می‌کنید، بنابراین نیازی به به‌روزرسانی همه APK‌ها نیست)، باید از طرحی برای کدهای نسخه خود استفاده کنید که ارائه می‌کند فضای کافی بین هر APK به طوری که بتوانید کد را در یکی افزایش دهید بدون اینکه نیاز به افزایش در سایر APK داشته باشید. همچنین باید نام نسخه واقعی خود را در کد بنویسید (یعنی نسخه قابل مشاهده کاربر که به android:versionName اختصاص داده شده است)، تا به راحتی بتوان کد نسخه و نام نسخه را مرتبط کرد.

توجه: وقتی کد نسخه APK را افزایش می‌دهید، Google Play از کاربران نسخه قبلی می‌خواهد برنامه را به‌روزرسانی کنند. بنابراین، برای جلوگیری از به‌روزرسانی‌های غیر ضروری، نباید کد نسخه APKهایی را که در واقع شامل تغییراتی نمی‌شوند، افزایش دهید.

پیشنهاد می کنیم از یک کد نسخه با حداقل 7 رقم استفاده کنید: اعداد صحیحی که پیکربندی های پشتیبانی شده را نشان می دهند در بیت های مرتبه بالاتر و نام نسخه (از android:versionName ) در بیت های مرتبه پایین تر است. به عنوان مثال، زمانی که نام نسخه برنامه 3.1.0 باشد، کدهای نسخه برای APK سطح 4 API و APK سطح 11 به ترتیب چیزی شبیه به 0400310 و 1100310 خواهند بود. دو رقم اول برای سطح API (به ترتیب 4 و 11)، دو رقم میانی برای اندازه‌های صفحه یا قالب‌های بافت GL (در این مثال‌ها استفاده نمی‌شوند) و سه رقم آخر مربوط به نام نسخه برنامه است. (3.1.0). شکل 1 دو نمونه را نشان می دهد که بر اساس نسخه پلتفرم (سطح API) و اندازه صفحه نمایش تقسیم می شوند.

شکل 1. یک طرح پیشنهادی برای کدهای نسخه شما، با استفاده از دو رقم اول برای سطح API، رقم دوم و سوم برای حداقل و حداکثر اندازه صفحه (1 تا 4 که هر یک از چهار اندازه را نشان می‌دهد) یا برای نشان دادن قالب‌های بافت و سه رقم آخر برای نسخه برنامه.

این طرح برای کدهای نسخه فقط یک پیشنهاد برای چگونگی ایجاد الگویی است که با تکامل برنامه شما مقیاس پذیر باشد. به طور خاص، این طرح راه حلی برای شناسایی فرمت های مختلف فشرده سازی بافت نشان نمی دهد. یک گزینه ممکن است این باشد که جدول خود را تعریف کنید که عدد صحیح متفاوتی را برای هر یک از فرمت های فشرده سازی مختلف که برنامه شما پشتیبانی می کند مشخص می کند (به عنوان مثال، 1 ممکن است با ETC1 مطابقت داشته باشد و 2 ATITC و غیره باشد).

می‌توانید از هر طرحی که می‌خواهید استفاده کنید، اما باید به دقت در نظر بگیرید که چگونه نسخه‌های بعدی برنامه شما نیاز به افزایش کدهای نسخه خود دارند و چگونه دستگاه‌ها می‌توانند به‌روزرسانی‌ها را هنگام تغییر پیکربندی دستگاه (مثلاً به دلیل به‌روزرسانی سیستم) یا زمانی دریافت کنند. شما پشتیبانی پیکربندی را برای یک یا چند APK تغییر می دهید.