این صفحه ویژگی های اصلی نسخه اندروید 9 را خلاصه می کند و پیوندهایی به اطلاعات اضافی ارائه می دهد. این خلاصه ویژگی ها بر اساس مکان مستندات ویژگی در این سایت سازماندهی شده اند. بهروزرسانیهای سایت آگوست 2018 را برای راهنمای حرکت بخش و تغییر نام ببینید.
یک تصویر سیستم عمومی (GSI) یک تصویر سیستم با پیکربندی های تنظیم شده برای دستگاه های Android است. تصویر سیستم عمومی (GSI) شامل جزئیات تفاوتهای بین GSI برای دستگاههایی است که با Android 9 راهاندازی میشوند و دستگاههای ارتقا یافته به Android 9.
تأیید سازگاری با چارچوب HIDL روشی برای تأیید سازگاری به عقب چارچوب است.
HAL های موجود پویا از خاموش شدن پویا زیرسیستم های سخت افزاری اندروید در زمانی که استفاده نمی شوند یا مورد نیاز نیستند، پشتیبانی می کنند.
HIDL MemoryBlock یک لایه انتزاعی است که بر روی hidl_memory ، HIDL @1.0::IAllocator و HIDL @1.0::IMapper ساخته شده است. این برای سرویس های HIDL طراحی شده است که دارای چندین بلوک حافظه هستند که یک پشته حافظه را به اشتراک می گذارند.
Android 9 و بالاتر شامل پشتیبانی از همپوشانی های فشرده در تصویر همپوشانی حباب درختی دستگاه (DTBO) هنگام استفاده از نسخه 1 سرصفحه جدول درختی دستگاه است.
اندروید 9 و بالاتر مستلزم آن است که بوت لودر حباب درخت یکپارچه دستگاه را قبل از اصلاح ویژگیهای تعریف شده در پوششهای درختی دستگاه (DTO) به هسته ارسال کند.
اندروید 9 و بالاتر شامل یک فیلد نسخه در هدر تصویر DTBO است.
اندروید 9 و بالاتر به پارتیشن DTBO نیاز دارد. برای افزودن گره ها یا ایجاد تغییراتی در ویژگی های SoC DT، بوت لودر باید به صورت پویا یک DT خاص دستگاه را روی SoC DT قرار دهد. برای اطلاعات بیشتر به کامپایل و تأیید مراجعه کنید.
اندروید 9 و بالاتر شامل الزاماتی است که بر هسته، رابط های آن و استفاده از DTBO تأثیر می گذارد. برای اطلاعات بیشتر به این صفحات مراجعه کنید:
- انتشار و به روز رسانی هسته پایدار
- هسته های مشترک اندروید
- نیازهای هسته مدولار
- نیازهای رابط
- روکش درخت دستگاه
برای اطلاع از تغییرات طراحی VNDK در اندروید 9 و بالاتر، به این صفحات مراجعه کنید:
- کیت توسعه بومی فروشنده (VNDK)
- پشتیبانی از سیستم ساخت VNDK
- ابزار تعریف VNDK
- دایرکتوری ها، قوانین، و سیاست
- برنامه های افزودنی VNDK
- فضای نام پیوند دهنده
صفحه پایداری ABI بررسیکننده رابط باینری برنامه (ABI) را توصیف میکند، که تضمین میکند تغییرات ایجاد شده در کتابخانههای VNDK انطباق ABI را حفظ میکند.
یک تصویر سیستمی میتواند از عکسهای فوری VNDK برای ارائه کتابخانههای صحیح VNDK به تصاویر فروشنده استفاده کند، حتی زمانی که تصاویر سیستم و فروشنده از نسخههای مختلف Android ساخته شدهاند.
صفحات زیر در بخش Vendor Interface Object بهروزرسانیهای Android 9 و بالاتر را توضیح میدهند:
صفحات زیر نحوه منسوخ کردن و حذف HIDL HAL ها توسط Android را شرح می دهند:
اندروید 9 و بالاتر از ساخت /product با استفاده از سیستم ساخت اندروید پشتیبانی می کند. پیش از این، Android 8.x جداسازی اجزای خاص سیستم روی تراشه (SoC) را از پارتیشن /system به پارتیشن /vendor بدون اختصاص فضایی برای اجزای خاص OEM ساخته شده از سیستم ساخت اندروید اعمال میکرد.
صفحه Canonical Boot Reason تغییرات مشخصات دلیل بوت لودر را در اندروید 9 و بالاتر توضیح می دهد.
همه دستگاههایی که با Android 9 و بالاتر راهاندازی میشوند باید از system-as-root استفاده کنند که ramdisk.img با system.img (همچنین به عنوان no-ramdisk شناخته میشود) ادغام میکند، که به نوبه خود به عنوان rootfs نصب میشود.
در اندروید 9 و بالاتر، هدر تصویر بوت حاوی فیلدی برای نشان دادن نسخه هدر است. بوت لودر باید این قسمت نسخه را بررسی کرده و هدر را بر اساس آن تجزیه کند.
برای جلوگیری از خرابی OTA به دلیل عدم تطابق بین تصویر بازیابی و پارتیشن DTBO در دستگاههای غیر A/B، تصویر بازیابی باید حاوی اطلاعات تصویر DTBO باشد.
بریدگیهای نمایشگر به توسعهدهندگان برنامه اجازه میدهند تا تجربههای همهجانبه و لبه به لبه را ایجاد کنند و در عین حال فضایی را برای حسگرهای مهم در جلوی دستگاهها ایجاد کنند.
بهروزرسانیهای رفتار چرخش صفحه اندروید 9 و بالاتر شامل پشتیبانی از کنترل رو به روی کاربر برای پین کردن چرخش صفحه به افقی یا عمودی حتی در صورت تغییر موقعیت دستگاه است.
انتقال همزمان برنامه امکان انیمیشن های انتقال برنامه جدید را فراهم می کند.
Android 9 و بالاتر شامل یک سرویس Text Classifier است که روش پیشنهادی برای پیادهسازی طبقهبندی متن و یک سرویس پیشفرض است.
اندروید 9 و بالاتر شامل پشتیبانی از رنگ های گسترده است، از جمله:
- محدوده دینامیکی بالا (HDR)
- پردازش محتوا در فضای رنگی BT2020، اما نه به عنوان فضای داده هدف نهایی
برای استفاده از رنگهای گسترده، پشته نمایش کامل دستگاه (مانند صفحه نمایش، آهنگساز سختافزار، GPU) باید از رنگهای گستره وسیع یا فرمتهای بافر پشتیبانی کند. حتی اگر سختافزار آن را پشتیبانی کند، نیازی به ادعای پشتیبانی از محتوای گسترده نیست. با این حال، برای استفاده کامل از سخت افزار، رنگ با وسعت گسترده باید فعال شود. برای جلوگیری از یک تجربه بصری ناسازگار، رنگ با گستره وسیع نباید در طول زمان اجرا خاموش شود.
سند تعریف سازگاری Android 9 (CDD) با بهروزرسانیهایی برای ویژگیهای جدید و تغییرات در الزامات عملکردهای قبلی منتشر شده، بر اساس نسخههای قبلی تکرار میشود.
چارچوب ویجت برنامه اندروید، به ویژه زمانی که کاربر ویجت ها را حذف یا به صورت دستی اضافه می کند، دید بیشتری را در تعاملات کاربر ارائه می دهد. این قابلیت به طور پیش فرض با Launcher3 ارائه می شود.
اگر بر اساس Launcher3 نباشد، سازندگان باید برنامههای راهانداز خود را (که با دستگاهها ارسال میشوند) بهروزرسانی کنند تا از این ویژگی پشتیبانی کنند. OEM ها باید از فیلد جدید ویجت Features در راه اندازی پیش فرض خود پشتیبانی کنند.
توجه داشته باشید که این ویژگی فقط زمانی کار میکند که راهاندازها آن را مطابق انتظار اجرا کنند. AOSP شامل یک نمونه پیاده سازی است. برای کد نمونه ارائه شده به AOSP Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca مراجعه کنید.
پخش سیستم محافظت شده را می توان به برنامه هایی ارسال کرد که دارای مجوز INSTALL_PACKAGES هستند، هر زمان که تغییری در ویژگی هایی مانند محلی یا تراکم نمایش وجود داشته باشد. گیرنده ها را می توان در مانیفست ثبت کرد و فرآیندی برای دریافت پخش بیدار می شود. این برای نصبکنندههای بسته مفید است که میخواهند اجزای اضافی برنامهها را با چنین تغییراتی نصب کنند، که غیرمعمول است، زیرا تغییرات پیکربندی واجد شرایط برای راهاندازی این پخش نادر است.
کد منبع اعلان تغییر وضعیت دستگاه در مکان های زیر در platform/frameworks/base قرار دارد:
-
api/system-current.txt -
core/java/android/content/Intent.java -
core/res/AndroidManifest.xml -
services/core/java/com/android/server/am/ActivityManagerService.java
تغییرات در معماری اطلاعات برای برنامه تنظیمات، عملکرد بیشتر و اجرای آسانتری را ارائه میکند.
ابزار خط فرمان Atest به شما امکان میدهد تستهای اندروید را به صورت محلی بسازید، نصب و اجرا کنید، بدون نیاز به آگاهی از گزینههای خط فرمان مهار تست فدراسیون تجارت، سرعت اجرای مجدد تست را بسیار بالا میبرد.
بستههای Compatibility Test Suite (CTS) که از اندروید 9 پشتیبانی میکنند در صفحه دانلودهای CTS موجود هستند. کد منبع برای تست های ارائه شده را می توان با تگ android-cts-9.0_r1 در درخت منبع باز همگام سازی کرد.
برای اندروید 9، CTS v2 دستور و آرگومان زیر را دریافت می کند:
-
run retryتمام تست هایی را که شکست خورده اند یا از جلسات قبلی اجرا نشده اند دوباره امتحان می کند. -
'--shard-countخردههای یک CTS به تعداد معینی از تکههای مستقل اجرا میشود تا روی چندین دستگاه به صورت موازی اجرا شوند.
علاوه بر این، دستور غیرمستند قبلی --retry-type به همان مرجع فرمان کنسول CTS v2 اضافه شده است.
سرویس Secure Element با شناسایی اینکه آیا دستگاهها دارای پیادهسازی SE HAL هستند یا خیر، عناصر ایمن پشتیبانی شده از پلتفرم جهانی را بررسی میکند و اگر چنین است، چه تعداد. این به عنوان پایه ای برای آزمایش API و اجرای عنصر امن زیرین استفاده می شود.
جعبه ترکیب سنسور در مجموعه تست عکس دوربین (Camera ITS) تست ترکیب سنسور و تست همگام سازی چند دوربین استفاده می شود و یک محیط آزمایشی ثابت برای اندازه گیری دقت مهر زمانی دوربین و سایر سنسورها برای تلفن های اندرویدی فراهم می کند. برای اطلاعات بیشتر به این صفحات مراجعه کنید:
- راهنمای شروع سریع جعبه فیوژن سنسور مراحل تنظیم تست فیوژن سنسور و جعبه فیوژن سنسور را برای اولین بار ارائه می دهد.
- مونتاژ جعبه فیوژن سنسور مراحلی را برای مونتاژ جعبه فیوژن سنسور ارائه می دهد.
میدان دید وسیع ITS-in-a-box یک سیستم خودکار است که برای آزمایش سیستم های دوربین میدان دید گسترده (WFoV) و میدان دید معمولی (RFoV) در Camera ITS طراحی شده است.
معماری کنترلکننده میزبان مجموعه تست فروشنده (VTS) معماری چارچوب آزمایشی VTS است که با سرویس سرویس آزمایشی مبتنی بر ابر آن یکپارچه شده است.
آزمایش HAL آگاه از نام سرویس VTS از دریافت نام سرویس یک نمونه HAL بر اساس دستگاهی که آزمایشهای VTS روی آن اجرا میشود، پشتیبانی میکند.
بررسی قابلیت آزمایش VTS HAL شامل یک روش زمان اجرا برای استفاده از پیکربندی دستگاه برای شناسایی اینکه کدام آزمایش VTS باید برای آن هدف دستگاه نادیده گرفته شود.
زیرساخت تست خودکار یک زیرساخت VTS برای آزمایش خودکار VTS، CTS یا سایر آزمایشها بر روی دستگاههای شریکی است که تصویر سیستم عمومی AOSP (GSI) را اجرا میکنند.
در اندروید، تله متری فرآیند جمع آوری خودکار اطلاعات استفاده و تشخیص در مورد دستگاه، سیستم اندروید و برنامه ها است. در نسخههای قبلی اندروید، پشته تلهمتری محدود بود و اطلاعات مورد نیاز برای شناسایی و حلوفصل قابلیت اطمینان سیستم و مشکلات دستگاه یا برنامه را جمعآوری نمیکرد. این امر شناسایی علل ریشه ای مسائل را دشوار، اگر نگوییم غیرممکن می کرد.
اندروید 9 دارای ویژگی statsd telemetry است که با جمع آوری سریعتر داده های بهتر، این کمبود را برطرف می کند. statsd آمار مصرف برنامه، باتری و فرآیند و خرابی ها را جمع آوری می کند. داده ها تجزیه و تحلیل شده و برای بهبود محصولات، سخت افزار و خدمات استفاده می شود.
برای جزئیات بیشتر، frameworks/base/cmds/statsd/ ببینید.
طرح امضای v3 APK از چرخش کلید APK پشتیبانی می کند.
اندروید 9 شامل کلاس عمومی BiometricPrompt است که برنامهها میتوانند از آن برای ادغام پشتیبانی احراز هویت بیومتریک به روشی که دستگاهها و مدالیتهها را تشخیص میدهند، استفاده کنند. برای اطلاعات بیشتر در مورد ادغام پشته بیومتریک خود برای گنجاندن BiometricPrompt ، به بیومتریک مراجعه کنید.
اندروید 9 شامل پشتیبانی بیشتر از ابزارهای کاهش سوء استفاده و تجزیه و تحلیل است .
یکپارچگی جریان کنترل (CFI) یک مکانیسم امنیتی است که تغییرات در نمودار جریان کنترل اصلی یک باینری کامپایل شده را ممنوع می کند و انجام چنین حملاتی را به طور قابل توجهی دشوارتر می کند.
علاوه بر سیستم CFI که به طور پیشفرض فعال است، اندروید 9 و بالاتر از یکپارچگی جریان کنترل هسته (CFI) پشتیبانی میکند.
رمزگذاری مبتنی بر فایل (FBE) برای کار با فضای ذخیره سازی قابل قبول به روز شده است. دستگاه های جدید باید از رمزگذاری مبتنی بر فایل به جای رمزگذاری فول دیسک استفاده کنند.
اندروید 9 و بالاتر شامل پشتیبانی از رمزگذاری ابرداده در جایی که پشتیبانی سختافزاری وجود دارد، میشود. با رمزگذاری ابرداده، یک کلید موجود در زمان راهاندازی، از رمزگذاری مبتنی بر فایل برای رمزگذاری هر محتوای نامشخصی استفاده میکند.
اندروید 9 و بالاتر شامل Keymaster 4 است که این ویژگی ها را دارد.
Android 9 و بالاتر شامل پشتیبانی از کلیدهای Android Keystore است که در یک CPU فیزیکی مجزا که برای برنامههای کاربردی با امنیت بالا ساخته شده است، ذخیره و استفاده میشوند، مانند یک عنصر امن جاسازی شده (SE) . StrongBox Keymaster پیاده سازی Keymaster HAL در سخت افزار امن گسسته است. یک StrongBox دارای:
- CPU گسسته
- ذخیره سازی امن یکپارچه
- مولد اعداد تصادفی واقعی با کیفیت بالا
- بسته بندی مقاوم در برابر دستکاری
- مقاومت کانال جانبی
برای وارد کردن ایمن یک کلید به Keymaster 4، کلیدی که خارج از دستگاه ایجاد شده است با مشخصات مجوزهایی که نحوه استفاده از کلید را مشخص می کند رمزگذاری می شود.
Keymaster 4 شامل 3DES برای سازگاری با سیستم های قدیمی که از 3DES استفاده می کنند.
برای پشتیبانی از ساختار مدولار Treble و شکستن اتصال system.img به boot.img ، Keymaster 4 مدل binding نسخه کلید را تغییر داد تا سطوح پچ جداگانه برای هر پارتیشن داشته باشد. این اجازه می دهد تا هر پارتیشن به طور مستقل به روز شود و در عین حال محافظت برگشتی را فراهم می کند.
دستگاههای پشتیبانیشده که با نصب Android 9 راهاندازی میشوند، به توسعهدهندگان امکان استفاده از Android Protected Confirmation API را میدهند. با استفاده از این API، برنامهها میتوانند از یک نمونه از ConfirmationPrompt برای نمایش درخواستی به کاربر استفاده کنند و از آنها بخواهند یک عبارت کوتاه را تأیید کنند. این عبارت به یک برنامه اجازه می دهد تا مجدداً تأیید کند که کاربر می خواهد یک تراکنش حساس را انجام دهد، مانند پرداخت.
سندباکس برنامه دارای محافظها و موارد آزمایشی جدیدی است تا اطمینان حاصل شود که همه برنامههای غیرمجاز که اندروید 9 و بالاتر را هدف قرار میدهند، جعبههای سندباکس SELinux را اجرا میکنند.
بهروزرسانیهای Treble SELinux در اندروید 9 و بالاتر در چندین صفحه در بخش SELinux ثبت شدهاند.
Vendor init با استفاده از یک دامنه SELinux جداگانه برای اجرای دستورات /vendor با مجوزهای خاص فروشنده، سوراخ در تقسیم سیستم/فروشنده Treble را می بندد.
اندروید 9 ویژگی های سیستم را از اشتراک گذاری بی مورد بین پارتیشن های system و vendor محدود می کند و روشی را برای اطمینان از سازگاری بین ویژگی های سیستم مشترک ارائه می دهد.
Android 9 شامل تستهای زمان ساخت جدید است که اطمینان میدهد همه فایلها در مکانهای خاص دارای ویژگیهای مناسب هستند. به عنوان مثال، تمام فایل های موجود در sysfs دارای ویژگی sysfs_type لازم هستند.
بهروزرسانیهای جلوههای صوتی با وضوح بالا شامل تبدیل پردازش افکت از int16 به فرمت شناور و افزایش آهنگهای خروجی همزمان مشتری، حداکثر حافظه کلاینت/سرور و کل آهنگهای ترکیبی است.
Android 9 و بالاتر از استفاده از دوربینهای USB plug-and-play (یعنی وبکمها) با استفاده از API استاندارد Android Camera2 و رابط دوربین HIDL پشتیبانی میکند.
دستگاه های دوربین می توانند قابلیت ردیابی حرکت را تبلیغ کنند .
پشتیبانی از چند دوربین شامل پشتیبانی API برای دستگاههای چند دوربینه از طریق یک دستگاه دوربین منطقی جدید متشکل از دو یا چند دستگاه دوربین فیزیکی است که در یک جهت قرار دارند.
پیادهسازی پارامترهای جلسه میتواند با فعال کردن مشتریان دوربین برای پیکربندی فعال زیرمجموعهای از پارامترهای درخواستی پرهزینه به عنوان بخشی از مرحله اولیهسازی جلسه ضبط، تاخیرها را کاهش دهد.
حمل و نقل بافر دوربین تک تولید کننده، چند مصرف کننده مجموعه ای از روش ها است که به مشتریان دوربین اجازه می دهد تا سطوح خروجی را به صورت پویا اضافه و حذف کنند، در حالی که جلسه ضبط فعال است و جریان دوربین ادامه دارد.
Android 9 و بالاتر پشتیبانی بهبود یافتهای را برای شرکتهایی که برنامههای داده را با استفاده از APIهای SubscriptionPlan پیادهسازی میکنند، ارائه میکند.
Android 9 و بالاتر API هایی را ارائه می دهد که به برنامه های تماس شخص ثالث (3P) اجازه می دهد تا تماس های شرکت مخابراتی ورودی را مدیریت کنند و تماس ها را در گزارش تماس های سیستم ثبت کنند.
در اندروید 9، AOSP یک پایگاه داده شناسه حامل را برای کمک به شناسایی حامل اضافه می کند. پایگاه داده با ارائه روشی متداول برای شناسایی اپراتورها، منطق تکراری و تجربیات تکه تکه برنامه را به حداقل می رساند.
سیمکارت جاسازیشده (eSIM یا eUICC) جدیدترین فناوری است که به کاربران تلفن همراه امکان میدهد پروفایل شرکت مخابراتی را دانلود کنند و خدمات شرکت مخابراتی را بدون داشتن سیمکارت فیزیکی فعال کنند. در اندروید 9 و بالاتر، چارچوب Android APIهای استانداردی را برای دسترسی به eSIM و مدیریت پروفایلهای اشتراک در eSIM ارائه میکند. برای اطلاعات بیشتر رجوع کنید به:
اندروید 9 و بالاتر بهبودهایی را در تنظیمات کاربر برای زیرسیستم چندرسانه ای IP (IMS) ارائه می دهد. میتوانید بهجای اشتراکگذاری این تنظیمات در همه اشتراکها، LTE صوتی (VoLTE)، تماس ویدیویی، و تماس Wi-Fi را بر اساس هر اشتراک تنظیم کنید.
در Android 9 و بالاتر، Intent.ACTION_SIM_STATE_CHANGED منسوخ شده است و دو پخش جداگانه برای وضعیت کارت و وضعیت برنامه کارت اضافه شده است، TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED و TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED .
با این تغییرات، گیرندههایی که فقط باید بدانند کارت موجود است یا نه، نیازی به گوش دادن به تغییرات وضعیت برنامه ندارند و گیرندههایی که فقط باید بدانند آیا برنامههای کارت آماده هستند یا خیر، مجبور نیستند به تغییرات وضعیت کارت گوش دهند.
دو پخش جدید @SystemApis هستند و چسبناک نیستند. فقط گیرنده هایی با مجوز READ_PRIVILEGED_PHONE_STATE می توانند پخش ها را دریافت کنند.
وقتی قفل دستگاه را باز میکنید، مقاصد بازپخش نمیشوند. گیرندههایی که به پخشهایی که قبل از باز کردن قفل ارسال میشوند وابسته هستند یا باید از directBootAware استفاده کنند یا باید وضعیت را پس از باز کردن قفل توسط کاربر جستجو کنند. وضعیت ها را می توان با استفاده از API های مربوطه در TelephonyManager، getSimCardState() و getSimApplicationState() جستجو کرد.
ویژگی Wi-Fi اپراتور به دستگاهها اجازه میدهد به طور خودکار به شبکههای Wi-Fi اجرا شده توسط اپراتور متصل شوند. در مناطق پر ازدحام یا با حداقل پوشش سلولی مانند استادیوم یا ایستگاه قطار زیرزمینی، وای فای حامل به بهبود اتصال و تخلیه ترافیک کمک می کند.
تصادفیسازی MAC به دستگاهها اجازه میدهد از آدرسهای MAC تصادفی هنگام جستوجوی شبکههای جدید استفاده کنند در حالی که در حال حاضر با شبکه مرتبط نیستند. در اندروید 9 و بالاتر، یک گزینه توسعه دهنده را می توان فعال کرد تا باعث شود دستگاه هنگام اتصال به شبکه Wi-Fi از یک آدرس MAC تصادفی استفاده کند.
هنگامی که ویژگی روشن کردن Wi-Fi به طور خودکار فعال باشد، هر زمان که دستگاه در نزدیکی یک شبکه Wi-Fi ذخیره شده با نشانگر قدرت سیگنال دریافتی نسبتاً بالا (RSSI) باشد، Wi-Fi به طور خودکار دوباره فعال می شود.
زمان رفت و برگشت Wi-Fi (RTT) به دستگاهها اجازه میدهد تا فاصله تا سایر دستگاههای پشتیبانی کننده را اندازهگیری کنند، خواه آنها نقاط دسترسی (APs) باشند یا Wi-Fi Aware همتایان (اگر Wi-Fi Aware در دستگاه پشتیبانی میشود). این ویژگی بر اساس پروتکل IEEE 802.11mc ساخته شده است و برنامهها را قادر میسازد تا از دقت و آگاهی موقعیت مکانی پیشرفته استفاده کنند.
مدلهای بهبود یافته امتیازدهی Wi-Fi به سرعت و با دقت تعیین میکنند که چه زمانی دستگاه باید از شبکه Wi-Fi متصل خارج شود یا وارد یک شبکه Wi-Fi جدید شود. این مدل ها با اجتناب از شکاف در اتصال، تجربه ای مطمئن و بدون درز را برای کاربران فراهم می کنند.
مقادیر RSSI را در منابع config.xml بررسی و تنظیم کنید، به خصوص موارد زیر:
-
config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz -
config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz -
config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz -
config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz
Wi-Fi STA/AP Concurrency توانایی دستگاه ها برای کار همزمان در حالت ایستگاه (STA) و نقطه دسترسی (AP) است. برای دستگاههایی که از Wi-Fi همزمان دو باند (DBS) پشتیبانی میکنند، این ویژگی قابلیتهایی مانند عدم ایجاد اختلال در STA Wi-Fi را هنگامی که کاربر میخواهد نقطه اتصال (SoftAP) را فعال کند، باز میکند.
WifiStateMachine کلاس اصلی است که برای کنترل فعالیت Wi-Fi، هماهنگ کردن ورودی کاربر (حالتهای عملیاتی: نقطه اتصال، اسکن، اتصال، یا خاموش) و کنترل اقدامات شبکه Wi-Fi (مانند اسکن یا اتصال) استفاده میشود.
در اندروید 9 و بالاتر، کد فریمورک Wi-Fi و پیادهسازی WifiStateMachine مجدداً طراحی شده است که منجر به کاهش اندازه کد، منطق کنترل Wi-Fi آسانتر برای دنبال کردن، بهبود جزئیات کنترل و افزایش پوشش و کیفیت تستهای واحد میشود.
در سطح بالایی، WifiStateMachine به Wi-Fi اجازه می دهد تا در یکی از چهار حالت باشد:
- حالت مشتری (قابلیت اتصال و اسکن)
- حالت فقط اسکن
- حالت SoftAP (نقطه اتصال Wi-Fi)
- غیرفعال (وای فای کاملاً خاموش است)
هر حالت Wi-Fi نیازمندیهای متفاوتی برای اجرای سرویسها دارد و باید به شیوهای ثابت راهاندازی شود و فقط رویدادهای مربوط به عملکرد خود را مدیریت کند. پیاده سازی جدید کد را به رویدادهای مربوط به آن حالت محدود می کند و زمان اشکال زدایی و خطر معرفی باگ های جدید را به دلیل پیچیدگی کاهش می دهد. علاوه بر مدیریت صریح برای عملکرد حالت، مدیریت رشته به شیوه ای ثابت مدیریت می شود و استفاده از کانال های ناهمزمان به عنوان مکانیزمی برای همگام سازی حذف می شود.
در Android 9 و بالاتر، مجوز برنامه CHANGE_WIFI_STATE به طور پیش فرض فعال است. میتوانید مجوز هر برنامهای را در صفحه تنظیمات در تنظیمات > برنامهها و اعلانها > دسترسی ویژه برنامه > کنترل Wi-Fi غیرفعال کنید.
برنامهها باید بتوانند مواردی را که مجوز CHANGE_WIFI_STATE اعطا نشده است رسیدگی کنند.
برای تایید این رفتار، تست های روبوالکتریک و دستی را اجرا کنید.
برای تست دستی:
- به تنظیمات > برنامهها و اعلانها > دسترسی ویژه برنامه > کنترل Wi-Fi بروید.
- مجوز برنامه خود را انتخاب و خاموش کنید.
- بررسی کنید که برنامه شما میتواند با سناریویی که مجوز
CHANGE_WIFI_STATEاعطا نشده است، مقابله کند.
به دلیل مسائل امنیتی، راهاندازی محافظت شده از Wi-Fi (WPS) در WiFiManager منسوخ شده و در اندروید ۹ و بالاتر غیرفعال شده است. با این حال، WiFiDirect هنوز از WPS در درخواست کننده WPA استفاده می کند.
اندروید 9 و بالاتر از اجرای API گرافیکی Vulkan 1.1 پشتیبانی می کند.
اندروید 9 و بالاتر شامل ابزار WinScope برای ردیابی انتقال پنجره است. WinScope زیرساخت ها و ابزارهایی را برای ثبت و تجزیه و تحلیل وضعیت مدیر پنجره در حین و پس از انتقال فراهم می کند. این اجازه می دهد تا ضبط و گام برداشتن از طریق انتقال پنجره، در حالی که ضبط تمام وضعیت مدیر پنجره مربوط به یک فایل ردیابی. میتوانید از این دادهها برای پخش مجدد و گذر از انتقال استفاده کنید.
کد منبع ابزار WinScope در platform/development/tools/winscope قرار دارد.
Automotive Audio معماری صوتی را برای پیاده سازی های اندروید مرتبط با خودرو توصیف می کند.
شبکه های عصبی (NN) HAL انتزاعی از شتاب دهنده های مختلف را تعریف می کند. درایورهای این شتاب دهنده ها باید با این HAL مطابقت داشته باشند.
Vehicle Properties تغییرات رابط HAL خودرو را توصیف می کند.
هنگام کار با HAL های جدید سیستم ناوبری ماهواره ای جهانی (GNSS) (نسخه 1.1+)، Android Framework تنظیمات Android را نظارت می کند. شرکا می توانند تنظیمات را از سرویس های Google Play یا سایر به روز رسانی های سیستم تغییر دهند. این تنظیمات به GNSS HAL می گویند که آیا ماهواره های GNSS خاصی نباید استفاده شوند. این می تواند در صورت خطاهای مستمر ماهواره یا صورت فلکی GNSS، یا واکنش سریعتر به مسائل اجرای GNSS HAL که ممکن است هنگام اختلاط صورت های فلکی با استفاده از سیستم های زمانی مختلف و رویدادهای خارجی، مانند جابجایی اعداد در ثانیه کبیسه، روز یا هفته، رخ دهد، مفید باشد.
در اندروید 9، GNSS HAL نسخه 1.1 یا بالاتر می تواند اطلاعات مربوط به API سخت افزاری را به پلتفرم منتقل کند. پلتفرم باید رابط IGnssCallback را پیاده سازی کند و یک دسته را به HAL ارسال کند. GNSS HAL اطلاعات مدل سخت افزاری را از طریق متد LocationManager#getGnssHardwareModelName() ارسال می کند. سازندگان دستگاه باید با ارائه دهندگان GNSS HAL خود برای ارائه این اطلاعات در صورت امکان همکاری کنند.
پیکربندی کنترل دسترسی اختیاری (DAC) حاوی بهروزرسانیهایی برای مکانیسم شناسههای Android (AIDs) برای گسترش قابلیتهای سیستم فایل است.
در اندروید 9 و بالاتر، اگر مجوزهایی وجود دارد که باید رد شوند، XML را ویرایش کنید تا به جای برچسب permission استفاده شده در نسخههای قبلی، از تگ deny-permission استفاده کنید.
اندروید 9 پشتیبانی بهبود یافته ای را برای تخمین پهنای باند ارائه می دهد. اگر برنامههای اندروید به پهنای باند داده دسترسی داشته باشند، میتوانند تنظیمات وضوح مناسبتری را برای تماسهای ویدیویی و پخش ویدیو انجام دهند.
در دستگاههای دارای Android نسخه 6.0 یا بالاتر، تماسگیرندهای که میخواهد پهنای باند را برای یک شبکه سلولی تخمین بزند، ConnectivityManager.requestBandwidthUpdate() فرا میخواند، و این چارچوب ممکن است پهنای باند پایینپیوند تخمینی ارائه کند.
اما در دستگاههایی که نسخه 9 یا بالاتر دارند، زمانی که تغییر قابل توجهی در پهنای باند تخمینی ایجاد میشود، فراخوانی onCapabilitiesChanged() بهطور خودکار فعال میشود و فراخوانی requestBandwidthUpdate() بدون عملیات است. getLinkDownstreamBandwidthKbps() و getLinkUpstreamBandwidthKbps() با اطلاعات به روز شده ارائه شده توسط لایه فیزیکی پر شده اند.
علاوه بر این، دستگاهها میتوانند پهنای باند سلول LTE را از طریق ServiceState.getCellBandwidths() بررسی کنند. این به برنامهها اجازه میدهد تعیین کنند که چه مقدار پهنای باند (فرکانس) در یک سلول معین در دسترس است. اطلاعات پهنای باند سلول از طریق یک منوی مخفی در دسترس است تا آزمایشگران میدانی بتوانند جدیدترین اطلاعات را بررسی کنند.
ابزار ترافیک شبکه eBPF از ترکیبی از اجرای هسته و فضای کاربر برای نظارت بر استفاده از شبکه بر روی یک دستگاه از آخرین راهاندازی دستگاه استفاده میکند. این ابزار قابلیتهای اضافی مانند برچسبگذاری سوکت، جداسازی ترافیک پیشزمینه/پسزمینه و فایروال هر UID را برای مسدود کردن برنامهها از دسترسی به شبکه بسته به وضعیت دستگاه فراهم میکند.
اکنون دستگاه ها می توانند از نسخه های بعدی سیستم عامل بازیابی شوند. این به ویژه زمانی مفید است که کاربران گوشی های خود را ارتقا داده باشند اما سپس آنها را گم یا خراب کرده باشند.
اگر یک OEM عوامل پشتیبان را برای هر یک از بستههای سیستم (اندروید، سیستم، تنظیمات) تغییر دهد، آن عوامل باید مجموعههای پشتیبانگیری را که در نسخههای بالاتر پلتفرم ساخته شدهاند، بدون خرابی و با بازیابی حداقل برخی از دادهها، بازیابی کنند.
استفاده از اعتبارسنجی را برای بررسی مقادیر نامعتبر یک قطعه داده پشتیبان در نظر بگیرید و فقط داده های معتبر را بازیابی کنید، مانند core/java/android/provider/SettingsValidators.java .
این ویژگی به طور پیش فرض روشن است. پشتیبانی SettingsBackupAgent برای بازیابی از نسخههای آینده را میتوان از طریق Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION غیرفعال کرد. هیچ پیاده سازی اضافی مورد نیاز نیست مگر اینکه سازنده دستگاه یکی از عوامل پشتیبان موجود در ROM را گسترش دهد (یا یک عامل سفارشی اضافه کند).
این ویژگی اجازه می دهد تا سیستم را از نسخه های آینده پلت فرم بازیابی کند. با این حال، منطقی است که انتظار داشته باشیم که داده های بازیابی شده کامل نشوند. دستورالعمل های زیر برای عوامل پشتیبان زیر اعمال می شود:
PackageManagerBackupAgent از نسخههای بعدی دادههای پشتیبان از طریق فرمتسازی پشتیبانی میکند. برنامههای افزودنی در اینجا باید با کد بازیابی فعلی سازگار باشند یا دستورالعملهای کلاس را دنبال کنند، که شامل برهم زدن ثابتهای مناسب است.
SystemBackupAgent در اندروید 9 و بالاتر
restoreAnyVersion = falseرا مشخص می کند. بازیابی از نسخه های بالاتر API را پشتیبانی نمی کند.SettingsBackupAgent در اندروید 9 و بالاتر
restoreAnyVersion = trueرا مشخص می کند. پشتیبانی جزئی از طریق اعتبار سنجی وجود دارد. یک تنظیم را می توان از یک نسخه API بالاتر بازیابی کرد اگر اعتبارسنجی برای آن در سیستم عامل هدف وجود داشته باشد. افزودن هر تنظیمی باید با اعتبارسنجی آن همراه باشد. برای جزئیات کلاس را بررسی کنید.هر عامل پشتیبان سفارشی موجود در رام باید کد نسخه خود را هر زمان که تغییر ناسازگاری در قالب داده های پشتیبان ایجاد می شود افزایش دهد و اگر نماینده آنها آمادگی مقابله با داده های پشتیبان نسخه بعدی کد خود را نداشته باشد، از
restoreAnyVersion = false(پیش فرض) اطمینان حاصل کند.
تغییرات UX برای نمایه های مدیریت شده ، شناسایی، دسترسی و کنترل نمایه مدیریت شده را برای کاربران آسان تر می کند.
یک @SystemApi جدید به دارندگان دستگاه اجازه میدهد بهروزرسانیهای OTA، از جمله بهروزرسانیهای امنیتی را بهطور نامحدود متوقف کنند .
Android 9 و بالاتر شامل android.hardware.health HAL 2.0، ارتقاء نسخه اصلی از health@1.0 HAL است. برای اطلاعات بیشتر به این صفحات مراجعه کنید:
Android 9 و بالاتر شامل یک راه حل ذخیره APK برای نصب سریع برنامه های از پیش بارگذاری شده در دستگاهی است که از پارتیشن های A/B پشتیبانی می کند. OEM ها می توانند پیش بارگذاری ها و برنامه های محبوب را در حافظه پنهان APK که عمدتاً در پارتیشن خالی B در دستگاه های جدید پارتیشن بندی شده A/B ذخیره شده است، بدون تأثیر بر فضای داده رو به روی کاربر قرار دهند.
اندروید 9 و بالاتر از بهینهسازی هدایتشده با نمایه Clang (PGO) در ماژولهای اندرویدی بومی که قوانین ساخت طرح اولیه دارند، پشتیبانی میکند.
یک حالت خاص از SQLiteDatabase به نام compatibility write-ahead logging (WAL) به پایگاه داده اجازه می دهد تا journal_mode=WAL استفاده کند در حالی که حداکثر یک اتصال در هر پایگاه داده حفظ می شود.
Android 9 بهینه سازی زمان بوت را همانطور که در Optimizing Boot Times توضیح داده شده تغییر می دهد.
اندروید 9 و بالاتر شامل محدودیتهایی در پسزمینه است که به کاربران اجازه میدهد برنامههایی را که ممکن است باتری را خالی میکنند محدود کنند. این سیستم همچنین ممکن است پیشنهاد کند برنامه هایی را که بر سلامت دستگاه تأثیر منفی می گذارند غیرفعال کنید.
اندروید 9 دستگاههای بدون باتری را زیباتر از نسخههای قبلی مدیریت میکند. اندروید 9 کد دستگاههای بدون باتری را حذف میکند که بهطور پیشفرض فرض میکردند باتری وجود دارد، 100 درصد شارژ شده و در سلامتی خوب با خواندن دمای معمولی روی ترمیستور خود هستند.