دليل دمج وحدة التحكّم في القيود لتصحيح الأخطاء

استخدِم التعليمات الواردة في هذه الصفحة لدمج وحدة التحكّم في القيود المتعلقة بتصحيح الأخطاء في نظام التشغيل AAOS (DRC).

الشكل 1: مثال على تطبيق DRC

هندسة معمارية

توضّح الصورة 2 بنية DRC. تتضمّن المكوّنات التي تم تحديدها باللون الأحمر (مُصدِر الرمز المميّز و DRC) عمليات تنفيذ مرجعية يمكنك تخصيصها.

الشكل 2: بنية DRC

ما هو DRC؟

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

ما هو جهة إصدار الرمز المميّز؟

هذه خدمة ويب تُصدر علامات أمان وصول موقَّعة تشفيريًا (اطّلِع على مرجع تنفيذ packages/apps/Car/DebuggingRestrictionController/server). خدمة الويب المرجعية هي إحدى وظائف Firebase السحابية القابلة للنشر (للاطّلاع على مزيد من المعلومات، اطّلِع على مقالة وظائف سحابة لخدمة Firebase).

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

قبل نشر عملية تنفيذ مرجعية، احرص على إكمال المهام التالية.

تحضير الشهادات لتوقيع الرموز المميّزة للوصول

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

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

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

إعداد Firebase

يستخدم مُصدِر الرمز المرجعي Firebase Authentication وFirebase Cloud Function.

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

  1. لإنشاء مشروع على Firebase، اطّلِع على مقالة إضافة Firebase إلى مشروع Android.
  2. لتفعيل بعض مصادقة Firebase، اطّلِع على مقالة أين يمكنني البدء باستخدام Firebase Authentication؟.
  3. لإضافة دالة Firebase Cloud فارغة، راجِع مقالة البدء.
  4. ثبِّت Node.js وNPM وأدوات Firebase لتجميع ملف رمز الاعتماد و نشره، إذا لم يسبق لك إجراء ذلك.

دمج تطبيق DRC

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

الإصدار المجمّع

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

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

تم الآن ضبط التطبيق لاستخدام حسابك على Firebase وشهاداتك. في الإصدار 9 من نظام التشغيل Android والإصدارات الأحدث، يجب إعداد قائمة مسموح بها للأذونات المميّزة. يجب أن تحتوي القائمة المسموح بها على 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 لتجميع التطبيق.

لإنشاء إصدار غير مجمّع:

  1. تأكَّد من تثبيت حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
  2. أنشئ ملفًا نصيًا باسم local.properties في الدليل الجذر للتطبيق.
  3. اضبط موقع حزمة تطوير البرامج (SDK) لنظام التشغيل Android: 
     sdk.dir=path/to/android/sdk
  4. لإعداد Firebase، انسخ google-services.json إلى packages/apps/Car/DebuggingRestrictionController/app. يُحلِّل Gradle الملف ويُعدّ الباقي تلقائيًا.
  5. حدِّد متغيّرات البيئة. كما هو الحال مع الإصدارات المجمّعة، عليك تحديد ما يلي:
    • $TOKEN_USES_SELF_SIGNED_CA: صحيح أو خطأ
    • $ROOT_CA_CERT: مسار شهادة مرجع التصديق الجذر بترميز PEM
    • $TOKEN_ISSUER_API_NAME: اسم وظيفة Firebase Cloud
    • $TOKEN_ISSUER_HOST_NAME: عنوان شبكة التخزين في الشهادة
    • ‫$DRC_TEST_EMAIL و$DRC_TEST_EMAIL: بيانات اعتماد لحساب تجريبي، إصدارات تصحيح الأخطاء فقط
  6. لإنشاء التطبيق باستخدام Gradle، شغِّل أمرًا مثل هذا: 
    $ ./gradlew build

دمج جهة إصدار الرمز المميّز

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

  1. املأ ملف 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"
}

    يتم ترتيب الشهادات مع شهادة الكيان النهائي أولاً وشهادة هيئة إصدار الشهادات الجذر في النهاية. يمكن تخصيص فترة انتهاء الصلاحية ويمكن ضبطها على مدة أطول إذا كان الرمز المميّز الذي تم إصداره يستغرق بعض الوقت قبل أن يتم استلامه واستخدامه من خلال تطبيق DRC. ولا يمكن إبطال الرمز المميّز.

  2. حمِّل الإعدادات إلى Firebase:
    3. $ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"
  3. يمكنك نشر وظيفة Firebase Cloud باتّباع الخطوات التالية:
    4. $ firebase deploy --only functions
  4. لإدارة مُصدِّر الرمز المميّز وتتبُّعه، اطّلِع على مقالة إدارة خيارات وقت التشغيل ونشر الدوالّ.

ضبط القيود التلقائية

يمكن تطبيق القيود التلقائية قبل عملية التشغيل الأولى. يمكنك إجراء ذلك باستخدام تراكب موارد static لإلغاء الإعدادات التلقائية في إطار عمل 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>