במסמך הזה מפורטות תשובות לשאלות כלליות לגבי פלטפורמת הקוד הפתוח של Android (AOSP).
מידע על android-latest-release
למה אי אפשר לשלוח ל-aosp-main?
אי אפשר לשלוח אל aosp-main כי הענף הזה הוא עכשיו לקריאה בלבד.
איפה אפשר להציע שינויים ב-AOSP?
צריך להציע שינויים חדשים ב-android-latest-release (כשמשתמשים ב-Repo) או בענף הגרסה האחרונה שצוין במניפסט android-latest-release (כשמשתמשים ב-Git ישירות). אין צורך להעביר הצעות לשינויים קיימים בענפים אחרים (כמו aosp-main).
לאיזה ענף כדאי לסנכרן?
כשמשתמשים ב-Repo, מסנכרנים עם
android-latest-releaseבאמצעות הפקודה הבאה:repo init --partial-clone --no-use-superproject -b android-latest-release -u https://android.googlesource.com/platform/manifestכשמשתמשים ב-Git ישירות, צריך לסנכרן עם ענף ברירת המחדל של הגרסה שצוין ב
android-latest-releaseמניפסט.
פרטים נוספים על סנכרון ענפים זמינים במאמר בנושא הפעלת הלקוח של Repo.
האם הקוד מ-android-latest-release ימוזג עם aosp-main?
לא, הקוד לא ימוזג עם aosp-main, שהוא ענף לקריאה בלבד החל מ-27 במרץ 2025.
לאן נדחף הקוד של הגרסה הבאה?
Google דוחפת את הקוד של הגרסה הבאה אל הסתעפות הגרסה הציבורית האחרונה
ומעדכנת את android-latest-release קובץ המניפסט כך שיצביע על הסתעפות זו.
האם בקשת השינוי שלי תועתק מההסתעפות android-latest-release אל Gerrit הפנימי?
אחרי שמעלים שינוי מוצע, Google בודקת אותו ואם הוא מתקבל, היא בוחרת אותו ומעבירה אותו ל-Gerrit הפנימי.
איך אפשר לדעת אם בקשת השינוי אושרה?
שינויים שאושרו ונבחרו יופיעו בדחיפה עתידית לענף של גרסה במארח Android, ואפשר לסנכרן אותם עם repo באמצעות android-latest-release.
אין מנגנון התראות לגבי קבלת או דחיית שינוי מוצע.
מהו תהליך העבודה הכללי מרגע שמשתמש חיצוני מציע שינוי ועד שהוא ממוזג עם הענף של הגרסה האחרונה?
תורם חיצוני מציע שינוי ב-
android-latest-release(בשימוש ב-Repo) או בענף הגרסה האחרונה שצוין במניפסטandroid-latest-release(בשימוש ישירות ב-Git).Google בודקת את השינוי. אם השינוי הוא:
השינוי מתקבל, ו-Google בוחרת אותו וממזגת אותו עם ענף הפיתוח הפנימי.
השינוי לא מתקבל, ו-Google לא בוחרת רק חלק מהשינוי.
התורם החיצוני בודק את השינוי שלו ב-
android-latest-release.
מה קורה אם אני כבר לא צריך את השינוי שהצעתי?
אם אתם לא צריכים יותר את השינוי שהצעתם, לא רוצים שהשינוי ימוזג או יודעים ש-Google כבר בדקה את השינוי, אתם יכולים לבטל את השינוי כדי שהוא יישאר בהיסטוריית השינויים המוצעים במארח Android.
שאלות קוד פתוח
למה Google פתחה את קוד המקור של Android?
Google התחילה את פרויקט AOSP בתגובה לחוויות שלנו בהשקת אפליקציות לנייד. רצינו לוודא שתמיד תהיה פלטפורמה פתוחה זמינה לחברות סלולר, ליצרני ציוד מקורי ולמפתחים, כדי שיוכלו להגשים את הרעיונות החדשניים שלהם. רצינו גם להימנע מנקודת כשל מרכזית, כדי שאף גורם מרכזי בתעשייה לא יוכל להגביל או לשלוט בחידושים של גורם אחר. המטרה הכי חשובה שלנו בפרויקט הקוד הפתוח של Android (AOSP) היא לוודא שתוכנת Android בקוד פתוח תיושם בצורה רחבה ותואמת ככל האפשר, לטובת כולם.
איזה סוג של פרויקט קוד פתוח הוא Android?
Google מפקחת על הפיתוח של ליבת AOSP ופועלת ליצירת קהילות חזקות של מפתחים ומשתמשים. ברוב המקרים, קוד המקור של Android מורשה לשימוש במסגרת רישיון Apache 2.0 המתירני, ולא במסגרת רישיון copyleft. בחרנו ברישיון Apache 2.0 כי אנחנו מאמינים שהוא מעודד אימוץ נרחב של תוכנת Android. פרטים נוספים זמינים במאמר בנושא רישיונות.
למה Google אחראית על Android?
השקת פלטפורמת תוכנה היא תהליך מורכב. פתיחות היא חיונית להצלחה ארוכת הטווח של פלטפורמה, כי היא מושכת השקעות ממפתחים ומבטיחה תנאים שווים לכולם. הפלטפורמה צריכה להיות גם מוצר אטרקטיבי למשתמשים.
Google התחייבה להקצות את משאבי ההנדסה המקצועיים שדרושים כדי להבטיח ש-Android תהיה פלטפורמת תוכנה תחרותית לחלוטין. Google מתייחסת לפרויקט Android כאל פעילות פיתוח מוצרים בקנה מידה מלא, ומבצעת את העסקאות העסקיות הנדרשות כדי לוודא שמכשירים מצוינים עם מערכת Android יגיעו לשוק.
אנחנו עוזרים להבטיח את החיוניות של Android כפלטפורמה וכפרויקט קוד פתוח, על ידי כך שאנחנו מוודאים שהמשתמשים ייהנו מ-Android. אחרי הכול, מי רוצה את קוד המקור של מוצר שלא מצליח?
המטרה שלנו היא להבטיח סביבה עסקית מוצלחת סביב Android. פתחנו את קוד המקור של Android כדי שכל אחד יוכל לשנות את התוכנה ולהפיץ אותה בהתאם לצרכים שלו.
מהי האסטרטגיה הכוללת של Google לפיתוח מוצרים ל-Android?
אנחנו משיקים מכשירים מצוינים בשוק תחרותי. לאחר מכן, אנחנו משלבים את החידושים והשיפורים שביצענו בפלטפורמת הליבה כגרסה הבאה.
בפועל, המשמעות היא שצוות ההנדסה של Android מתמקד במספר קטן של מכשירי דגל ומפתח את הגרסה הבאה של תוכנת Android כדי לתמוך בהשקות של המוצרים האלה. מכשירי הדגל האלה סופגים חלק גדול מהסיכון של המוצר, וסוללים את הדרך לקהילת יצרני הציוד המקורי הרחבה, שממשיכה עם מכשירים נוספים שמנצלים את התכונות החדשות. כך אנחנו מוודאים שפלטפורמת Android מתפתחת בהתאם לצרכים של מכשירים בעולם האמיתי.
איך מפתחים תוכנה ל-Android?
לכל גרסת פלטפורמה של Android (למשל 1.5 או 8.1) יש ענף תואם בעץ הקוד הפתוח. ההסתעפות האחרונה נחשבת לגרסה הנוכחית של ההסתעפות היציבה, שאליה מפנה קובץ המניפסט android-latest-release.
זה הענף שהיצרנים מעבירים למכשירים שלהם. הענף הזה תמיד מתאים להפצה.
לבסוף, Google עובדת על הגרסה הבאה של פלטפורמת Android במקביל לפיתוח מכשיר דגל.
למה חלקים מ-Android מפותחים באופן פרטי?
בדרך כלל לוקח יותר משנה להשיק מכשיר בשוק. וכמובן, יצרני המכשירים רוצים לשלוח את התוכנה העדכנית ביותר שהם יכולים. במקביל, מפתחים לא רוצים לעקוב כל הזמן אחרי גרסאות חדשות של הפלטפורמה כשהם כותבים אפליקציות. בשתי הקבוצות יש מתח בין הרצון לשלוח מוצרים לבין הרצון לא לפגר אחרי המתחרים.
כדי לפתור את הבעיה הזו, חלקים מסוימים בגרסה הבאה של Android, כולל ממשקי הליבה של הפלטפורמה, מפותחים בענף פרטי. ממשקי ה-API האלה הם חלק מהגרסה הבאה של Android. המטרה שלנו היא למקד את תשומת הלב בגרסה היציבה הנוכחית של קוד המקור של Android בזמן שאנחנו יוצרים את הגרסה הבאה של הפלטפורמה. כך מפתחים ויצרני ציוד מקורי יכולים להשתמש בגרסה אחת בלי לעקוב אחרי עבודה עתידית לא גמורה רק כדי להתעדכן.
מתי מתבצעות הפצות של קוד מקור?
כשהם יהיו מוכנים. פרסום קוד המקור הוא תהליך מורכב למדי. חלקים מסוימים של Android, כמו ליבת המערכת, מפותחים באופן פתוח, וקוד המקור שלהם תמיד זמין. חלקים אחרים מפותחים קודם בעץ פרטי, וקוד המקור הזה מופץ כשהגרסה הבאה של הפלטפורמה מוכנה.
בגרסאות מסוימות, ממשקי ה-API של פלטפורמת הליבה מוכנים מספיק זמן מראש כדי שנוכל לפרסם את קוד המקור לצפייה מוקדמת לפני השקת המכשיר. בגרסאות אחרות, אי אפשר לעשות את זה. בכל המקרים, אנחנו מפרסמים את המקור של הפלטפורמה כשאנחנו מרגישים שהגרסה יציבה וכשתהליך הפיתוח מאפשר זאת.
מה כולל פרסום קוד המקור של גרסת Android חדשה?
פרסום קוד המקור של גרסה חדשה של פלטפורמת Android הוא תהליך משמעותי. קודם כול, התוכנה מוטמעת בתמונת מערכת למכשיר ועוברת תהליכי אישור שונים, כולל אישור רגולטורי ממשלתי לאזורים שבהם הטלפונים יופעלו. הקוד עובר גם בדיקות של האופרטור. זהו שלב חשוב בתהליך, כי הוא עוזר לזהות באגים בתוכנה.
כשהרגולטורים והמפעילים מאשרים את ההשקה, היצרן מתחיל בייצור המוני של המכשירים, ואנחנו מתחילים בהפצה של קוד המקור.
במקביל לייצור המוני, צוות Google מתחיל כמה פעולות כדי להכין את הגרסה של קוד פתוח. הפעולות האלה כוללות ביצוע שינויים סופיים ב-API, עדכון התיעוד (כדי לשקף שינויים שבוצעו במהלך בדיקות ההתאמה, למשל), הכנת SDK לגרסה החדשה והשקת מידע על תאימות הפלטפורמה.
הצוות המשפטי שלנו מאשר סופית את שחרור הקוד למקור פתוח. כמו שמשתתפים בפרויקטים של קוד פתוח נדרשים לחתום על הסכם רישיון משתתפים שמאשר את הבעלות שלהם על הקניין הרוחני של התוכן שהם תורמים, Google צריכה לוודא שהמקור קיבל אישור לתרום תוכן.
החל מהרגע שבו מתחיל ייצור המוני, תהליך הפצת התוכנה נמשך בדרך כלל כחודש, ולכן הפצות של קוד מקור מתרחשות לרוב בערך באותו הזמן שבו המכשירים מגיעים למשתמשים.
מה הקשר בין AOSP לבין תוכנית התאימות של Android?
פרויקט AOSP מתחזק את תוכנת Android ומפתח גרסאות חדשות. מכיוון שהתוכנה היא קוד פתוח, אפשר להשתמש בה לכל מטרה, כולל פיתוח מכשירים שלא תואמים למכשירים אחרים שמבוססים על אותו מקור.
המטרה של תוכנית התאימות של Android היא להגדיר הטמעה בסיסית של Android שתהיה תואמת לאפליקציות של צד שלישי שנכתבו על ידי מפתחים. מכשירים שתואמים ל-Android יכולים להשתתף בסביבה העסקית של Android, כולל Google Play. מכשירים שלא עומדים בדרישות התאימות לא נכללים בסביבה העסקית הזו.
במילים אחרות, תוכנית התאימות של Android היא הדרך שבה אנחנו מבחינים בין מכשירים שתואמים ל-Android לבין מכשירים שמריצים נגזרות של קוד המקור. אנחנו מעודדים שימוש בקוד המקור של Android, אבל כדי להשתתף בסביבת Android, המכשיר צריך להיות מזוהה על ידי התוכנית כמכשיר שתואם ל-Android.
איך אפשר לתרום ל-Android?
אתם יכולים לדווח על באגים, לכתוב אפליקציות ל-Android או לתרום קוד מקור ל-AOSP.
יש מגבלות על סוגי התרומות לקוד שאנחנו מקבלים. לדוגמה, מישהו עשוי לרצות לתרום API חלופי לאפליקציה, כמו סביבה מלאה שמבוססת על C++. נדחה את התוכן הזה, כי מומלץ להריץ אפליקציות ל-Android בסביבת זמן הריצה של ART. באופן דומה, לא נקבל תרומות כמו ספריות GPL או LGPL שלא תואמות ליעדי הרישוי שלנו.
אנחנו ממליצים לכל מי שמעוניין לתרום קוד מקור ליצור איתנו קשר דרך הערוצים שמפורטים בקהילת Android לפני שמתחילים לעבוד. פרטים נוספים זמינים במאמר בנושא תרומה.
איך הופכים ל-committer ב-Android?
ב-AOSP אין באמת מושג של מבצע שינוי. כל התרומות (כולל אלה שנכתבו על ידי עובדי Google) עוברות דרך מערכת מבוססת-אינטרנט שנקראת Gerrit, שהיא חלק מתהליך ההנדסה של Android. המערכת הזו פועלת בשילוב עם מערכת ניהול קוד המקור של Git כדי לנהל בצורה מסודרת תרומות של קוד מקור.
גורם מאשר ייעודי צריך לבדוק ולאשר את כל השינויים המוצעים. בדרך כלל, המאשרים הם עובדי Google, אבל אותם מאשרים אחראים לכל הפריטים שנשלחים, ללא קשר למקור שלהם.
פרטים נוספים זמינים במאמר בנושא שליחת תיקונים.