ממשקי 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 לכל שיטה שרוצים שתהיה זמינה ב-JavaScript (השיטה צריכה להיות גם 'גלויה לכולם'). אם לא תספקו את הערה, אין גישה לשיטה דרך דף אינטרנט בWebView בעת שימוש ב-Android מגרסה 4.2 ומעלה. אם מגדירים את הערך של targetSdkVersion ל-16 או פחות, אין צורך בהערה, אבל מומלץ לעדכן את גרסת היעד ולהוסיף את ההערה כדי לשפר את האבטחה.

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

Daydream

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

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

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

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

כדי שהמערכת תוכל לגשת ל-Daydream, צריך להצהיר על 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, משתמשים בממשקי ה-API DisplayManager או MediaRouter. ממשקי ה-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.

חשוב לזכור שאם האפליקציה מבקשת אחד ממזהי החומרה של המכשיר (כמו כתובת ה-MAC של ה-Wi-Fi או המספר 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 שסופקו על ידי המסגרת יהיו הפוכות.

אם אתם צריכים לבצע אופטימיזציה נוספת למראה האפליקציה כשהיא מוצגת בפריסת 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 מייצג את layout-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 של כל סקריפט מובנה, כדי להגדיר את האפשרויות והקלט הנדרשים. לבסוף, קוראים ל-method‏ 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. הדיוק הזה מאפשר סיבוב לריק של דנורמים וסיבוב כלפי אפס. בנוסף, אסור להשתמש בסקריפטים של Filterscript בסוגי נתונים מובנים של 32 ביט, וחייבים לציין פונקציית root בהתאמה אישית באמצעות המאפיין __attribute__((kernel)), כי Filterscript לא תומך ב-pointers (מצביעים), שהחתימה שמוגדרת כברירת מחדל של הפונקציה root() מגדירה.

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

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