במסמך הזה מופיעות תשובות לשאלות כלליות לגבי פלטפורמת הקוד הפתוח של 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-releasemanifest.
פרטים נוספים על סנכרון ענפים מופיעים במאמר בנושא הפעלת הלקוח של 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 בתגובה לחוויות שלנו בהשקת אפליקציות לנייד. רצינו לוודא שתמיד תהיה פלטפורמה פתוחה זמינה לספקי סלולר, ליצרני ציוד מקורי ולמפתחים, כדי שיוכלו להגשים את הרעיונות החדשניים שלהם. רצינו גם להימנע מנקודת כשל מרכזית, כדי שאף גורם בתעשייה לא יוכל להגביל או לשלוט בחידושים של גורם אחר. המטרה החשובה ביותר שלנו ב-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 Compatibility, המכשיר צריך להיות מזוהה כמכשיר שתואם ל-Android.
איך אפשר לתרום ל-Android?
אתם יכולים לדווח על באגים, לכתוב אפליקציות ל-Android או לתרום קוד מקור ל-AOSP.
יש מגבלות על סוגי התרומות לקוד שאנחנו מקבלים. לדוגמה, מישהו עשוי לרצות לתרום API חלופי לאפליקציה, כמו סביבה מלאה שמבוססת על C++. נדחה את התרומה הזו, כי מומלץ להריץ אפליקציות ל-Android בסביבת זמן הריצה של ART. באופן דומה, לא נקבל תרומות כמו ספריות GPL או LGPL שלא תואמות ליעדי הרישוי שלנו.
אנחנו ממליצים למי שמעוניין לתרום קוד מקור ליצור איתנו קשר דרך הערוצים שמפורטים בקהילת Android לפני שמתחילים לעבוד. לפרטים נוספים, אפשר לעיין במאמר בנושא תרומה.
איך הופכים לבעלי הרשאת Commit ב-Android?
ב-AOSP אין באמת מושג של בעל הרשאה לשינוי (committer). כל התרומות (כולל אלה שנכתבו על ידי עובדי Google) עוברות דרך מערכת מבוססת-אינטרנט שנקראת Gerrit, שהיא חלק מתהליך ההנדסה של Android. המערכת הזו פועלת בשילוב עם מערכת ניהול קוד המקור Git, כדי לנהל בצורה מסודרת תרומות של קוד מקור.
המאשר שמוגדר צריך לבדוק ולאשר את כל השינויים המוצעים. בדרך כלל, המאשרים הם עובדי Google, אבל אותם מאשרים אחראים לכל הבקשות, ללא קשר למקור שלהן.
פרטים נוספים זמינים במאמר בנושא שליחת תיקונים.