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

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

الشكل 1. DRC التطبيق المثال

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

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

العمارة الشكل 2. DRC

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

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

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

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

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

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

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

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

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

توفر Google شيل لتوليد الشهادات الموقعة ذاتيا في packages/apps/Car/DebuggingRestrictionController/server/genkey.sh .

إعداد Firebase

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

لإعداد حساب Firebase الخاص بك:

  1. لإنشاء مشروع Firebase، انظر اضافة Firebase إلى مشروع Android .
  2. لتمكين بعض الموثقون Firebase، انظر من أين أبدأ مع مصادقة Firebase؟ .
  3. لإضافة وظيفة Firebase سحابة فارغة، راجع الشروع .
  4. إذا لم يكن قد تم بالفعل ، فقم بتثبيت أدوات Node.js و NPM و Firebase لتجميع ونشر Token Issuer.

دمج تطبيق DRC

يقع التطبيق إشارة DRC في packages/apps/Car/DebuggingRestrictionController . التطبيق يمكن أن يبنى المجمعة في AOSP مع سونغ أو المفككة مع 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 الجذر موقعة ذاتيا. في حالة التمكين، وجمهورية الكونغو الديمقراطية التطبيق يثق سوى شهادة CA الجذر ترميز PEM المحددة في ROOT_CA_CERT .
    • TOKEN_ISSUER_API_NAME هو اسم الدالة Firebase الغيمة ويجب أن يتطابق مع وظيفة السحب قمت بإنشائها سابقا في وحدة التحكم Firebase.
    • TOKEN_ISSUER_HOSTNAME يجب أن يطابق اسم موضوع البديل في شهادة نهاية الكيان الذي سيوقع الرموز الوصول.
    • DRC_TEST_EMAIL و DRC_TEST_PASSWORD هي بيانات اعتماد حساب اختبار اختياري، والتي يمكن توفيرها قبل في Firebase إذا كنت قد مكنت تسجيل الدخول البريد الإلكتروني / كلمة المرور. هذه تستخدم في الاختبارات المجهزة فقط.

تم تكوين التطبيق الآن لاستخدام حسابك في Firebase وشهاداتك. في الروبوت 9 والتعليم العالي، يجب إعداد إذن المميز Allowlisting . يجب أن تحتوي على ما لا يقل عن allowlist 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. تأكد من تثبيت Android SDK.
  2. إنشاء ملف نصي يدعى local.properties في الدليل الجذر التطبيق.
  3. تعيين موقع أندرويد SDK:
     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 الغيمة.
    • $TOKEN_ISSUER_HOST_NAME : SAN في الشهادة؛
    • $DRC_TEST_EMAIL و $DRC_TEST_EMAI L: وثائق التفويض لحساب الاختبار، ويبني التصحيح فقط.
  6. لبناء التطبيق مع Gradle، تشغيل أمر من هذا القبيل:
    $ ./gradlew build
    

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

يُعد إصدار الرمز المميز المرجعي إحدى وظائف Firebase Cloud التي يتم تنفيذها في 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)"
    
  4. انشر وظيفة Firebase Cloud:
  5. $ firebase deploy --only functions
    
  6. لإدارة ومراقبة الخاص بك رمز المصدر، راجع إدارة خيارات وظائف نشر ووقت التشغيل .

تحديد القيود الافتراضية

يمكن تطبيق القيود الافتراضية قبل التمهيد الأول. قم بذلك باستخدام تراكبات موارد ثابتة لتجاوز الإعدادات الافتراضية في إطار عمل 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>