החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.

דף זה תורגם על ידי Cloud Translation API.

מדריך לשילוב של בקר להגבלות על ניפוי באגים
קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

בעזרת ההוראות שבהמשך תוכלו לשלב את AAOS Debugging Restriction Controller‏ (DRC).

איור 1. דוגמה לאפליקציה עם DRC.

ארכיטקטורה

הארכיטקטורה של DRC מופיעה באיור 2. לרכיבים שמסומנים באדום (הנפקת אסימונים ו-DRC) יש הטמעות עזר שאפשר להתאים אישית.

איור 2. ארכיטקטורת DRC.

מהו DRC?

היחידה הראשית ברכב כוללת את אפליקציית ה-DRC (ראו את הטמעת העזר ב-packages/apps/Car/DebuggingRestrictionController). אפליקציית העזר כוללת את הלוגיקה לקבלת אסימון גישה ממנפיק האסימון, לאימות האסימון ולאחר מכן להחלה של שינויים בהגבלות לניפוי באגים כפי שצוינו באסימון. הלוגיקה כוללת אלמנטים בסיסיים של חוויית משתמש בצד הרכב.

מהו המנפיק של האסימון?

זהו שירות אינטרנט שמנפיק אסימוני גישה עם חתימה קריפטוגרפית (ראו את ההטמעה לדוגמה בקובץ packages/apps/Car/DebuggingRestrictionController/server). שירות האינטרנט לדוגמה הוא פונקציית Cloud של Firebase שניתן לפרוס (מידע נוסף זמין במאמר Cloud Functions for Firebase).

דרישות מוקדמות

לפני שפורסים הטמעת עזר, חשוב לבצע את המשימות הבאות.

הכנת אישורים לחתימה על אסימוני גישה

מנפיק האסימון יוצר חתימות רשת מבוססות JSON ‏ (JWS) כאסימוני גישה. כדי לשמור על תאימות אופטימלית, מנפיק העזר תומך רק באלגוריתם RS256 (חתימות RSA עם SHA256). כדי להקל על רוטציית מפתחות, משתמשים בשרשרת אישורים במקום באישור יחיד כדי לחתום על אסימוני גישה. שרשרת אישורים רגילה צריכה לכלול אישור של רשות אישורי בסיס, אישור של רשות אישורים ברמת ביניים ואישור של ישות קצה.

אישור הישות הקצה שחותם על אסימוני ה-JWT לא שונה מאישור TLS רגיל. אפשר לרכוש אישור מרשויות אישורים ציבוריות כמו DigiCert, או לנהל שרשרת אישורים משלכם באמצעות אישורי Root CA בחתימה עצמית או מודולים של אבטחת חומרה. אישור הישות הקצה צריך להיות אישור X509v3 עם תוסף Subject Alternative Name‏ (SAN). הסיומת SAN מכילה מזהה (למשל, שם מארח) של המנפיק של האסימון. לבסוף, מומלץ להשתמש באישורי RSA במקום באישורי EC, כי מנפיק האסימונים תומך רק ב-RS256.

Google מספקת סקריפט מעטפת ליצירת אישורים בחתימה עצמית ב-packages/apps/Car/DebuggingRestrictionController/server/genkey.sh.

הגדרת Firebase

המנפיק של אסימון העזרה משתמש ב-Firebase Authentication וב-Firebase Cloud Function.

כדי להגדיר את חשבון Firebase:

במאמר הוספת Firebase לפרויקט Android מוסבר איך יוצרים פרויקט Firebase.
במאמר איך מתחילים להשתמש באימות ב-Firebase מוסבר איך מפעילים אימותים מסוימים של Firebase.
במאמר תחילת העבודה מוסבר איך מוסיפים פונקציה ריקה של Cloud Functions ב-Firebase.
אם עדיין לא עשיתם זאת, מתקינים את Node.js, את NPM ואת הכלים של Firebase כדי לקמפל ולפרוס את מנפיק האסימונים.
הערה: אחרי שיוצרים פרויקט ב-Firebase, מופיעה בקשה להוריד קובץ תצורה שנקרא google-services.json. הקובץ הזה לא מכיל מידע רגיש, והוא ישמש גם את אפליקציית ה-DRC לדוגמה וגם את מנפיק האסימון מאוחר יותר.

שילוב אפליקציית DRC

אפליקציית ה-DRC לדוגמה נמצאת ב-packages/apps/Car/DebuggingRestrictionController. אפשר ליצור את האפליקציה במקבץ ב-AOSP באמצעות Soong או ללא מקבץ באמצעות Gradle.

build בחבילה

כדי ליצור אפליקציה בחבילה:

מעתיקים את 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 הוא השם של פונקציית Cloud ב-Firebase, והוא צריך להתאים לפונקציית Cloud שיצרתם מקודם במסוף Firebase.
- השדה TOKEN_ISSUER_HOSTNAME צריך להתאים לשם החלופי של הנושא (SAN) באישור הישות הסופית שבו חותמים על אסימוני הגישה.
- 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>

build לא מקופל

ב-builds של DRC לא מקופלים נעשה שימוש ב-Gradle כדי לקמפל את האפליקציה.

כדי ליצור build ללא חבילה:

מוודאים שהתקנתם את Android SDK.
יוצרים קובץ טקסט בשם local.properties בתיקיית השורש של האפליקציה.
מגדירים את המיקום של Android SDK:
```
 sdk.dir=path/to/android/sdk
```
כדי להגדיר את Firebase, מעתיקים את google-services.json אל packages/apps/Car/DebuggingRestrictionController/app. Gradle מנתח את הקובץ ומגדיר את שאר הדברים באופן אוטומטי.
מגדירים את משתני הסביבה. כמו ב-builds בחבילה, צריך לציין את הפרטים הבאים:
- $TOKEN_USES_SELF_SIGNED_CA: true או false;
- $ROOT_CA_CERT: הנתיב לאישור ה-CA הבסיסי המקודד ב-PEM.
- $TOKEN_ISSUER_API_NAME: השם של פונקציית Cloud ב-Firebase.
- $TOKEN_ISSUER_HOST_NAME: כתובת ה-SAN באישור.
- $DRC_TEST_EMAIL ו-$DRC_TEST_EMAIL: פרטי כניסה לחשבון בדיקה, לגרסאות build לניפוי באגים בלבד.
כדי ליצור את האפליקציה באמצעות Gradle, מריצים פקודה כמו זו:
```
$ ./gradlew build
```
הערה: אפליקציית DRC לא מקובצת חייבת להיות חתומה על ידי אישור הפלטפורמה, כי היא דורשת הרשאה בעלת הרשאות, MANAGE_USERS. הוספת הרשאות להרשאה עדיין נדרשת מהסיבה הזו.

שילוב המנפיק של האסימון

המנפיק של אסימון העזר הוא פונקציית Cloud של Firebase שמיושמת ב-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)"

פורסים את הפונקציה של Cloud Functions ב-Firebase:

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