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

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

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

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

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

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

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

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

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

هذه خدمة ويب تصدر رموز الدخول الموقّعة بطريقة مشفرة (راجع المرجع عملية التنفيذ في packages/apps/Car/DebuggingRestrictionController/server). إنّ خدمة الويب المرجعية عبارة عن وظيفة في السحابة الإلكترونية Firebase قابلة للنشر (لمزيد من المعلومات، يُرجى مراجعة الوظائف السحابية 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

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

  1. لإنشاء مشروع على Firebase، اطّلِع على إضافة Firebase إلى مشروعك على Android.
  2. لتفعيل بعض مصادقات Firebase، يمكنك الاطلاع على أين يمكنني بمصادقة Firebase؟.
  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 ويؤدي ذلك إلى تفعيل تطبيق جمهورية الكونغو الديمقراطية من الاتصال بمنصّة Firebase بشكل صحيح.
  2. تعديل هذه الثوابت في 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 ويجب تتطابق مع دالة السحابة الإلكترونية التي أنشأتها سابقًا في "وحدة تحكُّم 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: المسار إلى شهادة CA الجذرية بترميز PEM،
    • $TOKEN_ISSUER_API_NAME: اسم وظيفة Firebase Cloud
    • $TOKEN_ISSUER_HOST_NAME: SAN في الشهادة.
    • $DRC_TEST_EMAIL و$DRC_TEST_EMAIL: بيانات اعتماد اختبار في إصدارات تصحيح الأخطاء فقط.
  6. لإنشاء التطبيق باستخدام Gradle، شغِّل أمرًا مثل: 
    $ ./gradlew build

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

إنّ جهة إصدار الرمز المميّز المرجعي هي إحدى وظائف السحابة الإلكترونية في Firebase التي تم تنفيذها في 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"
}

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

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

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

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