minSdkVersion | compileSdkVersion | targetSdkVersion

نویسنده : سید ایوب کوکبی ۱۰ تیر ۱۳۹۸
minSdkVersion | compileSdkVersion | targetSdkVersion

API چیست؟ منظور از API Level چیست؟ SDK چه فرقی با API دارد؟ فرق compileSdkVersion، minSdkVersion و targetSdkVersion چیست؟ چگونه می‌توان مطمئن شد که برنامۀ به درستی در نسخه‌های مختلف اندروید اجرا می‌شود؟ آیا برنامه‌ای که برای اندروید ۹ نوشته‌ایم روی نسخه‌های پایین‌تر کار می‌کند؟ چطور می‌شود برنامه‌ای ساخت که با نسخه‌های مختلف اندروید سازگار باشد. آیا می‌توان برنامه را طوری نوشت که ضمن سازگاری با نسخه‌های قدیمی از ویژگی‌های نسخۀ جدید اندروید هم بهره‌مند شود؟

احتمالاً بارها این سوالات و موارد مشابه برایتان پیش آمده یا لااقل در برهه‌ای از زمان در موردشان مجبور به تحقیق و جستجو شده‌اید. به هر حال بحث سازگاری برنامه با نسخه‌های مختلف اندروید بسیار مهم و حیاتی است و درک درست آن از اهم وظایف برنامه‌نویسان اندرویدی است. قصد داریم با نگاهی تحلیلی و موشکافانه دربارۀ این موضوع صجبت کنیم. مطلبی که می‌خوانید خلاصه ده‌ها منبع مختلف بوده و تا حد امکان سعی شده مسائل متعددی که در این حوزه وجود دارد تحت پوشش قرار گیرد.

قبل از هر چیز ابتدا باید تفاوت SDK و API و مقصود از API Level را در اکوسیستم اندروید درک کنید. معمولاً بین SDK و API رابطه‌ای یک به یک وجود دارد و به همین خاطر این دو واژه گاهی به جای هم استفاده می‌شوند؛ در حالی که با هم فرق دارند. با این حال اگر بگویید برای هر نسخه از اندروید یک SDK، یک API و یک API Level وجود دارد، حرف درستی زده‌اید.

API

این واژه سرنام عبارت Application Programming Interface است. API یک واسط برنامه‌نویسی است؛ واسطی که به شما می‌گوید برای انجام فلان کار چگونه باید عمل کنید. با دانلود یک SDK در واقع مجموعه‌ای از APIها و ابزارهای کدنویسی دریافت می‌کنید که به صورت جعبه سیاه در اختیار شما قرار می‌گیرد؛ البته در مورد برخی از آن‌ها مثل Android SDK چون متن باز است جعبه سیاه نیست و هر وقت که بخواهید می‌توانید پیاده‌سازی API را از اینترنت مشاهده کنید ولی معمولاً پیاده‌سازی API دربسته است و فقط امکان ارسال درخواست و دریافت پاسخ وجود دارد. به عنوان مثال در بحث Web API شما با یک سری API که از پیاده‌سازی آن خبر ندارید به سرور گوگل متصل شده و از امکانات نقشه در برنامۀ خود استفاده می‌کنید. یا Web API پیامک، همینطور سرویس‌های هواشناسی و … .

تمام کلاس‌ها، متدها، ماژول‌ها، ثوابت و هرآنچه در مستندات اندروید می‌بینید API هستند. API به عنوان یک قرارداد بین پروایدر مثلاً کتابخانه (library) و مصرف‌کننده عمل می‌کند. مثلاً در API Documentation اندروید برای نمایش پیامی کوتاه به کاربر باید از متد ()Toast.makeText مطابق فلان شیوه‌نامه استفاده کنید. یا برای دریافت موقعیت مکانی کاربر باید از فلان روش بروید. گفتنی است که شما به عنوان یک توسعه‌دهنده فقط با همین API ها کد می‌نویسید و کاری به پیاده‌سازی آن‌ها ندارید.

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

SDK

این کلمه سرنام Software Development Kit (کیت توسعۀ نرم‌افزار) است. به کلمۀ «کیت» دقت کنید. منظور از کیت کلکسیونی از ابزارها، کتابخانه‌ها، مستندات، ایمیولیتورها، مثال‌های برنامه‌نویسی، تورهای آموزشی و چیزهای دیگر است. با کمک JDK می‌توانید برنامه‌های جاوا بسازید. با iPhone SDK می‌توانید برنامه‌های iOS بنویسید. همینطور برای نوشتن برنامه‌های ویندوز فون باید Windows Phone SDK را دانلود کنید. می‌بینید که برای هر پلتفرمی باید SDK آن را دانلود کنید.

برنامۀ SDK Manager را اجرا کنید. این ابزار به خوبی نشان می‌دهد که چه چیزهایی در SDK وجود دارد. تب اول SDK Platforms، لیست SDK های موجود هر نسخۀ از اندروید را نشان می‌دهد. مثلاً در تصویر پایین اندروید ۹٫۰ شامل اقلام زیر است:

  • Android SDK Platform 28 (عدد ۲۸ شمارۀ API Level را نشان می‌دهد)؛
  • Sources for Android 28 (پیاده‌سازی API بوده که اختیاری است)؛
  • و بسیاری از چیزهای دیگر مثل ایمیج‌های مختلف برای Android Emulator.

هنگام نصب اندروید استودیو احتمالاً با نام‌هایی مثل Android SDK و Android SDK Tools مواجه شده‌اید و برایتان این سوال پیش آمده که فرق این‌ها چیست. یا مثلاً Android SDK Platform-tools چیست و فرقش با Android SDK Build-tools چیست. تعدد کامپوننت‌ها و نام‌گذاری‌ها در اکوسیستم اندروید اینقدر زیاد است که حتی کاربران حرفه‌ای را هم بیزار کرده است. در اینجا به صورت خلاصه و فشرده هر یک از این‌ها را توضیح می‌دهیم.

محتویات کیت توسعۀ اندروید (Android SDK) به چند دسته تقسیم می‌شود که هر دسته شامل ابزارهای و کامپوننت‌هایی است:

بخوانید  آموزش گیت - قسمت سوم

Android SDK Tools

شامل ابزارهایی کمکی برای SDK است؛ از جمله ابزارهای دیباگینگ مثل ,emulator, sdcard, sqlite, apk builder, sdkmanager, avdmanager,traceview, ddms, ddms, draw9patch و … . محتویات این شاخه در مسیر ANDROID_HOME/tools قرار دارد.

Android SDK Platform-tools

کامپوننت‌ها و ابزارهای موجود در این دسته برای پشتیبانی از فیچرهای نسخۀ خاصی از اندروید در نظر گرفته شده‌‌اند و عموماً شامل ابزارهایی است که برای ارتباط با دیوایس اندرویدی به کار می‌روند. از ابزارهای موجود در این دسته می‌توان به adb و fastboot اشاره کرد که در فرایند اجرای apk روی گوشی هنگام دیباگ در محیط اندروید استودیو استفاده می‌شود. همۀ این ابزارها در فولدر ANDROID_HOME/platform-tools مستقر شده‌اند.

Android SDK Build Tools

همانطور که از نامش پیداست شامل ابزارهایی است که برای دیباگ، build، اجرا و تست کدهای اندرویدی به کار می‌رود. ابزارهای این مجموعه را می‌توان از طریق IDE مثلاً اندروید استودیو و اکلیپس یا مستقیماً با خط فرمان اجرا کرد و توصیه می‌شود همواره از آخرین نسخۀ آن استفاده کنید. از ابزارهای مهم این دسته می‌توان aapt که برای ساخت خودکار فایل R.java و APK های unsign شده به کار می‌رود یا dx که برای تبدیل بایت کدهای جاوا به بایت کدهای دالویک استفاده می‌شود اشاره کرد. همچنین ابزار zipalign که برای بهینه‌سازی apk کاربرد دارد. ابزارها و کامپوننت‌های این دسته در فولدر ANDROID_HOME/build-tools/$VERSION قرار دارند.

API Level

API Level یا به صورت مختصر API عددی است که به صورت منحصر به فرد شمارۀ هر یک از نسخه‌های اندروید را بیان می‌کند.

توزیع نسخه‌های مختلف اندروید در گوگل‌پلی – سال ۱۳۹۸ – منبع

اندروید سه نام‌گذاری برای نسخه‌های مختلف اندروید در نظر گرفته است. Version, Codename, API. ورژن نمایش عددی نسخه است. codename نام کدگذاری شده است که در بین مصرف‌کننده‌ها کاربرد بیشتری دارد و API یا API Level که یک عدد سادۀ integer است و بیشتر به دردِ برنامه‌نویس‌ها می‌خورد. دقت کنید چند ورژن متعدد می‌توانند یک Codename و API Level یکسان داشته باشد. مثلاً به ورژن‌های ۲٫۳٫۳ تا ۲٫۳٫۷ نام Gingerbread اختصاص داده شده و همۀ آن‌ها با یک API Level واحد یعنی ۱۰ منتشر شده‌اند.

معمولاً آپدیت‌هایی که برای هر نسخه از فریم‌ورک ارائه می‌شود به گونه‌ای است که با نسخه‌های قبلی سازگار باشد تا نسخۀ جدید API با نسخه‌های قبلی همچنان سازگار باقی بماند. به همین دلیل است که API به صورت افزایشی است؛ یعنی چیزی حذف یا جایگزین نمی‌شود بلکه راهکارهای جدید در قالب روش‌های نو عرضه می‌شوند و روش‌های قدیمی deprecate شده اعلام می‌شوند تا توسعه‌دهنده به مرور زمان به روش‌های جدید رو بیاورد.

احتمالاً هنگام کدنویسی بارها intellisense اندروید استودیو شما را از قدیمی بودن برخی از متدها آگاه کرده است (متدهای خط خورده با برچسب deprecated). این یعنی در API Level جدید تابعی که می‌خواهید استفاده کنید از دور خارج شده و به جایش بهتر است از راهکار جایگزین دیگری که اغلب توسط IDE پیشنهاد می‌شود استفاده کنید. توابع قدیمی حذف نمی‌شوند تا پس از مهارجت به API Level جدید کدهای قدیمی از درجۀ اعتبار ساقط نشوند و همچنان کامپایل شوند.

همانطور که بالاتر توضیح دادیم پیاده‌سازی واقعی روی دستگاه کاربر قرار دارد. بیایید از سورس کد برنامه آغاز کنیم و تا اجرای فایل APK اتفاقات پیش‌رو را بررسی کنیم.

عموماً پروژه‌های اندروید با کدهایی در Android API نوشته می‌شوند. حالا در کنارش کتابخانه‌ها، ریسورس‌ها و سایر ماژول‌ها هم ممکن است استفاده شود ولی هستۀ اصلی کد همان تعاریفی است که در API وجود دارد. بعد از کامپایل، کدهای جاوا/کاتلین به همراه تمام کتابخانه‌ها و dependency ها به بایت‌کدهای DEX تبدیل شده و در فرمت APK تحویل داده می‌شود. این یعنی بدون پیاده‌سازی API فایل APK کامپایل می‌شود! داستان چیست؟ جوابش را در قسمت بعدی بخوانید.

فایل‌های DEX و Android Runtime

Android Runtime محیط اجرایی برنامه در گوشی یا Emulator ای است که برنامۀ شما در آن اجرا می‌شود. این همان جایی است که کار اصلی انجام شده و فایل‌های DEX اجرا می‌شوند. این قسمت از دو کامپوننت تشکیل شده:

  • Virtual Machine (ماشین مجازی) که به منظور پرتابل کردن و مستقل از پلتفرم ساختن برنامه در نظر گرفته شده است. با عرضۀ Android 5.0 (لالی پاپ)، رانتایم قدیمی یعنی Dalvik Virtual Machine با نسخۀ جدیدتر Android Runtime (یا ART) جایگزین شد. دالویک از کامپایلر JIT استفاده می‌کرد ولی ART از AOT (سرنام Ahead of Time) بعلاوۀ JIT برای اجرای کدها استفاده می‌کند؛
  • کتابخانه‌های پایه (Core Libraries) که مجموعه‌ای از کتابخانه‌های استاندارد جاوا و اندروید است. به زبان ساده این همان جایی است که پیاده‌سازی API در آن گنجانده شده است. اینکه کدام نسخه از API در گوشی وجود دارد بستگی به نسخه‌ای از اندروید دارد که روی گوشی کاربر نصب شده است؛ مثلاً اگر Android 9.0 نصب شده باشد، تمام API ها تا API Level 28 در دسترس خواهد بود.
بخوانید  آموزش گیت - قسمت دوم

اگر دقت کرده باشید هنگام آپدیت سیستم عاملِ اندروید، برنامه‌های قدیمی همچنان بدون مشکل اجرا می‌شوند. این به خاطر مفهومی تحت عنوان forward compatibility است؛ یعنی برنامه‌هایی که در گذشته تحت SDK های قدیمی نوشته شده‌اند بدون هیچ مشکلی باید روی نسخه‌های جدید اندروید که از SDK جدیدتر استفاده می‌کنند نیز اجرا شوند. اینجاست که سروکله سه Attribute یا خصیصۀ مهم تحت عنوان compileSdkVersion, minSdkVersion و targetSdkVersion پیدا می‌‌شود. این سه تعیین می‌کنند چه API هایی در دسترس شماست، چه API Level ای مورد نیاز است و چه compatibility mode اعمال شود.

compileSdkVersion

این خصیصه به گریدل (Gradle) می‌گوید که برنامۀ شما را با کدام نسخه از SDK کامپایل، دیباگ و تست کند. برای استفاده از جدیدترین API ها، اطلاع از آخرین API های deprecate شده، تم‌ها و استایل‌های جدید باید از نسخه‌های جدیدتر Android SDK و ترجیحاً آخرین نسخۀ آن استفاده کنید. نکتۀ مهم در مورد compileSdkVersion این است که تغییر مقدار آن هیچ اثری روی runtime ندارد چون این نسخه اصلاً در APK شما وجود ندارد؛ بلکه فقط و فقط در زمان کامپایل استفاده می‌شود.

تمام اخطاهارها و خطاهایی که کامپایلر پس از تغییر این پارامتر نشان می‌دهد حتماً باید رفع شوند والا در زمان اجرا برای شما دردسرساز خواهند شد. ضمناً توصیه اکید می‌کنیم که همواره از آخرین نسخه SDK برای این پارامتر استفاده کنید. با این کار compilation check های بیشتری در دسترس شما قرار می‌گیرد و توابع deprecated (از دور خارج شدۀ) بیشتری به اطلاع شما می‌رسد. بدین ترتیب زودتر به روش‌های جدیدی که SDK پیشنهاده کرده عادت می‌کنید.

به طور خلاصه مزایای استفاده از آخرین نسخۀ Android SDK برای compileSdkVersion به شرح ذیل است:

  • API Level بالا به توسعه‌دهنده امکان می‌دهد تا از آخرین API در کدهایش استفاده کند و طوری کد بنویسد که حداکثر سازگاری را با پلتفرم‌های جدید داشته باشد؛
  • برای استفاده از آخرین نسخۀ SupportLibrary حتماً باید از آخرین ورژن SDK برای compileSdkVersion استفاده کنید؛ برای مثال برای استفاده از supportlibrary+28.x.x باید compileSdkVersion را ۲۸ مقداردهی کنید (فقط مچ بودن عدد اول مهم است). همزمان با انتشار نسخۀ جدید پلتفرم، نسخۀ جدید support library هم منتشر می‌شود و این نسخه آخرین سازگاری را با API های جدید دارد؛
  • برای مهاجرت به AndroidX باید compileSdkVersion را حداقل روی ۲۸ بگذارید؛
  • گوگل به منظور جا انداختن نسخه‌های اندروید معمولاً هر سال توسعه‌دهندگان را وادار می‌کند که minimum target API را به سطح بالاتری افزایش دهند. اینجا باز هم به انتخاب رقم بالاتری برای compileSdkVersion نیاز پیدا می‌کنید.

برنامه‌های اندرویدی forward-compatible هستند یعنی برنامه‌های قدیمی بدون هیچ مشکلی روی نسخه‌های جدید اندروید اجرا می‌شوند. بنابراین بدون هیچ نگرانی می‌توانید compileSdkVersion را افزایش دهید. برای مثال برنامه‌ای با compileSdkVersion=26 اگر از تابعِ ()xyz متعلق به API Level 26 استفاده کند به راحتی روی Android 8 Oreo قابل اجراست و بدون هیچ مشکلی روی اندروید ۹ (با API Level 28) و بالاتر نیز اجرا می‌شود.

minSdkVersion

این مقدار حداقل API Level ای که برنامه به آن نیاز دارد را تعیین می‌کند. این مقدار در واقع نمایانگر حداقل نیازمندی برنامۀ شماست. در صورتی که هیچ مقداری برای آن انتخاب نکنید به صورت خودکار ۱ در نظر گرفته می‌شود. minSdkVersion برای backward compatibility کاربرد دارد و با مسئولیت خودتان تغییر می‌کند. در هنگام کدنویسی اگر از تابعی متعلق به API Level ای بالاتر از minSdkVersion استفاده کنید، ابزار Lint به صورت پیش‌فرض اخطار می‌دهد تا مبادا به خاطر فرخوانی API ای که وجود ندارد با خطای زمان اجرا مواجه شوید. قابل ذکر است که برخی از ویژگی‌های جاوا ۸ نیز فقط از نسخۀ خاصی از minSdkVersion به بعد قابل استفاده هستند.

توجه به این اخطارها بسیار مهم است چرا که اگر آن‌ها را نادیده بگیرید برنامه موقع اجرا روی نسخه‌های قدیمی اندروید با خطا مواجه می‌شود؛ دلیلش این است که از قابلیتی در API بالاتر استفاده کرده‌اید که در آن API Level وجود ندارد. یکی از راهکارهای حل این مشکل استفاده از دستورات شرطی است. یعنی برحسب اینکه اندروید نصب شده روی دستگاه چه نسخه‌ای است از توابع سازگار استفاده کنید.

گوگل پلی از روی همین عدد به کاربر اعلام می‌کند که آیا برنامه روی گوشی او قابل نصب هست یا نه. توسعه‌دهندگان باید روی انتخاب minSdkVersion حساسیت به خرج دهند چون اندروید همانطور که سازگاری رو به جلو دارد backward compatibility ندارد. انتخاب این عدد نوعی تصمیم‌گیری تجاری هم هست چون قطعاً روی تعداد افرادی که می‌توانند از برنامۀ شما استفاده کنند تاثیر می‌گذارد. یکی از روش‌های خوب برای تصمیم‌گیری در انتخاب این عدد بررسی داشبورد و آمارهای دوره‌ای است که توسط مارکت‌ها منتشر می‌شود. برای اطلاع از توزیع نسخه‌ها در گوگل‌پلی به داشبورد توسعه دهندگان اندروید و برای کافه‌بازار به گزارش‌های فصلی کافه‌بازار مراجعه کنید.

بخوانید  آشنایی با Android Lifecycle

به عنوان مثال گوگل ورژن تمام دیوایس‌هایی که در ۷ روز گذشته به گوگل‌پلی مراجعه کرده‌اند را بررسی می‌کند و به صورت نمودار درصد استفاده از هر نسخه را نشان می‌دهد. کافه‌بازار و سایر مارکت‌های داخلی هم چنین گزارش‌هایی دارند. مثلاً اگر درصد استفاده از نسخۀ ۵ اندروید به کمتر از ۳ درصد رسیده باشد، می‌توانید خودتان را از شر سازگاری برنامه با این نسخه رها کنید و minSdkVersion را به نسخۀ بالاتر ارتقا دهید. یا به عکس اگر در نسخۀ جدید اندروید قابلیتی عرضه شده که وسوسه شده‌اید از آن استفاده کنید با مراجعه به این آمارها تکلیفتان روشن خواهد شد.

برای برنامه‌ای با compileSdkVersion 26 و minSdkVersion 22 اگر از تابع ()xyz که در API Level 26 وجود دارد استفاده کنید بدون هیچ مشکلی روی اندروید ۸ (با API Level 26) اجرا می‌شود. همین برنامه بر روی اندروید ۵٫۱ (با API Level 22) نیز قابل اجراست ولی به این شرط که برای تابعِ ()xyz معادل آن تابع در API Level 22 در نظر گرفته باشید. در غیر این صورت سیستم عامل آن تابع را پیدا نمی‌کند و برنامه کرش می‌کند. در چنین شرایطی گفته می‌شود که برنامه backward compatible نیست.

یکی از روش‌های خوب برای سازگار کردن برنامه با نسخه‌های قدیمی، چک کردن پلتفرم گوشی در زمان اجراست. مثلاً برای استفاده از ActionBar ابتدا نسخۀ پلتفرم گوشی را چک کنید که آیا لالی پاپ و بالاتر از آن هست یا نه. در واقع این شرط برای زمانی کاربرد دارد که بخواهید از API ای استفاده کنید که فقط در یک API Level مشخص و بالاتر قابل استفاده است. برای نسخه‌های پایین‌تر می‌توانید از API های قدیمی استفاده کنید:

private void setUpActionBar() {
    // Make sure we're running on Honeycomb or higher to use ActionBar APIs
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
        ActionBar actionBar = getActionBar();
        actionBar.setDisplayHomeAsUpEnabled(true);
    }
}

معمولاً کتابخانه‌های جانبی مثل Support Library یا Google Play Services مقدار minSdkVersion خودشان را دارند. در چنین شرایطی باید توجه داشت که این عدد را برابر بالاترین minSdkVersion کتابخانه قرار داد. مثلاً اگر از کتابخانه‌هایی با minSdkVersion های ۴, ۷ و ۹ استفاده می‌کنید باید مقدار این خصیصه را برای برنامه‌تان ۹ قرار دهید. در شرایط نادری که ناچارید از کتابخانه‌ای با ورژنی بالاتر از minSdkVersion استفاده کنید می‌توانید به صورت صریح از tools:overrideLibrary marker استفاده کنید. برای درک اینکه چه زمانی به این مورد نیاز پیدا می‌کنید این سوال در Stackoverflow را بخوانید.

targetSdkVersion

جالب‌ترین مورد در بین این سه خصیصه targetSdkVersion است. این مورد برخلاف compileSdkVersion که فقط در زمان کامپایل کاربرد داشت رفتار برنامه را در زمان اجرا کنترل می‌کند و همانند minSdkVersion جزئی از APK است. مقدار انتخاب شده، نسخه‌ای از اندروید که برنامه برای آن هدف‌گذاری و تست شده را تعیین می‌کند و اگر چیزی در نظر نگیرید به صورت پیش‌فرض برابر minSdkVersion خواهد شد. در واقع به کمک این خصیصه ویژگی forward compatibility را کنترل می‌کنید.

به عنوان مثال با انتشار نسخۀ ۶ اندروید (API Level 23) مدل مجوزها به Runtime Permission تغییر کرد. قبل از آن کاربر در زمان نصب برنامه باید همۀ مجوزها را تأیید می‌کرد تا برنامه نصب می‌شد ولی اکنون برنامه در زمان اجرا تک تک مجوزها را به صورت تفکیک شده از یوزر درخواست می‌کند. در چنین شرایطی اگر مقدار targetSdkVersion در برنامۀ شما کمتر از ۲۳ باشد (مثلاً ۲۲). کاربر هنگام اجرای برنامه با درخواست مجوز مواجه نمی‌شود.

یا اگر targetSdkVersion را ۱۱ یا بالاتر قرار دهید. اندروید ۳٫۰ (API Level 11) و بالاتر اجازه پیدا می‌کند تم پیش فرض جدید Holo را برای برنامه شما فعال کند و همچنین Screen Compatibility Mode را زمانی که برنامه روی صفحات بزرگتر اجرا می‌شود غیرفعال کند؛ چون API Level 11 به صورت توکار از صفحات بزرگ پشتیبانی می‌کند.

و آخرین مثال اگر targetSdkVersion را کمتر از ۲۴ قرار دهید و برنامه را در محیط multi-window در اندروید +۷٫۰ اجرا کنید پیامی ظاهر می‌شود که برنامۀ شما با این قابلیت سازگار نیست. برای ظاهر نشدن این پیام مقدار targetSdkVersion را به ۲۴ و بالاتر تغییر دهید. در واقع زمانی باید مقدار این خصیصه را افزایش دهید که برنامه آمادگی استفاده از ویژگی‌های جدید را داشته باشد؛ در غیر این صورت ممکن است برنامه کرش کند.

به صورت خلاصه پیشنهاد می‌شود مقادیر این سه خصیصه را به صورت زیر انتخاب کنید:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

و در حالت ایده‌آل:

minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)

انتخاب حداقل ممکن برای minSdkVersion در کنار دردسر سازگاری با نسخه‌های قدیمی و اندکی کدنویسی بیشتر، طیف گسترده‌تر مخاطبان را به دنبال خواهد داشت.

سید ایوب کوکبی

نویسنده و مترجم...

مطالب مرتبط

0 دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *