התנסות בפיתוח ל-Android

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

הגדרה לפיתוח ב-Android

לפני שאתם מורידים ויוצרים את ענף המניפסט android-latest-release של קוד המקור של Android, ודאו שהחומרה שלכם עומדת בדרישות הנדרשות ושהתקנתם כראוי את התוכנה הנדרשת. כדאי גם להכיר את המונחים הבאים:

Git
‫Git היא מערכת מבוזרת לניהול גרסאות בקוד פתוח שמוצעת בחינם. ב-Android משתמשים ב-Git לפעולות מקומיות כמו הסתעפות, ביצוע שינויים, השוואת גרסאות ועריכות. כדי ללמוד איך להשתמש ב-Git, אפשר להיעזר במאמרי העזרה של Git.
Repo
‫Repo הוא wrapper של Python סביב Git, שמפשט את ביצוע הפעולות המורכבות בכמה מאגרי Git. הכלי Repo לא מחליף את Git בכל הפעולות של ניהול הגרסאות, אלא רק מקל על ביצוע פעולות מורכבות ב-Git. הכלי Repo משתמש בקובצי מניפסט כדי לאסוף פרויקטים של Git לפרויקט-העל של Android.
קובץ מניפסט
קובץ מניפסט הוא קובץ XML שמציין איפה נמצאים פרויקטים שונים של Git במקור של Android בתוך עץ מקור של AOSP.

דרישות החומרה של Meet

תחנת העבודה לפיתוח צריכה לעמוד בדרישות החומרה הבאות, או בדרישות גבוהות יותר:

  • מערכת x86 של 64 ביט.

  • לפחות 400GB של מקום פנוי בכונן כדי לבדוק ולבנות את הקוד (250GB לבדיקה + 150GB לבנייה).

  • זיכרון RAM בנפח 64GB לפחות. ‫Google משתמשת במכונות עם 72 ליבות ו-RAM בנפח 64GB כדי ליצור את Android. עם הגדרת החומרה הזו, נדרשות כ-40 דקות לבנייה מלאה של Android ורק כמה דקות לבנייה מצטברת של Android. לעומת זאת, בנייה מלאה במכונה עם 6 ליבות ו-RAM בנפח 64GB נמשכת כ-6 שעות.

עמידה בדרישות מערכת ההפעלה

בתחנת העבודה לפיתוח צריכה לפעול הפצת Linux ב-64 ביט עם GNU C Library (glibc)‎ בגרסה 2.17 ואילך.

התקנת החבילות הנדרשות

כדי להתקין את החבילות הנדרשות ל-Ubuntu 18.04 ואילך, מריצים את הפקודה הבאה:

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

התקנת התוכנה הנדרשת

כדי לעבוד עם AOSP, צריך להתקין את OpenJDK,‏ Make,‏ Python 3 ו-Repo. הגרסה האחרונה של Android כוללת גרסאות מובנות מראש של OpenJDK,‏ Make ו-Python 3, כך שלא נדרשים שלבי התקנה נוספים. בקטע הבא מוסבר איך להתקין את Repo.

התקנת Repo

כדי להתקין את Repo:

  1. מורידים את פרטי החבילה הנוכחית:

    sudo apt-get update
  2. מריצים את הפקודה הבאה כדי להתקין את מרכז האפליקציות של המאגר:

    sudo apt-get install repo

    מרכז האפליקציות של Repo מספק סקריפט Python שמפעיל את ה-checkout ומוריד את הכלי המלא של Repo.

    אם הצלחתם, דלגו לשלב 4.

  3. אופציונלי: מתקינים את Repo באופן ידני באמצעות סדרת הפקודות הבאה:

    export REPO=$(mktemp /tmp/repo.XXXXXXXXX)
    curl -o ${REPO} https://storage.googleapis.com/git-repo-downloads/repo
    gpg --recv-keys 8BB9AD793E8E6153AF0F9A4416530D5E920F5C65
    curl -s https://storage.googleapis.com/git-repo-downloads/repo.asc | gpg --verify - ${REPO} && install -m 755 ${REPO} ~/bin/repo

    שלוש הפקודות הראשונות מגדירות קובץ זמני, מורידות את Repo לקובץ ומוודאות שהמפתח שסופק תואם למפתח הנדרש. אם הפקודות האלה מסתיימות ללא שגיאות, הפקודה האחרונה מתקינה את מרכז האפליקציות של Repo.

  4. מאמתים את הגרסה של מרכז האפליקציות של Repo:

    repo version

    הפלט אמור לציין גרסה 2.4 ומעלה, לדוגמה:

    repo launcher version 2.45
    

הורדת קוד המקור של Android

קוד המקור של Android נמצא באוסף של מאגרי Git שמתארחים ב-Google. כל מאגר Git כולל את כל ההיסטוריה של קוד המקור של Android, כולל השינויים שבוצעו בקוד המקור והמועד שבו הם בוצעו. כדי להוריד את קוד המקור של Android:

  1. עוברים לספריית הבית:

    cd ~
  2. יוצרים בתוכה ספריית משנה מקומית לעבודה:

    mkdir aosp
  3. עוברים לספרייה:

    cd aosp
  4. מאתחלים את ההסתעפות של הגרסה האחרונה של קוד המקור במאגר AOSP‏ (android-latest-release):

    repo init --partial-clone -b android-latest-release -u https://android.googlesource.com/platform/manifest
  5. מזינים או מאשרים את פרטי הכניסה ל-Git (שם, כתובת אימייל).

  6. מסנכרנים את קוד המקור:

    repo sync -c -j8

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

בניית הקוד

כדי ליצור את הקוד:

  1. בספריית העבודה, מפעילים את הסקריפט envsetup.sh כדי להגדיר את סביבת ה-build:

    source build/envsetup.sh
  2. מציינים את סוג מכשיר היעד שרוצים ליצור באמצעות הפקודה lunch. יעד הוא תצורה של מכשיר, כמו דגם או גורם צורה ספציפיים. מציינים את היעד הזה:

    lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug

    אמור להופיע תקציר של היעד ושל סביבת ה-build:

    ============================================
    PLATFORM_VERSION_CODENAME=Baklava
    PLATFORM_VERSION=Baklava
    TARGET_PRODUCT=aosp_cf_x86_64_only_phone
    TARGET_BUILD_VARIANT=userdebug
    TARGET_ARCH=x86_64
    TARGET_ARCH_VARIANT=silvermont
    HOST_OS=linux
    HOST_OS_EXTRA=Linux-6.10.11-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete
    HOST_CROSS_OS=windows
    BUILD_ID=BP1A.250305.020
    OUT_DIR=out
    ============================================
    
  3. בונים את היעד:

    m

ה-build הראשון צפוי להימשך כמה שעות. ה-builds הבאים יימשכו הרבה פחות זמן. הפלט של ה-build מופיע ב-$OUT_DIR.

הפעלת Cuttlefish

‫Cuttlefish הוא אמולטור Android שמשמש לבדיקת גרסאות ה-build שלכם.

  1. מריצים את הפקודות הבאות כדי להוריד, ליצור ולהתקין את חבילות Debian של המארח:

    sudo apt install -y git devscripts equivs config-package-dev debhelper-compat golang curl
    git clone https://github.com/google/android-cuttlefish
    cd android-cuttlefish
    tools/buildutils/build_packages.sh
    sudo apt install -y ./cuttlefish-base_*.deb ./cuttlefish-user_*.deb
    sudo usermod -aG kvm,cvdnetwork,render $USER
    sudo reboot

    ההפעלה מחדש מפעילה התקנה של מודולים נוספים של ליבה (kernel) ומחילה כללי udev.

  2. אחרי שהתחנה תופעל מחדש, עוברים לספרייה aosp, מגדירים את סביבת ה-build ומפעילים את Cuttlefish:

    cd ~/aosp
    source build/envsetup.sh
    lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug
    launch_cvd --daemon
  3. מתחברים למכשיר Cuttlefish על ידי מעבר אל https://localhost:8443 בדפדפן האינטרנט. המכשיר הווירטואלי שלכם שמופעל באמצעות Android מוצג.

ביצוע שינוי

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

  1. מהשורש של ה-checkout (הספרייה aosp/), עוברים לפרויקט Git של frameworks/native:

    cd frameworks/native
  2. מתחילים ענף זמני באמצעות הפקודה הבאה:

    repo start BRANCH_NAME .
  3. משתמשים בכלי העריכה כדי לערוך את SurfaceFlinger.cpp במיקום הבא:

    aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
    
  4. מוצאים את השורה הזו:

    void SurfaceFlinger::updateColorMatrixLocked() {
    
  5. מוסיפים את השורה הזו בתחילת הקובץ updateColorMatrixLocked():

    mClientColorMatrix = mat4(vec4{1.0f, 0.0f, 0.0f, 0.0f}, vec4{0.0f, -1.0f, 0.0f, 0.0f},
                              vec4{0.0f, 0.0f, -1.0f, 0.0f}, vec4{0.0f, 1.0f, 1.0f, 1.0f});
    
  6. יוצרים את הקוד:

    m
  7. מעדכנים את ה-build במכשיר:

    adb root
    adb remount -R
    adb root
    adb sync
    adb reboot
  8. מוודאים שהצבע השתנה במכשיר שנבחר.

תיקון בדיקה

בחלק הזה של ה-Codelab נשתמש בבדיקה לדוגמה שנמצאת בעץ המקור ונכשלת. כדי להריץ את הבדיקה, לנפות באגים ולתקן אותה, פועלים לפי ההוראות הבאות:

  1. מריצים את הפקודה:

    atest DevCodelabTest

    הבדיקה נכשלת.

  2. בודקים את דוח הקריסות של הבדיקה שנכשלה:

    STACKTRACE:
    java.lang.AssertionError
        at org.junit.Assert.fail(Assert.java:87)
        at org.junit.Assert.assertTrue(Assert.java:42)
        at org.junit.Assert.assertTrue(Assert.java:53)
        at android.test.example.devcodelab.DevCodelabTest.testHelloWorld(DevCodelabTest.java:29)
    

    השורה האחרונה בדוח הקריסות מציגה את הבדיקה שנכשלה (testHelloWorld). הבדיקה הזו נמצאת בקובץ בשם DevCodelabTest.java.

  3. כדי לקבוע את המיקום של הבדיקה שצריך לתקן, מוסיפים את WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/ לשורה האחרונה של דוח הקריסות, עד לשם של קובץ הבדיקה (כולל). לכן, android.test.example.devcodelab.DevCodelabTest הופך ל-WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java.

  4. עורכים את platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java ומחליפים את Assert.assertTrue(false) ב-Assert.assertTrue(true).

  5. מריצים את הבדיקה שוב כדי לוודא שהבעיה נפתרה:

    atest DevCodelabTest

העלאת הקוד לבדיקה

הכלי Repo מפשט את השימוש ב-Git על ידי קיבוץ פקודות כמו git clone כדי לעבוד על מספר מאגרי Git (או פרויקטים) בו-זמנית. כדי לבצע סקר קוד של הפרויקטים ב-Git, השתמשו במערכת Gerrit מבוססת-אינטרנט לסקר קוד.

  1. בהנחה שביצעתם את השינויים בפרויקט frameworks/native, הריצו את הפקודות הבאות כדי להעלות את השינויים:

    cd frameworks/native
    repo start BRANCH_NAME .
    git add .
    git commit
  2. מזינים את ההודעה הבאה:

    Android BRANCH_NAME change
    Test: manual atest
    
  3. מעלים את השינוי:

    repo upload

    אם הפעולה בוצעה בהצלחה, תופיע הודעה דומה לזו:

    Upload project frameworks/native/ to remote branch android17-release:
      branch BRANCH_NAME ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
             ff46b36d Android BRANCH_NAME change
    to https://android-review.googlesource.com/ (y/N)? y
    remote: Processing changes: refs: 1, new: 1, done
    remote:
    remote: SUCCESS
    remote:
    remote:   https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432 Android BRANCH_NAME change [NEW]
    remote:
    To https://android-review.googlesource.com/platform/frameworks/native
    * [new branch]          BRANCH_NAME -> refs/for/android17-release
    

הצגת השינוי ב-Gerrit

כדי לראות את השינוי ב-Gerrit, עוברים לקישור שמופיע בטרמינל. הקישור דומה לקישור הבא:

https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432

מבטלים את השינויים.

בדרך כלל, אחרי הבדיקה, הבדיקה והאישור, אתם שולחים את השינוי ב-Gerrit וממזגים אותו במאגר. במקום זאת, למטרות ה-Codelab הזה, בטלו את השינויים:

  1. ב-Gerrit, לוחצים על Abandon.

  2. נוטשים את ההסתעפות הזמנית שמשויכת בספריית הפרויקט frameworks/native (או בספריות המשנה שלה):

    repo abandon BRANCH_NAME .
  3. מבטלים את השינויים שביצעתם בקובץ הבדיקה. מכיוון שלא הרצתם את repo start, git commit ו-repo upload בשינוי הבדיקה, אתם יכולים לאפס את הקובץ עצמו. אם אתם נמצאים בספרייה aosp/platform_testing, השתמשו בפקודות הבאות כדי לאפס את הקובץ:

    git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
    git checkout .

זהו, סיימתם את ה-Codelab לפיתוח פלטפורמת Android.

עזרה

אם נתקלתם בשגיאות במהלך ה-Codelab, אתם יכולים לדווח עליהן באמצעות הקישור ל-Issue Tracker שבתחתית כל דף. לשלוח שאלות לקבוצה android-building.

מקלידים ps -A | grep crosvm כדי לבדוק אם crosvm כבר פועל. אם crosvm פועל, מקלידים stop_cvd || true או kill crosvm עם מזהה התהליך (PID).