اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
خيارات المطوّرين الآمنة
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
وفقًا لمستند تعريف التوافق مع Android،
على المصنّعين الأصليين للأجهزة توفير طريقة لتفعيل تطوير التطبيقات. ومع ذلك، فإنّ توفير خيارات المطوّرين المشابهة للأجهزة الجوّالة داخل السيارات يجعل هذه السيارات عرضة للهجوم. يمكن الآن لمصنعي الأجهزة الأصليين حظر الوصول إلى خيارات المطوّرين باستخدام آلية رمز مميّز مشفّر تم التحقّق منه.
على وجه التحديد، يمكن للمصنّع الأصلي للجهاز إجراء ما يلي:
- اضبط القيود التلقائية المطلوبة قبل بدء التشغيل لأول مرة.
- منح المطوّرين الإذن بأمان باستخدام الرموز المشفّرة إذا كان ذلك هو الخيار المفضّل
- تطبيق تغييرات القيود بعد مصادقة المطوّر وتفويضه
توضّح هذه المقالة عملية تنفيذ مرجعية تتألف من تطبيق تحكم في قيود تصحيح الأخطاء ومقدّمة نهاية لإصدار الرمز المميّز عن بُعد.
المصطلحات
بالإضافة إلى المصطلحات،
يتم استخدام هذه المصطلحات في هذه المقالة:
- توقيع JSON على الويب (JWS)، كما هو محدّد في RFC 7515
- المعهد الوطني للمعايير والتكنولوجيا (NIST)
التصميم
يمكن لمصنّعي المعدّات الأصلية تفويض المطوّرين باستخدام رموز توقيع JSON على الويب (JWS) (RFC7515). في عملية التنفيذ المرجعية، تُصدر المصنّعين الأصليّين للأجهزة رموز الوصول ويستهلكها تطبيق التحكّم في القيود. تم تصميم رموز الوصول لمقاومة هجمات إعادة التشغيل والرموز المزورة.
الشكل 1: التصميم
الدمج والضبط
على المصنّعين الأصليّين للأجهزة تحديد القيود التلقائية المطلوبة عند أول عملية تشغيل. ويتم ذلك باستخدام
عدة طبقات موارد ثابتة لإلغاء الإعدادات التلقائية في إطار عمل AOSP.
يمكن ضبط القيود التلقائية لمستخدم النظام بلا واجهة مستخدم باستخدام سلسلة
config_defaultFirstUserRestrictions في
frameworks/base/core/res/res/values/config.xml، على سبيل المثال:
<!-- User restrictions set when the first user is created.
Note: Also update appropriate overlay files. -->
<string-array translatable="false" name="config_defaultFirstUserRestrictions">
<item>no_debugging_features</item>
</string-array>
يمكن ضبط القيود التلقائية للسائقين والركاب والضيوف في
frameworks/base/core/res/res/xml/config_user_types.xml. يمكن لمصنّع المعدّات الأصلية (OEM) تراكب|
هذه السلاسل لضبط القيود التلقائية على كل نوع من المستخدمين على التوالي، على سبيل المثال:
<user-types>
<full-type name="android.os.usertype.full.SECONDARY" >
<default-restrictions no_debugging_features="true"/>
</full-type>
<full-type name="android.os.usertype.full.GUEST" >
<default-restrictions no_debugging_features="true"/>
</full-type>
</user-types>
يتوفّر تطبيق مرجعي في الموقع التالي في AOSP:
packages/apps/Car/DebuggingRestrictionController
الاختبار
تنصح Google المصنّعين الأصليّين للأجهزة بالبدء بالتطبيق المرجعي والبناء عليه.
- بعد ضبط القيود المطلوبة في ملفات التراكب، يمكنك تجميع AAOS و
التحقّق من صحّة عمليات النقل المحدّدة. استخدِم التطبيق المرجعي والخدمة المحلية المزوّدة بتنسيق JWS
للتحقّق من إعدادات الوصول.
- اضبط النظام لاستخدام خدمة السحابة الإلكترونية المزوّدة بتنسيق JWS (اختياري). تأكَّد من
أنّك تلاحظ التدفق المطلوب في خدمة الخلفية.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Secure developer options\n\nPer the [Android Compatibility Definition Document](/docs/compatibility/cdd),\nOEMs must provide a way to enable app development. However, providing mobile-like\ndeveloper options within cars leaves those cars vulnerable to attack. Access to developer\noptions can now be gated by an OEM using an authenticated cryptographic token mechanism.\nSpecifically, an OEM can:\n\n- Set desired default restrictions before the first boot.\n- Securely authorize developers, with crypto tokens if preferred.\n- Apply restriction changes once a developer is both authenticated and authorized.\n\nThis article describes a reference implementation consisting of a debugging restriction\ncontroller app and a remote token issuer endpoint.\n\nTerminology\n-----------\n\nIn addition to [Terminology](/docs/automotive/start/terms),\nthese terms are used in this article:\n\n- JSON Web Signature (JWS), defined in RFC 7515\n- National Institute of Standards and Technology (NIST)\n\nDesign\n------\n\nOEMs can authorize developers with JSON Web Signature (JWS) tokens (RFC7515). In the\nreference implementation, access tokens are issued by OEMs and consumed by the restriction\ncontroller app. Access tokens are designed to resist replay attacks and forged tokens.\n\n**Figure 1.** Design\n\nIntegration and configuration\n-----------------------------\n\nOEMs must specify the desired default restrictions on the first boot. This is done with\nseveral static resource overlays to override the defaults in the AOSP framework.\n\nThe default restrictions for the headless system user can be configured with the\n`config_defaultFirstUserRestrictions` string in\n`frameworks/base/core/res/res/values/config.xml`, for example: \n\n```scdoc\n\u003c!-- User restrictions set when the first user is created.\n Note: Also update appropriate overlay files. --\u003e\n \u003cstring-array translatable=\"false\" name=\"config_defaultFirstUserRestrictions\"\u003e\n \u003citem\u003eno_debugging_features\u003c/item\u003e\n \u003c/string-array\u003e\n```\n\nThe default restrictions for drivers, passengers, and guests can be configured in\n`frameworks/base/core/res/res/xml/config_user_types.xml`. An OEM can overlay\\|\nthese strings to set the default restrictions on each type of user respectively, for example: \n\n```carbon\n\u003cuser-types\u003e\n \u003cfull-type name=\"android.os.usertype.full.SECONDARY\" \u003e\n \u003cdefault-restrictions no_debugging_features=\"true\"/\u003e\n \u003c/full-type\u003e\n \u003cfull-type name=\"android.os.usertype.full.GUEST\" \u003e\n \u003cdefault-restrictions no_debugging_features=\"true\"/\u003e\n \u003c/full-type\u003e\n\u003c/user-types\u003e\n```\n\nA reference implementation is provided at the following location in AOSP: \n\n```carbon\npackages/apps/Car/DebuggingRestrictionController\n```\n\nTesting\n-------\n\nGoogle recommends that OEMs start with the reference implementation and build out from there.\n\n1. After configuring the desired restrictions in the overlay files, compile AAOS and validate the defined flows. Use the reference app and local JWS enabled service to verify your access settings.\n2. Configure the system to use your JWS enabled cloud service (optional). Verify you're observing the desired flow on your backend service."]]
