از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
گزینه های توسعه دهنده ایمن
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
طبق سند تعریف سازگاری اندروید ، OEM ها باید راهی برای فعال کردن توسعه برنامه ارائه دهند. با این حال، ارائه گزینه‌های توسعه‌دهنده شبیه موبایل در داخل خودروها، این خودروها را در برابر حمله آسیب‌پذیر می‌کند. اکنون می‌توان دسترسی به گزینه‌های توسعه‌دهنده را توسط یک OEM با استفاده از مکانیزم رمزنگاری تأیید شده مسدود کرد. به طور خاص، یک OEM می تواند:
- قبل از اولین بوت، محدودیت های پیش فرض دلخواه را تنظیم کنید.
- به توسعه‌دهندگان، در صورت تمایل، با توکن‌های رمزنگاری مجوز ایمن بدهید.
- زمانی که یک توسعه‌دهنده احراز هویت و مجاز شد، تغییرات محدودیت را اعمال کنید.
این مقاله یک پیاده‌سازی مرجع را توصیف می‌کند که شامل یک برنامه کنترل‌کننده محدودیت اشکال‌زدایی و یک نقطه پایانی صادرکننده نشانه راه دور است.
اصطلاحات
علاوه بر اصطلاحات ، از این اصطلاحات در این مقاله استفاده می شود:
- JSON Web Signature (JWS)، تعریف شده در RFC 7515
- موسسه ملی استاندارد و فناوری (NIST)
طراحی
OEM ها می توانند به توسعه دهندگان با توکن های JSON Web Signature (JWS) (RFC7515) مجوز دهند. در پیاده سازی مرجع، توکن های دسترسی توسط OEM ها صادر می شوند و توسط برنامه کنترل کننده محدودیت مصرف می شوند. توکن های دسترسی برای مقاومت در برابر حملات تکراری و توکن های جعلی طراحی شده اند.
شکل 1. طراحی
یکپارچه سازی و پیکربندی
OEM ها باید محدودیت های پیش فرض مورد نظر را در اولین بوت مشخص کنند. این کار با چندین همپوشانی منبع ثابت انجام می‌شود تا پیش‌فرض‌ها در چارچوب 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
تست کردن
گوگل توصیه می کند که OEM ها با پیاده سازی مرجع شروع کنند و از آنجا بسازند.
- پس از پیکربندی محدودیت های مورد نظر در فایل های همپوشانی، AAOS را کامپایل کرده و جریان های تعریف شده را اعتبار سنجی کنید. از برنامه مرجع و سرویس محلی فعال JWS برای تأیید تنظیمات دسترسی خود استفاده کنید.
- سیستم را برای استفاده از سرویس ابری فعال JWS خود پیکربندی کنید (اختیاری). بررسی کنید که جریان مورد نظر را در سرویس باطن خود مشاهده می کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]
