بازبینی را ببینید
- [7.6.1/H-1-1] باید فقط از یک ABI (فقط 64 بیتی یا فقط 32 بیتی) پشتیبانی کند.
بازبینی را ببینید
الزامات جدید را شروع کنید
اگر پیاده سازی دستگاه های دستی شامل پشتیبانی از Vulkan باشد، آنها:
- [ 7.1 .4.2/H-1-1] باید الزامات مشخص شده توسط نمایه Android Baseline 2021 را برآورده کند.
بازبینی را ببینید
الزامات جدید را شروع کنید
اگر پیاده سازی های دستگاه Watch شامل پشتیبانی از Vulkan باشد، آنها:
- [ 7.1 .4.2/W-1-1] باید الزامات مشخص شده توسط نمایه Android Baseline 2021 را برآورده کند.
بازبینی را ببینید
الزامات جدید را شروع کنید
اگر پیادهسازیهای دستگاه Automotive شامل پشتیبانی از Vulkan باشد، آنها:
- [ 7.1 .4.2/A-1-1] باید الزامات مشخص شده توسط نمایه Android Baseline 2021 را برآورده کند.
برای پارامتر ODM_SKU:
بازبینی را ببینید
مقدار این فیلد باید به صورت ASCII 7 بیتی قابل رمزگذاری باشد و با عبارت منظم
^([0-9A-Za-z.,_-]+)$
مطابقت داشته باشد.
جزئیات اضافه شده برای فرمت/کدک Vorbis:
بازبینی را ببینید
رمزگشایی: پشتیبانی از محتوای مونو، استریو، 5.0 و 5.1 با نرخ نمونه برداری 8000، 12000، 16000، 24000 و 48000 هرتز.
رمزگذاری: پشتیبانی از محتوای مونو و استریو با نرخ نمونه برداری 8000، 12000، 16000، 24000 و 48000 هرتز.
بازبینی را ببینید
- [C-1-13] باید الزامات مشخص شده توسط نمایه Android Baseline 2021 را برآورده کند.
حذف:
بازبینی را ببینید
- نباید صوتی AOAv2 مستند شده در اسناد Open Accessory Protocol 2.0 Android را پیاده سازی کند. صدای AOAv2 از نسخه اندروید 8.0 (سطح API 26) منسوخ شده است.
برای حذف محتوای تکراری [C-SR-1] به [C-SR-7] شماره گذاری شد و [C-SR-8] حذف شد:
بازبینی را ببینید
[C-SR-1] اکیداً توصیه میشود که دادههای هستهای را که فقط در حین مقداردهی اولیه نوشته شدهاند، پس از مقداردهی اولیه، فقط خواندنی علامتگذاری شده نگه دارید (مثلا
__ro_after_init
).[C-SR-2] برای تصادفی کردن طرحبندی کد هسته و حافظه، و اجتناب از مواجهههایی که تصادفیسازی را به خطر میاندازد، اکیداً توصیه میشوند (مثلاً
CONFIG_RANDOMIZE_BASE
با آنتروپی بوتلودر از طریق/chosen/kaslr-seed Device Tree node
EFI_RNG_PROTOCOL
) .[C-SR-3] برای فعال کردن یکپارچگی جریان کنترل (CFI) در هسته برای ایجاد حفاظت بیشتر در برابر حملات استفاده مجدد از کد (مانند
CONFIG_CFI_CLANG
وCONFIG_SHADOW_CALL_STACK
) اکیداً توصیه می شود.[C-SR-4] اکیداً توصیه می شود که یکپارچگی کنترل جریان (CFI)، پشته تماس سایه (SCS) یا پاکسازی سرریز عدد صحیح (IntSan) را در مؤلفه هایی که آن را فعال کرده اند غیرفعال نکنید.
[C-SR-5] اکیداً برای فعال کردن CFI، SCS و IntSan برای هر مؤلفه اضافی فضای کاربری حساس به امنیت همانطور که در CFI و IntSan توضیح داده شده است، توصیه می شود.
[C-SR-6] برای فعال کردن مقداردهی اولیه پشته در هسته برای جلوگیری از استفاده از متغیرهای محلی اولیه (
CONFIG_INIT_STACK_ALL
یاCONFIG_INIT_STACK_ALL_ZERO
) اکیداً توصیه می شود. همچنین، پیادهسازیهای دستگاه نباید مقداری را که توسط کامپایلر برای مقداردهی اولیه محلیها استفاده میشود، در نظر بگیرند.[C-SR-7] اکیداً برای فعال کردن مقداردهی اولیه پشته در هسته برای جلوگیری از استفاده از تخصیصهای هیپ اولیه (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) توصیه میشود و نباید مقدار استفاده شده توسط کرنل را برای مقداردهی اولیه آن تخصیصها فرض کنند.
9.11. کلیدها و اعتبارنامه ها :
بازبینی را ببینید
- [C-1-6] باید یکی از موارد زیر را پشتیبانی کند:
- IKeymasterDevice 3.0،
- IKeymasterDevice 4.0،
- IKeymasterDevice 4.1،
- IKeyMintDevice نسخه 1، یا
- IKeyMintDevice نسخه 2.
- [C-1-6] باید یکی از موارد زیر را پشتیبانی کند:
9.11.1. صفحه قفل ایمن، احراز هویت و دستگاه های مجازی :
بازبینی را ببینید
- [C-8-3] آنها نباید یک API را برای استفاده توسط برنامه های شخص ثالث برای تغییر حالت قفل در معرض نمایش قرار دهند.
بازبینی را ببینید
- [C-12-4] باید
TrustManagerService.revokeTrust()
را فراخوانی کند.- پس از حداکثر 24 ساعت از اعطای اعتماد، یا
- پس از 8 ساعت پنجره بیکار، یا
- اگر پیادهسازیها از محدوده امن و دقیق رمزنگاری همانطور که در [C-12-5] تعریف شده است استفاده نمیکنند، زمانی که اتصال زیربنایی به دستگاه فیزیکی نزدیک از بین میرود.
- [C-12-5] پیادهسازیهایی که بر محدوده ایمن و دقیق برای برآوردن الزامات [C-12-4] تکیه دارند، باید از یکی از راهحلهای زیر استفاده کنند:
- پیاده سازی با استفاده از UWB:
- باید الزامات انطباق، گواهی، دقت و کالیبراسیون برای UWB را که در 7.4.9 توضیح داده شده است، برآورده کند.
- باید از یکی از حالت های امنیتی P-STS ذکر شده در 7.4.9 استفاده کنید.
- پیاده سازی ها با استفاده از شبکه آگاهی همسایگی Wi-Fi (NAN):
- باید الزامات دقت در 2.2.1 [7.4.2.5/H-SR-1] را برآورده کند، از پهنای باند 160 مگاهرتز (یا بالاتر) استفاده کند و مراحل تنظیم اندازه گیری مشخص شده در کالیبراسیون حضور را دنبال کند.
- باید از Secure LTF همانطور که در IEEE 802.11az تعریف شده است استفاده کنید.
- پیاده سازی با استفاده از UWB:
بازبینی را ببینید
الزامات جدید را شروع کنید
اگر پیادهسازیهای دستگاه دستی
FEATURE_BLUETOOTH_LE
را اعلام کنند، آنها:- [ 7.4 .3/H-1-3] باید اندازه گیری و جبران Rx Offset شود تا اطمینان حاصل شود که میانه BLE RSSI در فاصله 1 متری از دستگاه مرجعی که در
ADVERTISE_TX_POWER_HIGH
ارسال می کند -50dBm +/-15 دسی بل است. - [ 7.4 .3/H-1-4] باید برای Tx offset اندازه گیری و جبران شود تا اطمینان حاصل شود که میانه BLE RSSI -50dBm +/-15 dB در هنگام اسکن از دستگاه مرجع واقع در فاصله 1 متری و ارسال در
ADVERTISE_TX_POWER_HIGH
است.
- [ 7.4 .3/H-1-3] باید اندازه گیری و جبران Rx Offset شود تا اطمینان حاصل شود که میانه BLE RSSI در فاصله 1 متری از دستگاه مرجعی که در
بازبینی را ببینید
اگر پیادهسازیهای دستگاه دستی از System API
HotwordDetectionService
یا مکانیزم دیگری برای تشخیص کلید واژه بدون علامت دسترسی میکروفون پشتیبانی میکنند، آنها:- [9.8/H-1-6] نباید اجازه دهد بیش از 100 بایت داده به خارج از سرویس تشخیص کلمه کلیدی در هر نتیجه کلید واژه موفق منتقل شود ، به جز برای داده های صوتی ارسال شده از طریق HotwordAudioStream .
بازبینی را ببینید
تغییر [9.8/H-1-13] به:
- [9.8/H-SR-3] اکیداً توصیه میشود که فرآیند میزبانی سرویس تشخیص کلمه کلیدی را حداقل یک بار در هر ساعت یا هر 30 رویداد محرک سختافزاری، هرکدام که زودتر اتفاق بیفتد، مجدداً راه اندازی کنند.
بازبینی را ببینید
الزامات حذف شده [9.8.2/H-4-3]، [9.8.2/H-4-4]، [9.8.2/H-5-3].
بازبینی را ببینید
اگر پیادهسازیهای دستگاه دستی
android.os.Build.VERSION_CODES.U
را برایandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
برگردانند، آنگاه آنها:- [ 7.5 /H-1-3] باید از ویژگی
android.info.supportedHardwareLevel
به عنوانFULL
یا بهتر برای دوربین اصلی پشتی وLIMITED
یا بهتر برای دوربین اصلی جلو پشتیبانی کند.
- [ 7.5 /H-1-3] باید از ویژگی
بازبینی را ببینید
اگر پیادهسازیهای دستگاه تلویزیون دارای نمایشگر داخلی نباشند، اما در عوض از یک صفحه نمایش خارجی متصل از طریق HDMI پشتیبانی میکنند، آنها:
- [ 5.8 /T-0-1] باید حالت خروجی HDMI را روی بالاترین وضوح برای فرمت پیکسل انتخابی تنظیم کنید که با نرخ تجدید 50 هرتز یا 60 هرتز برای نمایشگر خارجی کار می کند، بسته به نرخ تازه سازی ویدیو برای منطقه ای که دستگاه فروخته می شود. باید
حالت خروجی HDMI را برای انتخاب حداکثر وضوح قابل پشتیبانی با نرخ تجدید 50 هرتز یا 60 هرتز تنظیم کنید.
- [ 5.8 /T-0-1] باید حالت خروجی HDMI را روی بالاترین وضوح برای فرمت پیکسل انتخابی تنظیم کنید که با نرخ تجدید 50 هرتز یا 60 هرتز برای نمایشگر خارجی کار می کند، بسته به نرخ تازه سازی ویدیو برای منطقه ای که دستگاه فروخته می شود. باید
بازبینی را ببینید
- نیاز حذف شده [C-1-9]
بازبینی را ببینید
اگر پیادهسازیهای دستگاه پشتیبانی از رمزگشای Dolby Vision را از طریق
HDR_TYPE_DOLBY_VISION
اعلام کنند، آنها:- [C-1-3] باید شناسه آهنگ لایه(های) پایه سازگار با عقب (در صورت وجود) را با شناسه تراک لایه Dolby Vision ترکیبی تنظیم کند.
7.1.1.1. اندازه و شکل صفحه نمایش :
بازبینی را ببینید
اگر پیادهسازیهای دستگاه از صفحههایی با قابلیت پیکربندی اندازه
UI_MODE_TYPE_NORMAL
پشتیبانی میکنند و از نمایشگر(های) فیزیکی با گوشههای گرد برای نمایش این صفحهها استفاده میکنند، آنها:- [C-1-1] باید اطمینان حاصل کند که حداقل یکی از الزامات زیر برای هر یک از این نمایشگرها برآورده شده است:
- هنگامی که
یک جعبه 15و 18 dp در1518 dp در هر گوشه از نمایشگر منطقی لنگر انداخته شود، حداقل یک پیکسل از هر جعبه بر روی صفحه نمایش قابل مشاهده است.
- هنگامی که
- [C-1-1] باید اطمینان حاصل کند که حداقل یکی از الزامات زیر برای هر یک از این نمایشگرها برآورده شده است:
بازبینی را ببینید
الزامات زیر را دوباره برقرار کرد:
اگر پیاده سازی های دستگاه
FEATURE_BLUETOOTH_LE
را اعلام کنند، آنها:[C-SR-2] به شدت توصیه می شود برای اندازه گیری و جبران افست Rx برای اطمینان از اینکه میانه BLE RSSI 60-dBm +/-10 دسی بل در فاصله 1 متری از دستگاه مرجعی است که در
ADVERTISE_TX_POWER_HIGH
ارسال می کند، جایی که دستگاه ها به گونه ای جهت گیری شده اند، توصیه می شود. در "صفحه های موازی" با صفحه های رو به یک جهت.[C-SR-3] برای اندازهگیری و جبران Tx Offset برای اطمینان از اینکه میانه BLE RSSI هنگام اسکن از دستگاه مرجع واقع در فاصله 1 متری و ارسال در
ADVERTISE_TX_POWER_HIGH
، جایی که دستگاهها جهتگیری دارند -60dBm +/-10 dB است، به شدت توصیه میشود. به طوری که آنها در "صفحه های موازی" با صفحه نمایش رو به یک جهت هستند.
بازبینی را ببینید
الزامات [C-10-3] و [C-10-4] به 2.2.1 منتقل شد. سخت افزار .
- [C-10-3] برای اطمینان از اینکه میانه BLE RSSI در فاصله 1 متری از دستگاه مرجعی که در
ADVERTISE_TX_POWER_HIGH
ارسال می کند، -55dBm +/-10 dB است، باید برای Rx offset اندازه گیری و جبران شود. - [C-10-4] برای اطمینان از اینکه میانه BLE RSSI هنگام اسکن از دستگاه مرجع در فاصله 1 متری و ارسال در
ADVERTISE_TX_POWER_HIGH
-55dBm +/-10 dB است، باید برای Tx offset اندازه گیری و جبران شود.
بازبینی را ببینید
اگر پیادهسازیهای دستگاه دستی از هر ABI 64 بیتی (با یا بدون هیچ ABI 32 بیتی) پشتیبانی میکنند:
بازبینی را ببینید
- [ 7.5 /H-1-13] اگر بیش از 1 دوربین RGB در پشت وجود دارد، باید از قابلیت
LOGICAL_MULTI_CAMERA
برای دوربین اصلی پشتی پشتیبانی کند.
- [ 7.5 /H-1-13] اگر بیش از 1 دوربین RGB در پشت وجود دارد، باید از قابلیت
بازبینی را ببینید
[ 5.8 /T-0-1] باید حالت خروجی HDMI را روی بالاترین وضوح برای فرمت انتخابی SDR یا HDR تنظیم کنید که با نرخ تازه سازی 50 هرتز یا 60 هرتز برای نمایشگر خارجی کار می کند.
باید حالت خروجی HDMI را برای انتخاب حداکثر وضوحی که میتواند با نرخ تازهسازی 50 هرتز یا 60 هرتز پشتیبانی کند، تنظیم کنید.
بازبینی را ببینید
- [9/W-0-1] باید
android.hardware.security.model.compatible feature
را اعلام کند.
- [9/W-0-1] باید
بازبینی را ببینید
- [C-0-12] باید یک اتم
LMK_KILL_OCCURRED_FIELD_NUMBER
در
بازبینی را ببینید
- [C-0-13] برای نمایش باید فرمان پوسته
dumpsys gpu --gpuwork
را اجرا کند
- [C-0-12] باید یک اتم
بازبینی را ببینید
اگر پیادهسازیهای دستگاه از یک هسته لینوکس استفاده میکنند که قادر به پشتیبانی از SELinux است، آنها:
بازبینی را ببینید
اگر پیاده سازی های دستگاه از هسته ای غیر از لینوکس یا لینوکس بدون SELinux استفاده کنند، آنها:
بازبینی را ببینید
پیادهسازیهای دستگاه اندروید در صورتی که تمام معیارهای زیر را داشته باشند به عنوان دستی طبقهبندی میشوند:
- اندازه صفحه نمایش مورب فیزیکی در محدوده 4 اینچ
3.3 اینچ (یا 2.5 اینچ برای پیاده سازی دستگاهی که در سطح API 29 یا قبل از آن عرضه شده است)تا 8 اینچ داشته باشید.
الزامات جدید را شروع کنید
- یک رابط ورودی صفحه لمسی داشته باشید.
- اندازه صفحه نمایش مورب فیزیکی در محدوده 4 اینچ
بازبینی را ببینید
پیاده سازی دستگاه های دستی:
- [ 7.1 .1.1/H-0-1] باید حداقل یک
نمایشگر سازگار با Android داشته باشد که تمام الزامات توضیح داده شده در این سند را برآورده کند.صفحه نمایشی که حداقل 2.2 اینچ در لبه کوتاه و 3.4 اینچ در لبه بلند اندازه دارد.
اگر پیاده سازی های دستگاه دستی از چرخش صفحه نرم افزار پشتیبانی می کنند، آنها:
- [ 7.1 .1.1/H-1-1]* باید صفحه منطقی را که برای برنامه های شخص ثالث در دسترس است، حداقل 2 اینچ در لبه(های) کوتاه و 2.7 اینچ در لبه(های) بلند قرار دهد. دستگاههایی که در Android API سطح 29 یا قبل از آن ارسال شدهاند، ممکن است از این شرط مستثنی باشند.
اگر پیاده سازی های دستگاه دستی از چرخش صفحه نرم افزار پشتیبانی نمی کنند، آنها:
- [ 7.1 .1.1/H-2-1]* باید صفحه منطقی را که برای برنامه های شخص ثالث در دسترس است، حداقل 2.7 اینچ روی لبه(های) کوتاه قرار دهد. دستگاههایی که در Android API سطح 29 یا قبل از آن ارسال شدهاند، ممکن است از این شرط مستثنی باشند.
الزامات جدید را شروع کنید
[ 7.1 .1.1/H-0-3]* باید هر صفحه نمایش
UI_MODE_NORMAL
را که برای برنامه های شخص ثالث در دسترس است، در یک ناحیه نمایش فیزیکی بدون مانع که حداقل 2.2 اینچ در لبه کوتاه و 3.4 اینچ در لبه بلند است، نقشه برداری کند.[ 7.1 .1.3/H-0-1]* باید مقدار
DENSITY_DEVICE_STABLE
را 92% یا بیشتر از چگالی فیزیکی واقعی نمایشگر مربوطه تنظیم کند.
اگر پیادهسازیهای دستگاه دستی
android.hardware.audio.output
وandroid.hardware.microphone
را اعلام کنند، آنها:[ 5.6 /H-1-1] باید میانگین تأخیر رفت و برگشت پیوسته 300 میلی ثانیه یا کمتر در 5 اندازه گیری، با میانگین انحراف مطلق کمتر از 30 میلی ثانیه ، در مسیرهای داده زیر داشته باشد: "بلندگو به میکروفون"، 3.5 میلی متر آداپتور Loopback (در صورت پشتیبانی)، USB Loopback (در صورت پشتیبانی).
[ 5.6 /H-1-2] باید میانگین تأخیر ضربه به تن 300 میلی ثانیه یا کمتر در حداقل 5 اندازه گیری در مسیر داده بلندگو به میکروفون داشته باشد.
اگر پیادهسازیهای دستگاه دستی شامل حداقل یک محرک لمسی باشد، آنها:
- [ 7.10 /H]* نباید از محرک لمسی (ویبراتور) جرم دوار غیرعادی (ERM) استفاده کرد.
- [ 7.10 /H]* باید همه ثابتهای عمومی را برای لمسی واضح در android.view پیادهسازی کند ، تأیید، رد، GESTURE_START و GESTURE_END).
- [ 7.10 /H]* باید همه ثابتهای عمومی را برای لمسی واضح در android.os.VibrationEffect پیادهسازی کند، یعنی (EFFECT_TICK، EFFECT_CLICK، EFFECT_HEAVY_CLICK و EFFECT_DOUBLE_CLICK) و همه ثابتهای عمومی امکانپذیر
PRIMITIVE_*
. CLICK، TICK، LOW_TICK، QUICK_FALL، QUICK_RISE، SLOW_RISE، SPIN، THUD). برخی از این موارد اولیه، مانند LOW_TICK و SPIN ممکن است تنها در صورتی امکان پذیر باشند که ویبراتور بتواند فرکانس های نسبتا پایین را پشتیبانی کند. - [7.10/H]* باید دستورالعمل نگاشت ثابت های عمومی در android.view.HapticFeedbackConstants به ثابت های توصیه شده android.os.VibrationEffect ، با روابط دامنه مربوطه را دنبال کنید.
- [ 7.10 /H]* باید ارزیابی کیفیت برای APIهای createOneShot() و createWaveform() را دنبال کند.
- [ 7.10 /H]* باید بررسی کند که نتیجه API عمومی android.os.Vibrator.hasAmplitudeControl() به درستی قابلیت های ویبراتور آنها را منعکس می کند.
- [ 7.10 /H]* باید محل قرارگیری محرک را در نزدیکی محلی قرار دهد که معمولاً دستگاه را با دست نگه داشته یا لمس میکند.
اگر پیادهسازیهای دستگاه دستی شامل حداقل یک محرک رزونانس خطی 7.10 باشد، آنها:
- [ 7.10 /H] باید محل قرارگیری محرک را در نزدیکی محلی قرار دهید که معمولاً دستگاه را با دست نگه داشته یا لمس میکنید.
- [ 7.10 /H] باید محرک لمسی را در محور X (چپ-راست) جهت
عمودیطبیعی دستگاه حرکت دهد.
اگر پیادهسازیهای دستگاه دستی دارای یک محرک لمسی با هدف عمومی باشند که محرک تشدید خطی محور X (LRA) است، آنها:
- [ 7.10 /H] باید فرکانس تشدید LRA محور X کمتر از 200 هرتز باشد.
- [ 7.1 .1.1/H-0-1] باید حداقل یک
بازبینی را ببینید
پیاده سازی دستگاه های دستی باید از فرمت های رمزگذاری ویدیوی زیر پشتیبانی کرده و آنها را برای برنامه های شخص ثالث در دسترس قرار دهند:
- [ 5.2 /H-0-3] AV1
پیاده سازی دستگاه های دستی باید از فرمت های رمزگشایی ویدیوی زیر پشتیبانی کرده و آنها را برای برنامه های شخص ثالث در دسترس قرار دهند:
- [ 5.3 /H-0-6] AV1
بازبینی را ببینید
اگر پیادهسازیهای دستگاه از جمله کلید ناوبری عملکرد اخیر که در بخش 7.2.3 توضیح داده شده است، رابط را تغییر دهد، آنها:
- [ 3.8 .3/H-1-1] باید رفتار پین کردن صفحه را اجرا کند و منوی تنظیمات را برای تغییر دادن ویژگی در اختیار کاربر قرار دهد.
اگر پیادهسازیهای دستگاه دستی شامل پشتیبانی از
ControlsProviderService
وControl
API باشد و به برنامههای شخص ثالث اجازه انتشار کنترلهای دستگاه را بدهد، آنها:- [ 3.8 .16/H-1-6] پیادهسازی دستگاه باید بهطور دقیق توانایی کاربر را به شرح زیر ارائه کند:
- اگر دستگاه
config_supportsMultiWindow=true
را تنظیم کرده باشد و برنامه فوق دادهMETA_DATA_PANEL_ACTIVITY
را در اعلانControlsProviderService
، از جمله ComponentName یک فعالیت معتبر (همانطور که توسط API تعریف شده است) اعلام کند، برنامه باید فعالیت مذکور را در این کاربر تعبیه کند. - اگر برنامه فوق داده
META_DATA_PANEL_ACTIVITY
را اعلام نکند، باید فیلدهای مشخص شده را همانطور که توسطControlsProviderService
API ارائه شده است و همچنین فیلدهای مشخص شده توسط Control API ارائه شود.
- اگر دستگاه
- [ 3.8 .16/H-1-7] اگر برنامه فوق داده را
META_DATA_PANEL_ACTIVITY
اعلام کند، باید مقدار تنظیم تعریف شده در [3.8.16/H-1-5] را با استفاده ازEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
هنگام راهاندازی فعالیت ارسال کند.
اگر پیادهسازیهای دستگاه به کاربران اجازه دهند هر نوع تماسی را برقرار کنند، آنها
- [ 7.4.1.2 /H-0-1] باید پرچم ویژگی را اعلام کند
android.software.telecom
. - [ 7.4.1.2 /H-0-2] باید چارچوب مخابراتی را پیاده سازی کند.
بازبینی را ببینید
پیاده سازی دستگاه های دستی:
- [ 8.5 /H-0-1] باید
در منوی تنظیمات،امکاناتی را برای کاربر فراهم کند تا همه برنامهها را با سرویسهای پیشزمینه فعال یا کارهای آغاز شده توسط کاربر، از جمله مدت زمان هر یک از این سرویسها از زمانی که شروع شده است، همانطور که در سند SDK توضیح داده شده است، مشاهده کند. .و توانایی متوقف کردن برنامهای که یک سرویس پیشزمینه یا یک کار آغاز شده توسط کاربر را اجرا میکند.با قابلیت توقف برنامهای که سرویس پیشزمینه را اجرا میکند و نمایش همه برنامههایی که سرویسهای پیشزمینه فعال دارند و مدت زمان هر یک از این سرویسها از زمانی که شروع به کار کرده است، همانطور که در سند SDK توضیح داده شده است.- ممکن است برخی از برنامهها از توقف یا فهرست شدن در چنین شرایطی که در سند SDK توضیح داده شده است معاف شوند.
- [ 8.5 /H-0-1] باید
- [ 8.5 /H-0-2]باید برای متوقف کردن برنامهای که یک سرویس پیشزمینه یا یک کار آغاز شده توسط کاربر را اجرا میکند، توانایی کاربر را فراهم کند.
بازبینی را ببینید
اگر پیادهسازیهای دستگاه از android.hardware.telephony
پشتیبانی میکنند، آنها:
- [ 9.5 /H-1-1] نباید
UserManager.isHeadlessSystemUserMode
را رویtrue
تنظیم کند.
اگر پیادهسازیهای دستگاه دارای صفحه قفل ایمن باشند و شامل یک یا چند نماینده اعتماد باشد که TrustAgentService
System API را پیادهسازی میکند، آنها:
- [ 9.11.1 /H-1-1] باید کاربر را برای یکی از روش های احراز هویت اولیه توصیه شده (مانند: پین، الگو، رمز عبور) بیشتر از یک بار در هر 72 ساعت به چالش بکشد.
اگر پیاده سازی های دستگاه دستی UserManager.isHeadlessSystemUserMode
را روی true
تنظیم کنند، آنها
اگر پیادهسازیهای دستگاه دستی از System API HotwordDetectionService
یا مکانیزم دیگری برای تشخیص کلمه کلیدی بدون علامت دسترسی میکروفون پشتیبانی میکنند، آنها:
- [9.8/H-1-1] باید مطمئن شود که سرویس تشخیص کلمه کلیدی فقط میتواند دادهها را به System،
ContentCaptureService
یا سرویس تشخیص گفتار روی دستگاه ایجاد شده توسطSpeechRecognizer#createOnDeviceSpeechRecognizer()
ارسال کند. - [9.8/H-1-6] نباید اجازه دهد بیش از 100 بایت داده (به استثنای جریان های صوتی) به خارج از سرویس تشخیص کلمه کلیدی در هر نتیجه موفق کلمه کلیدی منتقل شود.
- [9.8/H-1-15] باید اطمینان حاصل کند که جریان های صوتی ارائه شده در نتایج موفقیت آمیز کلمه کلیدی یک طرفه از سرویس تشخیص کلمه کلیدی به سرویس تعامل صوتی منتقل می شوند.
اگر پیادهسازیهای دستگاه شامل برنامهای باشد که از System API HotwordDetectionService
یا مکانیسمی مشابه برای تشخیص کلیدواژه بدون علامت استفاده از میکروفون استفاده میکند، برنامه:
- [9.8/H-2-3] نباید از سرویس تشخیص کلمه کلیدی، دادههای صوتی، دادههایی که میتوانند برای بازسازی (به طور کامل یا جزئی) صدا یا محتوای صوتی غیرمرتبط با خود کلمه کلیدی استفاده شوند، به جز
ContentCaptureService
یا سرویس تشخیص گفتار روی دستگاه
اگر پیادهسازیهای دستگاه دستی از System API VisualQueryDetectionService
یا مکانیزم دیگری برای تشخیص پرس و جو بدون علامت دسترسی میکروفون و/یا دوربین پشتیبانی میکنند، آنها:
- [9.8/H-3-1] باید مطمئن شود که سرویس تشخیص پرس و جو فقط می تواند داده ها را به سیستم یا
ContentCaptureService
یا سرویس تشخیص گفتار روی دستگاه (ایجاد شده توسطSpeechRecognizer#createOnDeviceSpeechRecognizer()
ارسال کند. - [9.8/H-3-2] نباید اجازه دهد هیچ گونه اطلاعات صوتی یا تصویری به خارج از
VisualQueryDetectionService
منتقل شود، مگر بهContentCaptureService
یا سرویس تشخیص گفتار روی دستگاه. - [9.8/H-3-3] هنگامی که دستگاه قصد کاربر را برای تعامل با برنامه دستیار دیجیتال (مثلاً با تشخیص حضور کاربر از طریق دوربین) تشخیص میدهد، باید یک اخطار کاربر را در رابط کاربری سیستم نمایش دهد.
- [9.8/H-3-4] باید یک نشانگر میکروفون نمایش داده شود و درخواست کاربر شناسایی شده را بلافاصله پس از شناسایی درخواست کاربر در UI نمایش دهد.
- [9.8/H-3-5] نباید به یک برنامه کاربردی قابل نصب توسط کاربر اجازه دهد تا سرویس تشخیص درخواست بصری را ارائه دهد.
بازبینی را ببینید
اگر پیادهسازیهای دستگاه دستی android.os.Build.VERSION_CODES.T
را برای android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
برگردانند، آنگاه آنها:
- باید الزامات رسانه ذکر شده در بخش CDD 2.2.7.1 Android 13 را برآورده کند.
الزامات جدید را شروع کنید
اگر پیادهسازیهای دستگاه دستیandroid.os.Build.VERSION_CODES.U
را برای android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
برگردانند، آنگاه آنها:- [5.1/H-1-1] باید حداکثر تعداد جلسات رمزگشای سخت افزاری سخت افزاری را که می تواند همزمان در هر ترکیب کدک اجرا شود، از طریق روش های
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
تبلیغ کند. - [5.1/H-1-2] باید از 6 نمونه از جلسات رمزگشای ویدیوی سخت افزاری 8 بیتی (SDR) (AVC، HEVC، VP9، AV1 یا جدیدتر) در هر ترکیب کدک که همزمان با 3 جلسه با وضوح 1080p@30 فریم بر ثانیه اجرا می شود، پشتیبانی کند. و 3 جلسه با وضوح 4k@30fps، مگر اینکه AV1. کدک های AV1 فقط برای پشتیبانی از وضوح 1080p مورد نیاز هستند، اما همچنان برای پشتیبانی از 6 نمونه با سرعت 1080p30fps مورد نیاز هستند.
- [5.1/H-1-3] باید حداکثر تعداد جلسات رمزگذاری سخت افزاری سخت افزاری را که می تواند به طور همزمان در هر ترکیب کدک اجرا شود، از طریق روش های
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
تبلیغ کند. - [5.1/H-1-4] باید از 6 نمونه از جلسات رمزگذار ویدیوی سخت افزاری 8 بیتی (SDR) (AVC، HEVC، VP9، AV1 یا جدیدتر) در هر ترکیب کدک که همزمان با 4 جلسه با وضوح 1080p@30 فریم بر ثانیه اجرا می شود، پشتیبانی کند. و 2 جلسه با وضوح 4k@30fps، مگر اینکه AV1. کدک های AV1 فقط برای پشتیبانی از وضوح 1080p مورد نیاز هستند، اما همچنان برای پشتیبانی از 6 نمونه با سرعت 1080p30fps مورد نیاز هستند.
- [5.1/H-1-5] باید حداکثر تعداد جلسات رمزگذار و رمزگشای سخت افزاری سخت افزاری را که می تواند همزمان در هر ترکیب کدک اجرا شود، از طریق روش های
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
تبلیغ کند. - [5.1/H-1-6] باید از 6 نمونه رمزگشای ویدیوی سخت افزاری 8 بیتی (SDR) و جلسات رمزگذار ویدیوی سخت افزاری (AVC، HEVC، VP9، AV1 یا جدیدتر) در هر ترکیب کدک که همزمان با 3 جلسه در 4K اجرا می شود، پشتیبانی کند. رزولوشن @30fps (مگر AV1)، که حداکثر 2 جلسه رمزگذار و 3 جلسه با وضوح 1080p است. کدک های AV1 فقط برای پشتیبانی از وضوح 1080p مورد نیاز هستند، اما همچنان برای پشتیبانی از 6 نمونه با سرعت 1080p30fps مورد نیاز هستند.
- [5.1/H-1-19] باید از 3 نمونه رسیور ویدیوی سخت افزاری 10 بیتی (HDR) و جلسات رمزگذار ویدیوی سخت افزاری (AVC، HEVC، VP9، AV1 یا جدیدتر) در هر ترکیب کدک که همزمان با وضوح 4K@30fps اجرا می شود، پشتیبانی کند. (مگر AV1) که حداکثر 1 جلسه رمزگذار است که می تواند در قالب ورودی RGBA_1010102 از طریق یک سطح GL پیکربندی شود. در صورت کدگذاری از سطح GL، تولید فراداده HDR توسط رمزگذار مورد نیاز نیست. جلسات کدک AV1 فقط برای پشتیبانی از وضوح 1080p مورد نیاز است، حتی زمانی که این نیاز به 4K نیاز دارد.
- [5.1/H-1-7] باید تأخیر اولیه کدک 40 میلی ثانیه یا کمتر برای یک جلسه کدگذاری ویدیویی 1080p یا کوچکتر برای همه رمزگذارهای ویدیوی سخت افزاری در هنگام بارگذاری داشته باشد. Load در اینجا به عنوان یک جلسه رمزگذاری همزمان ویدیویی 1080p تا 720p با استفاده از کدکهای ویدیویی سختافزاری همراه با مقداردهی اولیه ضبط صوتی-تصویری 1080p تعریف میشود. برای کدک Dolby Vision، تأخیر اولیه کدک باید 50 میلی ثانیه یا کمتر باشد.
- [5.1/H-1-8] باید تأخیر اولیه کدک 30 میلی ثانیه یا کمتر برای یک جلسه رمزگذاری صوتی 128 کیلوبیت بر ثانیه یا نرخ بیت پایین تر برای همه رمزگذارهای صوتی در هنگام بارگذاری داشته باشد. Load در اینجا به عنوان یک جلسه رمزگذاری همزمان ویدیویی 1080p تا 720p با استفاده از کدکهای ویدیویی سختافزاری همراه با مقداردهی اولیه ضبط صوتی-تصویری 1080p تعریف میشود.
- [5.1/H-1-9] باید از 2 نمونه از جلسات رمزگشای ویدیویی سخت افزاری ایمن (AVC، HEVC، VP9، AV1 یا جدیدتر) در هر ترکیب کدک که همزمان با وضوح 4k@30 فریم در ثانیه (مگر AV1) اجرا می شود، برای هر دو 8- پشتیبانی کند. محتوای بیت (SDR) و 10 بیت HDR. جلسات کدک AV1 فقط برای پشتیبانی از وضوح 1080p مورد نیاز است، حتی زمانی که این نیاز به 4K نیاز دارد.
- [5.1/H-1-10] باید از 3 نمونه از جلسات رمزگشای ویدیویی غیرایمن همراه با 1 نمونه از جلسه رمزگشای ویدیوی سخت افزاری ایمن (در مجموع 4 نمونه) (AVC، HEVC، VP9، AV1 یا جدیدتر) در هر کدک پشتیبانی کند. ترکیبی که همزمان با 3 جلسه با وضوح 4K@30 فریم در ثانیه (مگر اینکه AV1) اجرا می شود که شامل یک جلسه رمزگشای ایمن و 1 جلسه nn امن با وضوح 1080p@30fps است که حداکثر 2 جلسه می تواند در 10 بیت HDR باشد. جلسات کدک AV1 فقط برای پشتیبانی از وضوح 1080p مورد نیاز است، حتی زمانی که این نیاز به 4K نیاز دارد.
- [5.1/H-1-11] باید از رمزگشای ایمن برای هر رسیور سخت افزاری AVC، HEVC، VP9 یا AV1 روی دستگاه پشتیبانی کند.
- [5.1/H-1-12] باید تأخیر اولیه کدک 40 میلی ثانیه یا کمتر برای یک جلسه رمزگشایی ویدیوی 1080p یا کوچکتر برای همه رمزگشاهای ویدیوی سخت افزاری در هنگام بارگذاری داشته باشد. Load در اینجا به عنوان یک جلسه رمزگذاری همزمان ویدئویی 1080p تا 720p با استفاده از کدکهای ویدئویی سختافزاری همراه با مقداردهی اولیه پخش صوتی-تصویری 1080p تعریف میشود. برای کدک Dolby Vision، تأخیر اولیه کدک باید 50 میلی ثانیه یا کمتر باشد.
- [5.1/H-1-13] باید تأخیر اولیه کدک 30 میلی ثانیه یا کمتر برای جلسه رمزگشایی صوتی 128 کیلوبیت بر ثانیه یا نرخ بیت پایین تر برای همه رمزگشاهای صوتی در هنگام بارگذاری داشته باشد. Load در اینجا به عنوان یک جلسه رمزگذاری همزمان ویدئویی 1080p تا 720p با استفاده از کدکهای ویدئویی سختافزاری همراه با مقداردهی اولیه پخش صوتی-تصویری 1080p تعریف میشود.
- [5.1/H-1-14] باید از رمزگشای سخت افزاری AV1 اصلی 10، سطح 4.1 و دانه فیلم پشتیبانی کند.
- [5.1/H-1-15] باید حداقل 1 رمزگشای ویدیویی سخت افزاری داشته باشد که از 4K60 پشتیبانی می کند.
- [5.1/H-1-16] باید حداقل 1 رمزگذار ویدیوی سخت افزاری داشته باشد که از 4K60 پشتیبانی می کند.
- [5.3/H-1-1] نباید بیش از 1 فریم در 10 ثانیه رها کند (یعنی کمتر از 0.167 درصد افت فریم) برای یک جلسه ویدیویی 4K 60 فریم در ثانیه تحت بارگذاری.
- [5.3/H-1-2] نباید بیش از 1 فریم در 10 ثانیه در طول تغییر وضوح ویدیو در یک جلسه ویدیویی 60 فریم بر ثانیه تحت بارگیری برای یک جلسه 4K کاهش یابد.
- [5.6/H-1-1] باید با استفاده از تست ضربه به تن CTS Verifier تأخیر ضربه به تن 80 میلی ثانیه یا کمتر داشته باشد.
- [5.6/H-1-2] باید تأخیر صوتی رفت و برگشت 80 میلی ثانیه یا کمتر در حداقل یک مسیر داده پشتیبانی شده داشته باشد.
- [5.6/H-1-3] باید صدای >=24 بیتی را برای خروجی استریو بیش از جک های صوتی 3.5 میلی متری در صورت وجود و در صورت پشتیبانی از صدای USB از طریق کل مسیر داده برای تأخیر کم و پیکربندی های جریان پشتیبانی کند. برای پیکربندی تاخیر کم، AAaudio باید توسط برنامه در حالت پاسخ به تماس با تاخیر کم استفاده شود. برای پیکربندی استریم، برنامه باید از Java AudioTrack استفاده کند. در هر دو پیکربندی تاخیر کم و جریان، سینک خروجی HAL باید
AUDIO_FORMAT_PCM_24_BIT
،AUDIO_FORMAT_PCM_24_BIT_PACKED
،AUDIO_FORMAT_PCM_32_BIT
یاAUDIO_FORMAT_PCM_FLOAT
را بپذیرد. - [5.6/H-1-4] باید از دستگاه های صوتی USB 4 کانال پشتیبانی کند (این دستگاه توسط کنترلرهای DJ برای پیش نمایش آهنگ ها استفاده می شود.)
- [5.6/H-1-5] باید از دستگاه های MIDI سازگار با کلاس پشتیبانی کند و پرچم ویژگی MIDI را اعلام کند.
- [5.6/H-1-9] باید از اختلاط حداقل 12 کانال پشتیبانی کند. این به معنای قابلیت باز کردن یک AudioTrack با ماسک کانال 7.1.4 و فضایی سازی مناسب یا پایین میکس کردن همه کانال ها به استریو است.
- [5.6/H-SR] برای پشتیبانی از اختلاط 24 کانال با حداقل پشتیبانی از ماسک های 9.1.6 و 22.2 کانال اکیداً توصیه می شود.
- [5.7/H-1-2] باید
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
را با قابلیتهای رمزگشایی محتوای زیر پشتیبانی کند.
حداقل حجم نمونه | 4 مگابایت |
حداقل تعداد نمونه های فرعی - H264 یا HEVC | 32 |
حداقل تعداد نمونه های فرعی - VP9 | 9 |
حداقل تعداد نمونه فرعی - AV1 | 288 |
حداقل اندازه بافر نمونه فرعی | 1 مگابایت |
حداقل اندازه بافر رمزنگاری عمومی | 500 کیلو بایت |
حداقل تعداد جلسات همزمان | 30 |
حداقل تعداد کلید در هر جلسه | 20 |
حداقل تعداد کل کلیدها (همه جلسات) | 80 |
حداقل تعداد کل کلیدهای DRM (همه جلسات) | 6 |
اندازه پیام | 16 کیلو بایت |
فریم های رمزگشایی شده در ثانیه | 60 فریم بر ثانیه |
- [5.1/H-1-17] باید حداقل 1 رمزگشای تصویر سخت افزاری داشته باشد که از نمایه خط پایه AVIF پشتیبانی می کند.
- [5.1/H-1-18] باید از رمزگذار AV1 پشتیبانی کند که می تواند تا رزولوشن 480p با سرعت 30 فریم در ثانیه و 1 مگابیت بر ثانیه را رمزگذاری کند.
-
[5.12/H-1-1] MUST[5.12/H-SR] قویاً برای پشتیبانی از ویژگیFeature_HdrEditing
برای همه رمزگذارهای سخت افزاری AV1 و HEVC موجود در دستگاه توصیه می شود. - [5.12/H-1-2] باید از فرمت رنگی RGBA_1010102 برای همه رمزگذارهای سخت افزاری AV1 و HEVC موجود در دستگاه پشتیبانی کند.
- [5.12/H-1-3] برای نمونه برداری از بافت های YUV در 8 و 10 بیت، باید پشتیبانی از افزونه EXT_YUV_target را تبلیغ کند.
- [7.1.4/H-1-1] باید حداقل 6 پوشش سخت افزاری در واحد پردازش داده (DPU) Hardware Composer (HWC) داشته باشد، که حداقل 2 مورد از آنها قادر به نمایش محتوای ویدئویی 10 بیتی باشد.
اگر پیادهسازیهای دستگاه دستی android.os.Build.VERSION_CODES.U
را برای android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
برگردانند و شامل پشتیبانی از رمزگذار AVC یا HEVC سختافزاری میشوند، آنگاه آنها:
- [5.2/H-2-1] باید حداقل هدف کیفیتی را که توسط منحنیهای نرخ-اعوجاج رمزگذار ویدیویی برای کدکهای AVC و HEVC سختافزاری تعریف شده است، مطابق با مستندات آتی برآورده کند.
بازبینی را ببینید
android.os.Build.VERSION_CODES.U
را برای android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
برگردانند، آنگاه آنها:- [ 7.5 /H-1-1] باید دارای یک دوربین اصلی در پشت با وضوح حداقل 12 مگاپیکسل باشد که از فیلمبرداری با سرعت 4k@30fps پشتیبانی کند. دوربین اصلی جلو، دوربین پشتی است که کمترین شناسه دوربین را دارد.
- [ 7.5 /H-1-2] باید یک دوربین جلوی اصلی با وضوح حداقل 6 مگاپیکسل داشته باشد و از فیلمبرداری با سرعت 1080p@30fps پشتیبانی کند. دوربین جلوی اصلی، دوربین جلویی است که کمترین شناسه دوربین را دارد.
- [ 7.5 /H-1-3] باید از ویژگی
android.info.supportedHardwareLevel
به عنوان FULL یا بهتر برای هر دو دوربین اصلی پشتیبانی کند. - [ 7.5 /H-1-4] باید از
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
برای هر دو دوربین اصلی پشتیبانی کند. - [ 7.5 /H-1-5] باید دارای تأخیر عکسبرداری JPEG camera2 کمتر از 1000
900میلی ثانیه برای وضوح 1080p باشد که توسط دوربین CTS PerformanceTest در شرایط نوری ITS (3000K) برای هر دو دوربین اصلی اندازه گیری شده است. - [ 7.5 /H-1-6] باید تاخیر راه اندازی camera2 (دوربین باز تا اولین فریم پیش نمایش) کمتر از 500 میلی ثانیه باشد که توسط دوربین CTS PerformanceTest در شرایط نور ITS (3000K) برای هر دو دوربین اصلی اندازه گیری شده است.
- [ 7.5 /H-1-8] باید
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
وandroid.graphics.ImageFormat.RAW_SENSOR
را برای دوربین اصلی پشتی پشتیبانی کند. - [ 7.5 /H-1-9] باید یک دوربین اصلی در پشت داشته باشد که از 720p یا 1080p @ 240fps پشتیبانی کند.
- [ 7.5 /H-1-10] اگر یک دوربین RGB فوق عریض رو به یک جهت باشد، باید حداقل ZOOM_RATIO کمتر از 1.0 برای دوربین های اصلی داشته باشد.
- [ 7.5 /H-1-11] باید پخش همزمان از جلو در دوربین های اصلی را اجرا کند.
- [ 7.5 /H-1-12] باید
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
برای دوربین اصلی جلو و پشتی اصلی پشتیبانی کند. - [ 7.5 /H-1-13] در صورتی که بیش از 1 دوربین RGB در یک جهت باشد، باید از قابلیت
LOGICAL_MULTI_CAMERA
برای دوربین های اصلی پشتیبانی کند. - [ 7.5 /H-1-14] باید از قابلیت
STREAM_USE_CASE
هم برای دوربین اصلی جلو و هم برای دوربین اصلی پشتی پشتیبانی کند. - [ 7.5 /H-1-15] باید از برنامه های افزودنی حالت
بوکه وشب از طریق هر دو برنامه افزودنی CameraX و Camera2 برای دوربین های اصلی پشتیبانی کند. - [ 7.5 /H-1-16] باید از قابلیت DYNAMIC_RANGE_TEN_BIT برای دوربین های اصلی پشتیبانی کند.
- [ 7.5 /H-1-17] باید از CONTROL_SCENE_MODE_FACE_PRIORITY و تشخیص چهره ( STATISTICS_FACE_DETECT_MODE_SIMPLE یا STATISTICS_FACE_DETECT_MODE_FULL ) برای دوربین های اصلی پشتیبانی کند.
بازبینی را ببینید
android.os.Build.VERSION_CODES.U
را برای android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
برگردانند، آنگاه آنها:- [7.1.1.1/H-2-1] باید وضوح صفحه حداقل 1080p داشته باشد.
- [7.1.1.3/H-2-1] باید چگالی صفحه حداقل 400 dpi داشته باشد.
- [7.1.1.3/H-3-1] باید دارای نمایشگر HDR باشد که حداقل 1000 نیت متوسط را پشتیبانی کند.
- [7.6.1/H-2-1] باید حداقل 8 گیگابایت حافظه فیزیکی داشته باشد.
بازبینی را ببینید
android.os.Build.VERSION_CODES.U
را برای android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
برگردانند، آنگاه آنها:- [8.2/H-1-1] باید از عملکرد نوشتن متوالی حداقل 150 مگابایت بر ثانیه اطمینان حاصل کند.
- [8.2/H-1-2] باید از عملکرد نوشتن تصادفی حداقل 10 مگابایت بر ثانیه اطمینان حاصل کند.
- [8.2/H-1-3] باید عملکرد خواندن متوالی حداقل 250 مگابایت بر ثانیه را تضمین کند.
- [8.2/H-1-4] باید عملکرد خواندن تصادفی حداقل 100 مگابایت بر ثانیه را تضمین کند.
- [8.2/H-1-5] باید از عملکرد خواندن و نوشتن متوالی موازی با عملکرد خواندن 2x و نوشتن 1x حداقل 50 مگابایت بر ثانیه اطمینان حاصل کند.
بازبینی را ببینید
پیاده سازی دستگاه های تلویزیونی باید از فرمت های رمزگذاری ویدیوی زیر پشتیبانی کند و آنها را برای برنامه های شخص ثالث در دسترس قرار دهد:
- [ 5.2 /T-0-3] AV1
پیاده سازی دستگاه های تلویزیونی باید از قالب های رمزگشایی ویدیویی زیر پشتیبانی کند و آنها را در دسترس برنامه های شخص ثالث قرار دهد:
- [ 5.3.2 /T-0-7] AV1
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه دارای صفحه قفل ایمن باشد و یک یا چند عامل اعتماد را شامل شود ، که API سیستم TrustAgentService
را پیاده سازی می کند ، آنها:
- [ 9.11.1 /W-1-1] باید کاربر را برای یکی از روشهای تأیید اعتبار اولیه توصیه شده (به عنوان مثال: پین ، الگوی ، رمز عبور) بیشتر از هر 72 ساعت به چالش بکشد.
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه شامل پشتیبانی از رادیو پخش AM/FM و در معرض عملکرد در هر برنامه است ، آنها:
- [ 7.4
.10/A-0-1] باید پشتیبانی را ازFEATURE_BROADCAST_RADIO
اعلام کند.
دوربین نمای بیرونی دوربینی است که مانند دوربین عقب صحنه صحنه های خارج از اجرای دستگاه را نشان می دهد.
پیاده سازی دستگاه های خودرو:
- باید شامل یک یا چند دوربین نمای بیرونی باشد.
اگر پیاده سازی دستگاه های اتومبیل شامل دوربین نمای بیرونی ، برای چنین دوربین ، آنها:
- [ 7.5 /A-1-1] نباید دوربین های نمای بیرونی را از طریق API های دوربین Android در دسترس داشته باشد ، مگر اینکه آنها مطابق با نیازهای اصلی دوربین باشند.
- [ 7.5 /A-SR-1] به شدت توصیه می شود که پیش نمایش دوربین را بچرخانید یا به صورت افقی آینه نشود.
- [ 7.5 /A-SR-2] به شدت توصیه می شود که وضوح حداقل 1.3 مگاپیکسل داشته باشید.
- باید سخت افزار فوکوس ثابت یا EDOF (عمق گسترده فیلد) داشته باشد.
- ممکن است سخت افزاری یا فوکوس خودکار یا نرم افزاری برای تمرکز خودکار در درایور دوربین باشد.
اگر پیاده سازی دستگاه های خودرو شامل یک یا چند دوربین نمای بیرونی و سرویس سیستم نمای بیرونی (EVS) بارگذاری ، پس از آن برای چنین دوربین ، آنها:
- [ 7.5 /A-2-1] نباید پیش نمایش دوربین را بچرخانید یا به صورت افقی آینه کند.
پیاده سازی دستگاه های خودرو:
- ممکن است شامل یک یا چند دوربین باشد که در دسترس برنامه های شخص ثالث است.
اگر پیاده سازی دستگاه های خودرو حداقل یک دوربین را شامل می شود و آن را در دسترس برنامه های شخص ثالث قرار می دهد ، آنها:
- [ 7.5 /A-3-1] باید پرچم ویژگی
android.hardware.camera.any
را گزارش کند. - [ 7.5 /A-3-2] نباید دوربین را به عنوان دوربین سیستم اعلام کند.
- ممکن است از دوربین های خارجی که در بخش 7.5.3 شرح داده شده است پشتیبانی کند.
- ممکن است شامل ویژگی های (مانند فوکوس خودکار و غیره) در دسترس دوربین های عقب باشد که در بخش 7.5.1 توضیح داده شده است.
یک دوربین پشتی به معنای دوربین جهانی است که می تواند در هر مکانی روی وسیله نقلیه قرار بگیرد و رو به قسمت بیرونی کابین وسیله نقلیه قرار دارد. یعنی صحنه هایی را در قسمت دور بدنه وسیله نقلیه مانند دوربین دید عقب نشان می دهد.
یک دوربین جلوی آن به معنای یک دوربین کاربر کاربر است که می تواند در هر مکانی روی وسیله نقلیه واقع شود و در داخل کابین وسیله نقلیه قرار دارد. این همان تصویر کاربر است ، مانند کنفرانس ویدیویی و برنامه های مشابه.
پیاده سازی دستگاه های خودرو:
- [7.5/A-SR-1] به شدت توصیه می شود که یک یا چند دوربین در جهان را در بر بگیرید.
- ممکن است شامل یک یا چند دوربین کاربر کاربر باشد.
- [7.5/A-SR-2] به شدت توصیه می شود که از جریان همزمان دوربین های متعدد پشتیبانی کند.
اگر پیاده سازی دستگاه های خودرو حداقل شامل یک دوربین باشد که در آن جهان قرار دارد ، برای چنین دوربین ، آنها:
- [7.5/A-1-1] باید به گونه ای جهت یابی شود که بعد طولانی دوربین با صفحه XY محورهای سنسور خودروسازی آندروید تراز شود.
- [7.5/A-SR-3] به شدت توصیه می شود که سخت افزار فوکوس ثابت یا EDOF (عمق گسترده فیلد) داشته باشید.
- [7.5/A-1-2] باید دوربین اصلی جهان را به عنوان دوربین جهان با کمترین شناسه دوربین داشته باشد.
اگر پیاده سازی دستگاه های خودرو حداقل شامل یک دوربین است که در آن زمان کاربر کاربر است ، برای چنین دوربین:
- [7.5/A-2-1] دوربین اصلی کاربر کاربر باید دوربین کاربر کاربر با کمترین شناسه دوربین باشد.
- ممکن است به گونه ای گرا باشد که ابعاد طولانی دوربین با صفحه XY محورهای سنسور آندروید اتومبیل تراز شود.
اگر پیاده سازی دستگاه های خودرو شامل دوربینی است که از طریق android.hardware.Camera
یا android.hardware.camera2
API قابل دسترسی است ، پس آنها:
- [7.5/A-3-1] باید با نیاز دوربین اصلی در بخش 7.5 مطابقت داشته باشد.
اگر پیاده سازی دستگاه های خودرو شامل دوربینی است که از طریق android.hardware.Camera
یا android.hardware.camera2
API قابل دسترسی نیست ، پس آنها:
- [7.5/A-4-1] باید از طریق سرویس سیستم دید گسترده قابل دسترسی باشد.
اگر پیاده سازی دستگاه های خودرو شامل یک یا چند دوربین در دسترس از طریق سرویس سیستم نمای گسترده ، برای چنین دوربین ، آنها:
- [7.5/A-5-1] نباید پیش نمایش دوربین را بچرخانید یا به صورت افقی آینه کند.
- [7.5/A-SR-4] به شدت توصیه می شود که وضوح حداقل 1.3 مگاپیکسل داشته باشید.
اگر پیاده سازی دستگاه های خودرو شامل یک یا چند دوربین باشد که از طریق سرویس سیستم نمای گسترده و android.hardware.Camera
یا android.hardware.Camera2
API قابل دسترسی هستند ، سپس ، برای چنین دوربین ، آنها:
- [7.5/A-6-1] باید همان شناسه دوربین را گزارش دهد.
اگر پیاده سازی دستگاه های خودرو یک API دوربین اختصاصی را ارائه می دهد ، آنها:
- [7.5/A-7-1] باید چنین API دوربین را با استفاده از
android.hardware.camera2
API یا API سیستم نمای گسترده پیاده سازی کنید.
به تجدید نظر مراجعه کنید
پیاده سازی دستگاه های خودرو:
- [ 3.8 /A-0-1] نباید به کاربران کامل ثانویه که کاربر پیش زمینه فعلی نیستند ، فعالیت های خود را راه اندازی کرده و در هر نمایشگر به UI دسترسی داشته باشند.
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه های خودرو android.hardware.microphone
اعلام کنید ، آنها:
- [ 9.8.2 /A-1-1] باید هنگام دسترسی به داده های صوتی از میکروفون ، نشانگر میکروفون را نمایش دهد ، اما نه وقتی میکروفون فقط توسط
HotwordDetectionService
،SOURCE_HOTWORD
،ContentCaptureService
یا برنامه هایی که نقش های نامیده شده در بخش را دارند ، دسترسی پیدا می کند. 9.1 با شناسه CDD [C-4-X]. - [ 9.8.2 /A-1-2] نباید نشانگر میکروفون را برای برنامه های سیستم که دارای رابط های کاربر قابل مشاهده یا تعامل مستقیم کاربر هستند ، پنهان کند.
- [ 9.8.2 /A-1-3] باید یک هزینه کاربر را برای جابجایی میکروفون در برنامه تنظیمات فراهم کند.
اگر پیاده سازی دستگاه های اتومبیل android.hardware.camera.any
را اعلام کنید ، پس آنها:
- [ 9.8.2 /A-2-1] وقتی یک برنامه به داده های دوربین زنده دسترسی دارد ، باید نشانگر دوربین را نمایش دهد ، اما نه وقتی دوربین فقط توسط برنامه (ها) که نقش هایی را که تعریف شده در بخش 9.1 مجوزهای
تعریف شده است ،در اختیار شما قرار می دهد. با شناسه CDD [C-4-X][C-3-X].
اگر پیاده سازی دستگاه دارای صفحه قفل ایمن باشد و یک یا چند عامل اعتماد را شامل شود ، که API سیستم TrustAgentService
را پیاده سازی می کند ، آنها:
- [ 9.11.1 /A-1-1] باید کاربر را برای یکی از روشهای تأیید اعتبار اولیه (به عنوان مثال: پین ، الگوی ، رمز عبور) بیشتر از هر 336 ساعت به چالش بکشد.
به تجدید نظر مراجعه کنید
پیاده سازی دستگاه:
- [C-0-8] نباید از نصب برنامه های هدفمند سطح API کمتر از 23 پشتیبانی کند.
به تجدید نظر مراجعه کنید
اگر اجرای دستگاه
android.hardware.nfc.uicc
یاandroid.hardware.nfc.ese
را گزارش می کند ، آنها:- [C-19-1] باید API قصد NFCADAPTER.ACTION_TRANSACTION_DETECTECT را اجرا کند (به عنوان "EVT_TRANSACTION" تعریف شده توسط مشخصات فنی انجمن GSM Ts.26-الزامات گوشی NFC) .
3.3.1. رابط های باینری کاربرد :
به تجدید نظر مراجعه کنید
پیاده سازی دستگاه:
- [C-0-12] MUST export function symbols for the core
Vulkan 1.0Vulkan 1.1 function symbols, as well as theVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
, andVK_KHR_get_physical_device_properties2
extensions through thelibvulkan.so
library. توجه داشته باشید که در حالی که تمام نمادها باید حضور داشته باشند ، بخش 7.1.4.2 با جزئیات بیشتر الزامات مربوط به زمان پیش بینی اجرای کامل هر کارکرد مربوطه را توضیح می دهد.
- [C-0-12] MUST export function symbols for the core
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه شامل خروجی صفحه یا فیلم است ، آنها:
- [C-1-5] باید با استفاده از سبک های تم رنگی با استفاده از سبک های تم رنگی که در
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
ذکر شده است ، تولید کند. theme_customization_overlay_packages مستندات (بهandroid.theme.customization.theme_styles
) ، یعنیTONAL_SPOT
،VIBRANT
،EXPRESSIVE
،SPRITZ
،RAINBOW
،FRUIT_SALAD
وMONOCHROMATIC
.
- [C-1-5] باید با استفاده از سبک های تم رنگی با استفاده از سبک های تم رنگی که در
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه از جمله کلید ناوبری عملکرد Recents همانطور که در بخش 7.2.3 رابط را تغییر داده است ، آنها:
- [C-1-2] باید رفتار پین کردن صفحه را پیاده سازی کرده و منوی تنظیمات را در اختیار کاربر قرار دهد تا ویژگی را تغییر دهد.
3.9.2 پشتیبانی از پروفایل مدیریت شده :
به تجدید نظر مراجعه کنید
اگر پیاده سازی های دستگاه
android.software.managed_users
را اعلام کنید ، آنها:- [C-1-10] باید اطمینان حاصل کند که داده های تصویر در ذخیره سازی مشخصات کار ذخیره می شوند وقتی که یک تصویر با یک پنجره
topActivity
که دارای تمرکز است (که کاربر با آخرین فعالیت در بین همه فعالیت ها تعامل دارد) ضبط می شود و متعلق به یک پروفایل کار است. برنامه - [C-1-11] نباید محتوای صفحه نمایش دیگری (نوار سیستم ، اعلان ها یا هر محتوای پروفایل شخصی) را به جز پنجره برنامه کاربردی کار/ویندوز هنگام ذخیره یک تصویر به پروفایل کار ضبط کنید (برای اطمینان از اینکه داده های پروفایل شخصی است در نمایه کار ذخیره نشده است).
- [C-1-10] باید اطمینان حاصل کند که داده های تصویر در ذخیره سازی مشخصات کار ذخیره می شوند وقتی که یک تصویر با یک پنجره
3.9.5 چارچوب وضوح خط مشی دستگاه : بخش جدید
به تجدید نظر مراجعه کنید
اگر اجرای دستگاه
android.software.device_admin
یاandroid.software.managed_users
را گزارش می کند ، پس آنها:- [C-1-1] باید تعارضات خط مشی دستگاه را مطابق مستندات AOSP برطرف کند.
به تجدید نظر مراجعه کنید
پیاده سازی دستگاه باید از رمزگذاری رمزگذاری تصویر زیر پشتیبانی کند:
- [C-0-4] AVIF
- دستگاه ها باید
BITRATE_MODE_CQ
و مشخصات پایه پشتیبانی کنند.
- دستگاه ها باید
- [C-0-4] AVIF
به تجدید نظر مراجعه کنید
پیاده سازی دستگاه باید از رمزگشایی تصویر زیر پشتیبانی کند:
[C-0-7] AVIF (مشخصات پایه)
به تجدید نظر مراجعه کنید
قالب/کدک جزئیات انواع فایل پشتیبانی شده/قالبهای کانتینر JPEG پایه+مترقی JPEG (.jpg) GIF gif (.gif) PNG PNG (png.) BMP BMP (.bmp) وب پی وب (.webp) خام ARW (.ARW) ، CR2 (.CR2) ، DNG (.DNG) ، NEF (.NEF) ، NRW (.NRW) ، ORF (.orf) ، PEF (.pef) ، RAF (.RAF) ، RW2 ( .rw2) ، srw (.srw) HEIF تصویر ، جمع آوری تصویر ، توالی تصویر heif (.heif) ، heic (.heic) AVIF (مشخصات پایه) تصویر ، جمع آوری تصویر ، نمایه پایه توالی تصویر ظرف HEIF (.avif) به تجدید نظر مراجعه کنید
قالب/کدک جزئیات انواع پرونده/قالبهای کانتینر که باید پشتیبانی شوند H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- ماتروسکا (.mkv ، فقط رمزگشایی)
H.264 AVC برای جزئیات بیشتر به بخش 5.2 و 5.3 مراجعه کنید - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts ، قابل جستجو نیست)
- ماتروسکا (.mkv ، فقط رمزگشایی)
H.265 HEVC برای جزئیات بیشتر به بخش 5.3 مراجعه کنید - MPEG-4 (.mp4)
- ماتروسکا (.mkv ، فقط رمزگشایی)
MPEG-2 مشخصات اصلی - mpeg2-ts (.ts ، قابل جستجو نیست)
- MPEG-4 (.mp4 ، فقط رمزگشایی)
- ماتروسکا (.mkv ، فقط رمزگشایی)
MPEG-4 SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- ماتروسکا (.mkv ، فقط رمزگشایی)
VP8 برای جزئیات بیشتر به بخش 5.2 و 5.3 مراجعه کنید - وب (.webm)
- ماتروسکا (.mkv)
VP9 برای جزئیات بیشتر به بخش 5.3 مراجعه کنید - وب (.webm)
- ماتروسکا (.mkv)
AV1 برای جزئیات بیشتر به بخش 5.2 و بخش 5.3 مراجعه کنید - MPEG-4 (.mp4)
- ماتروسکا (.mkv ، فقط رمزگشایی)
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه از کدک های ویدیویی پشتیبانی می کند:
- [C-2-1] کلیه کدک های ویدیویی در صورت پشتیبانی از کدک باید داده های نرخ فریم قابل دستیابی را برای اندازه های زیر منتشر کنند:
SD (کیفیت پایین) SD (با کیفیت بالا) HD 720p HD 1080p UHD کیفیت ویدیو - 176 X 144 PX (H263 ، MPEG2 ، MPEG4)
- 352 x 288 PX (رمزگذار MPEG4 ، H263 ، MPEG2)
- 320 X 180 PX (VP8 ، VP8)
- 320 x 240 px (دیگر)
- 704 x 576 PX (H263)
- 640 x 360 PX (VP8 ، VP9)
- 640 x 480 PX (رمزگذار MPEG4)
- 720 x 480 px (دیگر ، AV1 )
- 1408 x 1152 PX (H263)
- 1280 x 720 px (دیگر ، AV1 )
1920 x 1080 PX (غیر از MPEG4 ، AV1 ) 3840 x 2160 PX (HEVC ، VP9 ، AV1 ) به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه از هر رمزگذار ویدیویی پشتیبانی کرده و آن را در دسترس برنامه های شخص ثالث قرار دهد ، آنها:- نباید بیش از دو پنجره کشویی ، بیش از 15 ٪ بیش از فواصل بین قاب (i-frame) باشد.
- نباید بیش از 100 ٪ بیش از یک پنجره کشویی 1 ثانیه باشد.
اگر پیاده سازی های دستگاه از هر رمزگذار ویدیویی پشتیبانی کرده و آن را در دسترس برنامه های شخص ثالث قرار داده و تنظیم کنید
MediaFormat.KEY_BITRATE_MODE
toBITRATE_MODE_VBR
به طوری که رمزگذار در حالت بیت متغیر کار کند ، پس تا زمانی که بر حداقل کف کیفیت تأثیر نگذارد ، بیت رمزگذاری شده:-
[c-5-1] نبایدبیش از یک پنجره کشویی ، بیش از 15 ٪ بیش از بیت بین فواصل داخل دهانه (I-frame) باشد. -
[C-5-2] نبایدبیش از 100 ٪ از بیت بیش از یک پنجره کشویی 1 ثانیه باشد.
اگر پیاده سازی های دستگاه از هر رمزگذار ویدیویی پشتیبانی می کنند و آن را در دسترس برنامه های شخص ثالث قرار می دهند و
MediaFormat.KEY_BITRATE_MODE
را بهBITRATE_MODE_CBR
تنظیم می کنند تا رمزگذار در حالت بیتراتی ثابت کار کند ، سپس بیت رمزگذاری شده:-
[C-6-1] باید[C-SR-2] به شدت توصیه شود که بیش از 15 ٪ نسبت به Bitrate Target بیش از یک پنجره کشویی 1 ثانیه نباشد.
به تجدید نظر مراجعه کنید
اگر پیاده سازی های دستگاه از رمزگذارهای H.263 پشتیبانی می کنند و آن را در دسترس برنامه های شخص ثالث قرار می دهند ، آنها:
- [C-1-1] باید از وضوح QCIF (176 144 144) با استفاده از مشخصات پایه سطح 45 پشتیبانی کند. وضوح SQCIF اختیاری است.
-
باید از بیت های قابل تنظیم پویا برای رمزگذار پشتیبانی شده پشتیبانی کند.
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه از کدک H.265 پشتیبانی کند ، آنها:
- [C-1-1] باید از سطح مشخصات اصلی 3 تا وضوح 512 x 512 پشتیبانی کند.
-
باید از پروفایل رمزگذاری HD همانطور که در جدول زیر نشان داده شده است پشتیبانی کند. - [C-SR-1] برای پشتیبانی از مشخصات 720 x 480 SD و پروفایل رمزگذاری HD همانطور که در جدول زیر نشان داده شده است ، در صورت وجود رمزگذار سخت افزاری توصیه می شود.
5.2.6. AV1 : بخش جدید
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه از کدک AV1 پشتیبانی کند ، آنها:
- [C-1-1] باید از مشخصات اصلی از جمله محتوای 8 بیتی و 10 بیتی پشتیبانی کند.
[C-1-2] باید داده های عملکرد IE را منتشر کند ، داده های عملکرد را از طریق
getSupportedFrameRatesFor()
یاgetSupportedPerformancePoints()
برای وضوح پشتیبانی شده در جدول زیر گزارش می کند.[C-1-3] باید ابرداده HDR را بپذیرد و آن را به bitstream خروجی کند
اگر رمزگذار AV1 سخت افزار شتاب دارد ، پس از آن:
- [C-2-1] باید از مشخصات رمزگذاری HD1080P از جدول زیر پشتیبانی کند:
SD HD 720p HD 1080p UHD کیفیت ویدیو 720 x 480 px 1280 x 720 px 1920 x 1080 پیکسل 3840 x 2160 px نرخ فریم ویدیو 30 فریم بر ثانیه 30 فریم بر ثانیه 30 فریم بر ثانیه 30 فریم بر ثانیه بیت ویدیویی 5 مگابیت بر ثانیه 8 مگابیت در ثانیه 16 مگابیت در ثانیه 50 مگابیت بر ثانیه به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه از رمزگشایی H.263 پشتیبانی می کند ، آنها:
- [C-1-1] باید از سطح مشخصات پایه 30 (CIF ، QCIF و SQCIF وضوح @ 30fps 384kbps) و سطح 45 (وضوح QCIF و SQCIF @ 30fps 128kbps) پشتیبانی کند.
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه از کدک AV1 پشتیبانی کند ، آنها:- [C-1-1] باید از پروفایل 0 از جمله محتوای 10 بیتی پشتیبانی کند.
اگر پیاده سازی دستگاه از کدک AV1 پشتیبانی کرده و آن را در دسترس برنامه های شخص ثالث قرار دهد ، آنها:
- [C-1-1] باید از مشخصات اصلی از جمله محتوای 8 بیتی و 10 بیتی پشتیبانی کند.
اگر پیاده سازی های دستگاه پشتیبانی از کدک AV1 را با رمزگشایی شتاب سخت افزاری ارائه می دهند ، پس از آن:
- [C-2-1] باید بتواند حداقل پروفایل های رمزگشایی ویدیویی HD 720p را از جدول زیر رمزگشایی کند که ارتفاع گزارش شده توسط
Display.getSupportedModes()
برابر یا بیشتر از 720p باشد. - [C-2-2] باید بتواند حداقل پروفایل های رمزگشایی ویدیویی HD 1080p را از جدول زیر رمزگشایی کند که ارتفاع گزارش شده توسط
Display.getSupportedModes()
برابر یا بیشتر از 1080p باشد.
SD HD 720p HD 1080p UHD کیفیت ویدیو 720 x 480 px 1280 x 720 px 1920 x 1080 پیکسل 3840 x 2160 px نرخ فریم ویدیو 30 فریم بر ثانیه 30 فریم بر ثانیه 30 فریم بر ثانیه 30 فریم بر ثانیه بیت ویدیویی 5 مگابیت بر ثانیه 8 مگابیت در ثانیه 16 مگابیت در ثانیه 50 مگابیت بر ثانیه اگر پیاده سازی دستگاه از مشخصات HDR از طریق API رسانه پشتیبانی کند ، آنها:
- [C-3-1] باید از استخراج و خروجی ابرداده HDR از Bitstream و/یا ظرف پشتیبانی کند.
- [C-3-2] باید به درستی محتوای HDR را در صفحه دستگاه یا در یک درگاه خروجی ویدیویی استاندارد (به عنوان مثال HDMI) نمایش دهید.
به تجدید نظر مراجعه کنید
اگر پیاده سازی های دستگاه
android.hardware.microphone
اعلام کنید ، آنها:- باید حساسیت ورودی صوتی را به گونه ای تنظیم کند که یک منبع تن سینوسی 1000 هرتز در سطح فشار صدا 90 دسی بل (SPL) (
در فاصله 30 سانتی متر ازکنار میکروفون اندازه گیری شود) یک پاسخ ایده آل از RMS 2500 را در طیف وسیعی از 1770 و به دست می آورد. 3530 برای 16 نمونه بیت (یا -22.35 dB ± 3DB مقیاس کامل برای نمونه های دقیق و دقیق دو برابر) برای هر میکروفونی که برای ضبط منبع صوتی تشخیص صدا استفاده می شود.
- باید حساسیت ورودی صوتی را به گونه ای تنظیم کند که یک منبع تن سینوسی 1000 هرتز در سطح فشار صدا 90 دسی بل (SPL) (
به تجدید نظر مراجعه کنید
اگر پیاده سازی های دستگاه ویژگی
android.hardware.audio.output
را اعلام کنید ، آنها:- [C-1-4] باید جلوه های صوتی را با ورودی و خروجی نقطه شناور پشتیبانی کند.
- [C-1-5] باید اطمینان حاصل کند که جلوه های صوتی از چندین کانال تا تعداد کانال میکسر که به عنوان FCC_LIMIT نیز شناخته می شوند ، پشتیبانی می کنند.
به تجدید نظر مراجعه کنید
اگر پیاده سازی های دستگاه
android.hardware.audio.output
را اعلام کنید به آنها توصیه می شود که نیازهای زیر را برآورده یا فراتر از آن فراتر رود:- [C-SR-4] زمانبندی خروجی توسط audiotrack.gettimestamp و
AAudioStream_getTimestamp
به +/- 1 ms بازگشت.
- [C-SR-4] تأخیر محاسبه شده دور بر اساس زمان بندی ورودی و خروجی برگرفته شده توسط
AAudioStream_getTimestamp
به شدت توصیه می شود که در مدت زمان 30 میلی ثانیه از تأخیر سفر دور اندازه گیری شده برایAAUDIO_PERFORMANCE_MODE_NONE
وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
برای بلندگوها ، و سرهای بی سیم.
- [C-SR-4] زمانبندی خروجی توسط audiotrack.gettimestamp و
به تجدید نظر مراجعه کنید
Android شامل امکاناتی است که به طور خودکار دارایی های برنامه و طرح های UI را به طور مناسب برای دستگاه تنظیم می کند تا اطمینان حاصل شود که برنامه های شخص ثالث به خوبی در
انواع تنظیمات سخت افزاری اجرا می شوند.انواع نمایشگرها و تنظیمات سخت افزاری. صفحه نمایش سازگار با اندرویدی یک صفحه نمایش صفحه نمایش است که تمام رفتارها و API های شرح داده شده در توسعه دهندگان Android را پیاده سازی می کند-نمای کلی سازگاری صفحه نمایش ، این بخش (7.1) و زیرمجموعه های آن ، و همچنین هرگونه رفتارهای خاص از نوع دستگاهی که در بخش 2 ثبت شده است این CDDدر صفحه نمایش (های) سازگار با Android که در آن همه برنامه های سازگار با اندرویدی شخص ثالث می توانند اجرا شوند ، اجرای دستگاه باید به درستی این API ها و رفتارها را اجرا کند ، همانطور که در این بخش شرح داده شده است.الزامات جدید را شروع کنید
پیاده سازی دستگاه:
- [C-0-1] باید به طور پیش فرض برنامه های شخص ثالث را فقط بر روی نمایشگرهای سازگار با اندروید ارائه دهد.
واحدهای ارجاع شده توسط الزامات موجود در این بخش به شرح زیر است:
- اندازه مورب فیزیکی . فاصله در اینچ بین دو گوشه مخالف قسمت روشن شده نمایشگر.
-
نقاط در هر اینچ (DPI)چگالی . تعداد پیکسل های شامل یک دهانه افقی یا عمودی خطی 1 اینچ ، به عنوان پیکسل در اینچ (PPI یا DPI) بیان شده است . در جایی که مقادیرDPIPPI و DPI ذکر شده است ، DPI افقی و عمودی باید در محدوده ذکر شده قرار گیرد. - نسبت ابعاد نسبت پیکسل های بعد طولانی تر به بعد کوتاه تر صفحه نمایش. به عنوان مثال ، نمایشگر 480x854 پیکسل 854/480 = 1.779 یا تقریباً "16: 9" خواهد بود.
- پیکسل مستقل از چگالی (DP) .
یکواحد پیکسل مجازی که به یک صفحه نمایشصفحه نمایش 160 DPI160 نرمال می شود. برای برخی از چگالی D ، و تعدادی پیکسل P ، تعداد پیکسل های مستقل از چگالی DP ، به صورت:پیکسل = DPS * (چگالی/160)محاسبه می شود. dp = (160 / d) * ص .
به تجدید نظر مراجعه کنید
اگر پیاده سازی های دستگاه از صفحه نمایش هایی که قادر به پیکربندی اندازه
UI_MODE_TYPE_NORMAL
هستند پشتیبانی می کنند و از صفحه نمایش (های) فیزیکیسازگار با Androidاستفاده می کنند تا این صفحه نمایش ها را ارائه دهند ، آنها:- [C-1-1] باید اطمینان حاصل کند که حداقل یکی از الزامات زیر برای هر صفحه نمایش برآورده شده است:
- شعاع گوشه های گرد کمتر از یا مساوی با 38 DP است.
هنگامی که یک جعبه 15 DP توسط 15 DP در هر گوشه نمایش منطقی لنگر می رود ، حداقل یک پیکسل از هر جعبه روی صفحه قابل مشاهده است.
باید شامل هزینه کاربر برای جابجایی به حالت نمایش با گوشه های مستطیل باشد.
الزامات جدید را شروع کنید
اگر پیاده سازی دستگاه فقط قادر به پیکربندی صفحه کلید
NO_KEYS
است و قصد دارد پشتیبانی از پیکربندی حالتUI_MODE_TYPE_NORMAL
UI را گزارش دهد ، آنها:- [C-4-1] باید به استثنای هرگونه برش صفحه نمایش ، حداقل 596 dp x 384 dp یا بیشتر داشته باشد.
اگر پیاده سازی دستگاه شامل یک صفحه نمایش (های) سازگار با اندرویدی باشد که قابل تاشو باشد ، یا یک لولا تاشو بین پانل های صفحه نمایش چندگانه را شامل می شود و چنین نمایشگر (های) را برای ارائه برنامه های شخص ثالث در دسترس قرار می دهد ، آنها:
- [C-2-1] باید آخرین نسخه پایدار موجود API Extensions یا نسخه پایدار API Sidecar را که توسط Window Manager Jetpack Library استفاده می شود ، پیاده سازی کند.
اگر پیاده سازی دستگاه شامل یک صفحه نمایش (های) سازگار با اندرویدی باشد که قابل تاشو باشد ، یا یک لولا تاشو بین پانل های صفحه نمایش چندگانه و اگر لولا یا تاشو از یک پنجره برنامه تمام صفحه عبور کند ، آنها:
- [C-3-1] باید موقعیت ، مرزها و حالت لولا یا تاشو را از طریق پسوندها یا API های Sidecar به برنامه گزارش دهد.
اگر پیاده سازی دستگاه شامل یک یا چند قسمت از نمایشگر سازگار با اندرویدی باشد که قابل تاشو باشد ، یا یک لولا تاشو بین چندین قسمت پانل نمایشگر سازگار با اندروید را شامل می شود و چنین مناطق نمایشگر را در دسترس برنامه ها قرار می دهد ، آنها:
- [C-4-1] باید نسخه صحیح سطح برنامه افزودنی Window Manager API را همانطور که در مستندات آینده توضیح داده شده است ، پیاده سازی کند.
7.1.1.2. نسبت ابعاد صفحه : حذف شد
به تجدید نظر مراجعه کنید
پیاده سازی دستگاه:
- [C-0-1]
به طور پیش فرض ، پیاده سازی دستگاه هافقطباید یکی از تراکم های فریم ورک Android را که درDisplayMetrics
از طریق APIDENSITY_DEVICE_STABLE
ذکر شده است گزارش دهد و این مقدار باید یک مقدار استاتیک برای هر صفحه نمایش فیزیکی باشددر هر زمان نباید تغییر کند. با این حال ،با این حال ، دستگاه ممکن است یکDisplayMetrics.density
چگالی دلخواهمتفاوتی را گزارش کند. تراکم با توجه به تغییرات پیکربندی صفحه نمایش داده شده توسط کاربر (به عنوان مثال ، اندازه نمایش) که پس از بوت اولیه تنظیم شده است.
- پیاده سازی دستگاه باید چگالی استاندارد فریم ورک Android را که از نظر عددی نزدیک به چگالی فیزیکی صفحه نمایش است ، تعریف کند ، مگر اینکه چگالی منطقی اندازه صفحه نمایش گزارش شده را زیر حداقل پشتیبانی کند. اگر چگالی چارچوب استاندارد Android که از نظر عددی نزدیک به چگالی فیزیکی نزدیک است ، در اندازه صفحه نمایش کوچکتر از کوچکترین اندازه صفحه نمایش سازگار با پشتیبانی (عرض 320 DP) باشد ، اجرای دستگاه باید کمترین چگالی چارچوب استاندارد Android را گزارش کند.
الزامات جدید را شروع کنید
- باید چگالی چارچوب استاندارد Android را که از نظر عددی نزدیک به چگالی فیزیکی صفحه نمایش است ، تعریف کنید ، یا مقداری که می تواند به همان اندازه گیری های دیدگاه زاویه ای معادل یک دستگاه دستی باشد.
اگر پیاده سازی دستگاه ها برای تغییر اندازه نمایشگر دستگاه ، هزینه ای
وجود دارد، آنها :- [C-1-1]
اندازه نمایشگر نباید مقیاس بندی شود ،نباید صفحه نمایش بزرگتر از 1.5 برابرDENSITY_DEVICE_STABLE
چگالی بومییا حداقل ابعاد صفحه نمایش مؤثر کوچکتر از 320DP (معادل صلاحیت منابع SW320DP) را ایجاد کند ، هر کدام از اول باشد. - [C-1-2]
اندازه نمایشگر نباید اندازه گیری شود ، هیچ کسنباید صفحه نمایش کوچکتر از 0.85 برابرDENSITY_DEVICE_STABLE
تراکم بومی رامقیاس کند.
- [C-0-1]
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه شامل پشتیبانی از Vulkan
1.0 یا بالاتر باشد، آنها:[C-1-3] باید API های
Vulkan 1.0Vulkan 1.1 را برای هرVkPhysicalDevice
شمارش شده به طور کامل پیاده سازی کند.[C-1-5] نباید لایه های ارائه شده توسط کتابخانه های خارج از بسته برنامه را ذکر کند ، یا روش های دیگری برای ردیابی یا رهگیری API Vulkan ارائه دهد ، مگر اینکه برنامه دارای
android:debuggable
تنظیم شده به عنوانtrue
یا ابردادهcom.android.graphics.injectLayers.enable
تنظیم شده درtrue
.
- باید از
VkPhysicalDeviceProtectedMemoryFeatures
وVK_EXT_global_priority
پشتیبانی کند.
- [C-1-13] باید الزامات مشخص شده توسط مشخصات پایه اندرویدی 2021 را برآورده کند.
[C-SR-5] به شدت توصیه می شود برای پشتیبانی از
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
وVK_EXT_global_priority
.[C-SR-6] به شدت توصیه می شود از
SkiaVk
با HWUI استفاده کنید.
اگر پیاده سازی دستگاه شامل پشتیبانی از Vulkan 1.1 است و هر یک از پرچم های ویژگی Vulkan را که در اینجا شرح داده شده است اعلام کنید ، آنها:
- [C-SR-7] به شدت توصیه می شود تا پسوند
VK_KHR_external_fence_fd
را در دسترس برنامه های شخص ثالث قرار دهید و برنامه را قادر به صادرات بار حصار به و واردات بار حصار از توصیف کننده های فایل POSIX کنید که در اینجا توضیح داده شده است.
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه دارای سنسور بیومتریک متعدد باشد ، آنها:
[C-7-1] باید ، هنگامی که یک بیومتریک در قفل است (یعنی بیومتریک غیرفعال می شود تا کاربر با تأیید اعتبار اولیه باز نشود) یا قفل محدوده زمان (یعنی بیومتریک به طور موقت غیرفعال می شود تا کاربر منتظر یک بازه زمانی باشد) به دلیل تلاش های ناکام بیش از حد ، تمام بیومتریک های دیگر یک کلاس بیومتریک پایین را قفل کنید. در مورد قفل محدوده زمان ، زمان بازگشت برای تأیید بیومتریک باید حداکثر زمان برگشت تمام بیومتریک در قفل زمان باشد.
[C-SR-12] به شدت توصیه می شود ، هنگامی که یک بیومتریک در قفل است (یعنی بیومتریک غیرفعال می شود تا زمانی که کاربر با احراز هویت اولیه باز نشود) یا قفل محدود به زمان (یعنی بیومتریک موقتاً غیرفعال می شود تا زمانی که کاربر منتظر بماند مدتی منتظر بماند. فاصله) به دلیل تلاش های ناکام بیش از حد ، همچنین تمام بیومتریک های دیگر کلاس بیومتریک مشابه را نیز قفل می کنند. در مورد قفل محدوده زمان ، زمان بازگشت برای تأیید بیومتریک به شدت توصیه می شود که حداکثر زمان برگشت تمام بیومتریک در قفل زمان باشد.
[C-7-2] باید کاربر را برای احراز هویت اولیه توصیه شده (به عنوان مثال: پین ، الگوی ، رمز عبور) به چالش بکشد تا شمارنده قفل را برای قفل شدن بیومتریک بازنشانی کند. بیومتریک کلاس 3 ممکن است مجاز به تنظیم مجدد پیشخوان قفل شده برای یک بیومتریک قفل شده در همان یا پایین باشد. بیومتریک کلاس 2 یا کلاس 1 نباید مجاز به انجام عملیات قفل تنظیم مجدد برای هرگونه بیومتریک باشد.
اگر پیاده سازی دستگاه ها می خواهند یک سنسور بیومتریک را به عنوان کلاس 1 (که قبلاً راحتی ) درمان می کند ، درمان کنند ، آنها:
[C-1-12] باید در هر گونه ابزار حمله (PAI) از 40 ٪ بالاتر از 40 ٪ در هر گونه ابزار حمله (PAI) بالاتر نباشد ، همانطور که توسط پروتکل های تست بیومتریک اندرویدی اندازه گیری می شود.
[C-SR-13] به شدت توصیه می شود که یک گونه جعل و پذیرش ایمپستر بالاتر از 30 ٪ در هر گونه ابزار حمله (PAI) ارائه شود ، همانطور که توسط پروتکل های تست بیومتریک اندرویدی اندازه گیری می شود.
[C-SR-14] به شدت توصیه می شود که کلاس بیومتریک سنسور بیومتریک و خطرات مربوط به فعال کردن آن را فاش کنید.
[C-SR-17] به شدت توصیه می شود که رابط های New AIDL را اجرا کنید (مانند ،
IFace.aidl
وIFingerprint.aidl
).
اگر پیاده سازی دستگاه ها می خواهند یک سنسور بیومتریک را به عنوان کلاس 2 (که قبلاً ضعیف بود ) درمان کند ، آنها:
- [C-SR-15] به شدت توصیه می شود که از نظر گونه های حمله (PAI) از 20 ٪ بالاتر از 20 ٪ در هر گونه ابزار حمله (PAI) بالاتر نباشد ، همانطور که توسط پروتکل های تست بیومتریک اندرویدی اندازه گیری می شود.
- [C-2-3] باید تطبیق بیومتریک را در یک محیط اجرای جدا شده در خارج از کاربر Android یا فضای هسته مانند محیط اجرای قابل اعتماد (TEE)
یادر تراشه با یک کانال امن به محیط اجرای جدا شده یا محافظت شده انجام دهد. ماشین مجازی که در بخش 9.17 شرایط لازم را برآورده می کند . - [C-2-4] باید همه داده های قابل شناسایی رمزگذاری شده و رمزنگاری شده را تأیید کند به گونه ای که نتوانند در خارج از محیط اجرای جدا شده یا یک تراشه با یک کانال امن به محیط اجرای جدا شده ، همانطور که در دستورالعمل های اجرای ثبت شده است ، به دست بیاورند ، بخوانند یا تغییر دهند. در سایت پروژه منبع باز اندروید یا یک ماشین مجازی محافظت شده توسط Hypervisor که در بخش 9.17 مورد نیاز است ، کنترل می شود .
- [C-2-5] برای بیومتریک مبتنی بر دوربین ، در حالی که احراز هویت مبتنی بر بیومتریک یا ثبت نام در حال وقوع است:
- باید دوربین را به صورت حالت کار کند که مانع از خواندن یا تغییر فریم های دوربین در خارج از محیط اجرای جدا شده یا تراشه با یک کانال امن به محیط اجرای جدا شده یا یک ماشین مجازی محافظت شده کنترل شده توسط Hypervisor که در بخش 9.17 نیاز دارد .
- برای راه حل های تک دوربین RGB ، فریم های دوربین می توانند در خارج از محیط اجرای جدا شده قابل خواندن باشند تا از عملیاتی مانند پیش نمایش برای ثبت نام پشتیبانی کنند ، اما هنوز هم قابل تغییر نیست.
- [C-2-7] نباید اجازه دسترسی غیرمترقبه به داده های بیومتریک قابل شناسایی یا داده های حاصل از آن (مانند تعبیه) را به پردازنده برنامه در خارج از متن TEE یا دستگاه مجازی محافظت شده کنترل شده توسط Hypervisor که در بخش مورد نیاز است ، قرار دهد. 9.17 . دستگاه های به روزرسانی که بر روی نسخه 9 یا قبل از آن انجام شده اند از C-2-7 معاف نیستند.
اگر پیاده سازی دستگاه ها می خواهند یک سنسور بیومتریک را به عنوان کلاس 3 (که قبلاً قوی بود ) درمان کند ، آنها:
- [C-SR-16] به شدت توصیه می شود که از نظر گونه های حمله (PAI) از 7 ٪ بالاتر از 7 ٪ در هر گونه ابزار حمله (PAI) بالاتر نباشد ، همانطور که توسط پروتکل های تست بیومتریک اندرویدی اندازه گیری می شود.
7.3.13. IEEE 802.1.15.4 (UWB) :
به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه شامل پشتیبانی از 802.1.15.4 و در معرض عملکرد در یک برنامه شخص ثالث باشد ، آنها:
- [C-1-2] باید از ویژگی های سخت افزاری پرچم
android.hardware.uwb
خبر دهد. - [C-1-3] باید از کلیه مجموعه های پیکربندی زیر (ترکیب های از پیش تعریف شده پارامترهای FIRA UCI ) تعریف شده در اجرای AOSP پشتیبانی کند.
-
CONFIG_ID_1
:STATIC STS DS-TWR
، حالت معوق ، فاصله زمانی 240 ms. -
CONFIG_ID_2
: FIRA تعریف شده از یک به بسیاری ازSTATIC STS DS-TWR
، حالت معوق ، فاصله 200 میلی ثانیه. مورد استفاده معمولی: تلفن هوشمند با بسیاری از دستگاه های هوشمند در تعامل است. -
CONFIG_ID_3
: مشابهCONFIG_ID_1
، به جز داده های زاویه ای (AOA) گزارش نشده است. -
CONFIG_ID_4
: همانCONFIG_ID_1
، به جز حالت امنیتی P-STS فعال است. -
CONFIG_ID_5
: مشابهCONFIG_ID_2
، به جز حالت امنیتی P-STS فعال است. -
CONFIG_ID_6
: همانCONFIG_ID_3
، به جز حالت امنیتی P-STS فعال است. -
CONFIG_ID_7
: همانCONFIG_ID_2
، به جز حالت کلید Controlee Controlee P-Sts فعال است.
-
- [C-1-4] باید هزینه کاربر را فراهم کند تا کاربر بتواند رادیو UWB را روشن/خاموش کند.
- [C-1-5] باید برنامه هایی را با استفاده از رادیو UWB مجوز
UWB_RANGING
(تحت گروه مجوزNEARBY_DEVICES
) را اجرا کند.
عبور از تست های مربوط به انطباق و صدور گواهینامه تعریف شده توسط سازمان های استاندارد ، از جمله FIRA ، CCC و CSA به اطمینان از عملکرد 802.1.15.4 به درستی کمک می کند.
- [C-1-2] باید از ویژگی های سخت افزاری پرچم
به تجدید نظر مراجعه کنید
"تلفن" همانطور که توسط ANDROID API استفاده می شود و این سند به طور خاص به سخت افزار مربوط به قرار دادن تماس های صوتی و ارسال پیامک یا ایجاد داده های تلفن همراه از طریق شبکه موبایل (به عنوان مثال GSM ، CDMA ، LTE ، NR) یا شبکه CDMA اشاره دارد. دستگاهی که از "تلفن" پشتیبانی می کند ممکن است برخی از خدمات تماس ، پیام رسانی و داده را متناسب با محصول ارائه دهد.
از طریق شبکه GSM یا CDMA. در حالی که این تماس های صوتی ممکن است بسته بندی بسته باشد یا نباشد ، آنها برای اهداف اندروید مستقل از هرگونه اتصال داده ای هستند که ممکن است با استفاده از همان شبکه اجرا شود. به عبارت دیگر ، عملکرد "تلفن" اندروید و API ها به طور خاص به تماس های صوتی و پیام کوتاه اشاره می کنند. به عنوان مثال ، پیاده سازی دستگاه هایی که نمی توانند تماس تلفنی یا ارسال پیامک ارسال کنند ، بدون در نظر گرفتن اینکه از یک شبکه تلفن همراه برای اتصال داده استفاده می کنند ، یک دستگاه تلفنی محسوب نمی شوند.به تجدید نظر مراجعه کنید
اگر پیاده سازی دستگاه شامل پشتیبانی از 802.11 و در معرض عملکرد در یک برنامه شخص ثالث باشد ، آنها:
- [C-1-4] باید از DNS Multicast (MDNS) پشتیبانی کند و نباید بسته های MDNS (224.0.0.251 یا FF02 :: FB ) را در هر زمان از کار ، از جمله زمانی که صفحه نمایش در حالت فعال نیست ، فیلتر کند ، مگر اینکه رها شود یا رها شود. فیلتر کردن این بسته ها برای ماندن در محدوده مصرف برق مورد نیاز توسط الزامات نظارتی قابل استفاده در بازار هدف ضروری است.
For Android Television device implementations, even when in standby power states.
- [C-1-4] باید از DNS Multicast (MDNS) پشتیبانی کند و نباید بسته های MDNS (224.0.0.251 یا FF02 :: FB ) را در هر زمان از کار ، از جمله زمانی که صفحه نمایش در حالت فعال نیست ، فیلتر کند ، مگر اینکه رها شود یا رها شود. فیلتر کردن این بسته ها برای ماندن در محدوده مصرف برق مورد نیاز توسط الزامات نظارتی قابل استفاده در بازار هدف ضروری است.
See revision
If device implementations declare FEATURE_BLUETOOTH_LE, they:
- [C-SR-2] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction. - [C-SR-3] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
- [C-10-3] MUST measure and compensate for Rx offset to ensure the median BLE RSSI is -55dBm +/-10 dB at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] MUST measure and compensate for Tx offset to ensure the median BLE RSSI is -55dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at
ADVERTISE_TX_POWER_HIGH
.
If device implementations support Bluetooth version 5.0, then they:
- [C-SR-4] Are STRONGLY RECOMMENDED to provide support for:
- LE 2M PHY
- LE Codec PHY
- LE Advertising Extension
- Periodic advertising
- At least 10 advertisement sets
- At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
- LE Link Layer Privacy
- A "resolving list" size of at least 8 entries
- [C-SR-2] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at
See revision
- [C-1-7] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT.
held face up and tilted 45 degrees.
- [C-1-7] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT.
See revision
A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera.
A rear-facing camera is a world-facing camera that images scenes on the far side of the device, like a traditional camera; on handheld devices, that is a camera located on the side of the device opposite the display.
See revision
A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.
A front-facing camera is a user-facing camera that is typically used to image the user, such as for video conferencing and similar applications; on handheld devices, that is a camera located on the same side of the device as the display.
See revision
An external camera is a camera that can be physically attached or detached from the device implementation at any time and can face any direction; such as USB cameras.
See revision
Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras. Device implementations:
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, consisting of all of the RGB cameras facing that direction as physical sub-devices.
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
See revision
Devices that fulfill all of the following criteria are exempt from the requirement above:
- Device implementations that are not capable of being rotated by the user such as automotive devices.
See revision
Devices intended to be hand-held or worn may include a general purpose haptic actuator, available to applications for purposes including getting attention through ringtones, alarms, notifications, as well as general touch feedback.
If device implementations DO NOT include such a general purpose haptic actuator, they:
- [7.10/C] MUST return false for
Vibrator.hasVibrator()
.
If device implementations DO include at least one such general purpose haptic actuator, they:
- [C-1-1] MUST return true for
Vibrator.hasVibrator()
. - SHOULD NOT use an eccentric rotating mass (ERM) haptic actuator (vibrator).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstants
namely (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
andGESTURE_END
). - SHOULD implement all public constants for clear haptics in
android.os.VibrationEffect
namely (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
andEFFECT_DOUBLE_CLICK
) and all feasible publicPRIMITIVE_*
constants for rich haptics inandroid.os.VibrationEffect.Composition
namely (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Some of these primitives, such asLOW_TICK
andSPIN
may only be feasible if the vibrator can support relatively low frequencies. - SHOULD follow the guidance for mapping public constants in
android.view.HapticFeedbackConstants
to the recommendedandroid.os.VibrationEffect
constants, with the corresponding amplitude relationships. - SHOULD use these linked haptic constants mappings .
- SHOULD follow quality assessment for
createOneShot()
andcreateWaveform()
APIs. - SHOULD verify that the result of the public
android.os.Vibrator.hasAmplitudeControl()
API correctly reflects their vibrator's capabilities. - SHOULD verify the capabilities for amplitude scalability by running
android.os.Vibrator.hasAmplitudeControl()
.
If device implementations follow the haptic constants mapping, they:
- SHOULD verify the implementation status by running
android.os.Vibrator.areAllEffectsSupported()
andandroid.os.Vibrator.arePrimitivesSupported()
APIs. - SHOULD perform a quality assessment for haptic constants.
- SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
- SHOULD provide fallback support to mitigate the risk of failure as described here .
See Section 2.2.1 for device-specific requirements.
- [7.10/C] MUST return false for
See revision
Device implementations:
- [C-0-4] MUST have one and only one implementation of both user interfaces.
If device implementations pre-install any packages that hold any of the System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence roles, the packages:
- [C-4-1] MUST fulfill all requirements outlined for device implementations in sections
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionService
they:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATION
as the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- heap buffer overflow
- use after free
- double free
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is به اشتراک گذاشته شده است. Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. اجازه .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentService
System API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of نگرانی.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the