ממשקי API של Android 4.2

רמת API: 17

Android 4.2 (JELLY_BEAN_MR1) הוא עדכון לגרסה של Jelly Bean שמציע תכונות חדשות למשתמשים ולאפליקציה למפתחים. במסמך הזה מתוארות המבוא ממשקי API חדשים ושימושיים למפתחים.

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

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

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

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

שינויים חשובים בהתנהגות

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

  • כברירת מחדל, לא מתבצע יותר ייצוא של ספקי תוכן. כלומר, ערך ברירת המחדל עבור המאפיין android:exported הוא עכשיו “false". אם חשוב שאפליקציות אחרות לגשת לספק התוכן, עכשיו צריך להגדיר במפורש את android:exported="true".

    השינוי הזה ייכנס לתוקף רק אם הערך של android:targetSdkVersion או של android:minSdkVersion הוא 17 ומעלה. אחרת, ערך ברירת המחדל הוא עדיין “true" גם אם המערכת פועלת ב-Android מגרסה 4.2 ואילך.

  • בהשוואה לגרסאות קודמות של Android, התוצאות של מיקום המשתמש עשויות להיות פחות מדויקות אם האפליקציה מבקשת את ההרשאה ACCESS_COARSE_LOCATION אבל לא מבקש את ההרשאה ACCESS_FINE_LOCATION.

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

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

    גם אם הערך של android:targetSdkVersion ושל android:minSdkVersion נמוך מ-17, האפליקציה שלך לא יכולה לשנות את ההגדרות עובר אל Settings.Global בהפעלה עם Android 4.2 ומעלה.

  • אם האפליקציה משתמשת ב-WebView, מערכת Android 4.2 מוסיפה שכבה נוספת של כדי שתוכל לקשר בין JavaScript בצורה בטוחה יותר קוד Android. אם מגדירים targetSdkVersion ל-17 ומעלה, צריך להוסיף עכשיו את ההערה @JavascriptInterface לכל method שרוצים רוצה להיות זמין ל-JavaScript (השיטה חייבת להיות גם מוגדרת כציבורית). אם לא תספקו את הערה, אין גישה לשיטה דרך דף אינטרנט בWebView בעת שימוש ב-Android מגרסה 4.2 ומעלה. אם מגדירים targetSdkVersion ל-16 ומטה, אין צורך בהערה, אבל מומלץ לעדכן את גרסת היעד. ולהוסיף את ההערה כדי לשפר את רמת האבטחה.

    מידע נוסף על קישור קוד JavaScript לקוד Android.

Daydream

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

אפשר ליצור חלום ל-Daydream על ידי הטמעת מחלקה של DreamService. ממשקי ה-API של DreamService נועדו להיות דומים לאלו של Activity. כדי לציין את ממשק המשתמש של לחלום, להעביר מזהה משאב פריסה או View ל-setContentView() בכל שלב חלון, למשל מתוך onAttachedToWindow() קריאה חוזרת.

המחלקה DreamService מספקת קריאה חוזרת (callback) חשובה נוספת במחזור החיים methods בנוסף לממשקי ה-API הבסיסיים Service, כמו onDreamingStarted(), onDreamingStopped() ו-onDetachedFromWindow(). לא ניתן להפעיל DreamService דרך אפליקציה – הוא מופעל באופן אוטומטי על ידי המערכת.

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

כדי להפעיל את החלום בהקיץ כזמין למערכת, צריך להצהיר על DreamService עם רכיב <service> בקובץ המניפסט. לאחר מכן צריך לכלול מסנן Intent עם הפעולה "android.service.dreams.DreamService". לדוגמה:

<service android:name=".MyDream" android:exported="true"
    android:icon="@drawable/dream_icon" android:label="@string/dream_label" >
    <intent-filter>
        <action android:name="android.service.dreams.DreamService" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</service>

יש עוד כמה שיטות שימושיות ב-DreamService חשוב לשים לב:

  • המדיניות setInteractive(boolean) קובעת אם החלום מקבל אירועי קלט או יוצא ממנו מיד לאחר קלט של משתמש. אם החלום אינטראקטיבית, המשתמש יכול להשתמש בלחצנים הקודם או דף הבית כדי לצאת מהחלום. לחלופין, אתם יכולים להתקשר finish() כדי לעצור את החלום.
  • אם אתם רוצים תצוגה היקפית מלאה, אפשר להפעיל את setFullscreen() כדי להסתיר את שורת הסטטוס.
  • לפני הפעלת 'חלום בהקיץ', המסך מעומעם כדי לאותת למשתמש שהזמן הקצוב לתפוגה של חוסר פעילות מתקרבת. כשמפעילים את התכונה setScreenBright(true), אפשר להגדיר את המסך בבהירות הרגילה שלו.

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

מסכים משניים

עכשיו מערכת Android מאפשרת לאפליקציה להציג תוכן ייחודי במסכים נוספים שמחוברים למכשיר של המשתמש באמצעות חיבור קווי או Wi-Fi. כדי ליצור תוכן ייחודי למסך משני, צריך להרחיב את Presentation ולהטמיע את הקריאה החוזרת (callback) של onCreate(). בטווח של onCreate(), הגדרת ממשק המשתמש למסך המשני באמצעות הטלפון setContentView(). כהרחבה של הכיתה Dialog, הכיתה Presentation מספקת את האזור שבו האפליקציה יכולה להציג ממשק משתמש ייחודי מסך משני.

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

כדי לקבל את תצוגת ברירת המחדל של המצגת, צריך להתקשר למספר MediaRouter.getSelectedRoute() ולהעביר אותה ROUTE_TYPE_LIVE_VIDEO. הפעולה הזו מחזירה אובייקט MediaRouter.RouteInfo שמתאר את המסלול הנוכחי של המערכת למצגות וידאו. אם הערך MediaRouter.RouteInfo אינו null, יש להפעיל את הפונקציה getPresentationDisplay() כדי לקבל את הערך Display שמייצג את המסך המחובר.

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

כדי לזהות בזמן הריצה חיבור של מסך חדש, צריך ליצור מופע של MediaRouter.SimpleCallback שבו מיישמים את שיטת הקריאה החוזרת (callback) של onRoutePresentationDisplayChanged(), שאליה המערכת תקרא בפעם הבאה המסך של המצגת מחובר. לאחר מכן רושמים את MediaRouter.SimpleCallback על ידי העברתו אל MediaRouter.addCallback() יחד עם סוג המסלול ROUTE_TYPE_LIVE_VIDEO. כשמקבלים שיחה אל onRoutePresentationDisplayChanged(), פשוט קוראים אל MediaRouter.getSelectedRoute() כפי שצוין למעלה.

כדי לבצע אופטימיזציה נוספת של ממשק המשתמש ב-Presentation במסכים משניים, ניתן להחיל נושא אחר באמצעות ציון המאפיין android:presentationTheme ב<style> שהוחלה על האפליקציה או על הפעילות שלכם.

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

למידע נוסף ולכמה דוגמאות קוד, ראו Presentation את המסמכים הכיתתיים שלנו.

ווידג'טים למסך הנעילה

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

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    ...
    android:widgetCategory="keyguard|home_screen">
</appwidget-provider>

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

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

משתמשים מרובים

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

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

שמירת נתונים בסביבה מרובת משתמשים

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

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

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

זיהוי משתמשים בסביבה מרובת משתמשים

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

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

הגדרות גלובליות חדשות

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

חלק מההגדרות הקיימות הועברו לכאן מSettings.System או Settings.Secure. אם האפליקציה מבצעות כרגע שינויים בהגדרות שהוגדרו קודם לכן באפליקציה Settings.System (כמו AIRPLANE_MODE_ON), עליך לצפות פעולה זו לא תפעל עוד במכשיר שבו פועלת מערכת Android 4.2 ומעלה אם הגדרות אלה הועברה אל Settings.Global. אפשר להמשיך לקרוא את ההגדרות שנמצאות Settings.Global, אבל כי ההגדרות כבר לא נחשבות בטוחות אם אפליקציות ישתנו, הניסיון לעשות זאת ייכשל באופן שקט והמערכת תכתוב אזהרה יומן המערכת בעת הפעלת האפליקציה ב-Android 4.2 ומעלה.

תמיכה בפריסה RTL

ב-Android יש עכשיו מספר ממשקי API שמאפשרים לכם לבנות ממשקי משתמש לשנות את כיוון הפריסה לתמיכה בשפות המשתמשות בממשקי משתמש מימין לשמאל (RTL) ובקריאה למשל ערבית ועברית.

כדי להתחיל לתמוך בפריסות RTL באפליקציה, צריך להגדיר את המאפיין android:supportsRtl לרכיב <application> בקובץ המניפסט ומגדירים אותה לערך “true". לאחר הפעלת האפשרות הזו, המערכת תפעיל ממשקי API שונים מסוג RTL כדי הצגת האפליקציה בפריסות RTL. למשל, בסרגל הפעולות יופיעו הסמל והכותרת שבצד ימין ולחצני הפעולה שבצד ימין, וכל הפריסות שיצרת עם גם View מחלקות שסופקו על ידי framework יבוטלו.

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

  1. המרת מאפייני פריסה לכיוון שמאל וימינה לפריסה ממוקדת-התחלה וסוף נכסים.

    לדוגמה, אפשר להשתמש ב-android:layout_marginStart במקום android:layout_marginLeft ו-android:layout_marginEnd במקום android:layout_marginRight.

    המחלקה RelativeLayout מספקת גם את הפריסה המתאימה שמחליפים מיקומים משמאל/ימין, כמו android:layout_alignParentStart עד מחליפים את android:layout_alignParentLeft ואת android:layout_toStartOf במקום android:layout_toLeftOf

  2. לחלופין, כדי לספק אופטימיזציה מלאה לפריסות בפורמט RTL, אפשר להוסיף פריסת קבצים באמצעות תוחם המשאבים ldrtl (ldrtl מייצג format-direction-right-to-left}). לדוגמה, ניתן לשמור את קובצי פריסת ברירת המחדל ב res/layout/ והפריסות שעברו אופטימיזציה מימין ל-RTL ב-res/layout-ldrtl/.

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

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

הערה: אם משתמשים ב-SQlite ויש לכם שמות של טבלאות או עמודות "number only", להיות זהירות: השימוש ב-String.format(String, Object...) עלול להוביל לשגיאות שבהן המספרים הומרו לשפות המקבילות בערבית אם המכשיר שלכם הוגדר לשפה הערבית. צריך להשתמש בפונקציה String.format(Locale,String,Object...) כדי לוודא שהמספרים נשמר כ-ASCII. יש להשתמש גם ב-String.format("%d", int) במקום String.valueOf(int) למשך עיצוב מספרים.

מקטעים מקוננים

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

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

Kotlin

val videoFragment = VideoPlayerFragment()
childFragmentManager.beginTransaction().apply {
    add(R.id.video_fragment, videoFragment)
    commit()
}

Java

Fragment videoFragment = new VideoPlayerFragment();
FragmentTransaction transaction = getChildFragmentManager().beginTransaction();
transaction.add(R.id.video_fragment, videoFragment).commit();

מתוך מקטע מקונן, ניתן לקבל הפניה למקטע ההורה על ידי קריאה getParentFragment()

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

הערה: לא ניתן להגדיל פריסה למקטע כאשר הפריסה הזו שכולל <fragment>. מקטעים מקוננים נתמכים רק כאשר מוסיפים אותם ל פרגמנטציה באופן דינמי.

רינדור

פונקציונליות המחשוב של Renderscript שופרה וכוללת את התכונות הבאות:

מאפייני סקריפט

אפשר להשתמש ברכיבי הסקריפט המובְנים של Renderscript שמטמיעים פעולות נפוצות שאפשר לבצע, כמו:

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

קבוצות סקריפטים

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

כדי להוסיף את כל הסקריפטים לקבוצה צריך להשתמש ב-ScriptGroup.Builder באמצעות הטלפון addKernel(). אחרי ש להוסיף את כל הסקריפטים, ליצור את החיבורים בין סקריפטים באמצעות קריאה ל-addConnection(). כדי לסיים את הוספת החיבורים, צריך להתקשר אל create() כדי ליצור את קבוצת הסקריפטים. לפני הרצת קבוצת הסקריפטים, יש לציין את הקלט Allocation והסקריפט הראשוני שיש להריץ עם setInput(Script.KernelID, Allocation) עם הפלט Allocation שבו התוצאה תיכתב והתסריט הסופי אל הפעלה עם setOutput(). לסיום, התקשרו execute() כדי להריץ את קבוצת הסקריפטים.

Filterscript

Filterscript מגדיר אילוצים בממשקי ה-API הקיימים של Renderscript, שמאפשרים לקוד שנוצר לרוץ במגוון רחב יותר של מעבדים (מעבדים, מעבדי GPU ומעבדי DSP). כדי ליצור קובצי Filterscript, צריך ליצור .fs קבצים במקום .rs קבצים, ולציין #pragma rs_fp_relaxed ל- אומרים לזמן הריצה של Renderscript שהסקריפטים לא זקוקים לדיוק IEEE 754-2008 של נקודה צפה (floating-point). הדיוק הזה מאפשר סיבוב לריק של דנורמים וסיבוב כלפי אפס. בנוסף, Filterscript סקריפטים אינם יכולים להשתמש בסוגים מובנים של 32 סיביות, ועליהם לציין פונקציית שורש מותאמת אישית באמצעות __attribute__((kernel)) מפני ש-Filterscript לא תומך בסמנים, חתימת ברירת המחדל של הפונקציה root().

הערה: למרות שהתמיכה ב-Filterscript נמצאת בפלטפורמה, המפתחים התמיכה תהיה זמינה בכלי SDK בגרסה 21.0.1.

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