ממשקי API של Android 4.0

רמת API: 14

Android 4.0 (ICE_CREAM_SANDWICH) היא גרסת פלטפורמה עיקרית שמוסיפה מגוון תכונות חדשות למשתמשים ולאפליקציה למפתחים. חוץ מכל התכונות וממשקי ה-API החדשים שמפורטים בהמשך, גרסת Android 4.0 היא השקת פלטפורמה מפני שהיא מספקת את המגוון הרחב של ממשקי API ועיצובים הולוגרפיים מ-Android 3.x למסכים קטנים יותר. כמפתחי אפליקציות, יש לכם עכשיו פלטפורמה אחת ומסגרת API מאוחדת שמאפשר לפתח ולפרסם את האפליקציה באמצעות חבילת APK אחת ולהבטיח חוויית משתמש אופטימלית עבור טלפונים ניידים, טאבלטים ועוד, כשמריצים את אותה הגרסה Android – Android 4.0 (רמת API 14) ואילך.

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

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

הקטעים הבאים מספקים סקירה טכנית של ממשקי API חדשים ב-Android 4.0.

ממשקי API חברתיים ב'ספק אנשי הקשר'

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

פרופיל משתמש

Android כולל עכשיו פרופיל אישי שמייצג את בעל המכשיר, כפי שמוגדר על ידי טבלה של ContactsContract.Profile. אפליקציות של רשתות חברתיות ששומרות על זהות המשתמש יכול לתרום לנתוני הפרופיל של המשתמש על ידי יצירת רשומת ContactsContract.RawContacts חדשה בתוך ContactsContract.Profile. כלומר, אנשי קשר גולמיים שמייצגים את המשתמש במכשיר לא משתייכים לטבלה המסורתית של אנשי הקשר הגולמיים שהוגדרה על ידי ה-URI של ContactsContract.RawContacts; במקום זאת, עליך להוסיף איש קשר גולמי של הפרופיל הטבלה שבכתובת CONTENT_RAW_CONTACTS_URI. גולמי לאחר מכן, אנשי הקשר שבטבלה זו מתווספים לפרופיל היחיד הגלוי למשתמש, שמסומן בתווית 'אני'.

כדי להוסיף איש קשר גולמי חדש עבור הפרופיל, הרשאה android.Manifest.permission#WRITE_PROFILE. בדומה לכך, כדי לקרוא מהפרופיל הטבלה, עליך לבקש את ההרשאה android.Manifest.permission#READ_PROFILE. אבל, לפעמים רוב האפליקציות לא צריכות לקרוא את פרופיל המשתמש, גם אם הן תורמות נתונים פרופיל. קריאת פרופיל המשתמש היא הרשאה רגישה, וצריך לצפות שהמשתמשים ספקן לגבי אפליקציות שמבקשות זאת.

כוונת הזמנה

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

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

תמונות גדולות

מערכת Android תומכת עכשיו בתמונות ברזולוציה גבוהה של אנשי קשר. עכשיו, כשדוחפים תמונה לתוך רשומת איש קשר, המערכת מעבדת אותה גם לתמונה ממוזערת בגודל 96x96 (כפי שעשתה בעבר) וגם "הצגת תמונה" בגודל 256x256 שמאוחסנים בחנות תמונות חדשה שמבוססת על קבצים (המידות המדויקות של המערכת עשויה להשתנות בעתיד). ניתן להוסיף תמונה גדולה לאנשי קשר באמצעות הצבת תמונה גדולה בעמודה PHOTO הרגילה של שורת נתונים, שאותה המערכת תעבד לאחר מכן לתמונה הממוזערת ולתמונה המוצגת רשומות.

משוב על השימוש באנשי קשר

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

ספק היומן

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

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

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

  • בטבלה CalendarContract.Calendars יש נתונים ספציפיים ליומן מידע. כל שורה בטבלה הזו כוללת את הפרטים של יומן מסוים, כמו השם שלו, צבע, סנכרון מידע וכו'.
  • הטבלה CalendarContract.Events מכילה מידע ספציפי לאירוע. כל שורה בטבלה הזו מכילה את המידע של אירוע אחד, כמו כותרת האירוע, מיקום, שעת התחלה, שעת סיום וכן הלאה. האירוע יכול להתרחש פעם אחת או לחזור כמה פעמים. המשתתפים, התזכורות והנכסים המורחבים מאוחסנים בטבלאות נפרדות להשתמש ב-_ID של האירוע כדי לקשר אותם לאירוע.
  • בטבלה CalendarContract.Instances מפורטים זמני ההתחלה והסיום של התרחשויות של אירוע. כל שורה בטבלה הזו מייצגת אירוע אחד. לאירועים חד-פעמיים יש מיפוי אחד לאחד של מופעים לאירועים. באירועים חוזרים, צריך לבצע כמה שורות נוצר באופן אוטומטי בהתאם למופעים המרובים של אותו אירוע.
  • הטבלה CalendarContract.Attendees מכילה את המשתתף או האורח באירוע מידע. כל שורה מייצגת אורח אחד באירוע. מציין את סוג האורח הוא שלו, והתשובה של אותו אדם לאירוע.
  • הטבלה CalendarContract.Reminders מכילה את נתוני ההתראה/התראה. כל שורה מייצגת התראה אחת לגבי אירוע. לאירוע אחד יכולות להיות מספר תזכורות. מספר תזכורות לכל אירוע מצוינות ב-MAX_REMINDERS, שמוגדר על ידי מתאם הסנכרון הוא הבעלים של היומן הנתון. התזכורות נוצרות מספר דקות לפני האירוע לתזמן ולקבוע שיטת התראה, למשל להשתמש בהתראה, באימייל או ב-SMS כדי להזכיר להם. למשתמש.
  • בטבלה CalendarContract.ExtendedProperties יש שדות נתונים אטומים בשימוש על ידי מתאם הסנכרון. הספק לא מבצע כל פעולה לגבי הפריטים בטבלה הזו מלבד מחיקה אותם כשהאירועים הקשורים אליהם נמחקים.

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

כוונת אירוע

אם רוצים רק להוסיף אירוע ליומן של המשתמש, אפשר להשתמש ב-Intent ACTION_INSERT עם הנתונים שמוגדרים על ידי Events.CONTENT_URI כדי להתחיל פעילות באפליקציית יומן Google שיוצרת אירועים חדשים. השימוש ב-Intent לא מחייב של Google, תוכלו לציין את פרטי האירוע עם התוספות הבאות:

ספק דואר קולי

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

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

המחלקה VoicemailContract מגדירה את ספק התוכן עבור ספק דואר קולי. מחלקות המשנה VoicemailContract.Voicemails ו-VoicemailContract.Status מספקות טבלאות שבהן אפליקציות יכולות הזנת נתוני הדואר הקולי לאחסון במכשיר. לדוגמה של אפליקציה של ספק הודעות קוליות, אפשר לעיין ב ספק הדואר הקולי הדגמה (דמו).

מולטימדיה

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

אפקטים של מדיה

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

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

  1. צריך לקשר אותם לתמונה של טקסטורה GL_TEXTURE_2D
  2. הן חייבות להכיל רמת מיפוי מייל אחת לפחות

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

  1. קריאה אל EffectContext.createWithCurrentGlContext() מההקשר של OpenGL ES 2.0.
  2. משתמשים בפונקציה EffectContext שהוחזרה כדי להפעיל את הפונקציה EffectContext.getFactory(), שמחזירה מופע מתוך EffectFactory.
  3. קוראים אל createEffect(), מעבירים שם האפקט מ- @link android.media.effect.effectiveProcess}, כמו EFFECT_FISHEYE או EFFECT_VIGNETTE.

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

כדי להחיל אפקט על טקסטורה, יש לקרוא ל-apply() Effect ולהעביר את טקסטורת הקלט, את הרוחב והגובה שלו, ואת הפלט טקסטורה. מרקם הקלט חייב להיות קשור למרקם GL_TEXTURE_2D תמונה (בדרך כלל נעשה על ידי קריאה ל-glTexImage2D()) ). אפשר לציין כמה רמות של מיילים ב-Mipmap. אם מרקם הפלט לא קושר תמונת טקסטורה, היא תהיה משויכת באופן אוטומטי לאפקט GL_TEXTURE_2D ועם רמת Mipmap אחת (0), שתהיה לה אותה גודל כקלט.

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

לקוח שלט רחוק

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

כדי להפעיל לקוחות של שליטה מרחוק בנגן המדיה שלכם, צריך ליצור מופע של RemoteControlClient באמצעות ה-constructor שלו, ולהעביר אותו PendingIntent שמשדר ACTION_MEDIA_BUTTON. אפליקציית Intent צריכה גם להצהיר על רכיב ה-BroadcastReceiver המפורש באפליקציה שלכם שמטפל באירוע ACTION_MEDIA_BUTTON.

כדי להצהיר באילו מקורות של בקרת מדיה הנגן יכול לטפל, צריך לבצע קריאה אל setTransportControlFlags() RemoteControlClient, העברת קבוצה של דגלים FLAG_KEY_MEDIA_*, כמו FLAG_KEY_MEDIA_PREVIOUS וגם FLAG_KEY_MEDIA_NEXT.

לאחר מכן עליך לרשום את RemoteControlClient על ידי העברתו אל MediaManager.registerRemoteControlClient(). לאחר ההרשמה, מקלט השידור שהצהרת עליו כשיצרת את המופע של RemoteControlClient יקבל ACTION_MEDIA_BUTTON אירועים כשלוחצים על לחצן בשלט רחוק. ה-Intent שמתקבל כולל את השדה KeyEvent של מקש המדיה שעליו לחצת, ואפשר לאחזר אותו מה-Intent באמצעות getParcelableExtra(Intent.EXTRA_KEY_EVENT).

כדי להציג מידע בשלט הרחוק לגבי הפעלת המדיה, צריך להפעיל את editMetaData() ולהוסיף מטא-נתונים RemoteControlClient.MetadataEditor. תוכלו לספק מפת סיביות לגרפיקה של מדיה, מידע מספרי כמו הזמן שחלף ופרטי טקסט כמו שם הטראק. עבור מידע על המפתחות הזמינים מופיע בדגלי METADATA_KEY_* ב-MediaMetadataRetriever.

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

נגן מדיה

  • מעכשיו, כדי לשדר מדיה בסטרימינג אונליין מ-MediaPlayer, נדרשת ההרשאה INTERNET. אם משתמשים ב-MediaPlayer כדי להפעיל תוכן מהאינטרנט, הקפידו להוסיף את INTERNET הרשאה למניפסט שלך, אחרת הפעלת המדיה לא תפעל החל מ-Android 4.0.
  • setSurface() מאפשר להגדיר Surface שיתנהג בהתאם ל-sink הסרטון.
  • setDataSource() מאפשר לך לשלוח כותרות HTTP נוספות יחד עם הבקשה, שיכולות להיות שימושיות לסטרימינג בשידור חי מסוג HTTP(S)
  • סטרימינג בשידור חי ב-HTTP(S) מכבד עכשיו קובצי Cookie של HTTP בכל הבקשות

סוגי המדיה

ב-Android 4.0 נוספת תמיכה בתכונות הבאות:

  • גרסה 3 של פרוטוקול סטרימינג בשידור חי ב-HTTP/HTTPS
  • קידוד אודיו של AAC גולמי של ADTS
  • תמונות WEBP
  • סרטון של Matroska

מידע נוסף זמין במדיה נתמכת פורמטים.

מצלמה

בכיתה Camera יש עכשיו ממשקי API לזיהוי פנים ולבקרה תחומי מיקוד ומדידה.

איתור פנים

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

כדי לזהות פנים באפליקציית המצלמה, עליך לרשום Camera.FaceDetectionListener בהתקשרות אל setFaceDetectionListener(). לאחר מכן אפשר להתחיל פני המצלמה ומתחילים לזהות פנים על ידי התקשרות אל startFaceDetection().

כשהמערכת מזהה פנים של אדם אחד או יותר בסצנת המצלמה, היא מבצעת קריאה חוזרת (callback) של onFaceDetection() ב של Camera.FaceDetectionListener, כולל מערך Camera.Face אובייקטים.

מופע של המחלקה Camera.Face מספק מידע שונה על הפנים שזוהו, כולל:

  • Rect שמציין את גבולות הפנים, ביחס לגבולות של המצלמה שדה הראייה הנוכחי
  • מספר שלם בין 1 ל-100 שמציין את מידת הביטחון של המערכת בכך שהאובייקט פנים אנושיות
  • מזהה ייחודי שיאפשר לך לעקוב אחרי כמה קבוצות פנים
  • מספר אובייקטים מסוג Point שמציינים את מיקום העיניים והפה נמצא

הערה: יכול להיות שהתכונה 'זיהוי פנים' לא תתמוך בחלק מהמכשירים לכן עליך לבדוק על ידי התקשרות אל getMaxNumDetectedFaces() ולוודא שהחזרת גדול מאפס. בנוסף, מכשירים מסוימים לא תומכים בזיהוי העיניים והפה, במקרה כזה, השדות האלה באובייקט Camera.Face יהיו ריקים.

אזורי מיקוד ומדידה

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

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

כדי לציין את אזורי המיקוד או מכסת המאמרים שבהם יש להשתמש, פשוט קוראים לפונקציה setFocusAreas() או setMeteringAreas(). כל אחד מהם לוקח List מתוך Camera.Area אובייקטים שמציינים את האזורים שצריך לקחת בחשבון למיקוד או למדידת ביצועים. לדוגמה, אפשר להטמיע תכונה שמאפשרת למשתמש להגדיר אזור המיקוד באמצעות נגיעה באזור בתצוגה המקדימה. לאחר מכן מתרגמים לאובייקט Camera.Area מבקשים שהמצלמה תתמקד באזור הזה בסצנה. המיקוד או החשיפה באזור הזה יתעדכנו באופן קבוע בהתאם לשינויים בסצנה.

מיקוד אוטומטי רציף לתמונות

עכשיו אפשר להפעיל מיקוד אוטומטי רציף (CAF) בזמן צילום תמונות. כדי להפעיל CAF ב- אפליקציית מצלמה, העברת FOCUS_MODE_CONTINUOUS_PICTURE אל setFocusMode(). כשמוכנים לצלם תמונה, התקשר אל autoFocus(). המכשיר Camera.AutoFocusCallback יקבל מיד התקשרות חזרה כדי לציין אם הושג. כדי להמשיך את הטיפול ב-CAF אחרי קבלת הקריאה החוזרת, צריך להתקשר ל-cancelAutoFocus().

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

תכונות אחרות של המצלמה

  • בזמן צילום וידאו, אפשר עכשיו להתקשר למספר takePicture() כדי לשמור תמונה בלי להפסיק את סשן הווידאו. לפני שתעשו זאת, עליכם צריך להתקשר אל isVideoSnapshotSupported() כדי לוודא שהחומרה תומך בכך.
  • עכשיו אפשר לנעול חשיפה אוטומטית ואיזון לבן באמצעות setAutoExposureLock() ו-setAutoWhiteBalanceLock() כדי למנוע כדי למנוע שינויים במאפיינים האלה.
  • עכשיו אפשר להתקשר אל setDisplayOrientation() בזמן שהתצוגה המקדימה של המצלמה פועלת. בעבר אפשר היה לקרוא לזה רק לפני התחלת התצוגה המקדימה, אבל עכשיו אפשר לשנות את הכיוון בכל שלב.

כוונות שידור מהמצלמה

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

Android Beam (NDEF Push with NFC)

Android Beam היא תכונת NFC חדשה שמאפשרת לשלוח הודעות NDEF ממכשיר אחד אל אחר (תהליך שנקרא גם "דחיפת NDEF"). העברת הנתונים מתחילה כאשר מכשירים מבוססי Android שתומכים ב-Android Beam נמצאים בסמוך (כ-4 ס"מ), בדרך כלל עם הגבים שלהם נוגעים. הנתונים בתוך הודעת NDEF יכולים להכיל את כל הנתונים שרוצים לשתף בין מכשירים. לדוגמה, אפליקציית 'אנשים' משתפת אנשי קשר, משתפת סרטונים ומנהלת את הדפדפן ב-YouTube משתף כתובות URL באמצעות Android Beam.

כדי להעביר נתונים בין מכשירים באמצעות Android Beam, עליך ליצור NdefMessage שמכיל את המידע שברצונך לשתף בזמן שהפעילות מתבצעת את החזית. לאחר מכן צריך להעביר את NdefMessage למערכת באחד מתוך שניים דרכים:

  • הגדרת NdefMessage יחיד לדחיפה בזמן הפעילות:

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

  • הגדרת ה-NdefMessage לדחיפה בזמן הפעלת Android Beam:

    יישום של NfcAdapter.CreateNdefMessageCallback, שבו יישום של createNdefMessage() הפונקציה מחזירה את הערך NdefMessage שרוצים לשלוח. לאחר מכן מעבירים את ההטמעה של NfcAdapter.CreateNdefMessageCallback אל setNdefPushMessageCallback().

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

למקרה שתרצו להריץ קוד ספציפי אחרי שהמערכת תעביר את ה-NDEF בהצלחה למכשיר השני, אפשר להטמיע את NfcAdapter.OnNdefPushCompleteCallback ולהגדיר אותו עם setNdefPushCompleteCallback(). המערכת לאחר מכן יש להתקשר למספר onNdefPushComplete() כשההודעה תימסר.

במכשיר המקבל, המערכת שולחת הודעות NDEF בדחיפה באופן דומה להודעות NFC רגילות. התגים. המערכת מפעילה Intent באמצעות ACTION_NDEF_DISCOVERED כדי להתחיל פעילות, באמצעות כתובת URL או סוג MIME המוגדרים לפי NdefRecord הראשון בNdefMessage. לגבי הפעילות שאתם רוצים יש לך אפשרות להצהיר על מסנני Intent של כתובות ה-URL או סוגי MIME שחשובים לאפליקציה. לקבלת מידע נוסף מידע על Tag Dispatch זמין במדריך למפתחים של NFC.

אם רוצים שה-NdefMessage יכלול URI, אפשר עכשיו להשתמש במאפיין הנוחות השיטה createUri כדי ליצור NdefRecord חדש על סמך מחרוזת או אובייקט Uri. אם ה-URI הוא פורמט מיוחד שברצונך שהאפליקציה תקבל גם במהלך אירוע של Android Beam, צריך ליצור מסנן Intent לפעילות שלכם באמצעות אותה סכימת URI, כדי לקבל את הודעת NDEF נכנסת.

עליך גם להעביר 'רשומה של אפליקציה ל-Android' עם NdefMessage ב- כדי להבטיח שהאפליקציה תטפל בהודעת ה-NDEF הנכנסת, גם אם היא מסננים של אפליקציות לאותה פעולת Intent. אפשר ליצור רשומה של אפליקציה ל-Android באמצעות התקשרות אל createApplicationRecord(), העברה שם החבילה של האפליקציה. כשהמכשיר השני מקבל את הודעת ה-NDEF עם רשומת אפליקציה ומספר אפליקציות מכילות פעילויות שמטפלות בכוונה שצוינה, המערכת תמיד מעבירה את ההודעה לפעילות באפליקציה (בהתאם רשומת בקשה). אם האפליקציה שלך לא מותקנת כרגע במכשיר היעד, המערכת משתמשת ברשומת האפליקציה של Android כדי להפעיל את Google Play ולהעביר את המשתמש כדי להתקין אותו.

אם האפליקציה שלך לא משתמשת בממשקי API של NFC כדי לבצע העברת הודעות NDEF Push, Android מספק התנהגות ברירת המחדל: כשהאפליקציה פועלת בחזית במכשיר אחד ו-Android Beam מופעל באמצעות מכשיר אחר המבוסס על Android, והמכשיר השני מקבל הודעת NDEF עם רשומה של אפליקציית Android שמזהה את האפליקציה שלכם. אם במכשיר המקבל יש את מותקנת, המערכת מפעילה אותו; אם האפליקציה לא מותקנת, אפליקציית Google Play נפתחת ומצלמת את המשתמש באפליקציה כדי להתקין אותה.

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

Wi-Fi P2P

Android תומך עכשיו בחיבורי Wi-Fi מקצה לקצה (P2P) בין מכשירים מבוססי Android לבין סוגי מכשירים אחרים (בהתאם ל-Wi-Fi DirectTM של Wi-Fi Alliance תוכנית הסמכה) ללא נקודה לשיתוף אינטרנט (Hotspot) או חיבור לאינטרנט. Android Framework מספק קבוצה של ממשקי Wi-Fi P2P API שמאפשרים לגלות מכשירים אחרים ולהתחבר אליהם בכל פעם שהמכשירים תומכת ב-Wi-Fi P2P, ואז מתקשרת בחיבור מהיר במרחקים ארוכים בהרבה חיבור Bluetooth.

חבילה חדשה, android.net.wifi.p2p, מכילה את כל ממשקי ה-API לביצוע מקצה לקצה (P2P) חיבורים עם Wi-Fi. הכיתה הראשית שאיתה צריך לעבוד היא WifiP2pManager. אפשר לרכוש אותה באמצעות הטלפון getSystemService(WIFI_P2P_SERVICE). WifiP2pManager כולל ממשקי API שמאפשרים לך:

  • לאתחל את האפליקציה לחיבורי P2P על ידי התקשרות אל initialize()
  • רוצה למצוא מכשירים בקרבת מקום? ניתן להתקשר אל discoverPeers()
  • כדי להתחיל חיבור P2P, צריך להתקשר אל connect()
  • ועוד

נחוצים גם כמה ממשקים ומחלקות אחרים, כמו:

  • הממשק של WifiP2pManager.ActionListener מאפשר לקבל קריאות חוזרות (callback) כשפעולה כמו איתור אפליקציות להשוואה או התחברות אליהן מצליחה או נכשלת.
  • הממשק של WifiP2pManager.PeerListListener מאפשר לך לקבל מידע על אפליקציות להשוואה שנמצאו. הקריאה החוזרת (callback) מספקת WifiP2pDeviceList, שבאמצעותו אפשר לאחזר אובייקט WifiP2pDevice לכל מכשיר שנמצא בטווח, ולקבל מידע כמו שם המכשיר, הכתובת, סוג המכשיר, הגדרות ה-WPS שבהן המכשיר תומך ועוד.
  • הממשק של WifiP2pManager.GroupInfoListener מאפשר לכם לקבל מידע על קבוצת P2P. הקריאה החוזרת מספקת אובייקט WifiP2pGroup, שמספק מידע על הקבוצה, כמו הבעלים, שם הרשת וביטוי הסיסמה.
  • הממשק של WifiP2pManager.ConnectionInfoListener מאפשר לכם לקבל מידע על החיבור הנוכחי. הקריאה החוזרת מספקת אובייקט WifiP2pInfo, שכולל מידע כמו אם קבוצה או לא נוצר ומי הבעלים של הקבוצה.

כדי להשתמש בממשקי ה-API של Wi-Fi P2P, האפליקציה שלך צריכה לבקש את הרשאות המשתמש הבאות:

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET (למרות שהאפליקציה שלך לא מתחברת מבחינה טכנית לאינטרנט, תקשורת עם עמיתים ב-Wi-Fi P2P שיש להם שקעי Java רגילים מחייבת חיבור לאינטרנט ).

מערכת Android משדרת גם כמה פעולות שונות במהלך אירועי Wi-Fi מסוימים P2P:

מידע נוסף זמין במסמכי התיעוד של WifiP2pManager. וגם לעיין הדגמת P2P של Wi-Fi של האפליקציה לדוגמה.

מכשירי Bluetooth Health

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

בדומה לאוזניות רגילות ולמכשירי פרופיל A2DP, כדי ליצור חיבור לפרופיל צריך להפעיל את getProfileProxy() עם BluetoothProfile.ServiceListener ועם סוג הפרופיל HEALTH אובייקט proxy.

אחרי שרוכשים את שרת ה-Proxy של פרופיל הבריאות (BluetoothHealth ), כשמתחברים למכשירי בריאות מותאמים ומתקשרים איתם, יש את הכלים הבאים סיווגי Bluetooth:

  • BluetoothHealthCallback: יש להרחיב את הכיתה ולהטמיע את שיטות קריאה חוזרת (callback) לקבלת עדכונים על שינויים במצב הרישום של האפליקציה, מצב ערוץ Bluetooth.
  • BluetoothHealthAppConfiguration: במהלך קריאות חוזרות אל BluetoothHealthCallback, יתקבל מופע של האובייקט הזה מספקת פרטי תצורה על המכשיר הזמין של תקינות ה-Bluetooth, שבו צריך להשתמש כדי לבצע פעולות שונות כמו ליזום ולסיים חיבורים עם ממשקי ה-API של BluetoothHealth.

מידע נוסף על השימוש בפרופיל Health ב-Bluetooth זמין במסמכים של BluetoothHealth.

נגישות

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

מצב 'גילוי באמצעות מגע'

משתמשים עם אובדן ראייה יכולים כעת לחקור את המסך על ידי נגיעה וגרירה של אצבע על פני כדי לשמוע תיאורים קוליים של התוכן. כי מצב 'גילוי אחר מגע' פועל כמו סמן וירטואלי, הוא מאפשר לקוראי מסך לזהות את הטקסט התיאורי באותו אופן שבו לקוראים יכולים לעשות זאת כשהמשתמש מנווט באמצעות מקשי החיצים (d-pad או כדור עקיבה) — על ידי קריאת המידע שסופק על ידי android:contentDescription ועל setContentDescription() במהלך סימולציה של 'מעבר מעל עכבר' אירוע. אז, זאת תזכורת לכך שצריך לספק טקסט תיאורי עבור התצוגות במיוחד לאפליקציות ImageButton, EditText, ImageView ווידג'טים אחרים שעשויים לא לכלול באופן טבעי תיאורים טקסט.

נגישות לתצוגות

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

חשוב לזכור קודם כל שההתנהגות של השיטה sendAccessibilityEvent() השתנתה ב-Android 4.0. כמו בגרסה הקודמת של Android, כשהמשתמש מפעיל שירותי נגישות במכשיר ואירוע קלט כמו קליק או העברת העכבר, מתרחש בתצוגה המתאימה, נשלחת קריאה sendAccessibilityEvent() בעבר, יישום של sendAccessibilityEvent() צריך לאתחל AccessibilityEvent ולשלוח אל AccessibilityManager. ההתנהגות החדשה כוללת קריאה חוזרת (callback) נוספת שיטות שמאפשרות לתצוגה ולהורים שלה להוסיף עוד מידע הקשרי לאירוע:

  1. בהפעלה, השיטות sendAccessibilityEvent() ו-sendAccessibilityEventUnchecked() דוחות דחייה אל onInitializeAccessibilityEvent().

    ייתכן שהטמעות מותאמות אישית של View יטמיעו את onInitializeAccessibilityEvent() לצרף מידע נוסף על נגישות ל-AccessibilityEvent, אבל צריך גם לבצע קריאה להטמעה של: לספק פרטי ברירת מחדל, כמו תיאור התוכן הרגיל, אינדקס הפריטים ועוד. אבל לא כדאי להוסיף תוכן טקסט נוסף בקריאה החוזרת (callback) – זה קורה הבא.

  2. אחרי האתחול, אם האירוע הוא אחד מכמה סוגים שצריך לאכלס בטקסט מידע, התצוגה תקבל קריאה אל dispatchPopulateAccessibilityEvent(), נוטרת ל-onPopulateAccessibilityEvent() קריאה חוזרת.

    הטמעות מותאמות אישית של View בדרך כלל אמורות להטמיע onPopulateAccessibilityEvent() כדי להוסיף עוד של תוכן הטקסט אל AccessibilityEvent אם הטקסט android:contentDescription חסר או לא מספיק. כדי להוסיף עוד טקסט תיאור AccessibilityEvent, שיחה אל getText().add().

  3. בשלב הזה, ה-View מעביר את האירוע למעלה בהיררכיית התצוגות באמצעות קריאה לפעולה requestSendAccessibilityEvent() ב- תצוגה ראשית. לכל תצוגת הורה יש הזדמנות לשפר את נתוני הנגישות על ידי הוספה של AccessibilityRecord, עד הוא מגיע בסופו של דבר לתצוגת הבסיס, ששולח את האירוע אל AccessibilityManager עם sendAccessibilityEvent().

בנוסף לשיטות החדשות שלמעלה, שהן שימושיות כשמרחיבים את המחלקה View, אפשר גם ליירט את הקריאות החוזרות של האירועים האלה בכל View. לשם כך, מרחיבים את AccessibilityDelegate ומגדירים אותו בתצוגה באמצעות setAccessibilityDelegate() לאחר מכן, כל שיטת נגישות בתצוגה דוחה את הקריאה לשיטה המתאימה בעל הגישה. לדוגמה, כשהתצוגה המפורטת מקבלת קריאה אל onPopulateAccessibilityEvent(), היא מעבירה אותה אל אותה שיטה בView.AccessibilityDelegate. שיטות שלא מטופלות על ידי משתמש עם הרשאה יקבל חזרה לתצוגה את התנהגות ברירת המחדל. כך אפשר לשנות רק את ההגדרות השיטות הנחוצות לכל תצוגה נתונה בלי להרחיב את המחלקה View.

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

שירותי נגישות

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

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

  1. עם קבלת AccessibilityEvent מאפליקציה, קוראים ל-AccessibilityEvent.getRecord() כדי לאחזר AccessibilityRecord ספציפי (ייתכן שצורפו כמה רשומות אירוע).
  2. מ-AccessibilityEvent או מ-AccessibilityRecord ספציפי, אפשר לקרוא ל-getSource() כדי לאחזר אובייקט AccessibilityNodeInfo.

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

  3. בעזרת AccessibilityNodeInfo אפשר לבצע שאילתות לגבי מידע מידע על כך, התקשר אל getParent() או getChild() כדי לחצות את התצוגה ההיררכיה, ואפילו להוסיף תצוגות צאצא לצומת.

כדי שהאפליקציה שלך תפרסם את עצמה במערכת בתור שירות נגישות, היא חייבת להצהיר על קובץ תצורה של XML שתואם ל-AccessibilityServiceInfo. כדי לקבל מידע נוסף על יצירת מידע על תצורת ה-XML מופיע במאמרים AccessibilityService ו-SERVICE_META_DATA.

ממשקי API אחרים לנגישות

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

שירותי בדיקת איות

מסגרת חדשה של בדיקת איות מאפשרת לאפליקציות ליצור בודקי איות באופן דומה framework של שיטת הקלט (ל-IMEs). כדי ליצור בדיקת איות חדשה, צריך להטמיע שירות נמשך SpellCheckerService ולהרחיב את הכיתה SpellCheckerService.Session כדי לספק הצעות איות על סמך בטקסט שמסופק על ידי שיטות הקריאה החוזרת (callback) של הממשק. ב-methods של הקריאה החוזרת (callback) ב-SpellCheckerService.Session, צריך להחזיר את הצעות איות כאובייקטים SuggestionsInfo.

אפליקציות עם שירות בודק איות חייבות להצהיר על ההרשאה BIND_TEXT_SERVICE כפי שנדרש על ידי השירות. השירות צריך גם להצהיר על מסנן Intent עם <action android:name="android.service.textservice.SpellCheckerService" /> כפעולה של Intent, והוא צריך כוללים רכיב <meta-data> שמצהיר על פרטי תצורה של האיות שבודק.

ראה דוגמה האפליקציה 'שירות בדיקת איות' דוגמה אפליקציית לקוח לבדיקת איות, למשל קוד.

מנועים להמרת טקסט לדיבור (TTS)

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

שימוש במנועי המרת טקסט לדיבור (TTS)

בגרסאות קודמות של Android, היה אפשר להשתמש במחלקה TextToSpeech כדי לבצע פעולות של המרת טקסט לדיבור (TTS) באמצעות מנוע ה-TTS שסופק על ידי המערכת, או כדי להגדיר מנוע מותאם אישית באמצעות setEngineByPackageName(). ב-Android 4.0, השיטה setEngineByPackageName() כבר הוצא משימוש ועכשיו אפשר להגדיר את המנוע לשימוש עם constructor חדש של TextToSpeech שמקבל את שם החבילה של מנוע TTS.

אפשר גם לשלוח שאילתות על מנועי ה-TTS הזמינים באמצעות getEngines(). השיטה הזו מחזירה רשימה של TextToSpeech.EngineInfo אובייקטים, כולל מטא-נתונים כמו סמל, תווית ושם חבילה.

יצירת מנועים להמרת טקסט לדיבור (TTS)

בעבר, מנועים בהתאמה אישית דרשו לבנות את המנוע באמצעות כותרת מקורית לא מתועדת חדש. ב-Android 4.0, יש ערכה שלמה של ממשקי API של framework לבניית מנועי TTS.

ההגדרה הבסיסית מחייבת הטמעה של TextToSpeechService, בתגובה לכוונה INTENT_ACTION_TTS_SERVICE. העבודה הראשית במנוע TTS מתרחשת במהלך הקריאה החוזרת של onSynthesizeText() בשירות שאורכו TextToSpeechService. המערכת מספקת את השיטה הזו אובייקטים:

  • SynthesisRequest: מכיל נתונים שונים, כולל הטקסט להרכיב, את הלוקאל, קצב הדיבור וגובה הצליל.
  • SynthesisCallback: זה הממשק שדרכו מנוע ה-TTS מספקת את נתוני הדיבור שמתקבלים כאודיו בסטרימינג. קודם כל המנוע צריך לקרוא ל-start() כדי לציין שהמנוע מוכן לספק את האודיו, ואז קוראים ל-audioAvailable(), ומעבירים אליו את נתוני האודיו במאגר נתונים זמני של בייטים. אחרי שהמנוע מעביר את כל האודיו דרך מאגר נתונים זמני, צריך לבצע קריאה אל done().

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

לדוגמה, למנוע TTS שמשתמש בממשקי ה-API החדשים, באפליקציה לדוגמה Text to Speech Engine.

שימוש ברשת

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

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

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

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

חשוב גם לשים לב שעכשיו getBackgroundDataSetting() הוצא משימוש ומחזיר תמיד True — צריך להשתמש במקום זאת ב-getActiveNetworkInfo(). לפני שתנסו להתחבר לרשת כלשהי עסקאות, תמיד צריך להתקשר אל getActiveNetworkInfo() כדי לקבל את ה-NetworkInfo שמייצג את הרשת הנוכחית ואת השאילתה isConnected() כדי לבדוק אם למכשיר יש חיבור כזה. לאחר מכן אפשר לבדוק מאפייני חיבור אחרים, למשל אם המכשיר בנדידה או בחיבור לרשת Wi-Fi.

Enterprise

מערכת Android 4.0 מרחיבה את היכולות לאפליקציות ארגוניות באמצעות התכונות הבאות.

שירותי VPN

הגרסה החדשה של VpnService מאפשרת לאפליקציות ליצור VPN משלהן (וירטואלי רשת פרטית), שפועל בתור Service. שירות VPN יוצר ממשק עבור רשת וירטואלית עם כתובת וכללי ניתוב משלה, ומבצעת את כל הקריאה והכתיבה באמצעות שמתאר קובץ.

כדי ליצור שירות VPN, צריך להשתמש במדיניות VpnService.Builder, שמאפשרת לציין את כתובת הרשת, שרת DNS, נתיב הרשת ועוד. בסיום התהליך אפשר להגדיר באמצעות קריאה ל-establish(), שמחזירה ParcelFileDescriptor.

שירות VPN יכול ליירט חבילות, ולכן יש השלכות על האבטחה. לכן, אם להטמיע את VpnService, ואז השירות חייב לדרוש את המאפיין BIND_VPN_SERVICE כדי להבטיח שרק המערכת תוכל לקשר אליו (רק שהמערכת קיבלה את ההרשאה הזו – אפליקציות לא יכולות לבקש אותה). כדי להשתמש בשירות ה-VPN: המשתמשים חייבים להפעיל אותה באופן ידני בהגדרות המערכת.

מדיניות המכשיר

אפליקציות שמנהלות את הגבלות המכשירים יכולות עכשיו להשבית את המצלמה באמצעות setCameraDisabled() והמאפיין USES_POLICY_DISABLE_CAMERA (מיושם עם רכיב <disable-camera /> בקובץ התצורה של המדיניות).

ניהול אישורים

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

החיישנים במכשיר

שני סוגי חיישנים חדשים נוספו ב-Android 4.0:

  • TYPE_AMBIENT_TEMPERATURE: חיישן טמפרטורה שמספק את טמפרטורת הסביבה במעלות צלזיוס.
  • TYPE_RELATIVE_HUMIDITY: חיישן לחות שמספק הלחות היחסית (בחדר) באחוזים.

אם במכשיר יש גם חיישנים של TYPE_AMBIENT_TEMPERATURE וגם TYPE_RELATIVE_HUMIDITY, אפשר להשתמש בהם כדי לחשב את נקודת הטל ואת הלחות המוחלטת.

חיישן הטמפרטורה הקודם, TYPE_TEMPERATURE, הוצא משימוש. עליך להשתמש בחיישן TYPE_AMBIENT_TEMPERATURE במקום זאת.

בנוסף, שלושת החיישנים הסינתטיים של Android שופרו באופן משמעותי, ועכשיו הם נמוכים יותר זמן אחזור ופלט חלק יותר. החיישנים האלה כוללים את חיישן הכבידה (TYPE_GRAVITY), חיישן וקטור הסיבוב (TYPE_ROTATION_VECTOR) וחיישן התאוצה הלינארית (TYPE_LINEAR_ACCELERATION). החיישנים המשופרים מסתמכים על הג'ירוסקופ כדי לשפר את הפלט, החיישנים מופיעים רק במכשירים שיש בהם ג'ירוסקופ.

סרגל פעולות

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

סרגל הפעולות של פיצול

אם סרגל הפעולות כולל מספר פעולות לביצוע, לא כולן יופיעו בסרגל הפעולות מסך צר, כך שהמערכת תציב יותר מהם בתפריט האפשרויות הנוספות. לעומת זאת, ב-Android 4.0 מאפשר להפעיל את 'סרגל הפעולות המפוצל' כדי שיופיעו עוד פעולות לביצוע על המסך סרגל נפרד בתחתית המסך. כדי להפעיל את סרגל הפעולות המפוצל, צריך להוסיף את android:uiOptions עם "splitActionBarWhenNarrow" לאחת מהאפשרויות <application> תג או תגי <activity> נפרדים בקובץ המניפסט. כשהאפשרות הזו מופעלת, המערכת תוסיף סרגל נוסף בתחתית לכל הפעולות לביצוע כשהמסך צר (לא יופיעו פעולות לביצוע בסרגל הפעולות).

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

סגנונות של סרגל הפעולות

כדי להחיל עיצוב מותאם אישית על סרגל הפעולות, אפשר להשתמש במאפייני הסגנון החדשים backgroundStacked ו-backgroundSplit כדי להחיל רקע שניתן להזזה או לצבוע לעמודה המוערמת ולסרגל המפוצל, בהתאמה. אפשר להגדיר את הסגנונות האלה גם בכתובת עם setStackedBackgroundDrawable() ו-setSplitBackgroundDrawable().

ספק הפעולות

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

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

כדי להצהיר על ספק פעולות לפעולה לביצוע, צריך לכלול את android:actionProviderClass ברכיב <item> שבתפריט האפשרויות של הפעילות, עם שם הסיווג של הפעולה הספק בתור הערך. לדוגמה:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

בonCreateOptionsMenu() של הפעילות בשיטת הקריאה החוזרת (callback), מאחזרים מופע של ספק הפעולה מהפריט בתפריט ומגדירים את Intent:

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

לדוגמה, באמצעות ה-ShareActionProvider, ראו ActionBarShareActionProviderActivity ב-ApiDemos.

תצוגת פעולה שניתן לכווץ

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

כדי להצהיר שפעולה לביצוע שכוללת תצוגת פעולה ניתנת לכיווץ, צריך לכלול את הדגל “collapseActionView" במאפיין android:showAsAction של הרכיב <item> בקובץ ה-XML של התפריט.

כדי לקבל קריאות חוזרות (callback) כשתצוגת פעולה עוברת בין תצוגה מורחבת למכווצת, צריך לרשום של MenuItem.OnActionExpandListener עם MenuItem המתאים, באמצעות הפקודה setOnActionExpandListener(). בדרך כלל צריך לעשות זאת במהלך הקריאה החוזרת (callback) של onCreateOptionsMenu().

כדי לשלוט בתצוגת פעולה שאפשר לכווץ, אפשר להפעיל את collapseActionView() ואת expandActionView() MenuItem המתאים.

כשיוצרים תצוגה של פעולה מותאמת אישית, אפשר גם להטמיע את ממשק CollapsibleActionView החדש כדי לקבל קריאות חוזרות (callback) כשהתצוגה מורחבת במצב מכווץ.

ממשקי API אחרים לסרגל הפעולות

  • setHomeButtonEnabled() מאפשר לך לציין אם הסמל/הלוגו פועלים כלחצן לניווט לדף הבית או למעלה (הזינו את המילה 'TRUE' כדי שיתנהג כמו לחצן).
  • setIcon() ו-setLogo() מאפשרים להגדיר את הסמל או הלוגו של סרגל הפעולות בזמן הריצה.
  • Fragment.setMenuVisibility() מאפשר לך להפעיל או להשבית את הרשאות הגישה לאפשרויות בתפריט האפשרויות שהוצהרו על ידי המקטע. זה שימושי אם מקטע זה התווסף לפעילות, אבל הוא לא גלוי, לכן האפשרויות בתפריט צריכות להיות מוסתרים.
  • FragmentManager.invalidateOptionsMenu() מאפשרת לבטל את התוקף של תפריט אפשרויות הפעילות במהלך מצבים שונים של מחזור החיים של המקטע שבהם שימוש בשיטה המקבילה מ-Activity לא יהיה זמין.

ממשק משתמש ותצוגות

מערכת Android 4.0 כוללת מגוון תצוגות חדשות ורכיבים אחרים בממשק המשתמש.

פריסת רשת

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

ראו ApiDemos לדגימות באמצעות GridLayout.

תצוגת טקסטורה

TextureView היא תצוגה חדשה שמאפשרת להציג מקור תוכן, כמו כסרטון או כתמונת OpenGL. למרות ש-TextureView דומה ל-SurfaceView, הוא ייחודי בכך שהוא מתנהג כמו תצוגה רגילה, במקום ליצור כך שאפשר להתייחס אליו כמו לכל אובייקט View אחר. לדוגמה, אפשר לבצע שינויים בשינויים, להנפיש אותם באמצעות ViewPropertyAnimator, או לכוונן את השקיפות שלו באמצעות setAlpha().

צריך לשים לב ש-TextureView פועל רק במסגרת חלון עם האצת חומרה.

לקבלת מידע נוסף, עיינו במסמכי התיעוד של TextureView.

החלפת הווידג'ט

הווידג'ט החדש של Switch הוא מתג דו-מצבי שבו המשתמשים יכולים לגרור אותו לאחד הצד השני או על הצד השני (או פשוט מקישים) כדי להחליף מצב בין שני מצבים.

אפשר להשתמש במאפיינים android:textOn ו-android:textOff כדי לציין את הטקסט יופיע במתג כאשר ההגדרה מופעלת וכבויה. גם המאפיין android:text מאפשרת להציב תווית לצד המתג.

כדי לראות דוגמה לשימוש במתגים, עיינו בקובץ הפריסה switches.xml ואת המתגים המתאימים .

ב-Android 3.0 הושקה PopupMenu במטרה ליצור תפריטים קצרים לפי הקשר שקופצו בנקודת עוגן שציינת (בדרך כלל בנקודה של הפריט שנבחר). Android 4.0 מורחב PopupMenu עם כמה תכונות שימושיות:

  • עכשיו אפשר להגדיל בקלות את התוכן של תפריט קופץ ממשאב תפריט של XML באמצעות inflate(), ולהעביר אליו את מזהה משאב התפריט.
  • עכשיו אפשר גם ליצור PopupMenu.OnDismissListener שמקבל קריאה חוזרת (callback) כשהתפריט נסגר.

העדפות

שיעור מופשט חדש ב-TwoStatePreference משמש כבסיס העדפות שמאפשרות לבחור שתי מדינות. הגרסה החדשה של SwitchPreference היא תוסף של TwoStatePreference שמספק את הווידג'ט Switch תצוגת העדפה שמאפשרת למשתמשים להפעיל או להשבית הגדרה מבלי לפתוח מסך ההעדפות או תיבת דו-שיח. לדוגמה, האפליקציה 'הגדרות' משתמשת ב-SwitchPreference עבור הגדרות ה-Wi-Fi וה-Bluetooth.

עיצובי המערכת

עיצוב ברירת המחדל לכל האפליקציות שמטרגטות את Android 4.0 (על ידי הגדרה של targetSdkVersion או minSdkVersion עד “14" ומעלה) הוא עכשיו 'ברירת המחדל של המכשיר' עיצוב: Theme.DeviceDefault. למשל עיצוב כהה של Holo או עיצוב כהה אחר שהוגדר על ידי המכשיר הספציפי.

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

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

לחצן של תפריט האפשרויות

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

כדי ליהנות מחוויית המשתמש הטובה ביותר, אפליקציות חדשות ומעודכנות צריכות להשתמש במקום זאת בActionBar כדי לתת גישה לאפשרויות בתפריט ולהגדיר את targetSdkVersion לערך "14" כדי לנצל את היתרונות של התנהגויות ברירת המחדל העדכניות של framework.

אמצעי בקרה להרשאות הגישה לממשק המשתמש של המערכת

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

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

  • הדגל SYSTEM_UI_FLAG_LOW_PROFILE מחליף את הדגל STATUS_BAR_HIDDEN. כשהסימון הזה מוגדר, הוא מפעיל את האפשרות 'פרופיל נמוך' למצב מופעל בסרגל המערכת סרגל הניווט. לחצני הניווט מעומעמים ורכיבים אחרים בסרגל המערכת גם מוסתרים. מפעיל כך אפשר ליצור משחקים סוחפים יותר בלי הסחות דעת לניווט במערכת. הלחצנים.
  • הדגל SYSTEM_UI_FLAG_VISIBLE מחליף את הדגל STATUS_BAR_VISIBLE כדי לבקש שסרגל המערכת או סרגל הניווט יהיו גלויים.
  • השדה SYSTEM_UI_FLAG_HIDE_NAVIGATION הוא דגל חדש שמבקש שסרגל הניווט מוסתר לגמרי. לתשומת ליבך: האפשרות הזו פועלת רק בסרגל הניווט. בטלפונים מסוימים, הוא לא מסתיר את סרגל המערכת בטאבלטים). הניווט העמודה תחזור לתצוגה ברגע שהמערכת מקבלת קלט ממשתמשים. לכן המצב הזה מועיל בעיקר להפעלת וידאו או במקרים אחרים שבהם צריך את כל המסך אבל הקלט של המשתמשים לא נדרש.

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

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

מחלקה OverscanActivity כדי להדגים אפשרויות שונות בממשק המשתמש של המערכת.

מסגרת של קלט

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

אירועי העברת העכבר

בכיתה View יש עכשיו תמיכה בהעברת העכבר מעל אירועים כדי לאפשר אינטראקציות עשירות יותר באמצעות שימוש במכשירים עם מצביע העכבר (כמו עכבר או מכשירים אחרים שממוקמים במסך ).

כדי לקבל אירועים של העברת העכבר בתצוגה מפורטת, צריך להטמיע את View.OnHoverListener וגם עליך לרשום אותו ב-setOnHoverListener(). כשמעבירים את העכבר מעל האירוע מתרחש בתצוגה, המאזינים מקבלים שיחה אל onHover() ומספקים את הView קיבל את האירוע ו-MotionEvent שמתאר את הסוג של אירוע העברת העכבר שהתרחש. האירוע של העברת העכבר יכול להיות אחת מהאפשרויות הבאות:

View.OnHoverListener צריך להחזיר True מ-onHover() אם הוא מטפל באירוע של העברת העכבר. אם ה-listener מחזיר את הערך false, ואירוע העברת העכבר יישלח לתצוגת ההורה כרגיל.

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

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

אירועים של לחצני סטיילוס ועכבר

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

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

האפליקציה יכולה להבחין בין קלט של אצבע, עכבר, סטיילוס ומחיקה על ידי שליחת שאילתות "סוג הכלי" שמשויך לכל מצביע ב-MotionEvent באמצעות getToolType(). סוגי הכלים שמוגדרים כרגע הם: TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUS ו-TOOL_TYPE_ERASER. על ידי שאילתה על סוג הכלי, האפליקציה יכול לטפל בקלט סטיילוס בדרכים שונות מהקלט באמצעות האצבע או העכבר.

האפליקציה יכולה גם לבצע שאילתה על איזה לחצני עכבר או סטיילוס לוחצים על ידי שליחת שאילתה על הלחצן " מצב" של MotionEvent באמצעות getButtonState(). מצבי הלחצן שמוגדרים כרגע הם: BUTTON_PRIMARY, BUTTON_SECONDARY, BUTTON_TERTIARY, BUTTON_BACK ו-BUTTON_FORWARD. לנוחיותכם, לחצני העכבר קדימה ואחורה ממופה באופן אוטומטי למפתחות KEYCODE_BACK ו-KEYCODE_FORWARD. האפליקציה שלך יכולה לטפל במפתחות האלה כדי לתמוך לחצן עכבר שמבוסס על ניווט אחורה וקדימה.

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

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

מאפיינים

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

לדוגמה, אם רוצים להגדיר את הערך של השדה bar באובייקט foo, צריך עשו זאת בעבר:

Kotlin

foo.bar = value

Java

foo.bar = value;

אם רוצים לקרוא לרכיב המגדיר בשדה פרטי בסיסי bar, קודם צריך לבצע את הפעולה הבאה עושים זאת:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

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

באמצעות הכיתה Property אפשר להצהיר על Property האובייקט BAR במחלקה Foo, כדי שאפשר יהיה להגדיר את השדה במופע foo של כיתה Foo דומה לזו:

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

הכיתה View משתמשת עכשיו בכיתה Property כדי מאפשרות להגדיר שדות שונים, כמו טרנספורמציה של מאפיינים שנוספו ב-Android 3.0 (ROTATION, ROTATION_X, TRANSLATION_X וכו').

הכיתה ObjectAnimator משתמשת גם ב-Property לכן אפשר ליצור ObjectAnimator עם Property, שהוא מהיר יותר, יעיל יותר ובטוח יותר לסוג יותר מהמחרוזת מבוססת-המחרוזות. .

שיפור המהירות באמצעות חומרה

החל מ-Android 4.0, שיפור המהירות באמצעות חומרה בכל החלונות מופעל כברירת מחדל אם האפליקציה הגדירה targetSdkVersion או minSdkVersion עד “14" ומעלה. שיפור המהירות באמצעות חומרה בדרך כלל מוביל לאנימציות חלקות יותר, גלילה ושיפור כללי בביצועים ובתגובה לאינטראקציה של המשתמש.

במידת הצורך, אפשר להשבית באופן ידני את האצת החומרה באמצעות hardwareAccelerated לרכיבי <activity> נפרדים או לרכיב <application> לרכיב מסוים. לחלופין, אפשר להשבית את האצת החומרה בתצוגות ספציפיות באמצעות קריאה ל-setLayerType(LAYER_TYPE_SOFTWARE).

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

שינויים ב-JNI

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

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

השינוי בהטמעת ה-JNI משפיע רק על אפליקציות שמטרגטות ל-Android 4.0 על ידי הגדרה של targetSdkVersion או minSdkVersion עד “14" ואילך. אם הגדרתם את המאפיינים האלה לערך נמוך יותר, קובצי העזר המקומיים של JNI מתנהגים בדיוק כמו בגרסאות הקודמות.

WebKit

  • WebKit עודכן לגרסה 534.30
  • תמיכה בגופנים הודיים (דוונאגרי, בנגלית וטמילית, כולל תמיכה מורכבת בתווים לצורך שילוב גליפים) ב-WebView ובדפדפן המובנה
  • תמיכה בגופנים אתיופיים, גיאורגיים וארמניים בWebView דפדפן מובנה
  • תמיכה ב-WebDriver כך שיהיה לך קל יותר לבדוק אפליקציות שמשתמשות ב-WebView

דפדפן Android

יישום הדפדפן מוסיף את התכונות הבאות לתמיכה באפליקציות אינטרנט:

הרשאות

אלו ההרשאות החדשות:

תכונות המכשיר

אלה התכונות החדשות במכשיר:

  • FEATURE_WIFI_DIRECT: הצהרה שהבקשה משתמשת Wi-Fi לתקשורת מקצה לקצה.

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

ממשקי ה-API הקודמים

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

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

Android 3.0
  • Fragment: רכיב framework שמאפשר להפריד רכיבים של פעילות במודולים עצמאיים, שמגדירים ממשק משתמש ומחזור חיים משלהם. לצפייה מדריך למפתחים בנושא מקטעים.
  • ActionBar: תחליף לשורת הכותרת המסורתית בחלק העליון של חלון הפעילות. הוא כולל את לוגו האפליקציה בפינה השמאלית ומספק של האפשרויות בתפריט. לצפייה המדריך למפתחים של סרגל הפעולות.
  • Loader: רכיב framework שמאפשר גישה אסינכרונית טעינת נתונים בשילוב עם רכיבי ממשק משתמש כדי לטעון נתונים באופן דינמי מבלי לחסום את ה-thread הראשי. לצפייה מדריך למפתחים של Loaders
  • לוח המערכת: אפליקציות יכולות להעתיק ולהדביק נתונים (מעבר לטקסט בלבד) אל וממנו את הלוח ברמת המערכת. נתונים חתוכים יכולים להיות טקסט פשוט, URI או Intent. לצפייה העתקה והדבקה של המדריך למפתחים.
  • גרירה ושחרור: קבוצה של ממשקי API מובנים בתוך מסגרת התצוגה, המאפשרים גרירה ושחרור ב-AI. לצפייה מדריך למפתחים בנושא גרירה ושחרור.
  • מסגרת אנימציה חדשה שמאפשרת הנפשה של מאפיינים שרירותיים של כל (תצוגה, שרטוט, מקטע, אובייקט או כל דבר אחר) ולהגדיר היבטי אנימציה כמו כמו משך זמן, אינטרפולציה, חזרה ועוד. המסגרת החדשה יוצרת אנימציות ב-Android פשוט יותר מתמיד. לצפייה מפתח של אנימציה של נכס מותאמת אישית.
  • גרפיקה ומנוע מחשוב של RenderScript: RenderScript מציע תלת-ממד בעל ביצועים גבוהים. עיבוד גרפיקה ו-Compute API ברמת המקור, שאותם כותבים בתקן C99 (C99), מספק את רמת הביצועים שאתם מצפים לקבל מסביבה מקורית, תוך שמירה על ניידות בכמה מעבדי CPU ומעבדי GPU. לצפייה מפתח של RenderScript מותאמת אישית.
  • גרפיקה דו-ממדית עם האצת חומרה: כעת ניתן להפעיל את מעבד OpenGL עבור על ידי הגדרה של {android:hardwareAccelerated="true"} ב-<application> של רכיב המניפסט אלמנט או עבור יחיד <activity> רכיבים. התוצאה של התהליך הזה באנימציות חלקות יותר, גלילה חלקה יותר וביצועים טובים יותר באופן כללי ותגובה טובה יותר למשתמש אינטראקציה חוזרת.

    הערה: אם הגדרתם את minSdkVersion או targetSdkVersion באפליקציה שלכם בתור ב-"14" ומעלה, שיפור המהירות באמצעות חומרה מופעל כברירת מחדל.

  • ועוד הרבה יותר. מידע נוסף זמין בפלטפורמת Android 3.0 לקבלת מידע נוסף.
Android 3.1
  • ממשקי API של USB: ממשקי API חדשים ועוצמתיים לשילוב ציוד היקפי מחובר עם אפליקציות ל-Android. ממשקי ה-API מבוססים על מקבץ USB ושירותים שמובנית בפלטפורמה, כולל תמיכה באינטראקציות עם מארח USB וגם עם מכשיר. כדאי לעיין במדריך למפתחים של מארח ואביזרים בחיבור USB.
  • ממשקי API של MTP/PTP: אפליקציות יכולות לקיים אינטראקציה ישירות עם מצלמות מחוברות ו-PTP אחרים מכשירים שיקבלו התראות על מכשירים מצורפים ויוסרו, ניהול קבצים ואחסון ב- במכשירים האלה, ולהעביר אליהם קבצים ומטא-נתונים. ממשק ה-API של MTP מטמיע את ה-PTP (Picture Transfer Protocol) משנה את מפרט ה-MTP (פרוטוקול העברת מדיה). לצפייה מסמכי תיעוד בנושא android.mtp.
  • ממשקי API של RTP: Android חושפת API לסטאק ה-RTP המובנה (Real-time Transport Protocol), אפליקציות שיכולות להשתמש בהן כדי לנהל זרימת נתונים על פי דרישה או אינטראקטיבית. באופן ספציפי, אפליקציות שמספקים VOIP, תמיכה לדיבור, שיחות ועידה וסטרימינג של אודיו יכולים להשתמש ב-API כדי להפעיל ולשדר או לקבל מקורות נתונים בכל רשת זמינה. לעיון במסמכי התיעוד של android.net.rtp.
  • תמיכה בג'ויסטיקים ובקלטי תנועה כלליים אחרים.
  • מידע נוסף זמין בפלטפורמת Android 3.1 ועוד הרבה ממשקי API חדשים.
Android 3.2
  • מסכים חדשים תומכים בממשקי API שמעניקים לך שליטה רבה יותר על אופן הפעולה של האפליקציות יוצגו במסכים בגדלים שונים. ה-API מרחיב את מודל התמיכה במסך הקיים באמצעות יכולת לטרגט במדויק טווחי גדלים ספציפיים של מסכים לפי מימדים, שנמדדת יחידות פיקסלים שאינן תלויות בדחיסות (כגון 600dp או רוחב 720dp), במקום לפי יחידות גודלי מסכים (כגון גדול או xlarge). לדוגמה, השלב הזה חשוב כדי לעזור לך הבחינו בין 5 אינץ' ומכשיר בגודל 7 אינץ' שבדרך כלל מסווגת בתור 'large' מסכים. לעיון בפוסט בבלוג, כלים חדשים לניהול גדלים של מסכים.
  • קבועים חדשים עבור <uses-feature> ל- הצהרה על דרישות הכיוון של מסך לרוחב או לאורך.
  • גודל המסך של המכשיר ההגדרות האישיות משתנות עכשיו בזמן כיוון המסך שינוי. אם האפליקציה שלך מטרגטת רמת API 13 ומעלה, עליך לטפל ב"screenSize" של ההגדרה האישית אם ברצונך לטפל גם בשינוי ההגדרה של "orientation". צפייה לקבלת מידע נוסף, android:configChanges.
  • מידע נוסף זמין בפלטפורמת Android 3.2 הערות לגבי ממשקי API חדשים אחרים.

רמת API

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

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

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