המסמך הזה מכיל תשובות לשאלות כלליות על Android Open Source Platform (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, וניתן לסנכרן אותם עם המאגר באמצעות 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 License 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 של הליבה של הפלטפורמה, מפותחים בהסתעפות פרטית. ממשקי ה-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 לפני שהוא מתחיל לעבוד. פרטים נוספים זמינים במאמר הוספת תוכן.
איך הופכים למשתמשי commit ב-Android?
ב-AOSP אין ממש מושג של 'מגיש קודים'. כל התרומות (כולל אלה שנכתבו על ידי עובדי Google) עוברות דרך מערכת מבוססת-אינטרנט שנקראת Gerrit, שהיא חלק מתהליך ההנדסה של Android. המערכת הזו פועלת בשילוב עם מערכת ניהול קוד המקור של Git כדי לנהל בצורה מסודרת את התרומות לקוד המקור.
גורם מאשר מורשה צריך לבדוק ולאשר את כל השינויים המוצעים. בדרך כלל, הגורמים המאשרים הם עובדים של Google, אבל אותם גורמים אחראים על כל הבקשות, ללא קשר למקור שלהן.
פרטים נוספים זמינים במאמר שליחת תיקונים.