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

Codelab למפתחי Android

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

על אף שהדרך מאתגרת, צוות Android שואף לפשט את המסע שלכם, כל גרסה. הצוות גם מבצע שיפורים מדי יום באמצעות עבודה ישירה על פרויקט קוד פתוח של Android (AOSP).

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

שערים

המשימה של Codelab זו כפולה:

לתת לכם טעימה קטנה איך תהליך העבודה של המפתחים פועל אצל מהנדסי Android שעובדים על הפלטפורמה (מערכת ההפעלה).
מומלץ לתת משוב לגבי הכלים, המסמכים ותהליך העבודה למפתחים של Android.

דרישות סף

רשימת הדרישות ל-Codelab הזה נגזרת מהדרישות לפיתוח פלטפורמה כללית (AOSP). כדי להשתמש ב-Codelab הזה, צריך להגדיר את הדברים הבאים:

תחנות עבודה פיזיות עם Linux שעומדות בכל הדרישות הציבוריות.
Repo ואת ההגדרות של Git שנדרשות לעריכת ה-codebase של Android.

סביבה

בדרך כלל המשתמשים בונים ומתפתחים בתחנת העבודה באופן ישיר. יכול להיות שאתם עובדים במסופים שונים, והרבה מהפקודות שבהן נעשה שימוש הן ספציפיות לטרמינל, ולכן תצטרכו להריץ אותן מחדש בכל סשן בטרמינל. באופן ספציפי, הן כוללות את הפקודות source build/envsetup.sh ו-lunch.

הגדרה של תחנת עבודה

מתקינים את החבילות הנדרשות בתחנת העבודה.
כשאתם עדיין נמצאים בטרמינל, מתקינים את Repo ומקבלים פרטי כניסה לכל המאגרים של Git.

הפעלה וסנכרון של הקוד

מנווטים לספריית הבית:
```
cd ~
```
כדי ליצור ספריית משנה מקומית לעבודה:
```
mkdir aosp
```
מנווטים לספרייה:
```
cd aosp
```
מאתחלים את ההסתעפות הראשית של קוד המקור של מאגר AOSP (ברירת המחדל):
```
repo init -u https://android.googlesource.com/platform/manifest
```
מזינים או מאשרים את פרטי הכניסה ל-Git (שם, כתובת אימייל).
מסנכרנים את קוד המקור:
```
repo sync -j8
```

סנכרונים ראשוניים יכולים להימשך שעה או יותר.

כל תשלום במאגר מיוצג על ידי קובץ מניפסט. מותר לנהל יותר מתשלום אחד במאגר אחד בכל פעם, כל עוד הם קיימים בספריות נפרדות. עם זאת, חשוב לזכור שכל תשלום בקופה וגרסת build מסתכמים בכ-300GB לשימוש (וזה הולך וגדל), כך שתוכלו להגביל את עצמכם לשני תשלומים נוספים במאגר או להרחיב את המערכת באמצעות כונן משני.

טיפ: כדי להגדיל את המקום הפנוי, מוחקים ספריית הסתעפות ומתחילים מחדש מיצירת הספרייה, כמו בדוגמה הבאה: rm -rf aosp2.

כתיבת הקוד

כדי לפתח את Android, צריך לבחור סוג מכשיר target ל-build באמצעות הפקודה lunch. יעד הוא תמורה של מכשיר, כמו דגם או גורם צורה ספציפיים.

מכשיר היעד aosp_cf_x86_64_phone-userdebug מאפשר לפתח מכשיר Android וירטואלי Cuttlefish לצורך בדיקה ללא מכשיר פיזי.

כדי לפתח מכשיר פיזי ולעדכן אותו במקום זאת, בוחרים יעד אחר ופועלים לפי ההוראות למכשירים מהבהבים.

כדי להגדיר את הסביבה לפיתוח מכשירי Android, מריצים את הפקודה הבאה מהרמה הבסיסית (root) של התשלום באמצעות קוד מקור:
```
source build/envsetup.sh
```
מעבירים את יעד ה-build לפקודה לארוחת צהריים, כך:
```
lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
```
אתם יכולים ליצור את הקוד מכל מקום בקופה באמצעות:
```
m
```

ה-build הראשון צפוי להימשך כמה שעות. גרסאות ה-build הבאות נמשכות פחות זמן באופן משמעותי.

הפעלת דיונון

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

אם אף פעם לא התקנתם את ה-Cuttlefish, עליכם להתקין את יחסי התלות הנדרשים של Cuttlefish. בחלון הטרמינל, מריצים את הפקודות הבאות כדי להוריד, ליצור ולהתקין את חבילות 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
for dir in base frontend; do
pushd $dir
# Install build dependencies
sudo mk-build-deps -i
dpkg-buildpackage -uc -us
popd
done
sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
sudo usermod -aG kvm,cvdnetwork,render $USER
sudo reboot

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

מפעילים את הדיונון:
```
launch_cvd --daemon
```
כדי להתחבר למכשיר Cuttlefish, עוברים אל https://localhost:8443 בדפדפן האינטרנט. יוצג לכם שידור וידאו של המכשיר המבוסס-Android שבניתם.

ביצוע שינוי

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

מהרמה הבסיסית (root) של התשלום בקופה (הספרייה aosp/), עוברים לפרויקט frameworks/native Git:
```
cd frameworks/native
```
מתחילים פרויקט זמני באמצעות הפקודה הבאה:
```
repo start <some-name> .
```
עורכים את SurfaceFlinger.cpp כדי לכלול את העדכונים מרשימת השינויים במיקום הבא:
```
aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
```

מצאו את השורה הזו:

void SurfaceFlinger::updateColorMatrixLocked() {

מוסיפים את שתי השורות הבאות בתחילת הפונקציה 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});

יוצרים את הקוד:
```
m
```

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

adb root
adb remount
adb sync
adb reboot

מוודאים שמופיע שינוי צבע במכשיר שנבחר, בדומה לזה שמופיע באיור 1.

דוגמה לשינוי צבע מוצלח

איור 1. מראה המסך לאחר שינוי הצבע בהצלחה

בדיקת הקוד

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

כדי להשתמש בבדיקה, יש לפעול לפי ההוראות הבאות:

הפעלה:
```
atest DevCodelabTest
```
הבדיקה תיכשל. כדי לפתור את הבעיה, מאתרים את קוד המקור של הבדיקה שנכשלה:
```
atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
```

לאחר מכן הסתכלו כאן

platform_testing/tests/example/devcodelab

כדי שתהיה אפשרות לערוך את הקובץ, מזינים את שם הבדיקה ב-android.test.example.devcodelab.DevCodelabTest ומחליפים את . ב-/, כדי לקבל את התוצאה הבאה:
```
src/android/test/example/devcodelab/DevCodelabTest.java
```

ואז לערוך

platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java

להחלפה

Assert.assertTrue(false)

עם

Assert.assertTrue(true)

מריצים שוב את הבדיקה כדי לוודא שהבעיה נפתרה:
```
atest DevCodelabTest
```

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

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

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

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

בהנחה שביצעתם את השינויים בפרויקט frameworks/native, מריצים את הפקודות הבאות כדי להעלות אותם:
```
cd frameworks/native
repo start codelab .
git add .
git commit
```
בהודעת ההצהרה, מזינים את הפרטים הבאים:
```
Android codelab change
Test: manual atest
```
מעלים את השינוי:
```
repo upload
```

אם תצליחו, תוצג הודעה שדומה להודעה הזו:

Upload project frameworks/native/ to remote branch main:
  branch codelab ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
         ff46b36d android codelab 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 codelab change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
 * [new branch]          codelab -> refs/for/main

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

עוברים לקישור, המודפס במסוף, שדומה לזה:

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

השלמה של ה-Codelab לתחילת העבודה לפיתוח פלטפורמת Android. ראו שליחת תיקונים לשלבים הבאים, ולקבל פרטים מלאים על פיתוח Android בשאר האתר.

ביטול השינוי

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

במקום זאת, לצורך ה-Codelab הזה, צריך לבטל את רשימת השינויים על ידי לחיצה על Abandon (נטישה) ב-Gerrit.

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

repo abandon codelab .

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

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

בשלב הזה סיימת! מעולה,

עזרה

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