<uses-sdk>

‫Google Play משתמש במאפיינים <uses-sdk> שמוצהרים בקובץ המניפסט של האפליקציה כדי לסנן את האפליקציה ממכשירים שלא עומדים בדרישות של גרסת הפלטפורמה. לפני שמגדירים את המאפיינים האלה, חשוב להבין את המסננים של Google Play.

תחביר:
<uses-sdk android:minSdkVersion="integer"
          android:targetSdkVersion="integer"
          android:maxSdkVersion="integer" />
מוכל ב:
<manifest>
תיאור:

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

למרות השם שלו, הרכיב הזה משמש לציון רמת ה-API, ולא מספר הגרסה של ערכת פיתוח התוכנה (SDK) או פלטפורמת Android. רמת ה-API היא תמיד מספר שלם יחיד. אי אפשר לגזור את רמת ה-API ממספר גרסת Android המשויך. לדוגמה, הוא לא זהה לגרסה הראשית או לסכום של הגרסה הראשית והגרסה המשנית.

אי אפשר לציין שאפליקציה מיועדת לגרסה משנית של SDK או דורשת אותה.

מומלץ גם לקרוא את המאמר בנושא ניהול גרסאות של אפליקציות.

מאפיינים:
android:minSdkVersion
מספר שלם שמציין את רמת ה-API המינימלית שנדרשת כדי שהאפליקציה תפעל. מערכת Android מונעת מהמשתמש להתקין את האפליקציה אם רמת ה-API של המערכת נמוכה מהערך שצוין במאפיין הזה. חובה להצהיר על המאפיין הזה.

זהירות: אם לא מצהירים על המאפיין הזה, המערכת מניחה שערך ברירת המחדל הוא '1', כלומר האפליקציה תואמת לכל גרסאות Android. אם לא הצהרתם על minSdkVersion המתאים, האפליקציה תקרוס במהלך זמן הריצה כשתנסו לגשת לממשקי ה-API הלא זמינים, אם היא תותקן במערכת עם רמת API לא תואמת. לכן, חשוב להקפיד להצהיר על רמת ה-API המתאימה במאפיין minSdkVersion.

android:targetSdkVersion
מספר שלם שמציין את רמת ה-API שהאפליקציה מטרגטת. אם לא מגדירים את הערך, ברירת המחדל שווה לערך שמוגדר ב-minSdkVersion.

המאפיין הזה מודיע למערכת שבדקתם את האפליקציה מול גרסת היעד, והמערכת לא מפעילה התנהגויות תאימות כדי לשמור על תאימות קדימה של האפליקציה עם גרסת היעד. האפליקציה עדיין יכולה לפעול בגרסאות ישנות יותר (עד גרסה minSdkVersion).

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

לדוגמה, אם מגדירים את הערך הזה ל-11 ומעלה, המערכת מחילה את ערכת הנושא שמוגדרת כברירת מחדל Holo על האפליקציה כשמריצים אותה ב-Android 3.0 ומעלה, וגם משביתה את מצב התאימות למסך כשמריצים אותה במסכים גדולים יותר, כי תמיכה ברמת API‏ 11 תומכת באופן מרומז במסכים גדולים יותר.

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

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

הוצג ב: רמת API‏ 4

android:maxSdkVersion
מספר שלם שמציין את רמת ה-API המקסימלית שהאפליקציה מיועדת לפעול בה.

ב-Android 1.5,‏ 1.6,‏ 2.0 ו-2.0.1, המערכת בודקת את הערך של התכונה הזו כשמתקינים אפליקציה וכשמאמתים מחדש את האפליקציה אחרי עדכון מערכת. בכל מקרה, אם ערך המאפיין maxSdkVersion של האפליקציה נמוך מרמת ה-API שבה המערכת עצמה משתמשת, המערכת לא מאפשרת להתקין את האפליקציה. במקרה של אימות מחדש אחרי עדכון מערכת, האפליקציה תוסר מהמכשיר.

כדי להמחיש איך המאפיין הזה יכול להשפיע על האפליקציה אחרי עדכוני מערכת, הנה דוגמה:

אפליקציה שמצהירה על maxSdkVersion="5" במניפסט שלה מתפרסמת ב-Google Play. משתמש שבמכשיר שלו פועלת גרסת Android 1.6 (רמת API‏ 4) מוריד ומתקין את האפליקציה. אחרי כמה שבועות, המשתמש מקבל עדכון מערכת דרך האוויר ל-Android 2.0 (רמת API‏ 5). אחרי שהעדכון מותקן, המערכת בודקת את maxSdkVersion של האפליקציה ומאמתת אותו מחדש בהצלחה.

האפליקציה פועלת כרגיל. אבל כעבור זמן מה, המכשיר מקבל עדכון מערכת נוסף, הפעם ל-Android 2.0.1 (רמת API 6). אחרי העדכון, המערכת לא יכולה יותר לאמת מחדש את האפליקציה כי רמת ה-API של המערכת (6) גבוהה יותר מהרמה המקסימלית שהאפליקציה תומכת בה (5). המערכת מונעת מהמשתמש לראות את האפליקציה, ובפועל מסירה אותה מהמכשיר.

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

הוצג ב: רמת API‏ 4

בגרסאות מסוימות של Android (מעבר לגרסה Android 2.0.1), המערכת לא בודקת או אוכפת את המאפיין maxSdkVersion במהלך ההתקנה או האימות מחדש. המערכת של Google Play ממשיכה להשתמש במאפיין הזה כמסנן, אבל רק כשמוצגות למשתמשים אפליקציות שזמינות להורדה.
הושק ב:
רמת API 1

מהי רמת API?

רמת ה-API היא ערך מספרי שמזהה באופן ייחודי את הגרסה של ה-API של מסגרת הפיתוח שמוצעת על ידי גרסה של פלטפורמת Android.

פלטפורמת Android מספקת ממשק API של Framework שאפליקציות יכולות להשתמש בו כדי ליצור אינטראקציה עם מערכת Android הבסיסית. ממשק ה-API של המסגרת מורכב מ:

  • קבוצה מרכזית של חבילות וכיתות
  • קבוצה של רכיבי XML ומאפיינים להצהרה על קובץ מניפסט
  • קבוצה של רכיבי XML ומאפיינים להצהרה על משאבים ולגישה אליהם
  • קבוצה של כוונות
  • קבוצת הרשאות שאפליקציות יכולות לבקש, וגם אכיפת הרשאות שכלולה במערכת

כל גרסה עוקבת של פלטפורמת Android יכולה לכלול עדכונים ל-API של Android application framework שהיא מספקת.

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

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

ממשק ה-API של ה-Framework שפלטפורמת Android מספקת מצוין באמצעות מזהה מספרי שנקרא רמת API. כל גרסה של פלטפורמת Android תומכת בדיוק ברמת API אחת, למרות שהתמיכה היא מרומזת לכל רמות ה-API הקודמות (עד רמת API 1). הגרסה הראשונה של פלטפורמת Android סיפקה רמת API‏ 1, ובגרסאות הבאות רמת ה-API עלתה. ממשקי API שהוצגו בערכות SDK של גרסאות טרום-הפצה, ושעדיין לא הגיעו ליציבות הפלטפורמה, מסומנים כ'API בפיתוח' במקום רמת API של מספר שלם.

בטבלה הבאה מפורטת רמת ה-API שנתמכת בכל גרסה של פלטפורמת Android. מידע על המספרים היחסיים של המכשירים שבהם פועלת כל גרסה זמין בלוח הבקרה של ההפצה.

גרסת פלטפורמהרמת ממשק API:VERSION_CODEהערות
Android 17 37 CINNAMON_BUN עיקרי השינויים בפלטפורמה
Android 16 36 BAKLAVA עיקרי השינויים בפלטפורמה
Android 15 35 VANILLA_ICE_CREAM עיקרי השינויים בפלטפורמה
Android 14 34 UPSIDE_DOWN_CAKE עיקרי השינויים בפלטפורמה
Android 13 33 TIRAMISU עיקרי השינויים בפלטפורמה
Android 12 32 S_V2 עיקרי השינויים בפלטפורמה
31 S עיקרי השינויים בפלטפורמה
Android 11 30 R עיקרי השינויים בפלטפורמה
Android 10 29 Q עיקרי השינויים בפלטפורמה
Android 9 28 P עיקרי השינויים בפלטפורמה
Android 8.1 27 O_MR1 עיקרי השינויים בפלטפורמה
Android 8.0 26 O עיקרי השינויים בפלטפורמה
Android 7.1.1
Android 7.1
25 N_MR1 עיקרי השינויים בפלטפורמה
Android 7.0 24 N עיקרי השינויים בפלטפורמה
Android 6.0 23 M עיקרי השינויים בפלטפורמה
Android 5.1 22 LOLLIPOP_MR1 עיקרי השינויים בפלטפורמה
Android 5.0 21 LOLLIPOP
‫Android 4.4W 20 KITKAT_WATCH ‫KitKat for Wearables Only
Android 4.4 19 KITKAT עיקרי השינויים בפלטפורמה
Android 4.3 18 JELLY_BEAN_MR2 עיקרי השינויים בפלטפורמה
Android 4.2, ‏ 4.2.2 17 JELLY_BEAN_MR1 עיקרי השינויים בפלטפורמה
Android 4.1, ‏ 4.1.1 16 JELLY_BEAN עיקרי השינויים בפלטפורמה
Android 4.0.3, ‏ 4.0.4 15 ICE_CREAM_SANDWICH_MR1 עיקרי השינויים בפלטפורמה
Android 4.0, ‏ 4.0.1, ‏ 4.0.2 14 ICE_CREAM_SANDWICH
Android 3.2 13 HONEYCOMB_MR2
Android 3.1.x 12 HONEYCOMB_MR1 עיקרי השינויים בפלטפורמה
Android 3.0.x 11 HONEYCOMB עיקרי השינויים בפלטפורמה
Android 2.3.4
Android 2.3.3
10 GINGERBREAD_MR1 עיקרי השינויים בפלטפורמה
Android 2.3.2
Android 2.3.1
Android 2.3
9 GINGERBREAD
Android 2.2.x 8 FROYO עיקרי השינויים בפלטפורמה
Android 2.1.x 7 ECLAIR_MR1 עיקרי השינויים בפלטפורמה
Android 2.0.1 6 ECLAIR_0_1
Android 2.0 5 ECLAIR
Android 1.6 4 DONUT עיקרי השינויים בפלטפורמה
Android 1.5 3 CUPCAKE עיקרי השינויים בפלטפורמה
Android 1.1 2 BASE_1_1
‫Android 1.0 1 BASE

ממשקי API שנמצאים בפיתוח

במאמרי העזרה של ה-API של Android, חלק מממשקי ה-API מסומנים בתווית 'API under development' (ממשק API בפיתוח) במקום ברמת API של מספר שלם. לממשקי API שנמצאים בפיתוח יש את המאפיינים הבאים:

  • סטטוס של גרסת טרום-הפצה: ממשקי ה-API האלה הם כרגע חלק מגרסת טרום-הפצה פעילה של ערכת SDK מסוג בטא או קנרית, והם עדיין לא הגיעו ליציבות בפלטפורמה.
  • אין ערובה ליציבות: בניגוד לממשקי API שפורסמו (שיש להם רמת API קבועה והם תואמים לאחור בגרסאות עתידיות), ממשקי API שנמצאים בפיתוח עשויים לשנות חתימות, לשנות שמות או להוסר לחלוטין בין גרסאות SDK של גרסאות קדם-הפצה.

בדיקה של ממשקי API שנמצאים בפיתוח בזמן ריצה (PREVIEW_SDK_INT)

מכיוון ש-API שנמצאים בפיתוח יכולים להשתנות או להיעלם בין גרסאות טרום-השקה, אסור להשתמש בבדיקה של גדול או שווה (>=) כדי להגן על קריאות ל-API שלא הושקו. יכול להיות שממשק API שמופיע בגרסת טרום-השקה 1 ישונה או יוסר בגרסת טרום-השקה 2.

במקום זאת, אפליקציות שכוללות תכונות בגרסת טרום-השקה צריכות לבדוק את הערך של Build.VERSION.PREVIEW_SDK_INT כדי לוודא שהוא שווה בדיוק לגרסת הטרום-השקה שאיתה האפליקציה עברה קומפילציה (==):

  • בגרסאות build ובגרסאות סופיות לסביבת הייצור, הערך של Build.VERSION.PREVIEW_SDK_INT הוא תמיד 0.
  • בגרסאות טרום-הפצה, PREVIEW_SDK_INT הוא ייחודי לכל גרסה.

שימושים ברמת API ב-Android

מזהה רמת ה-API ממלא תפקיד חשוב בהבטחת החוויה הטובה ביותר למשתמשים ולמפתחי אפליקציות:

  • הוא מאפשר לפלטפורמת Android לתאר את הגרסה המקסימלית של Framework API שהיא תומכת בה.
  • הוא מאפשר לאפליקציות לתאר את הגרסה של Framework API שנדרשת להן.
  • המדיניות הזו מאפשרת למערכת לנהל משא ומתן על התקנת אפליקציות במכשיר של המשתמש, כך שאפליקציות עם גרסאות לא תואמות לא יותקנו.

כל גרסה של פלטפורמת Android מאחסנת את מזהה רמת ה-API שלה באופן פנימי, במערכת Android עצמה.

אפליקציות יכולות להשתמש ברכיב מניפסט שסופק על ידי API של מסגרת – <uses-sdk> – כדי לתאר את רמות ה-API המינימליות והמקסימליות שבהן הן יכולות לפעול, וגם את רמת ה-API המועדפת שהן מיועדות לתמוך בה. הרכיב כולל שלושה מאפייני מפתח:

  • android:minSdkVersion: רמת ה-API המינימלית שבה האפליקציה יכולה לפעול. ערך ברירת המחדל הוא '1'.
  • android:targetSdkVersion: רמת ה-API שבה האפליקציה מיועדת לפעול. במקרים מסוימים, זה מאפשר לאפליקציה להשתמש ברכיבי מניפסט או בהתנהגויות שמוגדרים ברמת ה-API של היעד, במקום להיות מוגבלת לשימוש רק באלה שמוגדרים לרמת ה-API המינימלית.
  • android:maxSdkVersion: רמת ה-API המקסימלית שבה האפליקציה יכולה לפעול. חשוב: לפני שמשתמשים במאפיין הזה, כדאי לקרוא את המידע על המאפיין בדף הזה.

לדוגמה, כדי לציין את רמת ה-API המינימלית של המערכת שאפליקציה צריכה כדי לפעול, האפליקציה כוללת במניפסט שלה רכיב <uses-sdk> עם מאפיין android:minSdkVersion. הערך של android:minSdkVersion הוא מספר שלם שמתאים לרמת ה-API של הגרסה המוקדמת ביותר של פלטפורמת Android שבה האפליקציה יכולה לפעול.

כשמשתמש מנסה להתקין אפליקציה, או כשמבצעים אימות מחדש של אפליקציה אחרי עדכון מערכת, מערכת Android בודקת קודם את המאפיינים <uses-sdk> במניפסט של האפליקציה ומשווה את הערכים לרמת ה-API הפנימית שלה. המערכת תאפשר להתחיל בהתקנה רק אם התנאים הבאים יתקיימו:

  • אם מוצהר על מאפיין android:minSdkVersion, הערך שלו קטן ממספר השלם של רמת ה-API של המערכת או שווה לו. אם לא מצהירים על רמת ה-API, המערכת מניחה שהאפליקציה דורשת רמת API 1.
  • אם מוצהר מאפיין android:maxSdkVersion, הערך שלו גדול ממספר השלם של רמת ה-API של המערכת או שווה לו. אם לא מצהירים על רמת ה-API המקסימלית, המערכת מניחה שלאפליקציה אין רמת API מקסימלית. מידע נוסף על אופן הטיפול של המערכת במאפיין הזה זמין בתיאור שלו.

כשמצהירים על רכיב <uses-sdk> במניפסט של אפליקציה, הוא עשוי להיראות כך:

<manifest>
  <uses-sdk android:minSdkVersion="5" />
  ...
</manifest>

הסיבה העיקרית לכך שאפליקציה מצהירה על רמת API ב-android:minSdkVersion היא להודיע למערכת Android שהיא משתמשת בממשקי API שהוצגו ברמת ה-API שצוינה.

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

שיקולי פיתוח

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

תאימות קדימה של אפליקציות

אפליקציות ל-Android בדרך כלל תואמות לגרסאות חדשות של פלטפורמת Android.

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

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

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

כדי לעזור לכם לבדוק את האפליקציה בגרסאות שונות של פלטפורמת Android, ‏ Android SDK כולל פלטפורמות שונות שאפשר להוריד. כל פלטפורמה כוללת קובץ אימג' של המערכת תואם שאפשר להפעיל ב-AVD כדי לבדוק את האפליקציה.

תאימות לאחור של אפליקציות

אפליקציות ל-Android לא בהכרח תואמות לאחור לגרסאות של פלטפורמת Android שקודמות לגרסה שבה הן עברו קומפילציה.

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

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

בחירת גרסת פלטפורמה ורמת API

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

כדי לקבוע את הגרסה הכי נמוכה שאפשר להשתמש בה בפלטפורמה, צריך לקמפל את האפליקציה מול יעדי בנייה נמוכים יותר. אחרי שקובעים את הגרסה הכי נמוכה, יוצרים AVD באמצעות גרסת הפלטפורמה ורמת ה-API המתאימות, ובודקים את האפליקציה באופן מלא. חשוב להצהיר על המאפיין android:minSdkVersion במניפסט של האפליקציה ולהגדיר את הערך שלו לרמת ה-API של גרסת הפלטפורמה.

הצהרה על רמת API מינימלית

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

אם האפליקציה שלכם משתמשת בממשקי API שהוצגו בגרסה האחרונה של הפלטפורמה, אבל לא מצהירה על מאפיין android:minSdkVersion, היא תפעל בצורה תקינה במכשירים שמותקנת בהם הגרסה האחרונה של הפלטפורמה, אבל לא במכשירים שמותקנות בהם גרסאות קודמות של הפלטפורמה. במקרה האחרון, האפליקציה קורסת בזמן הריצה כשהיא מנסה להשתמש בממשקי API שלא קיימים בגרסאות הקודמות.

בדיקה מול רמות API גבוהות יותר

אחרי שמקמפלים את האפליקציה, חשוב לבדוק אותה בפלטפורמה שצוינה במאפיין android:minSdkVersion של האפליקציה. כדי לעשות זאת, יוצרים מכשיר וירטואלי של Android (AVD) שמשתמש בגרסת הפלטפורמה שנדרשת על ידי האפליקציה. בנוסף, כדי לבדוק תאימות קדימה, צריך להריץ את האפליקציה ולבדוק אותה בכל הפלטפורמות שמשתמשות ברמת API גבוהה יותר מזו שבה משתמשת האפליקציה שלכם.

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

כדי לגשת לכלי העדכון, משתמשים בandroid כלי שורת הפקודה, שנמצא בספרייה <sdk>/tools. כדי להפעיל את הכלי לעדכון ה-SDK, מריצים את הפקודה android sdk. אפשר גם ללחוץ לחיצה כפולה על הקובץ android.bat (Windows) או android (OS X/Linux).

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

סינון מאמרי העזרה לפי רמת API

בדפי העיון בפלטפורמת Android יש אמצעי בקרה מסוג 'רמת API' בפינה הימנית העליונה של כל דף. אתם יכולים להשתמש באמצעי הבקרה כדי להציג תיעוד רק לחלקים ב-API שאפליקציה יכולה לגשת אליהם בפועל, על סמך רמת ה-API שהיא מציינת במאפיין android:minSdkVersion של קובץ המניפסט שלה.

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

סינון לפי רמת API בתיעוד לא מספק תצוגה של מה חדש או מה נוסף בכל רמת API. הוא מספק דרך להציג את כל ה-API שמשויך לרמת API נתונה, תוך החרגה של רכיבי API שהוצגו ברמות API מאוחרות יותר.

כדי לחזור להצגת המסמכים המלאים, בוחרים באפשרות REL בחלק העליון של תפריט רמת ה-API. כברירת מחדל, הסינון לפי רמת API מושבת, כך שתוכלו לראות את כל ה-API של ה-Framework, ללא קשר לרמת ה-API.

במאמרי העזרה של רכיבי API ספציפיים מצוינת רמת ה-API שבה כל רכיב מוצג. רמת ה-API של חבילות וסיווגים מצוינת כ'נוספה ברמת API' בפינה השמאלית העליונה של אזור התוכן בכל דף תיעוד. רמת ה-API של חברי הכיתה מצוינת בכותרות התיאור המפורט שלהם, בשוליים השמאליים. בממשקי API בגרסת טרום-השקה שעדיין לא הגיעו ליציבות הפלטפורמה, במיקום הזה מוצג 'API בתהליך פיתוח' במקום מספר של רמת API.