تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

دليل تكامل وحدة تحكم تقييد التصحيح

استخدم الإرشادات الموجودة في هذه الصفحة لدمج وحدة تحكم تقييد تصحيح الأخطاء AAOS (DRC).

الشكل 1. مثال على تطبيق جمهورية الكونغو الديمقراطية.

بنيان

تم توضيح بنية DRC في الشكل 2. المكونات الموضحة باللون الأحمر (جهة إصدار الرمز المميز وDRC) لها تطبيقات مرجعية مصاحبة يمكنك تخصيصها.

الشكل 2. بنية جمهورية الكونغو الديمقراطية.

ما هي جمهورية الكونغو الديمقراطية؟

تشتمل وحدة رأس السيارة على تطبيق DRC (راجع التنفيذ المرجعي في packages/apps/Car/DebuggingRestrictionController ). يتضمن التطبيق المرجعي المنطق الخاص باستلام رمز وصول من مصدر الرمز المميز، والتحقق من صحة الرمز المميز، ثم تطبيق تغييرات قيود التصحيح كما هو محدد في الرمز المميز. يتضمن المنطق عناصر UX الأساسية على جانب السيارة.

ما هو مصدر الرمز المميز؟

هذه خدمة ويب تُصدر رموز وصول موقعة بالتشفير (راجع التنفيذ المرجعي في packages/apps/Car/DebuggingRestrictionController/server ). خدمة الويب المرجعية عبارة عن وظيفة Firebase Cloud قابلة للنشر (لمعرفة المزيد، راجع وظائف السحابة لـ Firebase ).

المتطلبات الأساسية

قبل نشر تطبيق مرجعي، تأكد من إكمال المهام التالية.

إعداد شهادات لتوقيع رموز الوصول

يقوم مُصدر الرمز المميز بإنشاء توقيعات ويب JSON (JWS) كرموز وصول. للحصول على التوافق الأمثل، يدعم المُصدر المرجعي فقط خوارزمية RS256 (توقيعات RSA مع SHA256). لتسهيل تدوير المفاتيح، استخدم سلسلة شهادات بدلاً من شهادة واحدة لتوقيع رموز الوصول المميزة. يجب أن تتكون سلسلة الشهادات النموذجية من شهادة CA الجذرية، وشهادة CA المتوسطة، وشهادة الكيان النهائي.

لا تختلف شهادة الكيان النهائي التي توقع رموز JWS عن شهادة TLS القياسية. يمكنك إما شراء شهادة من المراجع المصدقة العامة مثل DigiCert أو الحفاظ على سلسلة الشهادات الخاصة بك باستخدام شهادات CA الجذرية الموقعة ذاتيًا أو وحدات أمان الأجهزة. يجب أن تكون شهادة الكيان النهائي عبارة عن شهادة X509v3 ذات ملحق الاسم البديل للموضوع (SAN). يحتوي ملحق SAN على معرف (على سبيل المثال، اسم المضيف) لمصدر الرمز المميز. وأخيرًا، يجب تفضيل شهادات RSA على شهادات EC لأن مصدر الرمز المميز يدعم RS256 فقط.

توفر Google برنامج نصي shell لإنشاء شهادات موقعة ذاتيًا في packages/apps/Car/DebuggingRestrictionController/server/genkey.sh .

قم بإعداد Firebase

يستخدم مصدر الرمز المميز مصادقة Firebase ووظيفة Firebase Cloud .

لإعداد حسابك على Firebase:

لإنشاء مشروع Firebase، راجع إضافة Firebase إلى مشروع Android الخاص بك .
لتمكين بعض أدوات مصادقة Firebase، راجع من أين أبدأ باستخدام مصادقة Firebase؟ .
لإضافة وظيفة Firebase Cloud فارغة، راجع البدء .
إذا لم تكن قد قمت بذلك بالفعل، فقم بتثبيت أدوات Node.js وNPM وFirebase لتجميع مصدر الرمز المميز ونشره.
ملاحظة: بعد إنشاء مشروع Firebase، سيُطلب منك تنزيل ملف تكوين يسمى google-services.json . لا يحتوي هذا الملف على معلومات حساسة ويتم استهلاكه بواسطة كل من تطبيق DRC المرجعي ومصدر الرمز المميز لاحقًا.

دمج التطبيق جمهورية الكونغو الديمقراطية

يوجد تطبيق DRC المرجعي في packages/apps/Car/DebuggingRestrictionController . يمكن إنشاء التطبيق مجمعًا في AOSP باستخدام Soong أو غير مجمع باستخدام Gradle .

بناء المجمعة

لإنشاء تطبيق مجمع:

انسخ applicationId و projectId و apiKey من google-services.json إلى packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java . يؤدي القيام بذلك إلى تمكين تطبيق DRC من الاتصال بـ Firebase بشكل صحيح.
قم بتحديث هذه الثوابت في packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java :
- يشير TOKEN_USES_SELF_SIGNED_CA إلى ما إذا كان يتم استخدام شهادات CA الجذرية الموقعة ذاتيًا. في حالة التمكين، يثق تطبيق DRC فقط في شهادة CA الجذرية المشفرة بواسطة PEM والمحددة في ROOT_CA_CERT .
- TOKEN_ISSUER_API_NAME هو اسم وظيفة Firebase Cloud ويجب أن يتطابق مع وظيفة Cloud التي أنشأتها مسبقًا في Firebase Console.
- يجب أن يتطابق TOKEN_ISSUER_HOSTNAME مع الاسم البديل للموضوع في شهادة الكيان النهائي التي ستوقع رموز الوصول.
- DRC_TEST_EMAIL و DRC_TEST_PASSWORD هما بيانات اعتماد لحساب اختبار اختياري، والذي يمكن توفيره مسبقًا في Firebase إذا قمت بتمكين تسجيل الدخول عبر البريد الإلكتروني/كلمة المرور. وتستخدم هذه للاختبارات المجهزة فقط.

تم الآن تكوين التطبيق لاستخدام حساب Firebase الخاص بك وشهاداتك. في نظام التشغيل Android 9 والإصدارات الأحدث، يجب عليك إعداد القائمة المسموح بها للأذونات المميزة . يجب أن تحتوي القائمة المسموح بها على android.permission.MANAGE_USERS على الأقل. على سبيل المثال:

<permissions>
  <privapp-permissions package="com.android.car.debuggingrestrictioncontroller">
    <permission name="android.permission.INTERNET"/>
    <permission name="android.permission.MANAGE_USERS"/>
  </privapp-permissions>
</permissions>

بناء غير المجمعة

تستخدم إصدارات DRC غير المجمعة Gradle لتجميع التطبيق.

لإنشاء بنية غير مجمعة:

تأكد من تثبيت Android SDK.
قم بإنشاء ملف نصي باسم local.properties في الدليل الجذر للتطبيق.
قم بتعيين موقع Android SDK:
```
 sdk.dir=path/to/android/sdk
```
لإعداد Firebase، انسخ google-services.json إلى packages/apps/Car/DebuggingRestrictionController/app . يقوم Gradle بتحليل الملف وإعداد الباقي تلقائيًا.
تحديد متغيرات البيئة. كما هو الحال مع الإصدارات المجمعة، يجب عليك تحديد:
- $TOKEN_USES_SELF_SIGNED_CA : صحيح أم خطأ؛
- $ROOT_CA_CERT : المسار إلى شهادة CA الجذرية المشفرة بـ PEM؛
- $TOKEN_ISSUER_API_NAME : اسم وظيفة Firebase Cloud؛
- $TOKEN_ISSUER_HOST_NAME : SAN في الشهادة؛
- $DRC_TEST_EMAIL و $DRC_TEST_EMAI L: بيانات الاعتماد لحساب اختباري، إصدارات تصحيح الأخطاء فقط.
لإنشاء التطبيق باستخدام Gradle، قم بتشغيل أمر مثل هذا:
```
$ ./gradlew build
```
ملاحظة: يجب توقيع تطبيق DRC غير المجمع باستخدام شهادة النظام الأساسي لأنه يتطلب إذنًا مميزًا، MANAGE_USERS . لا تزال القائمة المسموح بها للأذونات المميزة مطلوبة لنفس السبب.

دمج مُصدر الرمز المميز

مُصدر الرمز المميز المرجعي هو إحدى وظائف Firebase Cloud التي تم تنفيذها في Node.js لا يمكن استدعاء الوظيفة إلا بواسطة مستخدم مصادق عليه. قبل نشر التطبيق، يجب عليك إعداد المفتاح الخاص والشهادات المستخدمة لتوقيع رموز JWS المميزة.

قم بملء ملف JSON بالمحتويات التالية:
```
{
    "key": "---BEGIN PRIVATE KEY---\nRSA_PRIVATE_KEY\n-----END PRIVATE KEY-----\n",
    "certificates.0": "-----BEGIN CERTIFICATE-----\nTOKEN_SIGNING_CERT\n-----END CERTIFICATE-----\n",
    "certificates.1": "-----BEGIN CERTIFICATE-----\nINTERMEDIATE_CA_CERT\n-----END CERTIFICATE-----\n",
    "certificates.2": "-----BEGIN CERTIFICATE-----\nROOT_CA_CERT\n-----END CERTIFICATE-----\n",
    "expiration": "30m",
    "issuer": "Debugging Access Token Issuer",
    "audience": "IHU"
}
```
يتم طلب الشهادات باستخدام شهادة الكيان النهائي أولاً وشهادة CA الجذرية في النهاية. فترة انتهاء الصلاحية قابلة للتخصيص ويمكن ضبطها على مدة أطول إذا استغرق الرمز المميز الصادر بعض الوقت قبل أن يتم استلامه واستهلاكه بواسطة تطبيق DRC. إبطال الرمز المميز غير مدعوم.
قم بتحميل التكوين إلى Firebase:

$ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"

نشر وظيفة Firebase Cloud:

$ firebase deploy --only functions

لإدارة جهة إصدار الرمز المميز ومراقبته، راجع إدارة خيارات نشر الوظائف ووقت التشغيل .

تعيين القيود الافتراضية

يمكن تطبيق القيود الافتراضية قبل التمهيد الأول. قم بذلك باستخدام تراكبات الموارد الثابتة لتجاوز الإعدادات الافتراضية في إطار عمل Android. ويمكن تطبيق القيود على أنواع مختلفة من المستخدمين على التوالي. للتعرف على الأنواع المختلفة من المستخدمين، راجع دعم المستخدمين المتعددين .

يمكن تكوين التقييد الافتراضي لمستخدم النظام بدون رأس باستخدام مصفوفة السلسلة config_defaultFirstUserRestrictions في frameworks/base/core/res/res/values/config.xml . يؤدي تعيين هذا القيد إلى تعطيل Android Debug Bridge (ADB) تلقائيًا حتى تتم إزالة القيد، على سبيل المثال:

<string-array translatable="false" name="config_defaultFirstUserRestrictions">
  <item>no_debugging_features</item>
</string-array>

يمكن تكوين القيود الافتراضية للمستخدمين العاديين (على سبيل المثال، السائقين والركاب)، والضيوف في frameworks/base/core/res/res/xml/config_user_types.xml . يمكنك تراكب هذه السلاسل لتعيين القيود الافتراضية لكل نوع من المستخدمين على التوالي، على سبيل المثال:

<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>