تغییرات رفتار: همه برنامه ها

اندروید 9 (سطح API 28) تعدادی تغییرات را در سیستم اندروید معرفی می کند. تغییرات رفتاری زیر برای همه برنامه‌ها وقتی روی پلتفرم Android 9 اجرا می‌شوند، صرف‌نظر از سطح API مورد نظرشان اعمال می‌شود. همه توسعه‌دهندگان باید این تغییرات را بررسی کرده و برنامه‌های خود را تغییر دهند تا در صورت لزوم، به درستی از آنها پشتیبانی کنند.

برای تغییراتی که فقط بر برنامه‌هایی تأثیر می‌گذارند که سطح API 28 یا بالاتر را هدف قرار می‌دهند، به تغییرات رفتار: برنامه‌هایی که API سطح 28+ را هدف قرار می‌دهند، مراجعه کنید.

مدیریت نیرو

اندروید 9 ویژگی های جدیدی را برای بهبود مدیریت انرژی دستگاه معرفی می کند. این تغییرات، همراه با ویژگی‌هایی که قبلاً قبل از اندروید 9 وجود داشت، کمک می‌کند تا اطمینان حاصل شود که منابع سیستم در دسترس برنامه‌هایی قرار می‌گیرد که بیشتر به آن‌ها نیاز دارند.

برای جزئیات، به مدیریت نیرو مراجعه کنید.

حریم خصوصی تغییر می کند

برای افزایش حریم خصوصی کاربر، اندروید 9 چندین تغییر رفتاری را معرفی می‌کند، مانند محدود کردن دسترسی برنامه‌های پس‌زمینه به حسگرهای دستگاه، محدود کردن اطلاعات بازیابی شده از اسکن‌های Wi-Fi، و قوانین جدید مجوز و گروه‌های مجوز مربوط به تماس‌های تلفنی، وضعیت تلفن و Wi- اسکن Fi

این تغییرات بدون در نظر گرفتن نسخه SDK هدف، بر تمام برنامه های اجرا شده در اندروید 9 تأثیر می گذارد.

دسترسی محدود به حسگرها در پس زمینه

اندروید 9 امکان دسترسی برنامه‌های پس‌زمینه به ورودی‌های کاربر و داده‌های حسگر را محدود می‌کند. اگر برنامه شما در پس‌زمینه دستگاهی با Android 9 اجرا می‌شود، سیستم محدودیت‌های زیر را برای برنامه شما اعمال می‌کند:

• برنامه شما نمی تواند به میکروفون یا دوربین دسترسی پیدا کند.
• حسگرهایی که از حالت گزارش مداوم استفاده می کنند، مانند شتاب سنج و ژیروسکوپ، رویدادها را دریافت نمی کنند.
• حسگرهایی که از حالت‌های گزارش لحظه‌ای یا یک‌شات استفاده می‌کنند، رویدادها را دریافت نمی‌کنند.

اگر برنامه شما نیاز به تشخیص رویدادهای حسگر در دستگاه‌های دارای Android 9 دارد، از سرویس پیش‌زمینه استفاده کنید.

دسترسی محدود به گزارش تماس ها

Android 9 گروه مجوز CALL_LOG را معرفی می‌کند و مجوزهای READ_CALL_LOG ، WRITE_CALL_LOG و PROCESS_OUTGOING_CALLS را به این گروه منتقل می‌کند. در نسخه های قبلی اندروید، این مجوزها در گروه مجوز PHONE قرار داشتند.

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

اگر برنامه شما نیاز به دسترسی به گزارش تماس دارد یا نیاز به پردازش تماس‌های خروجی دارد، باید این مجوزها را صریحاً از گروه مجوز CALL_LOG درخواست کنید. در غیر این صورت، یک SecurityException رخ می دهد.

دسترسی محدود به شماره تلفن

برنامه‌هایی که روی Android 9 اجرا می‌شوند، نمی‌توانند شماره تلفن یا وضعیت تلفن را بدون دریافت مجوز READ_CALL_LOG ، بعلاوه سایر مجوزهایی که موارد استفاده برنامه شما به آن نیاز دارند، بخوانند.

شماره‌های تلفن مرتبط با تماس‌های ورودی و خروجی در پخش وضعیت تلفن ، مانند تماس‌های ورودی و خروجی، قابل مشاهده هستند و از کلاس PhoneStateListener قابل دسترسی هستند. با این حال، بدون مجوز READ_CALL_LOG ، قسمت شماره تلفن ارائه شده در پخش‌های PHONE_STATE_CHANGED و از طریق PhoneStateListener خالی است.

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

• برای خواندن اعداد از اقدام قصد PHONE_STATE ، هم به مجوز READ_CALL_LOG و هم به مجوز READ_PHONE_STATE نیاز دارید.
• برای خواندن اعداد از onCallStateChanged() فقط به مجوز READ_CALL_LOG نیاز دارید. شما به مجوز READ_PHONE_STATE نیاز ندارید.

دسترسی محدود به مکان Wi-Fi و اطلاعات اتصال

در اندروید 9، الزامات مجوز برای یک برنامه برای انجام اسکن وای فای سخت تر از نسخه های قبلی است. برای جزئیات، محدودیت‌های اسکن Wi-Fi را ببینید.

محدودیت‌های مشابهی برای متد getConnectionInfo() نیز اعمال می‌شود که یک شی WifiInfo را که اتصال Wi-Fi فعلی را توصیف می‌کند، برمی‌گرداند. فقط در صورتی می‌توانید از روش‌های این شی برای بازیابی مقادیر SSID و BSSID استفاده کنید که برنامه تماس‌گیرنده مجوزهای زیر را داشته باشد:

• ACCESS_FINE_LOCATION یا ACCESS_COARSE_LOCATION
• ACCESS_WIFI_STATE

برای بازیابی SSID یا BSSID نیز باید خدمات مکان در دستگاه فعال شود (در زیر تنظیمات > مکان ).

اطلاعات از روش‌های سرویس Wi-Fi حذف شد

در Android 9، رویدادها و پخش‌های زیر اطلاعاتی درباره موقعیت مکانی کاربر یا داده‌های قابل شناسایی شخصی دریافت نمی‌کنند:

• متدهای getScanResults() و getConnectionInfo() از WifiManager .
• متدهای discoverServices() و addServiceRequest() از WifiP2pManager .
• پخش NETWORK_STATE_CHANGED_ACTION .

سیستم NETWORK_STATE_CHANGED_ACTION که از Wi-Fi پخش می‌شود، دیگر حاوی SSID (قبلا EXTRA_SSID)، BSSID (قبلا EXTRA_BSSID) یا اطلاعات اتصال (قبلاً EXTRA_NETWORK_INFO) نیست. اگر برنامه شما به این اطلاعات نیاز دارد، به جای آن با getConnectionInfo() تماس بگیرید.

اطلاعات تلفن اکنون به تنظیمات مکان دستگاه متکی است

اگر کاربر مکان دستگاه را در دستگاهی که Android 9 دارد غیرفعال کرده باشد، روش‌های زیر نتیجه‌ای را ارائه نمی‌دهند:

• getAllCellInfo()
• listen()
• getCellLocation()
• getNeighboringCellInfo()

محدودیت در استفاده از رابط های غیر SDK

برای کمک به اطمینان از ثبات و سازگاری برنامه، پلتفرم استفاده از برخی روش‌ها و زمینه‌های غیر SDK را محدود می‌کند. این محدودیت‌ها اعمال می‌شوند چه بخواهید مستقیماً به این روش‌ها و فیلدها دسترسی داشته باشید، از طریق بازتاب یا با استفاده از JNI. در Android 9، برنامه شما می‌تواند همچنان به این رابط‌های محدود دسترسی داشته باشد. این پلتفرم از نان تست ها و ورودی های گزارش استفاده می کند تا توجه شما را جلب کند. اگر برنامه شما چنین نان تستی را نشان می دهد، مهم است که استراتژی پیاده سازی دیگری غیر از رابط کاربری محدود را دنبال کنید. اگر فکر می کنید که هیچ استراتژی جایگزینی امکان پذیر نیست، می توانید یک اشکال را برای درخواست تجدید نظر در محدودیت ارسال کنید.

محدودیت‌ها در رابط‌های غیر SDK حاوی اطلاعات مهم دیگری است. باید آن را بررسی کنید تا مطمئن شوید که برنامه شما به درستی کار می کند.

رفتار امنیتی تغییر می کند

تغییرات امنیتی دستگاه

Android 9 چندین قابلیت اضافه می کند که امنیت برنامه شما را بهبود می بخشد، صرف نظر از اینکه برنامه شما کدام نسخه را هدف قرار می دهد.

تغییرات پیاده سازی TLS

پیاده سازی TLS سیستم در اندروید 9 دستخوش تغییرات زیادی شده است:

• اگر نمونه ای از SSLSocket در حین ایجاد اتصال نتواند، سیستم یک IOException به جای NullPointerException پرتاب می کند.
• کلاس SSLEngine به طور تمیز با هر هشدار close_notify که رخ می دهد کنترل می کند.

برای کسب اطلاعات بیشتر در مورد ایجاد درخواست های وب ایمن در یک برنامه Android، یک مثال HTTPS را ببینید.

فیلتر SECCOMP دقیق تر

اندروید 9 تماس‌های سیستمی را که برای برنامه‌ها در دسترس است محدودتر می‌کند. این رفتار یک برنامه افزودنی از فیلتر SECCOMP است که Android 8.0 (سطح API 26) شامل می شود .

تغییرات رمزنگاری

اندروید 9 تغییرات زیادی را در پیاده سازی و مدیریت الگوریتم های رمزنگاری ایجاد می کند.

پیاده سازی پارامترها و الگوریتم ها را رمزگذاری کنید

اندروید 9 پیاده سازی های اضافی پارامترهای الگوریتم را در Conscrypt ارائه می دهد. این پارامترها عبارتند از: AES، DESEDE، OAEP و EC. نسخه‌های Bouncy Castle این پارامترها و بسیاری از الگوریتم‌ها از اندروید 9 منسوخ شده‌اند.

اگر برنامه شما Android 8.1 (سطح API 27) یا پایین‌تر را هدف قرار می‌دهد، هنگام درخواست اجرای Bouncy Castle از یکی از این الگوریتم‌های منسوخ، هشداری دریافت می‌کنید. با این حال، اگر اندروید 9 را هدف قرار دهید، هر یک از این درخواست‌ها یک NoSuchAlgorithmException می‌دهند.

تغییرات دیگر

اندروید 9 چندین تغییر دیگر مرتبط با رمزنگاری را معرفی می کند:

• هنگام استفاده از کلیدهای PBE، اگر Bouncy Castle منتظر یک بردار اولیه (IV) باشد و برنامه شما یکی را ارائه نکند، یک هشدار دریافت می‌کنید.
• اجرای Conscrypt رمز ARC4 به شما امکان می دهد ARC4/ECB/NoPadding یا ARC4/NONE/NoPadding را مشخص کنید.
• ارائه دهنده Crypto Java Cryptography Architecture (JCA) حذف شده است. در نتیجه، اگر برنامه شما SecureRandom.getInstance("SHA1PRNG", "Crypto") را فراخوانی کند، یک NoSuchProviderException رخ می دهد.
• اگر برنامه شما کلیدهای RSA را از بافرهایی که بزرگتر از ساختار کلید هستند تجزیه کند، دیگر استثنایی رخ نخواهد داد.

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

فایل‌های رمزگذاری شده امن Android دیگر پشتیبانی نمی‌شوند

اندروید 9 به طور کامل پشتیبانی از فایل های رمزگذاری شده ایمن اندروید (ASEC) را حذف می کند.

در Android 2.2 (سطح API 8)، اندروید ASEC ها را برای پشتیبانی از عملکرد برنامه ها روی کارت SD معرفی کرد. در Android 6.0 (سطح API 23)، این پلتفرم یک فناوری دستگاه ذخیره سازی قابل قبول را معرفی کرد که توسعه دهندگان می توانند به جای ASEC از آن استفاده کنند.

به روز رسانی کتابخانه های ICU

اندروید 9 از نسخه 60 کتابخانه ICU استفاده می کند. اندروید 8.0 (سطح API 26) و اندروید 8.1 (سطح API 27) از ICU 58 استفاده می کنند.

ICU برای ارائه APIهای عمومی در زیر android.icu package استفاده می شود و به صورت داخلی در پلتفرم Android برای پشتیبانی بین المللی استفاده می شود. به عنوان مثال، برای پیاده سازی کلاس های اندروید در java.util ، java.text و android.text.format استفاده می شود.

به‌روزرسانی ICU 60 شامل بسیاری از تغییرات کوچک اما مفید است، از جمله پشتیبانی از داده‌های Emoji 5.0 و فرمت‌های تاریخ/زمان بهبود یافته، همانطور که در یادداشت‌های انتشار ICU 59 و ICU 60 مستند شده است.

تغییرات قابل توجه در این به روز رسانی:

• نحوه مدیریت این پلتفرم با مناطق زمانی تغییر کرده است.
  • پلتفرم GMT و UTC را بهتر مدیریت می کند. UTC دیگر مترادف GMT نیست.

    ICU اکنون نام مناطق ترجمه شده را برای GMT ​​و UTC ارائه می دهد. این تغییر قالب‌بندی android.icu و رفتار تجزیه را برای مناطقی مانند "GMT"، "Etc/GMT"، "UTC"، "Etc/UTC" و "Zulu" تحت تاثیر قرار می‌دهد.

  • java.text.SimpleDateFormat اکنون از ICU برای ارائه نام های نمایشی برای UTC /GMT استفاده می کند، به این معنی:
    • قالب بندی zzzz یک رشته محلی طولانی برای بسیاری از مناطق ایجاد می کند. قبلاً "UTC" برای UTC و رشته هایی مانند "GMT+00:00" برای GMT ​​تولید می کرد.
    • تجزیه zzzz رشته هایی مانند "زمان هماهنگ جهانی" و "زمان میانگین گرینویچ" را تشخیص می دهد.
    • اگر برنامه‌ها فرض کنند که «UTC» یا «GMT+00:00» برای zzzz در همه زبان‌ها خروجی دارند، ممکن است با مشکلات سازگاری مواجه شوند.
  • رفتار java.text.DateFormatSymbols.getZoneStrings() تغییر کرده است:
    • همانند SimpleDateFormat ، UTC و GMT اکنون نام های طولانی دارند. انواع DST نام‌های منطقه زمانی برای منطقه UTC، مانند "UTC"، "Etc/UTC" و "Zulu" به GMT+00:00 تبدیل می‌شوند، که زمانی که نامی در دسترس نباشد، بازگشتی استاندارد است. رشته کد سخت UTC .
    • برخی از شناسه‌های ناحیه به درستی به‌عنوان مترادف مناطق دیگر شناخته می‌شوند، بنابراین Android رشته‌هایی را برای شناسه‌های منطقه قدیمی، مانند Eire پیدا می‌کند که قبلاً قابل حل نبودند.
  • آسیا/هانوی دیگر یک منطقه شناخته شده نیست. به همین دلیل java.util.TimeZones.getAvailableIds() این مقدار را بر نمی گرداند و java.util.TimeZone.getTimeZone() آن را تشخیص نمی دهد. این رفتار با رفتار android.icu موجود مطابقت دارد.
• روش android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) ممکن است حتی در هنگام تجزیه متن ارز قانونی، یک ParseException ایجاد کند. با استفاده از NumberFormat.parseCurrency ، که از Android نسخه 7.0 (سطح API 24) برای متن ارز به سبک PLURALCURRENCYSTYLE در دسترس است، از این مشکل جلوگیری کنید.

تغییرات تست اندروید

اندروید 9 تغییرات متعددی را در ساختار کتابخانه و کلاس چارچوب Android Test ایجاد می کند. این تغییرات به توسعه دهندگان کمک می کند تا از API های عمومی با پشتیبانی از چارچوب استفاده کنند، اما این تغییرات همچنین به انعطاف پذیری بیشتری در ساخت و اجرای آزمایش ها با استفاده از کتابخانه های شخص ثالث یا منطق سفارشی اجازه می دهد.

کتابخانه ها از چارچوب حذف شدند

Android 9 کلاس‌های مبتنی بر JUnit را در سه کتابخانه سازماندهی مجدد می‌کند: android.test.base ، android.test.runner و android.test.mock . این تغییر به شما امکان می‌دهد آزمایش‌هایی را بر روی نسخه‌ای از JUnit اجرا کنید که با وابستگی‌های پروژه شما بهترین کار را دارد. این نسخه از JUnit ممکن است با نسخه ای که android.jar ارائه می دهد متفاوت باشد.

برای کسب اطلاعات بیشتر درباره نحوه سازماندهی کلاس‌های مبتنی بر JUnit در این کتابخانه‌ها، و همچنین نحوه آماده‌سازی پروژه برنامه‌تان برای نوشتن و اجرای آزمایش‌ها، به راه‌اندازی پروژه برای تست Android مراجعه کنید.

آزمایش تغییرات ساخت مجموعه

متد addRequirements() در کلاس TestSuiteBuilder حذف شده است و خود کلاس TestSuiteBuilder منسوخ شده است. متد addRequirements() توسعه دهندگان را ملزم به ارائه آرگومان هایی می کرد که انواع آنها API های مخفی هستند و باعث می شود API نامعتبر باشد.

رسیور جاوا UTF

UTF-8 مجموعه نویسه های پیش فرض در اندروید است. یک دنباله بایت UTF-8 را می توان توسط یک سازنده String ، مانند String(byte[] bytes) رمزگشایی کرد.

رمزگشای UTF-8 در اندروید 9 از استانداردهای یونیکد با دقت بیشتری نسبت به نسخه های قبلی پیروی می کند. تغییرات شامل موارد زیر است:

• غیرکوتاه ترین شکل UTF-8، مانند <C0, AF> ، به عنوان بد شکل تلقی می شود.
• شکل جانشین UTF-8، مانند U+D800 .. U+DFFF ، به عنوان بد شکل تلقی می شود.
• بخش فرعی حداکثر با یک واحد U+FFFD جایگزین می‌شود. به عنوان مثال، در دنباله بایت " 41 C0 AF 41 F4 80 80 41 "، بیشترین قسمت های فرعی " C0 "، " AF " و " F4 80 80 " هستند. " F4 80 80 " می تواند زیر دنباله اولیه " F4 80 80 80 " باشد، اما " C0 " نمی تواند دنباله ابتدایی هر دنباله واحد کد به خوبی شکل گرفته باشد. بنابراین، خروجی باید " A\ufffd\ufffdA\ufffdA " باشد.
• برای رمزگشایی یک دنباله UTF-8 / CESU-8 اصلاح شده در Android 9 یا بالاتر، از متد DataInputStream.readUTF() یا روش NewStringUTF() JNI استفاده کنید.

تأیید نام میزبان با استفاده از گواهی

RFC 2818 دو روش را برای تطبیق یک نام دامنه با یک گواهی توصیف می کند - با استفاده از نام های موجود در پسوند subjectAltName ( SAN ) یا در صورت عدم وجود پسوند SAN ، بازگشت به commonName ( CN ).

با این حال، بازگشت به CN در RFC 2818 منسوخ شد. به همین دلیل، Android دیگر به استفاده از CN برنمی‌گردد. برای تأیید نام میزبان، سرور باید یک گواهی با SAN منطبق ارائه دهد. گواهینامه هایی که حاوی SAN مطابق با نام میزبان نیستند، دیگر قابل اعتماد نیستند.

جستجوی آدرس شبکه می تواند باعث نقض شبکه شود

جستجوی آدرس شبکه که نیاز به تفکیک نام دارد می‌تواند شامل I/O شبکه باشد و بنابراین عملیات مسدود کردن در نظر گرفته می‌شود. عملیات مسدود کردن روی رشته اصلی می تواند باعث مکث یا jank شود.

کلاس StrictMode یک ابزار توسعه است که به توسعه دهندگان کمک می کند تا مشکلات موجود در کد خود را شناسایی کنند.

در Android 9 و بالاتر، StrictMode نقض‌های شبکه ناشی از جستجوی آدرس شبکه را که به وضوح نام نیاز دارند، شناسایی می‌کند.

شما نباید برنامه های خود را با فعال بودن StrictMode ارسال کنید. اگر این کار را انجام دهید، برنامه‌های شما می‌توانند استثناهایی مانند NetworkOnMainThreadException را هنگام استفاده از روش‌های detectNetwork() یا detectAll() برای دریافت خط‌مشی که نقض‌های شبکه را شناسایی می‌کند، تجربه کنند.

حل یک آدرس IP عددی یک عملیات مسدود کردن در نظر گرفته نمی شود. وضوح آدرس IP عددی مانند نسخه های قبل از اندروید 9 کار می کند.

برچسب گذاری سوکت

در نسخه‌های پلتفرم پایین‌تر از اندروید 9، اگر سوکتی با استفاده از متد setThreadStatsTag() برچسب‌گذاری شود، زمانی که سوکت با استفاده از IPC بایندر با ظرف ParcelFileDescriptor به فرآیند دیگری ارسال می‌شود، برچسب‌گذاری نمی‌شود.

در اندروید 9 و بالاتر، تگ سوکت زمانی که با استفاده از بایندر IPC به فرآیند دیگری ارسال می‌شود، حفظ می‌شود. این تغییر می تواند بر آمار ترافیک شبکه تأثیر بگذارد، به عنوان مثال، هنگام استفاده از متد queryDetailsForUidTag() .

اگر می‌خواهید رفتار نسخه‌های قبلی را حفظ کنید، که سوکتی را که به فرآیند دیگری فرستاده می‌شود حذف می‌کند، می‌توانید قبل از ارسال سوکت untagSocket() را فراخوانی کنید.

مقدار بایت های موجود در سوکت گزارش شده است

متد available() پس از فراخوانی متد shutdownInput() 0 برمی گرداند.

گزارش دقیق تر قابلیت های شبکه برای VPN ها

در Android 8.1 (سطح API 27) و پایین‌تر، کلاس NetworkCapabilities فقط مجموعه محدودی از اطلاعات را برای VPN‌ها، مانند TRANSPORT_VPN گزارش می‌کند، اما NET_CAPABILITY_NOT_VPN را حذف می‌کند. این اطلاعات محدود، تعیین اینکه آیا استفاده از VPN می‌تواند هزینه‌هایی را برای کاربر برنامه به همراه داشته باشد، دشوار می‌کرد. به عنوان مثال، بررسی NET_CAPABILITY_NOT_METERED تعیین نمی کند که آیا شبکه های اصلی اندازه گیری شده اند یا خیر.

در اندروید 9 و بالاتر، وقتی یک VPN متد setUnderlyingNetworks() فراخوانی می‌کند، سیستم Android انتقال‌ها و قابلیت‌های هر شبکه زیربنایی را ادغام می‌کند و نتیجه را به عنوان قابلیت‌های شبکه موثر شبکه VPN برمی‌گرداند.

در Android 9 و بالاتر، برنامه‌هایی که قبلاً NET_CAPABILITY_NOT_METERED را بررسی می‌کنند، قابلیت‌های شبکه VPN و شبکه‌های زیربنایی را دریافت می‌کنند.

فایل‌های موجود در پوشه xt_qtaguid دیگر در دسترس برنامه‌ها نیستند

با شروع اندروید 9، برنامه‌ها اجازه دسترسی خواندن مستقیم به فایل‌های موجود در پوشه /proc/net/xt_qtaguid را ندارند. دلیل آن اطمینان از سازگاری با برخی از دستگاه هایی است که اصلاً این فایل ها را ندارند.

API های عمومی که به این فایل ها متکی هستند، TrafficStats و NetworkStatsManager ، همچنان به کار خود ادامه می دهند. با این حال، توابع cutils پشتیبانی‌نشده، مانند qtaguid_tagSocket() ممکن است آنطور که انتظار می‌رود – یا اصلاً – در دستگاه‌های مختلف کار نکنند.

الزام FLAG_ACTIVITY_NEW_TASK اکنون اجرا می شود

با Android 9، نمی‌توانید فعالیتی را از یک زمینه غیرفعالی شروع کنید، مگر اینکه پرچم قصد FLAG_ACTIVITY_NEW_TASK را پاس کنید. اگر بخواهید بدون عبور از این پرچم فعالیتی را شروع کنید، فعالیت شروع نمی شود و سیستم پیامی را در گزارش چاپ می کند.

چرخش صفحه نمایش تغییر می کند

با شروع اندروید 9، تغییرات قابل توجهی در حالت چرخش پرتره وجود دارد. در اندروید 8.0 (سطح API 26)، کاربران می‌توانند با استفاده از کاشی تنظیمات سریع یا تنظیمات نمایش، بین حالت‌های چرخش خودکار و چرخش عمودی جابه‌جا شوند. حالت عمودی به قفل چرخشی تغییر نام داده است و هنگامی که چرخش خودکار خاموش شود فعال است. هیچ تغییری در حالت چرخش خودکار وجود ندارد.

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

فعالیت‌هایی که جهت‌گیری خاصی را درخواست می‌کنند (مثلاً screenOrientation=landscape )، اولویت قفل کاربر را نادیده می‌گیرند و مانند Android 8.0 رفتار می‌کنند.

تنظیمات ترجیحی جهت صفحه را می توان در سطح Activity در مانیفست Android یا به صورت برنامه نویسی با setRequestedOrientation () تنظیم کرد.

حالت قفل چرخش با تنظیم اولویت چرخش کاربر که WindowManager هنگام مدیریت چرخش فعالیت استفاده می کند، کار می کند. ترجیح چرخش کاربر ممکن است در موارد زیر تغییر کند. توجه داشته باشید که یک سوگیری برای بازگشت به چرخش طبیعی دستگاه وجود دارد که معمولاً برای دستگاه‌های فاکتور فرم تلفن به صورت عمودی است:

• هنگامی که کاربر یک پیشنهاد چرخش را می پذیرد، اولویت چرخش به پیشنهاد تغییر می کند.
• وقتی کاربر به یک برنامه پرتره اجباری (شامل صفحه قفل یا راه‌انداز) سوئیچ می‌کند، اولویت چرخش به حالت عمودی تغییر می‌کند.

جدول زیر رفتار چرخش را برای جهت گیری های رایج صفحه نمایش خلاصه می کند:

منسوخ شدن سرویس گیرنده Apache HTTP بر برنامه های دارای ClassLoader غیر استاندارد تأثیر می گذارد

با Android 6.0، پشتیبانی از سرویس گیرنده Apache HTTP را حذف کردیم . این تغییر روی اکثر برنامه‌هایی که اندروید 9 یا بالاتر را هدف قرار نمی‌دهند، تأثیری ندارد. با این حال، این تغییر می‌تواند بر برنامه‌های خاصی که از ساختار ClassLoader غیراستاندارد استفاده می‌کنند، تأثیر بگذارد، حتی اگر برنامه‌ها Android 9 یا بالاتر را هدف قرار ندهند.

اگر یک برنامه از ClassLoader غیر استانداردی استفاده کند که صریحاً به سیستم ClassLoader محول می شود، ممکن است تحت تأثیر قرار گیرد. این برنامه‌ها باید در عوض وقتی به دنبال کلاس‌ها در org.apache.http.* به برنامه ClassLoader واگذار شوند. اگر آنها را به سیستم ClassLoader واگذار کنند، برنامه‌ها در Android 9 یا بالاتر با NoClassDefFoundError از کار می‌افتند، زیرا آن کلاس‌ها دیگر برای ClassLoader سیستم شناخته نمی‌شوند. برای جلوگیری از مشکلات مشابه در آینده، برنامه ها به طور کلی باید کلاس ها را از طریق برنامه ClassLoader بارگیری کنند نه اینکه مستقیماً به ClassLoader سیستم دسترسی داشته باشند.

شمارش دوربین ها

برنامه‌هایی که روی دستگاه‌های Android 9 اجرا می‌شوند می‌توانند با فراخوانی getCameraIdList() هر دوربین موجود را پیدا کنند. یک برنامه نباید تصور کند که دستگاه فقط یک دوربین پشتی یا فقط یک دوربین جلو دارد.

برای مثال، اگر برنامه شما دکمه ای برای جابجایی بین دوربین جلو و عقب دارد، ممکن است بیش از یک دوربین جلو یا عقب برای انتخاب وجود داشته باشد. شما باید فهرست دوربین را طی کنید، ویژگی های هر دوربین را بررسی کنید و تصمیم بگیرید که کدام دوربین را در معرض دید کاربر قرار دهید.

اندروید 9 (سطح API 28) تعدادی تغییرات را در سیستم اندروید معرفی می کند. تغییرات رفتاری زیر برای همه برنامه‌ها وقتی روی پلتفرم Android 9 اجرا می‌شوند، صرف‌نظر از سطح API مورد نظرشان اعمال می‌شود. همه توسعه‌دهندگان باید این تغییرات را بررسی کرده و برنامه‌های خود را تغییر دهند تا در صورت لزوم، به درستی از آنها پشتیبانی کنند.

برای تغییراتی که فقط بر برنامه‌هایی تأثیر می‌گذارند که سطح API 28 یا بالاتر را هدف قرار می‌دهند، به تغییرات رفتار: برنامه‌هایی که API سطح 28+ را هدف قرار می‌دهند، مراجعه کنید.

مدیریت نیرو

اندروید 9 ویژگی های جدیدی را برای بهبود مدیریت انرژی دستگاه معرفی می کند. این تغییرات، همراه با ویژگی‌هایی که قبلاً قبل از اندروید 9 وجود داشت، کمک می‌کند تا اطمینان حاصل شود که منابع سیستم در دسترس برنامه‌هایی قرار می‌گیرد که بیشتر به آن‌ها نیاز دارند.

برای جزئیات، به مدیریت نیرو مراجعه کنید.

حریم خصوصی تغییر می کند

برای افزایش حریم خصوصی کاربر، اندروید 9 چندین تغییر رفتاری را معرفی می‌کند، مانند محدود کردن دسترسی برنامه‌های پس‌زمینه به حسگرهای دستگاه، محدود کردن اطلاعات بازیابی شده از اسکن‌های Wi-Fi، و قوانین جدید مجوز و گروه‌های مجوز مربوط به تماس‌های تلفنی، وضعیت تلفن و Wi- اسکن Fi

این تغییرات بدون در نظر گرفتن نسخه SDK هدف، بر تمام برنامه های اجرا شده در اندروید 9 تأثیر می گذارد.

دسترسی محدود به حسگرها در پس زمینه

اندروید 9 امکان دسترسی برنامه‌های پس‌زمینه به ورودی‌های کاربر و داده‌های حسگر را محدود می‌کند. اگر برنامه شما در پس‌زمینه دستگاهی با Android 9 اجرا می‌شود، سیستم محدودیت‌های زیر را برای برنامه شما اعمال می‌کند:

• برنامه شما نمی تواند به میکروفون یا دوربین دسترسی پیدا کند.
• حسگرهایی که از حالت گزارش مداوم استفاده می کنند، مانند شتاب سنج و ژیروسکوپ، رویدادها را دریافت نمی کنند.
• حسگرهایی که از حالت‌های گزارش لحظه‌ای یا یک‌شات استفاده می‌کنند، رویدادها را دریافت نمی‌کنند.

اگر برنامه شما نیاز به تشخیص رویدادهای حسگر در دستگاه‌های دارای Android 9 دارد، از سرویس پیش‌زمینه استفاده کنید.

دسترسی محدود به گزارش تماس ها

Android 9 گروه مجوز CALL_LOG را معرفی می‌کند و مجوزهای READ_CALL_LOG ، WRITE_CALL_LOG و PROCESS_OUTGOING_CALLS را به این گروه منتقل می‌کند. در نسخه های قبلی اندروید، این مجوزها در گروه مجوز PHONE قرار داشتند.

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

اگر برنامه شما نیاز به دسترسی به گزارش تماس دارد یا نیاز به پردازش تماس‌های خروجی دارد، باید این مجوزها را صریحاً از گروه مجوز CALL_LOG درخواست کنید. در غیر این صورت، یک SecurityException رخ می دهد.

دسترسی محدود به شماره تلفن

برنامه‌هایی که روی Android 9 اجرا می‌شوند، نمی‌توانند شماره تلفن یا وضعیت تلفن را بدون دریافت مجوز READ_CALL_LOG ، بعلاوه سایر مجوزهایی که موارد استفاده برنامه شما به آن نیاز دارند، بخوانند.

شماره‌های تلفن مرتبط با تماس‌های ورودی و خروجی در پخش وضعیت تلفن ، مانند تماس‌های ورودی و خروجی، قابل مشاهده هستند و از کلاس PhoneStateListener قابل دسترسی هستند. با این حال، بدون مجوز READ_CALL_LOG ، قسمت شماره تلفن ارائه شده در پخش‌های PHONE_STATE_CHANGED و از طریق PhoneStateListener خالی است.

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

• برای خواندن اعداد از اقدام قصد PHONE_STATE ، هم به مجوز READ_CALL_LOG و هم به مجوز READ_PHONE_STATE نیاز دارید.
• برای خواندن اعداد از onCallStateChanged() فقط به مجوز READ_CALL_LOG نیاز دارید. شما به مجوز READ_PHONE_STATE نیاز ندارید.

دسترسی محدود به مکان Wi-Fi و اطلاعات اتصال

در اندروید 9، الزامات مجوز برای یک برنامه برای انجام اسکن وای فای سخت تر از نسخه های قبلی است. برای جزئیات، محدودیت‌های اسکن Wi-Fi را ببینید.

محدودیت‌های مشابهی برای متد getConnectionInfo() نیز اعمال می‌شود که یک شی WifiInfo را که اتصال Wi-Fi فعلی را توصیف می‌کند، برمی‌گرداند. فقط در صورتی می‌توانید از روش‌های این شی برای بازیابی مقادیر SSID و BSSID استفاده کنید که برنامه تماس‌گیرنده مجوزهای زیر را داشته باشد:

• ACCESS_FINE_LOCATION یا ACCESS_COARSE_LOCATION
• ACCESS_WIFI_STATE

برای بازیابی SSID یا BSSID نیز باید خدمات مکان در دستگاه فعال شود (در زیر تنظیمات > مکان ).

اطلاعات از روش‌های سرویس Wi-Fi حذف شد

در Android 9، رویدادها و پخش‌های زیر اطلاعاتی درباره موقعیت مکانی کاربر یا داده‌های قابل شناسایی شخصی دریافت نمی‌کنند:

• متدهای getScanResults() و getConnectionInfo() از WifiManager .
• متدهای discoverServices() و addServiceRequest() از WifiP2pManager .
• پخش NETWORK_STATE_CHANGED_ACTION .

سیستم NETWORK_STATE_CHANGED_ACTION که از Wi-Fi پخش می‌شود، دیگر حاوی SSID (قبلا EXTRA_SSID)، BSSID (قبلا EXTRA_BSSID) یا اطلاعات اتصال (قبلاً EXTRA_NETWORK_INFO) نیست. اگر برنامه شما به این اطلاعات نیاز دارد، به جای آن با getConnectionInfo() تماس بگیرید.

اطلاعات تلفن اکنون به تنظیمات مکان دستگاه متکی است

اگر کاربر مکان دستگاه را در دستگاهی که Android 9 دارد غیرفعال کرده باشد، روش‌های زیر نتیجه‌ای را ارائه نمی‌دهند:

• getAllCellInfo()
• listen()
• getCellLocation()
• getNeighboringCellInfo()

محدودیت در استفاده از رابط های غیر SDK

برای کمک به اطمینان از ثبات و سازگاری برنامه، پلتفرم استفاده از برخی روش‌ها و زمینه‌های غیر SDK را محدود می‌کند. این محدودیت‌ها اعمال می‌شوند چه بخواهید مستقیماً به این روش‌ها و فیلدها دسترسی داشته باشید، از طریق بازتاب یا با استفاده از JNI. در Android 9، برنامه شما می‌تواند همچنان به این رابط‌های محدود دسترسی داشته باشد. این پلتفرم از نان تست ها و ورودی های گزارش استفاده می کند تا توجه شما را جلب کند. اگر برنامه شما چنین نان تستی را نشان می دهد، مهم است که استراتژی پیاده سازی دیگری غیر از رابط کاربری محدود را دنبال کنید. اگر فکر می کنید که هیچ استراتژی جایگزینی امکان پذیر نیست، می توانید یک اشکال را برای درخواست تجدید نظر در محدودیت ارسال کنید.

محدودیت‌ها در رابط‌های غیر SDK حاوی اطلاعات مهم دیگری است. باید آن را بررسی کنید تا مطمئن شوید که برنامه شما به درستی کار می کند.

رفتار امنیتی تغییر می کند

تغییرات امنیتی دستگاه

Android 9 چندین قابلیت اضافه می کند که امنیت برنامه شما را بهبود می بخشد، صرف نظر از اینکه برنامه شما کدام نسخه را هدف قرار می دهد.

تغییرات پیاده سازی TLS

پیاده سازی TLS سیستم در اندروید 9 دستخوش تغییرات زیادی شده است:

• اگر نمونه ای از SSLSocket در حین ایجاد اتصال نتواند، سیستم یک IOException به جای NullPointerException پرتاب می کند.
• کلاس SSLEngine به طور تمیز با هر هشدار close_notify که رخ می دهد کنترل می کند.

برای کسب اطلاعات بیشتر در مورد ایجاد درخواست های وب ایمن در یک برنامه Android، یک مثال HTTPS را ببینید.

فیلتر SECCOMP دقیق تر

اندروید 9 تماس‌های سیستمی را که برای برنامه‌ها در دسترس است محدودتر می‌کند. این رفتار یک برنامه افزودنی از فیلتر SECCOMP است که Android 8.0 (سطح API 26) شامل می شود .

تغییرات رمزنگاری

اندروید 9 تغییرات زیادی را در پیاده سازی و مدیریت الگوریتم های رمزنگاری ایجاد می کند.

پیاده سازی پارامترها و الگوریتم ها را رمزگذاری کنید

اندروید 9 پیاده سازی های اضافی پارامترهای الگوریتم را در Conscrypt ارائه می دهد. این پارامترها عبارتند از: AES، DESEDE، OAEP و EC. نسخه‌های Bouncy Castle این پارامترها و بسیاری از الگوریتم‌ها از اندروید 9 منسوخ شده‌اند.

اگر برنامه شما Android 8.1 (سطح API 27) یا پایین‌تر را هدف قرار می‌دهد، هنگام درخواست اجرای Bouncy Castle از یکی از این الگوریتم‌های منسوخ، هشداری دریافت می‌کنید. با این حال، اگر اندروید 9 را هدف قرار دهید، هر یک از این درخواست‌ها یک NoSuchAlgorithmException می‌دهند.

تغییرات دیگر

اندروید 9 چندین تغییر دیگر مرتبط با رمزنگاری را معرفی می کند:

• هنگام استفاده از کلیدهای PBE، اگر Bouncy Castle منتظر یک بردار اولیه (IV) باشد و برنامه شما یکی را ارائه نکند، یک هشدار دریافت می‌کنید.
• اجرای Conscrypt رمز ARC4 به شما امکان می دهد ARC4/ECB/NoPadding یا ARC4/NONE/NoPadding را مشخص کنید.
• ارائه دهنده Crypto Java Cryptography Architecture (JCA) حذف شده است. در نتیجه، اگر برنامه شما SecureRandom.getInstance("SHA1PRNG", "Crypto") را فراخوانی کند، یک NoSuchProviderException رخ می دهد.
• اگر برنامه شما کلیدهای RSA را از بافرهایی که بزرگتر از ساختار کلید هستند تجزیه کند، دیگر استثنایی رخ نخواهد داد.

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

فایل‌های رمزگذاری شده امن Android دیگر پشتیبانی نمی‌شوند

اندروید 9 به طور کامل پشتیبانی از فایل های رمزگذاری شده ایمن اندروید (ASEC) را حذف می کند.

در Android 2.2 (سطح API 8)، اندروید ASEC ها را برای پشتیبانی از عملکرد برنامه ها روی کارت SD معرفی کرد. در Android 6.0 (سطح API 23)، این پلتفرم یک فناوری دستگاه ذخیره سازی قابل قبول را معرفی کرد که توسعه دهندگان می توانند به جای ASEC از آن استفاده کنند.

به روز رسانی کتابخانه های ICU

اندروید 9 از نسخه 60 کتابخانه ICU استفاده می کند. اندروید 8.0 (سطح API 26) و اندروید 8.1 (سطح API 27) از ICU 58 استفاده می کنند.

ICU برای ارائه APIهای عمومی در زیر android.icu package استفاده می شود و به صورت داخلی در پلتفرم Android برای پشتیبانی بین المللی استفاده می شود. به عنوان مثال، برای پیاده سازی کلاس های اندروید در java.util ، java.text و android.text.format استفاده می شود.

به‌روزرسانی ICU 60 شامل بسیاری از تغییرات کوچک اما مفید است، از جمله پشتیبانی از داده‌های Emoji 5.0 و فرمت‌های تاریخ/زمان بهبود یافته، همانطور که در یادداشت‌های انتشار ICU 59 و ICU 60 مستند شده است.

تغییرات قابل توجه در این به روز رسانی:

• نحوه مدیریت این پلتفرم با مناطق زمانی تغییر کرده است.
  • پلتفرم GMT و UTC را بهتر مدیریت می کند. UTC دیگر مترادف GMT نیست.

    ICU اکنون نام مناطق ترجمه شده را برای GMT ​​و UTC ارائه می دهد. این تغییر قالب‌بندی android.icu و رفتار تجزیه را برای مناطقی مانند "GMT"، "Etc/GMT"، "UTC"، "Etc/UTC" و "Zulu" تحت تاثیر قرار می‌دهد.

  • java.text.SimpleDateFormat اکنون از ICU برای ارائه نام های نمایشی برای UTC /GMT استفاده می کند، به این معنی:
    • قالب بندی zzzz یک رشته محلی طولانی برای بسیاری از مناطق ایجاد می کند. قبلاً "UTC" برای UTC و رشته هایی مانند "GMT+00:00" برای GMT ​​تولید می کرد.
    • تجزیه zzzz رشته هایی مانند "زمان هماهنگ جهانی" و "زمان میانگین گرینویچ" را تشخیص می دهد.
    • اگر برنامه‌ها فرض کنند که «UTC» یا «GMT+00:00» برای zzzz در همه زبان‌ها خروجی دارند، ممکن است با مشکلات سازگاری مواجه شوند.
  • رفتار java.text.DateFormatSymbols.getZoneStrings() تغییر کرده است:
    • همانند SimpleDateFormat ، UTC و GMT اکنون نام های طولانی دارند. انواع DST نام‌های منطقه زمانی برای منطقه UTC، مانند "UTC"، "Etc/UTC" و "Zulu" به GMT+00:00 تبدیل می‌شوند، که زمانی که نامی در دسترس نباشد، بازگشتی استاندارد است. رشته کد سخت UTC .
    • برخی از شناسه‌های ناحیه به درستی به‌عنوان مترادف مناطق دیگر شناخته می‌شوند، بنابراین Android رشته‌هایی را برای شناسه‌های منطقه قدیمی، مانند Eire پیدا می‌کند که قبلاً قابل حل نبودند.
  • آسیا/هانوی دیگر یک منطقه شناخته شده نیست. به همین دلیل java.util.TimeZones.getAvailableIds() این مقدار را بر نمی گرداند و java.util.TimeZone.getTimeZone() آن را تشخیص نمی دهد. این رفتار با رفتار android.icu موجود مطابقت دارد.
• روش android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) ممکن است حتی در هنگام تجزیه متن ارز قانونی، یک ParseException ایجاد کند. با استفاده از NumberFormat.parseCurrency ، که از Android نسخه 7.0 (سطح API 24) برای متن ارز به سبک PLURALCURRENCYSTYLE در دسترس است، از این مشکل جلوگیری کنید.

تغییرات تست اندروید

اندروید 9 تغییرات متعددی را در ساختار کتابخانه و کلاس چارچوب Android Test ایجاد می کند. این تغییرات به توسعه دهندگان کمک می کند تا از API های عمومی با پشتیبانی از چارچوب استفاده کنند، اما این تغییرات همچنین به انعطاف پذیری بیشتری در ساخت و اجرای آزمایش ها با استفاده از کتابخانه های شخص ثالث یا منطق سفارشی اجازه می دهد.

کتابخانه ها از چارچوب حذف شدند

Android 9 کلاس‌های مبتنی بر JUnit را در سه کتابخانه سازماندهی مجدد می‌کند: android.test.base ، android.test.runner و android.test.mock . این تغییر به شما امکان می‌دهد آزمایش‌هایی را بر روی نسخه‌ای از JUnit اجرا کنید که با وابستگی‌های پروژه شما بهترین کار را دارد. این نسخه از JUnit ممکن است با نسخه ای که android.jar ارائه می دهد متفاوت باشد.

برای کسب اطلاعات بیشتر درباره نحوه سازماندهی کلاس‌های مبتنی بر JUnit در این کتابخانه‌ها، و همچنین نحوه آماده‌سازی پروژه برنامه‌تان برای نوشتن و اجرای آزمایش‌ها، به راه‌اندازی پروژه برای تست Android مراجعه کنید.

آزمایش تغییرات ساخت مجموعه

متد addRequirements() در کلاس TestSuiteBuilder حذف شده است و خود کلاس TestSuiteBuilder منسوخ شده است. متد addRequirements() توسعه دهندگان را ملزم به ارائه آرگومان هایی می کرد که انواع آنها API های مخفی هستند و باعث می شود API نامعتبر باشد.

رسیور جاوا UTF

UTF-8 مجموعه نویسه های پیش فرض در اندروید است. یک دنباله بایت UTF-8 را می توان توسط یک سازنده String ، مانند String(byte[] bytes) رمزگشایی کرد.

رمزگشای UTF-8 در اندروید 9 از استانداردهای یونیکد با دقت بیشتری نسبت به نسخه های قبلی پیروی می کند. تغییرات شامل موارد زیر است:

• غیرکوتاه ترین شکل UTF-8، مانند <C0, AF> ، به عنوان بد شکل تلقی می شود.
• شکل جانشین UTF-8، مانند U+D800 .. U+DFFF ، به عنوان بد شکل تلقی می شود.
• بخش فرعی حداکثر با یک واحد U+FFFD جایگزین می‌شود. به عنوان مثال، در دنباله بایت " 41 C0 AF 41 F4 80 80 41 "، بیشترین قسمت های فرعی " C0 "، " AF " و " F4 80 80 " هستند. " F4 80 80 " می تواند زیر دنباله اولیه " F4 80 80 80 " باشد، اما " C0 " نمی تواند دنباله ابتدایی هر دنباله واحد کد به خوبی شکل گرفته باشد. بنابراین، خروجی باید " A\ufffd\ufffdA\ufffdA " باشد.
• برای رمزگشایی یک دنباله UTF-8 / CESU-8 اصلاح شده در Android 9 یا بالاتر، از متد DataInputStream.readUTF() یا روش NewStringUTF() JNI استفاده کنید.

تأیید نام میزبان با استفاده از گواهی

RFC 2818 دو روش را برای تطبیق یک نام دامنه با یک گواهی توصیف می کند - با استفاده از نام های موجود در پسوند subjectAltName ( SAN ) یا در صورت عدم وجود پسوند SAN ، بازگشت به commonName ( CN ).

با این حال، بازگشت به CN در RFC 2818 منسوخ شد. به همین دلیل، Android دیگر به استفاده از CN برنمی‌گردد. برای تأیید نام میزبان، سرور باید یک گواهی با SAN منطبق ارائه دهد. گواهینامه هایی که حاوی SAN مطابق با نام میزبان نیستند، دیگر قابل اعتماد نیستند.

جستجوی آدرس شبکه می تواند باعث نقض شبکه شود

جستجوی آدرس شبکه که نیاز به تفکیک نام دارد می‌تواند شامل I/O شبکه باشد و بنابراین عملیات مسدود کردن در نظر گرفته می‌شود. عملیات مسدود کردن روی رشته اصلی می تواند باعث مکث یا jank شود.

کلاس StrictMode یک ابزار توسعه است که به توسعه دهندگان کمک می کند تا مشکلات موجود در کد خود را شناسایی کنند.

در Android 9 و بالاتر، StrictMode نقض‌های شبکه ناشی از جستجوی آدرس شبکه را که به وضوح نام نیاز دارند، شناسایی می‌کند.

شما نباید برنامه های خود را با فعال بودن StrictMode ارسال کنید. اگر این کار را انجام دهید، برنامه‌های شما می‌توانند استثناهایی مانند NetworkOnMainThreadException را هنگام استفاده از روش‌های detectNetwork() یا detectAll() برای دریافت خط‌مشی که نقض‌های شبکه را شناسایی می‌کند، تجربه کنند.

حل یک آدرس IP عددی یک عملیات مسدود کردن در نظر گرفته نمی شود. وضوح آدرس IP عددی مانند نسخه های قبل از اندروید 9 کار می کند.

برچسب گذاری سوکت

در نسخه‌های پلتفرم پایین‌تر از اندروید 9، اگر سوکتی با استفاده از متد setThreadStatsTag() برچسب‌گذاری شود، زمانی که سوکت با استفاده از IPC بایندر با ظرف ParcelFileDescriptor به فرآیند دیگری ارسال می‌شود، برچسب‌گذاری نمی‌شود.

در اندروید 9 و بالاتر، تگ سوکت زمانی که با استفاده از بایندر IPC به فرآیند دیگری ارسال می‌شود، حفظ می‌شود. این تغییر می تواند بر آمار ترافیک شبکه تأثیر بگذارد، به عنوان مثال، هنگام استفاده از متد queryDetailsForUidTag() .

اگر می‌خواهید رفتار نسخه‌های قبلی را حفظ کنید، که سوکتی را که به فرآیند دیگری فرستاده می‌شود حذف می‌کند، می‌توانید قبل از ارسال سوکت untagSocket() را فراخوانی کنید.

مقدار بایت های موجود در سوکت گزارش شده است

متد available() پس از فراخوانی متد shutdownInput() 0 برمی گرداند.

گزارش دقیق تر قابلیت های شبکه برای VPN ها

در Android 8.1 (سطح API 27) و پایین‌تر، کلاس NetworkCapabilities فقط مجموعه محدودی از اطلاعات را برای VPN‌ها، مانند TRANSPORT_VPN گزارش می‌کند، اما NET_CAPABILITY_NOT_VPN را حذف می‌کند. این اطلاعات محدود، تعیین اینکه آیا استفاده از VPN می‌تواند هزینه‌هایی را برای کاربر برنامه به همراه داشته باشد، دشوار می‌کرد. به عنوان مثال، بررسی NET_CAPABILITY_NOT_METERED تعیین نمی کند که آیا شبکه های اصلی اندازه گیری شده اند یا خیر.

در اندروید 9 و بالاتر، وقتی یک VPN متد setUnderlyingNetworks() فراخوانی می‌کند، سیستم Android انتقال‌ها و قابلیت‌های هر شبکه زیربنایی را ادغام می‌کند و نتیجه را به عنوان قابلیت‌های شبکه موثر شبکه VPN برمی‌گرداند.

در Android 9 و بالاتر، برنامه‌هایی که قبلاً NET_CAPABILITY_NOT_METERED را بررسی می‌کنند، قابلیت‌های شبکه VPN و شبکه‌های زیربنایی را دریافت می‌کنند.

فایل‌های موجود در پوشه xt_qtaguid دیگر در دسترس برنامه‌ها نیستند

با شروع اندروید 9، برنامه‌ها اجازه دسترسی خواندن مستقیم به فایل‌های موجود در پوشه /proc/net/xt_qtaguid را ندارند. دلیل آن اطمینان از سازگاری با برخی از دستگاه هایی است که اصلاً این فایل ها را ندارند.

API های عمومی که به این فایل ها متکی هستند، TrafficStats و NetworkStatsManager ، همچنان به کار خود ادامه می دهند. با این حال، توابع cutils پشتیبانی‌نشده، مانند qtaguid_tagSocket() ممکن است آنطور که انتظار می‌رود – یا اصلاً – در دستگاه‌های مختلف کار نکنند.

الزام FLAG_ACTIVITY_NEW_TASK اکنون اجرا می شود

با Android 9، نمی‌توانید فعالیتی را از یک زمینه غیرفعالی شروع کنید، مگر اینکه پرچم قصد FLAG_ACTIVITY_NEW_TASK را پاس کنید. اگر بخواهید بدون عبور از این پرچم فعالیتی را شروع کنید، فعالیت شروع نمی شود و سیستم پیامی را در گزارش چاپ می کند.

چرخش صفحه نمایش تغییر می کند

با شروع اندروید 9، تغییرات قابل توجهی در حالت چرخش پرتره وجود دارد. در اندروید 8.0 (سطح API 26)، کاربران می‌توانند با استفاده از کاشی تنظیمات سریع یا تنظیمات نمایش، بین حالت‌های چرخش خودکار و چرخش عمودی جابه‌جا شوند. حالت عمودی به قفل چرخشی تغییر نام داده است و هنگامی که چرخش خودکار خاموش شود فعال است. هیچ تغییری در حالت چرخش خودکار وجود ندارد.

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

فعالیت‌هایی که جهت‌گیری خاصی را درخواست می‌کنند (مثلاً screenOrientation=landscape )، اولویت قفل کاربر را نادیده می‌گیرند و مانند Android 8.0 رفتار می‌کنند.

تنظیمات ترجیحی جهت صفحه را می توان در سطح Activity در مانیفست Android یا به صورت برنامه نویسی با setRequestedOrientation () تنظیم کرد.

حالت قفل چرخش با تنظیم اولویت چرخش کاربر که WindowManager هنگام مدیریت چرخش فعالیت استفاده می کند، کار می کند. ترجیح چرخش کاربر ممکن است در موارد زیر تغییر کند. توجه داشته باشید که یک سوگیری برای بازگشت به چرخش طبیعی دستگاه وجود دارد که معمولاً برای دستگاه‌های فاکتور فرم تلفن به صورت عمودی است:

• هنگامی که کاربر یک پیشنهاد چرخش را می پذیرد، اولویت چرخش به پیشنهاد تغییر می کند.
• وقتی کاربر به یک برنامه پرتره اجباری (شامل صفحه قفل یا راه‌انداز) سوئیچ می‌کند، اولویت چرخش به حالت عمودی تغییر می‌کند.

جدول زیر رفتار چرخش را برای جهت گیری های رایج صفحه نمایش خلاصه می کند:

منسوخ شدن سرویس گیرنده Apache HTTP بر برنامه های دارای ClassLoader غیر استاندارد تأثیر می گذارد

با Android 6.0، پشتیبانی از سرویس گیرنده Apache HTTP را حذف کردیم . این تغییر روی اکثر برنامه‌هایی که اندروید 9 یا بالاتر را هدف قرار نمی‌دهند، تأثیری ندارد. با این حال، این تغییر می‌تواند بر برنامه‌های خاصی که از ساختار ClassLoader غیراستاندارد استفاده می‌کنند، تأثیر بگذارد، حتی اگر برنامه‌ها Android 9 یا بالاتر را هدف قرار ندهند.

اگر یک برنامه از ClassLoader غیر استانداردی استفاده کند که صریحاً به سیستم ClassLoader محول می شود، ممکن است تحت تأثیر قرار گیرد. این برنامه‌ها باید در عوض وقتی به دنبال کلاس‌ها در org.apache.http.* به برنامه ClassLoader واگذار شوند. اگر آنها را به سیستم ClassLoader واگذار کنند، برنامه‌ها در Android 9 یا بالاتر با NoClassDefFoundError از کار می‌افتند، زیرا آن کلاس‌ها دیگر برای ClassLoader سیستم شناخته نمی‌شوند. برای جلوگیری از مشکلات مشابه در آینده، برنامه ها به طور کلی باید کلاس ها را از طریق برنامه ClassLoader بارگیری کنند نه اینکه مستقیماً به ClassLoader سیستم دسترسی داشته باشند.

شمارش دوربین ها

برنامه‌هایی که روی دستگاه‌های Android 9 اجرا می‌شوند می‌توانند با فراخوانی getCameraIdList() هر دوربین موجود را پیدا کنند. یک برنامه نباید تصور کند که دستگاه فقط یک دوربین پشتی یا فقط یک دوربین جلو دارد.

برای مثال، اگر برنامه شما دکمه ای برای جابجایی بین دوربین جلو و عقب دارد، ممکن است بیش از یک دوربین جلو یا عقب برای انتخاب وجود داشته باشد. شما باید فهرست دوربین را طی کنید، ویژگی های هر دوربین را بررسی کنید و تصمیم بگیرید که کدام دوربین را در معرض دید کاربر قرار دهید.

اندروید 9 (سطح API 28) تعدادی تغییرات را در سیستم اندروید معرفی می کند. تغییرات رفتاری زیر برای همه برنامه‌ها وقتی روی پلتفرم Android 9 اجرا می‌شوند، صرف‌نظر از سطح API مورد نظرشان اعمال می‌شود. همه توسعه‌دهندگان باید این تغییرات را بررسی کرده و برنامه‌های خود را تغییر دهند تا در صورت لزوم، به درستی از آنها پشتیبانی کنند.

برای تغییراتی که فقط بر برنامه‌هایی تأثیر می‌گذارند که سطح API 28 یا بالاتر را هدف قرار می‌دهند، به تغییرات رفتار: برنامه‌هایی که API سطح 28+ را هدف قرار می‌دهند، مراجعه کنید.

مدیریت نیرو

اندروید 9 ویژگی های جدیدی را برای بهبود مدیریت انرژی دستگاه معرفی می کند. این تغییرات، همراه با ویژگی‌هایی که قبلاً قبل از اندروید 9 وجود داشت، کمک می‌کند تا اطمینان حاصل شود که منابع سیستم در دسترس برنامه‌هایی قرار می‌گیرد که بیشتر به آن‌ها نیاز دارند.

برای جزئیات، به مدیریت نیرو مراجعه کنید.

حریم خصوصی تغییر می کند

برای افزایش حریم خصوصی کاربر، اندروید 9 چندین تغییر رفتاری را معرفی می‌کند، مانند محدود کردن دسترسی برنامه‌های پس‌زمینه به حسگرهای دستگاه، محدود کردن اطلاعات بازیابی شده از اسکن‌های Wi-Fi، و قوانین جدید مجوز و گروه‌های مجوز مربوط به تماس‌های تلفنی، وضعیت تلفن و Wi- اسکن Fi

این تغییرات بدون در نظر گرفتن نسخه SDK هدف، بر تمام برنامه های اجرا شده در اندروید 9 تأثیر می گذارد.

دسترسی محدود به حسگرها در پس زمینه

اندروید 9 امکان دسترسی برنامه‌های پس‌زمینه به ورودی‌های کاربر و داده‌های حسگر را محدود می‌کند. اگر برنامه شما در پس‌زمینه دستگاهی با Android 9 اجرا می‌شود، سیستم محدودیت‌های زیر را برای برنامه شما اعمال می‌کند:

• برنامه شما نمی تواند به میکروفون یا دوربین دسترسی پیدا کند.
• حسگرهایی که از حالت گزارش مداوم استفاده می کنند، مانند شتاب سنج و ژیروسکوپ، رویدادها را دریافت نمی کنند.
• حسگرهایی که از حالت‌های گزارش لحظه‌ای یا یک‌شات استفاده می‌کنند، رویدادها را دریافت نمی‌کنند.

اگر برنامه شما نیاز به تشخیص رویدادهای حسگر در دستگاه‌های دارای Android 9 دارد، از سرویس پیش‌زمینه استفاده کنید.

دسترسی محدود به گزارش تماس ها

Android 9 گروه مجوز CALL_LOG را معرفی می‌کند و مجوزهای READ_CALL_LOG ، WRITE_CALL_LOG و PROCESS_OUTGOING_CALLS را به این گروه منتقل می‌کند. در نسخه های قبلی اندروید، این مجوزها در گروه مجوز PHONE قرار داشتند.

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

اگر برنامه شما نیاز به دسترسی به گزارش تماس دارد یا نیاز به پردازش تماس‌های خروجی دارد، باید این مجوزها را صریحاً از گروه مجوز CALL_LOG درخواست کنید. در غیر این صورت، یک SecurityException رخ می دهد.

دسترسی محدود به شماره تلفن

برنامه‌هایی که روی Android 9 اجرا می‌شوند، نمی‌توانند شماره تلفن یا وضعیت تلفن را بدون دریافت مجوز READ_CALL_LOG ، بعلاوه سایر مجوزهایی که موارد استفاده برنامه شما به آن نیاز دارند، بخوانند.

شماره‌های تلفن مرتبط با تماس‌های ورودی و خروجی در پخش وضعیت تلفن ، مانند تماس‌های ورودی و خروجی، قابل مشاهده هستند و از کلاس PhoneStateListener قابل دسترسی هستند. با این حال، بدون مجوز READ_CALL_LOG ، قسمت شماره تلفن ارائه شده در پخش‌های PHONE_STATE_CHANGED و از طریق PhoneStateListener خالی است.

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

• برای خواندن اعداد از اقدام قصد PHONE_STATE ، هم به مجوز READ_CALL_LOG و هم به مجوز READ_PHONE_STATE نیاز دارید.
• برای خواندن اعداد از onCallStateChanged() فقط به مجوز READ_CALL_LOG نیاز دارید. شما به مجوز READ_PHONE_STATE نیاز ندارید.

دسترسی محدود به مکان Wi-Fi و اطلاعات اتصال

در اندروید 9، الزامات مجوز برای یک برنامه برای انجام اسکن وای فای سخت تر از نسخه های قبلی است. برای جزئیات، محدودیت‌های اسکن Wi-Fi را ببینید.

محدودیت‌های مشابهی برای متد getConnectionInfo() نیز اعمال می‌شود که یک شی WifiInfo را که اتصال Wi-Fi فعلی را توصیف می‌کند، برمی‌گرداند. فقط در صورتی می‌توانید از روش‌های این شی برای بازیابی مقادیر SSID و BSSID استفاده کنید که برنامه تماس‌گیرنده مجوزهای زیر را داشته باشد:

• ACCESS_FINE_LOCATION یا ACCESS_COARSE_LOCATION
• ACCESS_WIFI_STATE

برای بازیابی SSID یا BSSID نیز باید خدمات مکان در دستگاه فعال شود (در زیر تنظیمات > مکان ).

اطلاعات از روش‌های سرویس Wi-Fi حذف شد

در Android 9، رویدادها و پخش‌های زیر اطلاعاتی درباره موقعیت مکانی کاربر یا داده‌های قابل شناسایی شخصی دریافت نمی‌کنند:

• متدهای getScanResults() و getConnectionInfo() از WifiManager .
• متدهای discoverServices() و addServiceRequest() از WifiP2pManager .
• پخش NETWORK_STATE_CHANGED_ACTION .

سیستم NETWORK_STATE_CHANGED_ACTION که از Wi-Fi پخش می‌شود، دیگر حاوی SSID (قبلا EXTRA_SSID)، BSSID (قبلا EXTRA_BSSID) یا اطلاعات اتصال (قبلاً EXTRA_NETWORK_INFO) نیست. اگر برنامه شما به این اطلاعات نیاز دارد، به جای آن با getConnectionInfo() تماس بگیرید.

اطلاعات تلفن اکنون به تنظیمات مکان دستگاه متکی است

اگر کاربر مکان دستگاه را در دستگاهی که Android 9 دارد غیرفعال کرده باشد، روش‌های زیر نتیجه‌ای را ارائه نمی‌دهند:

• getAllCellInfo()
• listen()
• getCellLocation()
• getNeighboringCellInfo()

محدودیت در استفاده از رابط های غیر SDK

برای کمک به اطمینان از ثبات و سازگاری برنامه، پلتفرم استفاده از برخی روش‌ها و زمینه‌های غیر SDK را محدود می‌کند. این محدودیت‌ها اعمال می‌شوند چه بخواهید مستقیماً به این روش‌ها و فیلدها دسترسی داشته باشید، از طریق بازتاب یا با استفاده از JNI. در Android 9، برنامه شما می‌تواند همچنان به این رابط‌های محدود دسترسی داشته باشد. این پلتفرم از نان تست ها و ورودی های گزارش استفاده می کند تا توجه شما را جلب کند. اگر برنامه شما چنین نان تستی را نشان می دهد، مهم است که استراتژی پیاده سازی دیگری غیر از رابط کاربری محدود را دنبال کنید. اگر فکر می کنید که هیچ استراتژی جایگزینی امکان پذیر نیست، می توانید یک اشکال را برای درخواست تجدید نظر در محدودیت ارسال کنید.

محدودیت‌ها در رابط‌های غیر SDK حاوی اطلاعات مهم دیگری است. باید آن را بررسی کنید تا مطمئن شوید که برنامه شما به درستی کار می کند.

رفتار امنیتی تغییر می کند

تغییرات امنیتی دستگاه

Android 9 چندین قابلیت اضافه می کند که امنیت برنامه شما را بهبود می بخشد، صرف نظر از اینکه برنامه شما کدام نسخه را هدف قرار می دهد.

تغییرات پیاده سازی TLS

پیاده سازی TLS سیستم در اندروید 9 دستخوش تغییرات زیادی شده است:

• اگر نمونه ای از SSLSocket در حین ایجاد اتصال نتواند، سیستم یک IOException به جای NullPointerException پرتاب می کند.
• کلاس SSLEngine به طور تمیز با هر هشدار close_notify که رخ می دهد کنترل می کند.

برای کسب اطلاعات بیشتر در مورد ایجاد درخواست های وب ایمن در یک برنامه Android، یک مثال HTTPS را ببینید.

فیلتر SECCOMP دقیق تر

اندروید 9 تماس‌های سیستمی را که برای برنامه‌ها در دسترس است محدودتر می‌کند. این رفتار یک برنامه افزودنی از فیلتر SECCOMP است که Android 8.0 (سطح API 26) شامل می شود .

تغییرات رمزنگاری

اندروید 9 تغییرات زیادی را در پیاده سازی و مدیریت الگوریتم های رمزنگاری ایجاد می کند.

پیاده سازی پارامترها و الگوریتم ها را رمزگذاری کنید

اندروید 9 پیاده سازی های اضافی پارامترهای الگوریتم را در Conscrypt ارائه می دهد. این پارامترها عبارتند از: AES، DESEDE، OAEP و EC. نسخه‌های Bouncy Castle این پارامترها و بسیاری از الگوریتم‌ها از اندروید 9 منسوخ شده‌اند.

اگر برنامه شما Android 8.1 (سطح API 27) یا پایین‌تر را هدف قرار می‌دهد، هنگام درخواست اجرای Bouncy Castle از یکی از این الگوریتم‌های منسوخ، هشداری دریافت می‌کنید. با این حال، اگر اندروید 9 را هدف قرار دهید، هر یک از این درخواست‌ها یک NoSuchAlgorithmException می‌دهند.

تغییرات دیگر

اندروید 9 چندین تغییر دیگر مرتبط با رمزنگاری را معرفی می کند:

• هنگام استفاده از کلیدهای PBE، اگر Bouncy Castle منتظر یک بردار اولیه (IV) باشد و برنامه شما یکی را ارائه نکند، یک هشدار دریافت می‌کنید.
• اجرای Conscrypt رمز ARC4 به شما امکان می دهد ARC4/ECB/NoPadding یا ARC4/NONE/NoPadding را مشخص کنید.
• ارائه دهنده Crypto Java Cryptography Architecture (JCA) حذف شده است. در نتیجه، اگر برنامه شما SecureRandom.getInstance("SHA1PRNG", "Crypto") را فراخوانی کند، یک NoSuchProviderException رخ می دهد.
• اگر برنامه شما کلیدهای RSA را از بافرهایی که بزرگتر از ساختار کلید هستند تجزیه کند، دیگر استثنایی رخ نخواهد داد.

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

فایل‌های رمزگذاری شده امن Android دیگر پشتیبانی نمی‌شوند

اندروید 9 به طور کامل پشتیبانی از فایل های رمزگذاری شده ایمن اندروید (ASEC) را حذف می کند.

در Android 2.2 (سطح API 8)، اندروید ASEC ها را برای پشتیبانی از عملکرد برنامه ها روی کارت SD معرفی کرد. در Android 6.0 (سطح API 23)، این پلتفرم یک فناوری دستگاه ذخیره سازی قابل قبول را معرفی کرد که توسعه دهندگان می توانند به جای ASEC از آن استفاده کنند.

به روز رسانی کتابخانه های ICU

اندروید 9 از نسخه 60 کتابخانه ICU استفاده می کند. اندروید 8.0 (سطح API 26) و اندروید 8.1 (سطح API 27) از ICU 58 استفاده می کنند.

ICU برای ارائه APIهای عمومی در زیر android.icu package استفاده می شود و به صورت داخلی در پلتفرم Android برای پشتیبانی بین المللی استفاده می شود. به عنوان مثال، برای پیاده سازی کلاس های اندروید در java.util ، java.text و android.text.format استفاده می شود.

به‌روزرسانی ICU 60 شامل بسیاری از تغییرات کوچک اما مفید است، از جمله پشتیبانی از داده‌های Emoji 5.0 و فرمت‌های تاریخ/زمان بهبود یافته، همانطور که در یادداشت‌های انتشار ICU 59 و ICU 60 مستند شده است.

تغییرات قابل توجه در این به روز رسانی:

• نحوه مدیریت این پلتفرم با مناطق زمانی تغییر کرده است.
  • پلتفرم GMT و UTC را بهتر مدیریت می کند. UTC دیگر مترادف GMT نیست.

    ICU اکنون نام مناطق ترجمه شده را برای GMT ​​و UTC ارائه می دهد. این تغییر قالب‌بندی android.icu و رفتار تجزیه را برای مناطقی مانند "GMT"، "Etc/GMT"، "UTC"، "Etc/UTC" و "Zulu" تحت تاثیر قرار می‌دهد.

  • java.text.SimpleDateFormat اکنون از ICU برای ارائه نام های نمایشی برای UTC /GMT استفاده می کند، به این معنی:
    • قالب بندی zzzz یک رشته محلی طولانی برای بسیاری از مناطق ایجاد می کند. قبلاً "UTC" برای UTC و رشته هایی مانند "GMT+00:00" برای GMT ​​تولید می کرد.
    • تجزیه zzzz رشته هایی مانند "زمان هماهنگ جهانی" و "زمان میانگین گرینویچ" را تشخیص می دهد.
    • اگر برنامه‌ها فرض کنند که «UTC» یا «GMT+00:00» برای zzzz در همه زبان‌ها خروجی دارند، ممکن است با مشکلات سازگاری مواجه شوند.
  • رفتار java.text.DateFormatSymbols.getZoneStrings() تغییر کرده است:
    • همانند SimpleDateFormat ، UTC و GMT اکنون نام های طولانی دارند. انواع DST نام‌های منطقه زمانی برای منطقه UTC، مانند "UTC"، "Etc/UTC" و "Zulu" به GMT+00:00 تبدیل می‌شوند، که زمانی که نامی در دسترس نباشد، بازگشتی استاندارد است. رشته کد سخت UTC .
    • برخی از شناسه‌های ناحیه به درستی به‌عنوان مترادف مناطق دیگر شناخته می‌شوند، بنابراین Android رشته‌هایی را برای شناسه‌های منطقه قدیمی، مانند Eire پیدا می‌کند که قبلاً قابل حل نبودند.
  • آسیا/هانوی دیگر یک منطقه شناخته شده نیست. به همین دلیل java.util.TimeZones.getAvailableIds() این مقدار را بر نمی گرداند و java.util.TimeZone.getTimeZone() آن را تشخیص نمی دهد. این رفتار با رفتار android.icu موجود مطابقت دارد.
• روش android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) ممکن است حتی در هنگام تجزیه متن ارز قانونی، یک ParseException ایجاد کند. با استفاده از NumberFormat.parseCurrency ، که از Android نسخه 7.0 (سطح API 24) برای متن ارز به سبک PLURALCURRENCYSTYLE در دسترس است، از این مشکل جلوگیری کنید.

تغییرات تست اندروید

اندروید 9 تغییرات متعددی را در ساختار کتابخانه و کلاس چارچوب Android Test ایجاد می کند. این تغییرات به توسعه دهندگان کمک می کند تا از API های عمومی با پشتیبانی از چارچوب استفاده کنند، اما این تغییرات همچنین به انعطاف پذیری بیشتری در ساخت و اجرای آزمایش ها با استفاده از کتابخانه های شخص ثالث یا منطق سفارشی اجازه می دهد.

کتابخانه ها از چارچوب حذف شدند

Android 9 کلاس‌های مبتنی بر JUnit را در سه کتابخانه سازماندهی مجدد می‌کند: android.test.base ، android.test.runner و android.test.mock . این تغییر به شما امکان می‌دهد آزمایش‌هایی را بر روی نسخه‌ای از JUnit اجرا کنید که با وابستگی‌های پروژه شما بهترین کار را دارد. این نسخه از JUnit ممکن است با نسخه ای که android.jar ارائه می دهد متفاوت باشد.

برای کسب اطلاعات بیشتر درباره نحوه سازماندهی کلاس‌های مبتنی بر JUnit در این کتابخانه‌ها، و همچنین نحوه آماده‌سازی پروژه برنامه‌تان برای نوشتن و اجرای آزمایش‌ها، به راه‌اندازی پروژه برای تست Android مراجعه کنید.

آزمایش تغییرات ساخت مجموعه

متد addRequirements() در کلاس TestSuiteBuilder حذف شده است و خود کلاس TestSuiteBuilder منسوخ شده است. متد addRequirements() توسعه دهندگان را ملزم به ارائه آرگومان هایی می کرد که انواع آنها API های مخفی هستند و باعث می شود API نامعتبر باشد.

رسیور جاوا UTF

UTF-8 مجموعه نویسه های پیش فرض در اندروید است. یک دنباله بایت UTF-8 را می توان توسط یک سازنده String ، مانند String(byte[] bytes) رمزگشایی کرد.

رمزگشای UTF-8 در اندروید 9 از استانداردهای یونیکد با دقت بیشتری نسبت به نسخه های قبلی پیروی می کند. تغییرات شامل موارد زیر است:

• غیرکوتاه ترین شکل UTF-8، مانند <C0, AF> ، به عنوان بد شکل تلقی می شود.
• شکل جانشین UTF-8، مانند U+D800 .. U+DFFF ، به عنوان بد شکل تلقی می شود.
• بخش فرعی حداکثر با یک واحد U+FFFD جایگزین می‌شود. به عنوان مثال، در دنباله بایت " 41 C0 AF 41 F4 80 80 41 "، بیشترین قسمت های فرعی " C0 "، " AF " و " F4 80 80 " هستند. " F4 80 80 " می تواند زیر دنباله اولیه " F4 80 80 80 " باشد، اما " C0 " نمی تواند دنباله ابتدایی هر دنباله واحد کد به خوبی شکل گرفته باشد. بنابراین، خروجی باید " A\ufffd\ufffdA\ufffdA " باشد.
• برای رمزگشایی یک دنباله UTF-8 / CESU-8 اصلاح شده در Android 9 یا بالاتر، از متد DataInputStream.readUTF() یا روش NewStringUTF() JNI استفاده کنید.

تأیید نام میزبان با استفاده از گواهی

RFC 2818 دو روش را برای تطبیق یک نام دامنه با یک گواهی توصیف می کند - با استفاده از نام های موجود در پسوند subjectAltName ( SAN ) یا در صورت عدم وجود پسوند SAN ، بازگشت به commonName ( CN ).

با این حال، بازگشت به CN در RFC 2818 منسوخ شد. به همین دلیل، Android دیگر به استفاده از CN برنمی‌گردد. برای تأیید نام میزبان، سرور باید یک گواهی با SAN منطبق ارائه دهد. گواهینامه هایی که حاوی SAN مطابق با نام میزبان نیستند، دیگر قابل اعتماد نیستند.

جستجوی آدرس شبکه می تواند باعث نقض شبکه شود

جستجوی آدرس شبکه که نیاز به تفکیک نام دارد می‌تواند شامل I/O شبکه باشد و بنابراین عملیات مسدود کردن در نظر گرفته می‌شود. عملیات مسدود کردن روی رشته اصلی می تواند باعث مکث یا jank شود.

کلاس StrictMode یک ابزار توسعه است که به توسعه دهندگان کمک می کند تا مشکلات موجود در کد خود را شناسایی کنند.

در Android 9 و بالاتر، StrictMode نقض‌های شبکه ناشی از جستجوی آدرس شبکه را که به وضوح نام نیاز دارند، شناسایی می‌کند.

شما نباید برنامه های خود را با فعال بودن StrictMode ارسال کنید. اگر این کار را انجام دهید، برنامه‌های شما می‌توانند استثناهایی مانند NetworkOnMainThreadException را هنگام استفاده از روش‌های detectNetwork() یا detectAll() برای دریافت خط‌مشی که نقض‌های شبکه را شناسایی می‌کند، تجربه کنند.

حل یک آدرس IP عددی یک عملیات مسدود کردن در نظر گرفته نمی شود. وضوح آدرس IP عددی مانند نسخه های قبل از اندروید 9 کار می کند.

برچسب گذاری سوکت

در نسخه‌های پلتفرم پایین‌تر از اندروید 9، اگر سوکتی با استفاده از متد setThreadStatsTag() برچسب‌گذاری شود، زمانی که سوکت با استفاده از IPC بایندر با ظرف ParcelFileDescriptor به فرآیند دیگری ارسال می‌شود، برچسب‌گذاری نمی‌شود.

در اندروید 9 و بالاتر، تگ سوکت زمانی که با استفاده از بایندر IPC به فرآیند دیگری ارسال می‌شود، حفظ می‌شود. این تغییر می تواند بر آمار ترافیک شبکه تأثیر بگذارد، به عنوان مثال، هنگام استفاده از متد queryDetailsForUidTag() .

اگر می‌خواهید رفتار نسخه‌های قبلی را حفظ کنید، که سوکتی را که به فرآیند دیگری فرستاده می‌شود حذف می‌کند، می‌توانید قبل از ارسال سوکت untagSocket() را فراخوانی کنید.

مقدار بایت های موجود در سوکت گزارش شده است

متد available() پس از فراخوانی متد shutdownInput() 0 برمی گرداند.

گزارش دقیق تر قابلیت های شبکه برای VPN ها

در Android 8.1 (سطح API 27) و پایین‌تر، کلاس NetworkCapabilities فقط مجموعه محدودی از اطلاعات را برای VPN‌ها، مانند TRANSPORT_VPN گزارش می‌کند، اما NET_CAPABILITY_NOT_VPN را حذف می‌کند. این اطلاعات محدود، تعیین اینکه آیا استفاده از VPN می‌تواند هزینه‌هایی را برای کاربر برنامه به همراه داشته باشد، دشوار می‌کرد. به عنوان مثال، بررسی NET_CAPABILITY_NOT_METERED تعیین نمی کند که آیا شبکه های اصلی اندازه گیری شده اند یا خیر.

در اندروید 9 و بالاتر، وقتی یک VPN متد setUnderlyingNetworks() فراخوانی می‌کند، سیستم Android انتقال‌ها و قابلیت‌های هر شبکه زیربنایی را ادغام می‌کند و نتیجه را به عنوان قابلیت‌های شبکه موثر شبکه VPN برمی‌گرداند.

در Android 9 و بالاتر، برنامه‌هایی که قبلاً NET_CAPABILITY_NOT_METERED را بررسی می‌کنند، قابلیت‌های شبکه VPN و شبکه‌های زیربنایی را دریافت می‌کنند.

فایل‌های موجود در پوشه xt_qtaguid دیگر در دسترس برنامه‌ها نیستند

با شروع اندروید 9، برنامه‌ها اجازه دسترسی خواندن مستقیم به فایل‌های موجود در پوشه /proc/net/xt_qtaguid را ندارند. دلیل آن اطمینان از سازگاری با برخی از دستگاه هایی است که اصلاً این فایل ها را ندارند.

API های عمومی که به این فایل ها متکی هستند، TrafficStats و NetworkStatsManager ، همچنان به کار خود ادامه می دهند. با این حال، توابع cutils پشتیبانی‌نشده، مانند qtaguid_tagSocket() ممکن است آنطور که انتظار می‌رود – یا اصلاً – در دستگاه‌های مختلف کار نکنند.

الزام FLAG_ACTIVITY_NEW_TASK اکنون اجرا می شود

با Android 9، نمی‌توانید فعالیتی را از یک زمینه غیرفعالی شروع کنید، مگر اینکه پرچم قصد FLAG_ACTIVITY_NEW_TASK را پاس کنید. اگر بخواهید بدون عبور از این پرچم فعالیتی را شروع کنید، فعالیت شروع نمی شود و سیستم پیامی را در گزارش چاپ می کند.

چرخش صفحه نمایش تغییر می کند

با شروع اندروید 9، تغییرات قابل توجهی در حالت چرخش پرتره وجود دارد. در اندروید 8.0 (سطح API 26)، کاربران می‌توانند با استفاده از کاشی تنظیمات سریع یا تنظیمات نمایش، بین حالت‌های چرخش خودکار و چرخش عمودی جابه‌جا شوند. حالت عمودی به قفل چرخشی تغییر نام داده است و هنگامی که چرخش خودکار خاموش شود فعال است. هیچ تغییری در حالت چرخش خودکار وجود ندارد.

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

فعالیت‌هایی که جهت‌گیری خاصی را درخواست می‌کنند (مثلاً screenOrientation=landscape )، اولویت قفل کاربر را نادیده می‌گیرند و مانند Android 8.0 رفتار می‌کنند.

تنظیمات ترجیحی جهت صفحه را می توان در سطح Activity در مانیفست Android یا به صورت برنامه نویسی با setRequestedOrientation () تنظیم کرد.

حالت قفل چرخش با تنظیم اولویت چرخش کاربر که WindowManager هنگام مدیریت چرخش فعالیت استفاده می کند، کار می کند. ترجیح چرخش کاربر ممکن است در موارد زیر تغییر کند. توجه داشته باشید که یک سوگیری برای بازگشت به چرخش طبیعی دستگاه وجود دارد که معمولاً برای دستگاه‌های فاکتور فرم تلفن به صورت عمودی است:

• هنگامی که کاربر یک پیشنهاد چرخش را می پذیرد، اولویت چرخش به پیشنهاد تغییر می کند.
• وقتی کاربر به یک برنامه پرتره اجباری (شامل صفحه قفل یا راه‌انداز) سوئیچ می‌کند، اولویت چرخش به حالت عمودی تغییر می‌کند.

جدول زیر رفتار چرخش را برای جهت گیری های رایج صفحه نمایش خلاصه می کند:

منسوخ شدن سرویس گیرنده Apache HTTP بر برنامه های دارای ClassLoader غیر استاندارد تأثیر می گذارد

با Android 6.0، پشتیبانی از سرویس گیرنده Apache HTTP را حذف کردیم . این تغییر روی اکثر برنامه‌هایی که اندروید 9 یا بالاتر را هدف قرار نمی‌دهند، تأثیری ندارد. با این حال، این تغییر می‌تواند بر برنامه‌های خاصی که از ساختار ClassLoader غیراستاندارد استفاده می‌کنند، تأثیر بگذارد، حتی اگر برنامه‌ها Android 9 یا بالاتر را هدف قرار ندهند.

اگر یک برنامه از ClassLoader غیر استانداردی استفاده کند که صریحاً به سیستم ClassLoader محول می شود، ممکن است تحت تأثیر قرار گیرد. این برنامه‌ها باید در عوض وقتی به دنبال کلاس‌ها در org.apache.http.* به برنامه ClassLoader واگذار شوند. اگر آنها را به سیستم ClassLoader واگذار کنند، برنامه‌ها در Android 9 یا بالاتر با NoClassDefFoundError از کار می‌افتند، زیرا آن کلاس‌ها دیگر برای ClassLoader سیستم شناخته نمی‌شوند. برای جلوگیری از مشکلات مشابه در آینده، برنامه ها به طور کلی باید کلاس ها را از طریق برنامه ClassLoader بارگیری کنند نه اینکه مستقیماً به ClassLoader سیستم دسترسی داشته باشند.

شمارش دوربین ها

برنامه‌هایی که روی دستگاه‌های Android 9 اجرا می‌شوند می‌توانند با فراخوانی getCameraIdList() هر دوربین موجود را پیدا کنند. یک برنامه نباید تصور کند که دستگاه فقط یک دوربین پشتی یا فقط یک دوربین جلو دارد.

برای مثال، اگر برنامه شما دکمه ای برای جابجایی بین دوربین جلو و عقب دارد، ممکن است بیش از یک دوربین جلو یا عقب برای انتخاب وجود داشته باشد. شما باید فهرست دوربین را طی کنید، ویژگی های هر دوربین را بررسی کنید و تصمیم بگیرید که کدام دوربین را در معرض دید کاربر قرار دهید.

اندروید 9 (سطح API 28) تعدادی تغییرات را در سیستم اندروید معرفی می کند. تغییرات رفتاری زیر برای همه برنامه‌ها وقتی روی پلتفرم Android 9 اجرا می‌شوند، صرف‌نظر از سطح API مورد نظرشان اعمال می‌شود. همه توسعه‌دهندگان باید این تغییرات را بررسی کرده و برنامه‌های خود را تغییر دهند تا در صورت لزوم، به درستی از آنها پشتیبانی کنند.

برای تغییراتی که فقط بر برنامه‌هایی تأثیر می‌گذارند که سطح API 28 یا بالاتر را هدف قرار می‌دهند، به تغییرات رفتار: برنامه‌هایی که API سطح 28+ را هدف قرار می‌دهند، مراجعه کنید.

مدیریت نیرو

اندروید 9 ویژگی های جدیدی را برای بهبود مدیریت انرژی دستگاه معرفی می کند. این تغییرات، همراه با ویژگی‌هایی که قبلاً قبل از اندروید 9 وجود داشت، کمک می‌کند تا اطمینان حاصل شود که منابع سیستم در دسترس برنامه‌هایی قرار می‌گیرد که بیشتر به آن‌ها نیاز دارند.

برای جزئیات، به مدیریت نیرو مراجعه کنید.

حریم خصوصی تغییر می کند

برای افزایش حریم خصوصی کاربر، اندروید 9 چندین تغییر رفتاری را معرفی می‌کند، مانند محدود کردن دسترسی برنامه‌های پس‌زمینه به حسگرهای دستگاه، محدود کردن اطلاعات بازیابی شده از اسکن‌های Wi-Fi، و قوانین جدید مجوز و گروه‌های مجوز مربوط به تماس‌های تلفنی، وضعیت تلفن و Wi- اسکن Fi

این تغییرات بدون در نظر گرفتن نسخه SDK هدف، بر تمام برنامه های اجرا شده در اندروید 9 تأثیر می گذارد.

دسترسی محدود به حسگرها در پس زمینه

اندروید 9 امکان دسترسی برنامه‌های پس‌زمینه به ورودی‌های کاربر و داده‌های حسگر را محدود می‌کند. اگر برنامه شما در پس‌زمینه دستگاهی با Android 9 اجرا می‌شود، سیستم محدودیت‌های زیر را برای برنامه شما اعمال می‌کند:

• برنامه شما نمی تواند به میکروفون یا دوربین دسترسی پیدا کند.
• حسگرهایی که از حالت گزارش مداوم استفاده می کنند، مانند شتاب سنج و ژیروسکوپ، رویدادها را دریافت نمی کنند.
• حسگرهایی که از حالت‌های گزارش لحظه‌ای یا یک‌شات استفاده می‌کنند، رویدادها را دریافت نمی‌کنند.

اگر برنامه شما نیاز به تشخیص رویدادهای حسگر در دستگاه‌های دارای Android 9 دارد، از سرویس پیش‌زمینه استفاده کنید.

دسترسی محدود به گزارش تماس ها

Android 9 گروه مجوز CALL_LOG را معرفی می‌کند و مجوزهای READ_CALL_LOG ، WRITE_CALL_LOG و PROCESS_OUTGOING_CALLS را به این گروه منتقل می‌کند. در نسخه های قبلی اندروید، این مجوزها در گروه مجوز PHONE قرار داشتند.

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

اگر برنامه شما نیاز به دسترسی به گزارش تماس دارد یا نیاز به پردازش تماس‌های خروجی دارد، باید این مجوزها را صریحاً از گروه مجوز CALL_LOG درخواست کنید. در غیر این صورت، یک SecurityException رخ می دهد.

دسترسی محدود به شماره تلفن

برنامه‌هایی که روی Android 9 اجرا می‌شوند، نمی‌توانند شماره تلفن یا وضعیت تلفن را بدون دریافت مجوز READ_CALL_LOG ، بعلاوه سایر مجوزهایی که موارد استفاده برنامه شما به آن نیاز دارند، بخوانند.

شماره‌های تلفن مرتبط با تماس‌های ورودی و خروجی در پخش وضعیت تلفن ، مانند تماس‌های ورودی و خروجی، قابل مشاهده هستند و از کلاس PhoneStateListener قابل دسترسی هستند. با این حال، بدون مجوز READ_CALL_LOG ، قسمت شماره تلفن ارائه شده در پخش‌های PHONE_STATE_CHANGED و از طریق PhoneStateListener خالی است.

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

• برای خواندن اعداد از اقدام قصد PHONE_STATE ، هم به مجوز READ_CALL_LOG و هم به مجوز READ_PHONE_STATE نیاز دارید.
• برای خواندن اعداد از onCallStateChanged() فقط به مجوز READ_CALL_LOG نیاز دارید. شما به مجوز READ_PHONE_STATE نیاز ندارید.

دسترسی محدود به مکان Wi-Fi و اطلاعات اتصال

در اندروید 9، الزامات مجوز برای یک برنامه برای انجام اسکن وای فای سخت تر از نسخه های قبلی است. برای جزئیات، محدودیت‌های اسکن Wi-Fi را ببینید.

محدودیت‌های مشابهی برای متد getConnectionInfo() نیز اعمال می‌شود که یک شی WifiInfo را که اتصال Wi-Fi فعلی را توصیف می‌کند، برمی‌گرداند. فقط در صورتی می‌توانید از روش‌های این شی برای بازیابی مقادیر SSID و BSSID استفاده کنید که برنامه تماس‌گیرنده مجوزهای زیر را داشته باشد:

• ACCESS_FINE_LOCATION یا ACCESS_COARSE_LOCATION
• ACCESS_WIFI_STATE

برای بازیابی SSID یا BSSID نیز باید خدمات مکان در دستگاه فعال شود (در زیر تنظیمات > مکان ).

اطلاعات از روش‌های سرویس Wi-Fi حذف شد

در Android 9، رویدادها و پخش‌های زیر اطلاعاتی درباره موقعیت مکانی کاربر یا داده‌های قابل شناسایی شخصی دریافت نمی‌کنند:

• متدهای getScanResults() و getConnectionInfo() از WifiManager .
• متدهای discoverServices() و addServiceRequest() از WifiP2pManager .
• پخش NETWORK_STATE_CHANGED_ACTION .

سیستم NETWORK_STATE_CHANGED_ACTION که از Wi-Fi پخش می‌شود، دیگر حاوی SSID (قبلا EXTRA_SSID)، BSSID (قبلا EXTRA_BSSID) یا اطلاعات اتصال (قبلاً EXTRA_NETWORK_INFO) نیست. اگر برنامه شما به این اطلاعات نیاز دارد، به جای آن با getConnectionInfo() تماس بگیرید.

اطلاعات تلفن اکنون به تنظیمات مکان دستگاه متکی است

اگر کاربر مکان دستگاه را در دستگاهی که Android 9 دارد غیرفعال کرده باشد، روش‌های زیر نتیجه‌ای را ارائه نمی‌دهند:

• getAllCellInfo()
• listen()
• getCellLocation()
• getNeighboringCellInfo()

محدودیت در استفاده از رابط های غیر SDK

برای کمک به اطمینان از ثبات و سازگاری برنامه، پلتفرم استفاده از برخی روش‌ها و زمینه‌های غیر SDK را محدود می‌کند. این محدودیت‌ها اعمال می‌شوند چه بخواهید مستقیماً به این روش‌ها و فیلدها دسترسی داشته باشید، از طریق بازتاب یا با استفاده از JNI. در Android 9، برنامه شما می‌تواند همچنان به این رابط‌های محدود دسترسی داشته باشد. این پلتفرم از نان تست ها و ورودی های گزارش استفاده می کند تا توجه شما را جلب کند. اگر برنامه شما چنین نان تستی را نشان می دهد، مهم است که استراتژی پیاده سازی دیگری غیر از رابط کاربری محدود را دنبال کنید. اگر فکر می کنید که هیچ استراتژی جایگزینی امکان پذیر نیست، می توانید یک اشکال را برای درخواست تجدید نظر در محدودیت ارسال کنید.

محدودیت‌ها در رابط‌های غیر SDK حاوی اطلاعات مهم دیگری است. باید آن را بررسی کنید تا مطمئن شوید که برنامه شما به درستی کار می کند.

رفتار امنیتی تغییر می کند

تغییرات امنیتی دستگاه

Android 9 چندین قابلیت اضافه می کند که امنیت برنامه شما را بهبود می بخشد، صرف نظر از اینکه برنامه شما کدام نسخه را هدف قرار می دهد.

تغییرات پیاده سازی TLS

پیاده سازی TLS سیستم در اندروید 9 دستخوش تغییرات زیادی شده است:

• اگر نمونه ای از SSLSocket در حین ایجاد اتصال نتواند، سیستم یک IOException به جای NullPointerException پرتاب می کند.
• کلاس SSLEngine به طور تمیز با هر هشدار close_notify که رخ می دهد کنترل می کند.

برای کسب اطلاعات بیشتر در مورد ایجاد درخواست های وب ایمن در یک برنامه Android، یک مثال HTTPS را ببینید.

فیلتر SECCOMP دقیق تر

اندروید 9 تماس‌های سیستمی را که برای برنامه‌ها در دسترس است محدودتر می‌کند. این رفتار یک برنامه افزودنی از فیلتر SECCOMP است که Android 8.0 (سطح API 26) شامل می شود .

تغییرات رمزنگاری

اندروید 9 تغییرات زیادی را در پیاده سازی و مدیریت الگوریتم های رمزنگاری ایجاد می کند.

پیاده سازی پارامترها و الگوریتم ها را رمزگذاری کنید

اندروید 9 پیاده سازی های اضافی پارامترهای الگوریتم را در Conscrypt ارائه می دهد. این پارامترها عبارتند از: AES، DESEDE، OAEP و EC. نسخه‌های Bouncy Castle این پارامترها و بسیاری از الگوریتم‌ها از اندروید 9 منسوخ شده‌اند.

اگر برنامه شما Android 8.1 (سطح API 27) یا پایین‌تر را هدف قرار می‌دهد، هنگام درخواست اجرای Bouncy Castle از یکی از این الگوریتم‌های منسوخ، هشداری دریافت می‌کنید. با این حال، اگر اندروید 9 را هدف قرار دهید، هر یک از این درخواست‌ها یک NoSuchAlgorithmException می‌دهند.

تغییرات دیگر

اندروید 9 چندین تغییر دیگر مرتبط با رمزنگاری را معرفی می کند:

• هنگام استفاده از کلیدهای PBE، اگر Bouncy Castle منتظر یک بردار اولیه (IV) باشد و برنامه شما یکی را ارائه نکند، یک هشدار دریافت می‌کنید.
• اجرای Conscrypt رمز ARC4 به شما امکان می دهد ARC4/ECB/NoPadding یا ARC4/NONE/NoPadding را مشخص کنید.
• ارائه دهنده Crypto Java Cryptography Architecture (JCA) حذف شده است. در نتیجه، اگر برنامه شما SecureRandom.getInstance("SHA1PRNG", "Crypto") را فراخوانی کند، یک NoSuchProviderException رخ می دهد.
• اگر برنامه شما کلیدهای RSA را از بافرهایی که بزرگتر از ساختار کلید هستند تجزیه کند، دیگر استثنایی رخ نخواهد داد.

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

فایل‌های رمزگذاری شده امن Android دیگر پشتیبانی نمی‌شوند

اندروید 9 به طور کامل پشتیبانی از فایل های رمزگذاری شده ایمن اندروید (ASEC) را حذف می کند.

در Android 2.2 (سطح API 8)، اندروید ASEC ها را برای پشتیبانی از عملکرد برنامه ها روی کارت SD معرفی کرد. در Android 6.0 (سطح API 23)، این پلتفرم یک فناوری دستگاه ذخیره سازی قابل قبول را معرفی کرد که توسعه دهندگان می توانند به جای ASEC از آن استفاده کنند.

به روز رسانی کتابخانه های ICU

اندروید 9 از نسخه 60 کتابخانه ICU استفاده می کند. اندروید 8.0 (سطح API 26) و اندروید 8.1 (سطح API 27) از ICU 58 استفاده می کنند.

ICU برای ارائه APIهای عمومی در زیر android.icu package استفاده می شود و به صورت داخلی در پلتفرم Android برای پشتیبانی بین المللی استفاده می شود. به عنوان مثال، برای پیاده سازی کلاس های اندروید در java.util ، java.text و android.text.format استفاده می شود.

به‌روزرسانی ICU 60 شامل بسیاری از تغییرات کوچک اما مفید است، از جمله پشتیبانی از داده‌های Emoji 5.0 و فرمت‌های تاریخ/زمان بهبود یافته، همانطور که در یادداشت‌های انتشار ICU 59 و ICU 60 مستند شده است.

تغییرات قابل توجه در این به روز رسانی:

• نحوه مدیریت این پلتفرم با مناطق زمانی تغییر کرده است.
  • پلتفرم GMT و UTC را بهتر مدیریت می کند. UTC دیگر مترادف GMT نیست.

    ICU اکنون نام مناطق ترجمه شده را برای GMT ​​و UTC ارائه می دهد. این تغییر قالب‌بندی android.icu و رفتار تجزیه را برای مناطقی مانند "GMT"، "Etc/GMT"، "UTC"، "Etc/UTC" و "Zulu" تحت تاثیر قرار می‌دهد.

  • java.text.SimpleDateFormat اکنون از ICU برای ارائه نام های نمایشی برای UTC /GMT استفاده می کند، به این معنی:
    • قالب بندی zzzz یک رشته محلی طولانی برای بسیاری از مناطق ایجاد می کند. قبلاً "UTC" برای UTC و رشته هایی مانند "GMT+00:00" برای GMT ​​تولید می کرد.
    • تجزیه zzzz رشته هایی مانند "زمان هماهنگ جهانی" و "زمان میانگین گرینویچ" را تشخیص می دهد.
    • اگر برنامه‌ها فرض کنند که «UTC» یا «GMT+00:00» برای zzzz در همه زبان‌ها خروجی دارند، ممکن است با مشکلات سازگاری مواجه شوند.
  • رفتار java.text.DateFormatSymbols.getZoneStrings() تغییر کرده است:
    • همانند SimpleDateFormat ، UTC و GMT اکنون نام های طولانی دارند. انواع DST نام‌های منطقه زمانی برای منطقه UTC، مانند "UTC"، "Etc/UTC" و "Zulu" به GMT+00:00 تبدیل می‌شوند، که زمانی که نامی در دسترس نباشد، بازگشتی استاندارد است. رشته کد سخت UTC .
    • برخی از شناسه‌های ناحیه به درستی به‌عنوان مترادف مناطق دیگر شناخته می‌شوند، بنابراین Android رشته‌هایی را برای شناسه‌های منطقه قدیمی، مانند Eire پیدا می‌کند که قبلاً قابل حل نبودند.
  • آسیا/هانوی دیگر یک منطقه شناخته شده نیست. به همین دلیل java.util.TimeZones.getAvailableIds() این مقدار را بر نمی گرداند و java.util.TimeZone.getTimeZone() آن را تشخیص نمی دهد. این رفتار با رفتار android.icu موجود مطابقت دارد.
• روش android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) ممکن است حتی در هنگام تجزیه متن ارز قانونی، یک ParseException ایجاد کند. با استفاده از NumberFormat.parseCurrency ، که از Android نسخه 7.0 (سطح API 24) برای متن ارز به سبک PLURALCURRENCYSTYLE در دسترس است، از این مشکل جلوگیری کنید.

تغییرات تست اندروید

اندروید 9 تغییرات متعددی را در ساختار کتابخانه و کلاس چارچوب Android Test ایجاد می کند. این تغییرات به توسعه دهندگان کمک می کند تا از API های عمومی با پشتیبانی از چارچوب استفاده کنند، اما این تغییرات همچنین به انعطاف پذیری بیشتری در ساخت و اجرای آزمایش ها با استفاده از کتابخانه های شخص ثالث یا منطق سفارشی اجازه می دهد.

کتابخانه ها از چارچوب حذف شدند

Android 9 کلاس‌های مبتنی بر JUnit را در سه کتابخانه سازماندهی مجدد می‌کند: android.test.base ، android.test.runner و android.test.mock . این تغییر به شما امکان می‌دهد آزمایش‌هایی را بر روی نسخه‌ای از JUnit اجرا کنید که با وابستگی‌های پروژه شما بهترین کار را دارد. این نسخه از JUnit ممکن است با نسخه ای که android.jar ارائه می دهد متفاوت باشد.

برای کسب اطلاعات بیشتر درباره نحوه سازماندهی کلاس‌های مبتنی بر JUnit در این کتابخانه‌ها، و همچنین نحوه آماده‌سازی پروژه برنامه‌تان برای نوشتن و اجرای آزمایش‌ها، به راه‌اندازی پروژه برای تست Android مراجعه کنید.

آزمایش تغییرات ساخت مجموعه

متد addRequirements() در کلاس TestSuiteBuilder حذف شده است و خود کلاس TestSuiteBuilder منسوخ شده است. متد addRequirements() توسعه دهندگان را ملزم به ارائه آرگومان هایی می کرد که انواع آنها API های مخفی هستند و باعث می شود API نامعتبر باشد.

رسیور جاوا UTF

UTF-8 مجموعه نویسه های پیش فرض در اندروید است. یک دنباله بایت UTF-8 را می توان توسط یک سازنده String ، مانند String(byte[] bytes) رمزگشایی کرد.

رمزگشای UTF-8 در اندروید 9 از استانداردهای یونیکد با دقت بیشتری نسبت به نسخه های قبلی پیروی می کند. تغییرات شامل موارد زیر است:

• غیرکوتاه ترین شکل UTF-8، مانند <C0, AF> ، به عنوان بد شکل تلقی می شود.
• شکل جانشین UTF-8، مانند U+D800 .. U+DFFF ، به عنوان بد شکل تلقی می شود.
• بخش فرعی حداکثر با یک واحد U+FFFD جایگزین می‌شود. به عنوان مثال، در دنباله بایت " 41 C0 AF 41 F4 80 80 41 "، بیشترین قسمت های فرعی " C0 "، " AF " و " F4 80 80 " هستند. " F4 80 80 " می تواند زیر دنباله اولیه " F4 80 80 80 " باشد، اما " C0 " نمی تواند دنباله ابتدایی هر دنباله واحد کد به خوبی شکل گرفته باشد. بنابراین، خروجی باید " A\ufffd\ufffdA\ufffdA " باشد.
• برای رمزگشایی یک دنباله UTF-8 / CESU-8 اصلاح شده در Android 9 یا بالاتر، از متد DataInputStream.readUTF() یا روش NewStringUTF() JNI استفاده کنید.

تأیید نام میزبان با استفاده از گواهی

RFC 2818 دو روش را برای تطبیق یک نام دامنه با یک گواهی توصیف می کند - با استفاده از نام های موجود در پسوند subjectAltName ( SAN ) یا در صورت عدم وجود پسوند SAN ، بازگشت به commonName ( CN ).

با این حال، بازگشت به CN در RFC 2818 منسوخ شد. به همین دلیل، Android دیگر به استفاده از CN برنمی‌گردد. برای تأیید نام میزبان، سرور باید یک گواهی با SAN منطبق ارائه دهد. گواهینامه هایی که حاوی SAN مطابق با نام میزبان نیستند، دیگر قابل اعتماد نیستند.

جستجوی آدرس شبکه می تواند باعث نقض شبکه شود

جستجوی آدرس شبکه که نیاز به تفکیک نام دارد می‌تواند شامل I/O شبکه باشد و بنابراین عملیات مسدود کردن در نظر گرفته می‌شود. عملیات مسدود کردن روی رشته اصلی می تواند باعث مکث یا jank شود.

کلاس StrictMode یک ابزار توسعه است که به توسعه دهندگان کمک می کند تا مشکلات موجود در کد خود را شناسایی کنند.

در Android 9 و بالاتر، StrictMode نقض‌های شبکه ناشی از جستجوی آدرس شبکه را که به وضوح نام نیاز دارند، شناسایی می‌کند.

شما نباید برنامه های خود را با فعال بودن StrictMode ارسال کنید. اگر این کار را انجام دهید، برنامه‌های شما می‌توانند استثناهایی مانند NetworkOnMainThreadException را هنگام استفاده از روش‌های detectNetwork() یا detectAll() برای دریافت خط‌مشی که نقض‌های شبکه را شناسایی می‌کند، تجربه کنند.

حل یک آدرس IP عددی یک عملیات مسدود کردن در نظر گرفته نمی شود. وضوح آدرس IP عددی مانند نسخه های قبل از اندروید 9 کار می کند.

برچسب گذاری سوکت

در نسخه‌های پلتفرم پایین‌تر از اندروید 9، اگر سوکتی با استفاده از متد setThreadStatsTag() برچسب‌گذاری شود، زمانی که سوکت با استفاده از IPC بایندر با ظرف ParcelFileDescriptor به فرآیند دیگری ارسال می‌شود، برچسب‌گذاری نمی‌شود.

در اندروید 9 و بالاتر، تگ سوکت زمانی که با استفاده از بایندر IPC به فرآیند دیگری ارسال می‌شود، حفظ می‌شود. این تغییر می تواند بر آمار ترافیک شبکه تأثیر بگذارد، به عنوان مثال، هنگام استفاده از متد queryDetailsForUidTag() .

اگر می‌خواهید رفتار نسخه‌های قبلی را حفظ کنید، که سوکتی را که به فرآیند دیگری فرستاده می‌شود حذف می‌کند، می‌توانید قبل از ارسال سوکت untagSocket() را فراخوانی کنید.

مقدار بایت های موجود در سوکت گزارش شده است

متد available() پس از فراخوانی متد shutdownInput() 0 برمی گرداند.

گزارش دقیق تر قابلیت های شبکه برای VPN ها

در Android 8.1 (سطح API 27) و پایین‌تر، کلاس NetworkCapabilities فقط مجموعه محدودی از اطلاعات را برای VPN‌ها، مانند TRANSPORT_VPN گزارش می‌کند، اما NET_CAPABILITY_NOT_VPN را حذف می‌کند. این اطلاعات محدود، تعیین اینکه آیا استفاده از VPN می‌تواند هزینه‌هایی را برای کاربر برنامه به همراه داشته باشد، دشوار می‌کرد. به عنوان مثال، بررسی NET_CAPABILITY_NOT_METERED تعیین نمی کند که آیا شبکه های اصلی اندازه گیری شده اند یا خیر.

در اندروید 9 و بالاتر، وقتی یک VPN متد setUnderlyingNetworks() فراخوانی می‌کند، سیستم Android انتقال‌ها و قابلیت‌های هر شبکه زیربنایی را ادغام می‌کند و نتیجه را به عنوان قابلیت‌های شبکه موثر شبکه VPN برمی‌گرداند.

در Android 9 و بالاتر، برنامه‌هایی که قبلاً NET_CAPABILITY_NOT_METERED را بررسی می‌کنند، قابلیت‌های شبکه VPN و شبکه‌های زیربنایی را دریافت می‌کنند.

فایل‌های موجود در پوشه xt_qtaguid دیگر در دسترس برنامه‌ها نیستند

با شروع اندروید 9، برنامه‌ها اجازه دسترسی خواندن مستقیم به فایل‌های موجود در پوشه /proc/net/xt_qtaguid را ندارند. دلیل آن اطمینان از سازگاری با برخی از دستگاه هایی است که اصلاً این فایل ها را ندارند.

API های عمومی که به این فایل ها متکی هستند، TrafficStats و NetworkStatsManager ، همچنان به کار خود ادامه می دهند. با این حال، توابع cutils پشتیبانی‌نشده، مانند qtaguid_tagSocket() ممکن است آنطور که انتظار می‌رود – یا اصلاً – در دستگاه‌های مختلف کار نکنند.

الزام FLAG_ACTIVITY_NEW_TASK اکنون اجرا می شود

با Android 9، نمی‌توانید فعالیتی را از یک زمینه غیرفعالی شروع کنید، مگر اینکه پرچم قصد FLAG_ACTIVITY_NEW_TASK را پاس کنید. اگر بخواهید بدون عبور از این پرچم فعالیتی را شروع کنید، فعالیت شروع نمی شود و سیستم پیامی را در گزارش چاپ می کند.

چرخش صفحه نمایش تغییر می کند

با شروع اندروید 9، تغییرات قابل توجهی در حالت چرخش پرتره وجود دارد. در اندروید 8.0 (سطح API 26)، کاربران می‌توانند با استفاده از کاشی تنظیمات سریع یا تنظیمات نمایش، بین حالت‌های چرخش خودکار و چرخش عمودی جابه‌جا شوند. حالت عمودی به قفل چرخشی تغییر نام داده است و هنگامی که چرخش خودکار خاموش شود فعال است. هیچ تغییری در حالت چرخش خودکار وجود ندارد.

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

فعالیت‌هایی که جهت‌گیری خاصی را درخواست می‌کنند (مثلاً screenOrientation=landscape )، اولویت قفل کاربر را نادیده می‌گیرند و مانند Android 8.0 رفتار می‌کنند.

تنظیمات ترجیحی جهت صفحه را می توان در سطح Activity در مانیفست Android یا به صورت برنامه نویسی با setRequestedOrientation () تنظیم کرد.

حالت قفل چرخش با تنظیم اولویت چرخش کاربر که WindowManager هنگام مدیریت چرخش فعالیت استفاده می کند، کار می کند. ترجیح چرخش کاربر ممکن است در موارد زیر تغییر کند. توجه داشته باشید که یک سوگیری برای بازگشت به چرخش طبیعی دستگاه وجود دارد که معمولاً برای دستگاه‌های فاکتور فرم تلفن به صورت عمودی است:

• هنگامی که کاربر یک پیشنهاد چرخش را می پذیرد، اولویت چرخش به پیشنهاد تغییر می کند.
• وقتی کاربر به یک برنامه پرتره اجباری (شامل صفحه قفل یا راه‌انداز) سوئیچ می‌کند، اولویت چرخش به حالت عمودی تغییر می‌کند.

جدول زیر رفتار چرخش را برای جهت گیری های رایج صفحه نمایش خلاصه می کند:

منسوخ شدن سرویس گیرنده Apache HTTP بر برنامه های دارای ClassLoader غیر استاندارد تأثیر می گذارد

با Android 6.0، پشتیبانی از سرویس گیرنده Apache HTTP را حذف کردیم . این تغییر روی اکثر برنامه‌هایی که اندروید 9 یا بالاتر را هدف قرار نمی‌دهند، تأثیری ندارد. با این حال، این تغییر می‌تواند بر برنامه‌های خاصی که از ساختار ClassLoader غیراستاندارد استفاده می‌کنند، تأثیر بگذارد، حتی اگر برنامه‌ها Android 9 یا بالاتر را هدف قرار ندهند.

اگر یک برنامه از ClassLoader غیر استانداردی استفاده کند که صریحاً به سیستم ClassLoader محول می شود، ممکن است تحت تأثیر قرار گیرد. این برنامه‌ها باید در عوض وقتی به دنبال کلاس‌ها در org.apache.http.* به برنامه ClassLoader واگذار شوند. اگر آنها را به سیستم ClassLoader واگذار کنند، برنامه‌ها در Android 9 یا بالاتر با NoClassDefFoundError از کار می‌افتند، زیرا آن کلاس‌ها دیگر برای ClassLoader سیستم شناخته نمی‌شوند. برای جلوگیری از مشکلات مشابه در آینده، برنامه ها به طور کلی باید کلاس ها را از طریق برنامه ClassLoader بارگیری کنند نه اینکه مستقیماً به ClassLoader سیستم دسترسی داشته باشند.

شمارش دوربین ها

برنامه‌هایی که روی دستگاه‌های Android 9 اجرا می‌شوند می‌توانند با فراخوانی getCameraIdList() هر دوربین موجود را پیدا کنند. یک برنامه نباید تصور کند که دستگاه فقط یک دوربین پشتی یا فقط یک دوربین جلو دارد.

برای مثال، اگر برنامه شما دکمه ای برای جابجایی بین دوربین جلو و عقب دارد، ممکن است بیش از یک دوربین جلو یا عقب برای انتخاب وجود داشته باشد. شما باید فهرست دوربین را طی کنید، ویژگی های هر دوربین را بررسی کنید و تصمیم بگیرید که کدام دوربین را در معرض دید کاربر قرار دهید.