ממשקי API של Android 3.2

רמת API: 13

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

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

רגעי השיא של הפלטפורמה

תכונות חדשות למשתמשים

• אופטימיזציות למגוון רחב יותר של טאבלטים

  Android 3.2 כולל מגוון אופטימיזציות בכל המערכת כדי להבטיח חוויית משתמש מעולה במגוון רחב יותר של מכשירי טאבלטים.

• תאימות זום לאפליקציות בגודל קבוע

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

• סנכרון מדיה מכרטיס SD

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

תכונות חדשות למפתחים

• API מורחב לניהול תמיכה במסכים

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

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

סקירה כללית על ממשקי API

ממשקי API לתמיכה במסכים

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

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

• הערך smallestwidth של מסך הוא הגודל המינימלי הבסיסי שלו. נמדדים ביחידות פיקסלים שלא תלויות בדחיסות ("dp"). בגובה המסך או ברוחב, הוא הקצר מבין השניים. במסך בפריסה לאורך, הערך של smallestWidth מבוסס בדרך כלל על הרוחב, ובפריסה לרוחב הוא מבוסס על הגובה. בכל המקרים, הרוחב הקטן ביותר נגזר ממאפיין קבוע של והערך לא משתנה, ללא קשר לכיוון. הערך של smallestWidth חשוב לאפליקציות כי הוא מייצג את הרוחב הקצר ביותר שבו צריך לצייר את ממשק המשתמש של האפליקציה, לא כולל אזורי המסך ששמורים על ידי המערכת.
• לעומת זאת, הרוחב ו-height של המסך מייצגים את השטח האופקי או האנכי הנוכחי שזמין לפריסת האפליקציה, נמדד ב-"dp" יחידות מידה, לא כולל אזורי מסך שנשמרו על ידי המערכת. כשהמשתמש משנה את כיוון המסך מתצוגה לאורך לתצוגה לרוחב, הרוחב והגובה של המסך משתנים.

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

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

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

ה-API החדש מאפשר לכם לטרגט מסכים באופן ישיר יותר באמצעות הפרמטרים smallestWidth,‏ width ו-height, ולכן כדאי להבין את המאפיינים האופייניים של סוגי המסכים השונים. בטבלה הבאה מפורטות כמה דוגמאות, שנמדדות ביחידות 'dp'.

טבלה 1. מכשירים אופייניים, עם צפיפות והגודל ב-dp.

סוג	צפיפות (כללית)	מידות (dp)	smallestWidth (dp)
טלפון Baseline	mdpi	320x480	320
טאבלט קטן/טלפון גדול	mdpi	480x800	480
טאבלט בגודל 7 אינץ'	mdpi	600 x 1,024	600
טאבלט בגודל 10 אינץ'	mdpi	800x1280	800

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

מגדירי משאבים חדשים לתמיכה במסכים

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

הקריטריונים החדשים הם:

• swNNNdp — מציין את הרוחב המינימלי (smallestWidth) שבו צריך להשתמש במשאב, שנמדד ביחידות 'dp'. כפי שצוין למעלה, הרוחב הקטן ביותר של המסך הוא קבוע, ללא קשר לכיוון. למשל: sw320dp, sw720dp, sw720dp.
• wNNNdp ו-hNNNdp – קובעים את הרוחב או הגובה המינימלי שבו צריך להשתמש במשאב, שנמדדים ביחידות 'dp'. כפי שצוין למעלה, רוחב וגובה המסך יחסיים לכיוון המסך, והם משתנים בכל פעם שהכיוון משתנה. למשל: w320dp, w720dp, h1024dp.

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

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

res/layout/main_activity.xml   # For phones
res/layout-sw600dp/main_activity.xml   # For 7” tablets
res/layout-sw720dp/main_activity.xml   # For 10” tablets
res/layout-w600dp/main_activity.xml   # Multi-pane when enough width
res/layout-sw600dp-w720dp/main_activity.xml   # For large width

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

res/layout/main_activity.xml   # For phones
res/layout-xlarge/main_activity.xml   # For pre-3.2 tablets
res/layout-sw600dp/main_activity.xml   # For 3.2 and up tablets

למידע מלא על אופן השימוש במאפיינים החדשים, ניתן לעיין במאמר שימוש במאפיינים חדשים תוחמי גודל.

מאפייני מניפסט חדשים לתאימות לגודל המסך

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

מאפייני המניפסט החדשים לתמיכה במסך הם:

• android:compatibleWidthLimitDp="numDp" — הזה מאפשר לציין את הגודל המקסימלי הקטן ביותר שבו האפליקציה יכולה לפעול ללא צורך במצב תאימות. אם המסך הנוכחי גדול מ- הערך שצוין, המערכת תציג את האפליקציה במצב רגיל, מאפשרת למשתמש לעבור באופן אופציונלי למצב תאימות באמצעות הגדרה סרגל המערכת.
• android:largestWidthLimitDp="numDp" – המאפיין הזה מאפשר לציין את ה-smallestWidth המקסימלי שבו האפליקציה תוכננה לפעול. אם המסך הנוכחי גדול מהערך שצוין, המערכת מאלצת את האפליקציה למצב תאימות מסך, כדי להבטיח יוצגו במסך הנוכחי.
• android:requiresSmallestWidthDp="numDp" — הזה מאפשר לציין את הרוחב המינימלי הקטן ביותר שבו האפליקציה יכולות לפעול. אם המסך הנוכחי קטן מהערך שצוין, המערכת תתייחס לאפליקציה כאל לא תואמת למכשיר, אבל לא תמנע את ההתקנה וההפעלה שלה.

הערה: בשלב זה, Google Play לא מסנן אפליקציות על סמך אף אחד מהמאפיינים שלמעלה. תמיכה בסינון תתווסף בגרסה מאוחרת יותר של הפלטפורמה. אפליקציות שצריכות לסנן לפי גודל המסך יכולות להשתמש במאפייני <supports-screens> הקיימים.

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

מצב תאימות מסך

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

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

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

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

צפיפות מסך חדשה לטלוויזיות עם 720p ולמכשירים דומים

כדי לענות על הצרכים של אפליקציות שפועלות בטלוויזיות עם 720p או דומות עם מסכים עם צפיפות בינונית, Android 3.2 מציג צפיפות כללית חדשה, tvdpi, עם DPI משוער של 213. אפליקציות יכולות לשלוח שאילתות לגבי הצפיפות החדשה ב-densityDpi, ולהשתמש במאפיין המסומן tvdpi כדי לתייג משאבים לטלוויזיות ולמכשירים דומים. לדוגמה:

res/drawable-tvdpi/my_icon.png   # Bitmap for tv density

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

מסגרת UI

• קטעים
  • המדינה החדשה נמצאת ברמה Fragment.SavedState מידע שאוחזר ממופע מקטע דרך saveFragmentInstanceState().
  • השיטה החדשה saveFragmentInstanceState() שומרת את מצב המופע הנוכחי של ה-Fragment הנתון. אפשר להשתמש במצב מאוחר יותר כשיוצרים מופע חדש של ה-Fragment שמתאים למצב הנוכחי.
  • השיטה החדשה: setInitialSavedState() מגדיר את המצב השמור הראשוני של מקטע בעת בנייתו לראשונה.
  • שיטת ה-callback החדשה של onViewCreated() מעדכנת את ה-Fragment ש-onCreateView() חזר, אבל לפני שמצב שמור כלשהו שוחזר בתצוגה.
  • השיטה isDetached() קובעת אם ה-Fragment נותק במפורש מממשק המשתמש.
  • שיטות חדשות של attach() ו-detach() מאפשרות לאפליקציה לצרף מחדש או לנתק קטעים בממשק המשתמש.
  • שיטה חדשה של setCustomAnimations() לעומס יתר מאפשרת להגדיר אנימציה ספציפית למשאבים להרצת פעולות כניסה/יציאה, ובמיוחד כאשר "להעתיק את הערימה". ההטמעה הקיימת לא מביאה בחשבון בגלל ההתנהגות השונה של מקטעים במהלך פתיחת הערימה האחורית.
• מידע על גודל המסך ב-ActivityInfo וב-ApplicationInfo
  • ActivityInfo מוסיף את CONFIG_SCREEN_SIZE ו-CONFIG_SMALLEST_SCREEN_SIZE כמסכות ביט ב-configChanges. הביטים מציינים אם פעילות עצמו מתייחס לגודל המסך ולגודל המסך הקטן ביותר.
  • ApplicationInfo הוספות largestWidthLimitDp, compatibleWidthLimitDp ו-requiresSmallestWidthDp שדות, נגזר מהמאפיינים המתאימים של <supports-screens> בקובץ המניפסט של האפליקציה.
• פונקציות עזר לקבלת גודל התצוגה מ-WindowManager
  • השיטות החדשות getSize() ו-getRectSize() מאפשרות לאפליקציות לקבל את הגודל הגולמי של המסך.
• סגנונות 'הולוגרפיים' חדשים שגלויים לכולם
  • עכשיו יש בפלטפורמה מגוון סגנונות 'הולוגרפיים' ציבוריים לטקסט, לווידג'טים ולכרטיסיות בסרגל הפעולות ועוד. הרשימה המלאה מופיעה במאמר R.style.
• LocalActivityManager, ActivityGroup וגם LocalActivityManager הוצאו משימוש
  • באפליקציות חדשות צריך להשתמש ב-Fragments במקום בכיתות האלה. שפת תרגום ימשיכו לפעול בגרסאות ישנות יותר של הפלטפורמה, ניתן להשתמש בתמיכה של v4 ספרייה (ספריית תאימות), זמינה ב-Android SDK. ספריית התמיכה בגרסה 4 מספקת גרסה של Fragment API שתואמת ל-Android 1.6 ואילך (רמת API 4).
  • לאפליקציות המתפתחות מול Android 3.0 (רמת API) 11) ומעלה, בדרך כלל מוצגות כרטיסיות בממשק המשתמש באמצעות ActionBar.newTab() וממשקי API קשורים להצבת כרטיסיות בתוך אזור סרגל הפעולות שלהן.

מסגרת מדיה

• אפליקציות שמשתמשות בספק המדיה של הפלטפורמה (MediaStore) יכולות עכשיו לקרוא נתוני מדיה ישירות מכרטיס ה-SD הנשלף, אם המכשיר תומך בכך. אפליקציות יכולות גם לבצע אינטראקציה ישירות עם הקבצים בכרטיס ה-SD באמצעות MTP API.

גרפיקה

• כלי תחזוקה שניתן לחלק ב-Point ו-PointF
  • Point ו-PointF המחלקות כוללות עכשיו את הממשק Parcelable ואת שיטות השירות describeContents(), readFromParcel() ו-writeToParcel().

מסגרת IME

• שיטה חדשה getModifiers() לאחזור המצב הנוכחי של מקשי השינוי.

מסגרת USB

• שיטת getRawDescriptors() חדשה עבור אחזור מתארי ה-USB הגולמיים של המכשיר. אפשר להשתמש בשיטה הזו כדי לגשת למאפייני תיאור שלא נתמכים ישירות דרך ממשקי ה-API ברמה הגבוהה יותר.

רשת

• קבועים של סוג הרשת
  • ConnectivityManager מוסיף את הקבועים TYPE_ETHERNET ו-TYPE_BLUETOOTH.

טלפוניה

• קבוע מסוג רשת NETWORK_TYPE_HSPAP חדש.

כלי ליבה

• כלי עזר שניתן לחלק למקטעים
  • הממשק החדש Parcelable.ClassLoaderCreator מאפשר את האפליקציה לקבל את ה-ClassLoader שבו האובייקט נוצר.
  • adoptFd, dup() ו-fromFd() חדשים לניהול ParcelFileDescriptor אובייקטים.
• Binder ו-IBinder
  • השיטה החדשה: dumpAsync() ב-Binder וב-IBinder מאפשרים לאפליקציות העלאת הקובץ לקובץ שצוין, כדי לוודא שהיעד פועל באופן אסינכרוני.
  • קוד העסקה החדש של פרוטוקול IBinder TWEET_TRANSACTION מאפשר לאפליקציות לשלוח ציוץ לאובייקט היעד.

קבועים של תכונות חדשות

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

Google Play מסנן אפליקציות על סמך המאפיינים שלהן ב-<uses-feature>, כדי לוודא שהן זמינות רק למכשירים שעומדים בדרישות שלהן.

• מאפייני קבועים לדרישות של תמונות בפורמט לרוחב או לאורך

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

  • android.hardware.screen.landscape – האפליקציה דורשת תצוגה במצב לרוחב.
  • android.hardware.screen.portrait – האפליקציה דורשת תצוגה בפורמט לאורך.

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

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

• קבועים אחרים של תכונות
  • android.hardware.faketouch.multitouch.distinct – האפליקציה דורשת תמיכה באמולציה של קלט מולטיטאץ' עם מעקב ייחודי אחרי שתי נקודות או יותר.
  • android.hardware.faketouch.multitouch.jazzhand — האפליקציה דורשת תמיכה בקלט מולטי-טאץ (emulated mulitouch) עם מעקב נפרד אחרי חמש נקודות או יותר.

דוח ההבדלים בין ממשקי ה-API

לתצוגה מפורטת של כל שינויי ה-API ב-Android 3.2 (API שלב 13), ראו API הדוח 'הבדלים'.

רמת API

פלטפורמת Android 3.2 מספקת גרסה מעודכנת של API המסגרת. ל-Android 3.2 API מוקצה מזהה שלם – 13 – שנשמר במערכת עצמה. המזהה הזה, שנקרא 'רמת ה-API', מאפשר למערכת לקבוע בצורה נכונה אם אפליקציה תואמת למערכת, לפני התקנת האפליקציה.

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

מידע נוסף זמין במאמר מהו API רמה?