השימוש במילים 'חובה', 'אסור', 'נדרש', 'חייב', 'אסור', 'צריך', 'לא צריך', 'מומלץ', 'יכול' ו'אופציונלי' הוא בהתאם לתקן IETF שמוגדר ב-RFC2119 [מקורות מידע, 1].

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

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

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

לכן, פרויקט הקוד הפתוח של Android‏ [מקורות, 3] הוא גם ההטמעה המועדפת וגם ההטמעה לדוגמה של Android. אנחנו ממליצים מאוד למטמיעים של מכשירים לבסס את ההטמעות שלהם, ככל האפשר, על קוד המקור 'במעלה הזרם' שזמין בפרויקט Android Open Source Project. באופן תיאורטי, אפשר להחליף חלק מהרכיבים בהטמעות חלופיות, אבל לא מומלץ לעשות זאת כי יהיה קשה יותר לעבור את בדיקות התוכנה. באחריות המטמיע לוודא תאימות התנהגות מלאה להטמעה הרגילה של Android, כולל חבילה לבדיקות תאימות (CTS) ומעבר לה. לסיום, חשוב לזכור שהמסמך הזה אוסר במפורש על החלפות ושינוי של רכיבים מסוימים.

2. משאבים

רמות הדרישה של IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

סקירה כללית על תוכנית התאימות של Android: http://source.android.com/docs/compatibility/index.html

פרויקט קוד פתוח של Android: http://source.android.com/

הגדרות ומסמכי תיעוד של ממשקי API: http://developer.android.com/reference/packages.html

מידע על הרשאות ב-Android: http://developer.android.com/reference/android/Manifest.permission.html

מסמך העזרה של android.os.Build: http://developer.android.com/reference/android/os/Build.html

מחרוזות הגרסאות המותרות של Android 4.3: http://source.android.com/docs/compatibility/4.3/versions.html

Renderscript: ‏ http://developer.android.com/guide/topics/graphics/renderscript.html

שיפור המהירות באמצעות חומרה: http://developer.android.com/guide/topics/graphics/hardware-accel.html

הכיתה android.webkit.WebView: ‏ http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

יכולות אופליין של HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

תג וידאו ב-HTML5: http://dev.w3.org/html5/spec/Overview.html#video

Geolocation API של HTML5/W3C: http://www.w3.org/TR/geolocation-API/

HTML5/W3C webdatabase API: ‏ http://www.w3.org/TR/webdatabase/

HTML5/W3C IndexedDB API: ‏ http://www.w3.org/TR/IndexedDB/

מפרט המכונה הווירטואלית של Dalvik: זמין בקוד המקור של Android, בכתובת dalvik/docs

AppWidgets: ‏ http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

התראות: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

משאבי אפליקציה: http://code.google.com/android/reference/available-resources.html

מדריך הסגנון של סמלי שורת הסטטוס: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

מנהל החיפוש: http://developer.android.com/reference/android/app/SearchManager.html

הודעות Toast: http://developer.android.com/reference/android/widget/Toast.html

עיצובים: http://developer.android.com/guide/topics/ui/themes.html

הכיתה R.style: ‏ http://developer.android.com/reference/android/R.style.html

טפטים מונפשים: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

ניהול מכשירי Android: http://developer.android.com/guide/topics/admin/device-admin.html

מסמך העזרה של DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

ממשקי API של שירות הנגישות של Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

ממשקי API לנגישות ב-Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

פרויקט Eyes Free: http://code.google.com/p/eyes-free

ממשקי API להמרת טקסט לדיבור: http://developer.android.com/reference/android/speech/tts/package-summary.html

מסמכי עזרה של כלים (ל-adb,‏ aapt,‏ ddms ו-systrace): http://developer.android.com/guide/developing/tools/index.html

תיאור של קובץ APK ל-Android: http://developer.android.com/guide/topics/fundamentals.html

קובצי מניפסט: http://developer.android.com/guide/topics/manifest/manifest-intro.html

כלי הבדיקה Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey

הכיתה android.content.pm.PackageManager של Android ורשימת תכונות החומרה: http://developer.android.com/reference/android/content/pm/PackageManager.html

תמיכה במספר מסכים: http://developer.android.com/guide/practices/screens_support.html

android.util.DisplayMetrics: ‏ http://developer.android.com/reference/android/util/DisplayMetrics.html

android.content.res.Configuration: ‏ http://developer.android.com/reference/android/content/res/Configuration.html

android.hardware.SensorEvent: ‏ http://developer.android.com/reference/android/hardware/SensorEvent.html

Bluetooth API: ‏ http://developer.android.com/reference/android/bluetooth/package-summary.html

פרוטוקול דחיפה של NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X: ‏ http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: ‏ http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: ‏ http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: ‏ http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: ‏ http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: ‏ http://www.nxp.com/documents/application_note/AN130411.pdf

Camera orientation API: ‏ http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

מצלמה: http://developer.android.com/reference/android/hardware/Camera.html

Android Open Accessories: ‏ http://developer.android.com/guide/topics/usb/accessory.html

USB Host API: ‏ http://developer.android.com/guide/topics/usb/host.html

מידע על אבטחה והרשאות ב-Android: http://developer.android.com/guide/topics/security/security.html

אפליקציות ל-Android: http://code.google.com/p/apps-for-android

Android DownloadManager: ‏ http://developer.android.com/reference/android/app/DownloadManager.html

העברת קבצים ב-Android: ‏ http://www.android.com/filetransfer

פורמטים של מדיה ב-Android: http://developer.android.com/guide/appendix/media-formats.html

טיוטת פרוטוקול של HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

העברת חיבור ב-NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover

התאמה פשוטה ומאובטחת של Bluetooth באמצעות NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

Wifi Multicast API: ‏ http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

Action Assist: ‏ http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

מפרט הטעינה של USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

Android Beam: ‏ http://developer.android.com/guide/topics/nfc/nfc.html

אודיו ב-USB ל-Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

הגדרות שיתוף NFC ב-Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wifi Direct‏ (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

ווידג'ט למסך הנעילה ולמסך הבית: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

מסמך העזרה של UserManager: http://developer.android.com/reference/android/os/UserManager.html

מידע על אחסון חיצוני: https://source.android.com/docs/core/storage

ממשקי API של אחסון חיצוני: http://developer.android.com/reference/android/os/Environment.html

קוד SMS קצר: http://en.wikipedia.org/wiki/Short_code

לקוח של שלט רחוק למדיה: http://developer.android.com/reference/android/media/RemoteControlClient.html

מנהל התצוגה: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

Dreams: ‏ http://developer.android.com/reference/android/service/dreams/DreamService.html

הגדרות שקשורות לפיתוח אפליקציות ל-Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

מצלמה: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

תוסף EGL‏ – EGL_ANDROID_RECORDABLE: ‏ http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

Motion Event API: ‏ http://developer.android.com/reference/android/view/MotionEvent.html

הגדרת קלט מגע: http://source.android.com/docs/core/interaction/input/touch-devices.html

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

3. תוכנות

3.1. תאימות של ממשקי API מנוהלים

סביבת הביצוע המנוהלת (מבוססת Dalvik) היא אמצעי ההעברה העיקרי של אפליקציות Android. ממשק תכנות האפליקציות (API) של Android הוא קבוצת הממשקים של פלטפורמת Android שנחשפים לאפליקציות שפועלות בסביבת ה-VM המנוהלת. הטמעות במכשירים חייבות לספק הטמעות מלאות, כולל כל ההתנהגויות המתועדות, של כל ממשק API מתועד שנחשף על ידי Android 4.3 SDK‏ [מקורות מידע, 4].

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

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

3.2. תאימות ל-Soft API

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

3.2.1. הרשאות

מי שמטמיע את המכשיר חייב לתמוך בכל קבועי ההרשאות ולאכוף אותם, כפי שמתואר בדף העזרה בנושא הרשאות [משאבים, 5]. לתשומת ליבכם: בקטע 9 מפורטות דרישות נוספות שקשורות למודל האבטחה של Android.

3.2.2. פרמטרים של build

ממשקי ה-API של Android כוללים מספר קבועים בכיתה android.os.Build‏ [Resources, 6] שנועדו לתאר את המכשיר הנוכחי. כדי לספק ערכים עקביים ומשמעותיים בכל הטמעות המכשירים, בטבלה הבאה מפורטות הגבלות נוספות על הפורמטים של הערכים האלה, שאליהם הטמעות המכשירים חייבות לעמוד.

פרמטר	תגובות
android.os.Build.VERSION.RELEASE	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שמוגדרים בקטע [Resources, 7].
android.os.Build.VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שקוד של אפליקציות של צד שלישי יכול לגשת אליו. בגרסה 4.3 של Android, השדה הזה חייב לכלול את הערך השלם 18.
android.os.Build.VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שקוד של אפליקציות של צד שלישי יכול לגשת אליו. בגרסה 4.3 של Android, השדה הזה חייב לכלול את הערך השלם 18.
android.os.Build.VERSION.INCREMENTAL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את ה-build הספציפי של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש שוב בערך הזה לגרסאות build שונות שזמינות למשתמשי הקצה. שימוש נפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת בקרת הגרסאות ששימשו ליצירת ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.BOARD	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.BRAND	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את שם החברה, הארגון, האדם וכו' שייצרו את המכשיר, בפורמט שאפשר לקרוא על ידי בני אדם. אפשר להשתמש בשדה הזה כדי לציין את יצרן הציוד המקורי ו/או את הספק שמוכר את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.CPU_ABI	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3: תאימות ל-API מקורי
android.os.Build.CPU_ABI2	השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3: תאימות ל-API מקורי
android.os.Build.DEVICE	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את ההגדרה הספציפית או את הגרסה של המארז (שנקרא לפעמים 'עיצוב תעשייתי') של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, ולהתאים לביטוי הרגולרי `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.FINGERPRINT	מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות קריא למדי לאדם. הוא חייב לפעול לפי התבנית הבאה: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` לדוגמה: `acme/mydevice/generic:4.3/JRN53/3359:userdebug/test-keys` אסור לטביעת האצבע לכלול תווים של רווח לבן. אם יש תווים של רווח לבן בשדות אחרים שכלולים בתבנית שלמעלה, חובה להחליף אותם באצבע המזהה של ה-build בתווית אחרת, כמו קו תחתון (‎'_'). הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט.
android.os.Build.HARDWARE	שם החומרה (משורת הפקודה של הליבה או מ-/proc). הוא אמור להיות קריא לאנשים באופן סביר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, ולהתאים לביטוי הרגולרי `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.HOST	מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט שאפשר לקרוא אותו. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.ID	מזהה שנבחר על ידי מי שמטמיע את המכשיר כדי להפנות למהדורה ספציפית, בפורמט קריא לבני אדם. השדה הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל כדאי להגדיר בו ערך משמעותי מספיק כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות build של תוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.MANUFACTURER	השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.MODEL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה אמור להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי קצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה ("").
android.os.Build.PRODUCT	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המוצר (מק"ט). חובה שיהיו קריאים לבני אדם, אבל הם לא מיועדים בהכרח לצפייה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.SERIAL	מספר סידורי של חומרה, אם יש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `"^([a-zA-Z0-9]{0,20})$"`.
android.os.Build.TAGS	רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, שמבדילה עוד יותר את ה-build. לדוגמה, ‎"unsigned,debug"‎. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.TIME	ערך שמייצג את חותמת הזמן של מועד ה-build.
android.os.Build.TYPE	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את הגדרת סביבת זמן הריצה של ה-build. השדה הזה צריך לכלול אחד מהערכים שתואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן הריצה: 'user',‏ 'userdebug' או 'eng'. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.USER	שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").

3.2.3. תאימות לכוונה

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

3.2.3.1. כוונות ליבה של אפליקציות

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

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

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

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

אפליקציות הליבה של מערכת Android כוללות רכיבי Activity או Service שונים שנחשבים 'ציבוריים'. כלומר, המאפיין "android:exported" יכול להיות חסר או שיהיה לו הערך "true".

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

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

3.2.3.2. שינויים מברירת המחדל של Intent

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

עם זאת, הטמעות במכשירים עשויות לספק פעילויות ברירת מחדל לתבניות URI ספציפיות (למשל http://play.google.com) אם פעילות ברירת המחדל מספקת מסנן ספציפי יותר ל-URI של הנתונים. לדוגמה, מסנן Intent שמציין את ה-URI של הנתונים 'http://www.android.com' הוא ספציפי יותר מהמסנן בדפדפן עבור 'http://'. הטמעות במכשירים חייבות לספק ממשק משתמש שמאפשר למשתמשים לשנות את פעילות ברירת המחדל של הכוונות.

3.2.3.3. מרחבי שמות של כוונות

הטמעות במכשירים אסור לכלול רכיב Android שמתייחס לדפוסים חדשים של Intent או של Broadcast Intent באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב השמות android.* או com.android.*. אסור למטמיעים של מכשירים לכלול רכיבי Android שמכבדים דפוסים חדשים של Intent או של Broadcast Intent באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב החבילה ששייך לארגון אחר. מחברי מכשירי ה-Intent חייבים לא לשנות או להרחיב אף אחד מהדפוסים של ה-Intent שבהם משתמשות האפליקציות הליבה שמפורטות בקטע 3.2.3.1. הטמעות במכשירים יכולות לכלול דפוסי Intent שמשתמשים במרחבי שמות שמשויכים באופן ברור לארגון שלהם.

האיסור הזה דומה לאיסור שצוין לגבי כיתות של שפת Java בקטע 3.6.

3.2.3.4. כוונות לשידור

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

3.3. תאימות ל-API מקורי

3.3.1 ממשקי Application Binary

קוד מנוהל שפועל ב-Dalvik יכול להפעיל קוד מקומי שסופק בקובץ ה-APK של האפליקציה כקובץ ELF עם סיומת ‎.so שעבר הידור לארכיטקטורת החומרה המתאימה של המכשיר. מאחר שקוד Native תלוי מאוד בטכנולוגיית המעבד הבסיסית, מערכת Android מגדירה מספר ממשקי Application Binary Interface ‏ (ABI) ב-Android NDK, בקובץ docs/CPU-ARCH-ABIS.html. אם הטמעה של מכשיר תואמת ל-ABI אחד או יותר שהוגדרו, צריך להטמיע תאימות ל-Android NDK, כפי שמתואר בהמשך.

אם הטמעה של מכשיר כוללת תמיכה ב-ABI של Android, היא:

חובה לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לבצע קריאה לקוד מקומי, באמצעות סמנטיקה רגילה של Java Native Interface‏ (JNI)
חייבת להיות תואמת למקור (כלומר תואמת לכותרת) ותואמת לבינארי (ל-ABI) לכל ספרייה נדרשת ברשימה שבהמשך
חובה לדווח במדויק על ממשק ה-Application Binary Interface (ABI) המקורי שנתמך במכשיר, דרך ה-API‏ android.os.Build.CPU_ABI
חובה לדווח רק על ABIs שמתועדים בגרסה האחרונה של Android NDK, בקובץ docs/CPU-ARCH-ABIS.txt
צריך לבנות אותו באמצעות קוד המקור וקובצי הכותרת שזמינים ב-Android Open Source Project

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

libc (ספריית C)
libm (ספריית מתמטיקה)
תמיכה מינימלית ב-C++‎
ממשק JNI
liblog (רישום ביומן ב-Android)
libz (דחיסת Zlib)
libdl (מקשר דינמי)
libGLESv1_CM.so‏ (OpenGL ES 1.0)
libGLESv2.so‏ (OpenGL ES 2.0)
libGLESv3.so‏ (OpenGL ES 3.0)
libEGL.so‏ (ניהול פלטפורמה מקורי של OpenGL)
libjnigraphics.so
libOpenSLES.so (תמיכה באודיו של OpenSL ES 1.0.1)
libOpenMAXAL.so (תמיכה ב-OpenMAX AL 1.0.1)
libandroid.so (תמיכה בפעילות Native ב-Android)
תמיכה ב-OpenGL, כפי שמתואר בהמשך

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

הערה: הטמעות במכשירים חייבות לכלול את libGLESv3.so, והן חייבות לקשר אותה ל-libGLESv2.so באמצעות קישור סימלי. בהטמעות במכשירים שמצהירות על תמיכה ב-OpenGL ES 3.0, libGLESv2.so חייבת לייצא את סמלי הפונקציות של OpenGL ES 3.0 בנוסף לסמלי הפונקציות של OpenGL ES 2.0.

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

3.4. תאימות לאינטרנט

3.4.1. תאימות ל-WebView

בהטמעה של Android Open Source נעשה שימוש במנוע הרינדור של WebKit כדי להטמיע את android.webkit.WebView [Resources, 10] . מכיוון שלא ניתן לפתח חבילת בדיקות מקיפה למערכת עיבוד גרפיקה באינטרנט, מחברי מכשירים חייבים להשתמש ב-build הספציפי של WebKit ב-upstream בהטמעת WebView. פרטים נוספים:

הטמעות android.webkit.WebView של מכשירים חייבות להתבסס על גרסה 534.30 של WebKit מהעץ של Android Open Source ב-upstream עבור Android 4.3. הגרסה הזו כוללת קבוצה ספציפית של תיקוני אבטחה ופונקציות ל-WebView. מפתחי המכשירים יכולים לכלול התאמות אישיות בהטמעת WebKit. עם זאת, ההתאמות האישיות האלה אסור שישנו את ההתנהגות של WebView, כולל התנהגות הרינדור.
מחרוזת סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הזה:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
- הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של android.os.Build.VERSION.RELEASE
- הערך של המחרוזת $(LOCALE) צריך לפעול לפי מוסכמות ISO לגבי קוד המדינה והשפה, וצריך להתייחס לאזור הגיאוגרפי הנוכחי שהוגדר במכשיר
- הערך של המחרוזת $(MODEL) חייב להיות זהה לערך של android.os.Build.MODEL
- הערך של המחרוזת $(BUILD) חייב להיות זהה לערך של android.os.Build.ID
- הטמעות של מכשירים יכולות להשמיט את Mobile במחרוזת של סוכן המשתמש

רכיב WebView צריך לכלול תמיכה בחלקים רבים ככל האפשר ב-HTML5 [מקורות מידע, 11]. לכל הפחות, הטמעות במכשירים חייבות לתמוך בכל ממשקי ה-API האלה שמשויכים ל-HTML5 ב-WebView:

מטמון של אפליקציה/פעולה אופליין [משאבים, 12]
התג <video> [משאבים, 13]
מיקום גיאוגרפי [מקורות מידע, 14]

בנוסף, הטמעות במכשירים חייבות לתמוך ב-API של אחסון הנתונים באינטרנט ב-HTML5/W3C‏ [מקורות מידע, 15], ורצוי שתתמוך ב-API של IndexedDB ב-HTML5/W3C‏ [מקורות מידע, 16]. שימו לב: גופי התקנים לפיתוח אתרים עוברים להשתמש ב-IndexedDB במקום ב-webstorage, ולכן IndexedDB צפוי להפוך לרכיב נדרש בגרסה עתידית של Android.

ממשקי API של HTML5, כמו כל ממשקי ה-API של JavaScript, חייבים להיות מושבתים כברירת מחדל ב-WebView, אלא אם המפתח מפעיל אותם במפורש באמצעות ממשקי ה-API הרגילים של Android.

3.4.2. תאימות לדפדפנים

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

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

אפליקציית הדפדפן הנפרדת (בין שהיא מבוססת על אפליקציית הדפדפן של WebKit במקור ובין שהיא החלפה של צד שלישי) אמורה לכלול תמיכה בחלקים רבים ככל האפשר ב-HTML5 [מקורות מידע, 11]. לכל הפחות, הטמעות במכשירים חייבות לתמוך בכל ממשקי ה-API האלה שמשויכים ל-HTML5:

מטמון של אפליקציה/פעולה אופליין [משאבים, 12]
התג <video> [משאבים, 13]
מיקום גיאוגרפי [מקורות מידע, 14]

3.5. תאימות התנהגותית של API

ההתנהגויות של כל אחד מסוגי ה-API (מנוהל, רך, מקורי ואינטרנט) חייבות להיות עקביות עם ההטמעה המועדפת של פרויקט Android Open Source ב-upstream‏ [מקורות מידע, 3]. תחומים ספציפיים של תאימות:

אסור למכשירים לשנות את ההתנהגות או הסמנטיקה של כוונה רגילה
אסור למכשירים לשנות את מחזור החיים או את סמנטיקה של מחזור החיים של סוג מסוים של רכיב מערכת (כמו Service,‏ Activity,‏ ContentProvider וכו').
אסור למכשירים לשנות את הסמנטיקה של הרשאה רגילה

הרשימה שלמעלה היא חלקית. חבילה לבדיקות תאימות (CTS) היא חבילה של בדיקות שמטרתן לבדוק את התאימות ההתנהגותית של חלקים משמעותיים בפלטפורמה, אבל לא את כולם. באחריות המטמיע לוודא תאימות התנהגותית לפרויקט Android Open Source. לכן, כשהדבר אפשרי, מפתחי מכשירים צריכים להשתמש בקוד המקור שזמין דרך Android Open Source Project, במקום להטמיע מחדש חלקים משמעותיים במערכת.

3.6. מרחבי שמות של ממשקי API

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

java.*
javax.*
sun.‎*
android.*‎
com.android.*

שינויים אסורים כוללים:

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

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

למטמיעים של מכשירים מותר להוסיף ממשקי API בהתאמה אישית, אבל אסור שממשקי ה-API האלה יהיו במרחב שמות שנמצא בבעלות של ארגון אחר או מפנה לארגון אחר. לדוגמה, אסור למטמיעים של מכשירים להוסיף ממשקי API למרחב השמות com.google.* או למרחב שמות דומה. רק Google רשאית לעשות זאת. באופן דומה, אסור ל-Google להוסיף ממשקי API למרחבי שמות של חברות אחרות. בנוסף, אם הטמעה של מכשיר כוללת ממשקי API מותאמים אישית מחוץ למרחב השמות הרגיל של Android, חובה לארוז את ממשקי ה-API האלה בספרייה משותפת של Android, כך שרק אפליקציות שמשתמשות בהם באופן מפורש (באמצעות המנגנון <uses-library>) יושפעו מהשימוש המוגבר בזיכרון של ממשקי ה-API האלה.

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

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

3.7. תאימות למכונות וירטואליות

הטמעות במכשירים חייבות לתמוך במפרט המלא של קוד באייטים של Dalvik Executable‏ (DEX) ובסמנטיקה של מכונה וירטואלית של Dalvik‏ [משאבים, 17].

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

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

גודל המסך	צפיפות המסך	זיכרון האפליקציה
קטן / רגיל / גדול	ldpi / mdpi	16MB
קטן / רגיל / גדול	tvdpi / hdpi	32MB
קטן / רגיל / גדול	xhdpi	64MB
xlarge	mdpi	32MB
xlarge	tvdpi / hdpi	64MB
xlarge	xhdpi	128MB

3.8. תאימות של ממשק המשתמש

3.8.1. מרכז האפליקציות (מסך הבית)

מערכת Android 4.3 כוללת אפליקציית מרכז אפליקציות (מסך הבית) ותמיכה באפליקציות של צד שלישי שיכולות להחליף את מרכז האפליקציות (מסך הבית) של המכשיר. הטמעות במכשירים שמאפשרות לאפליקציות של צד שלישי להחליף את מסך הבית של המכשיר חייבות להצהיר על תכונת הפלטפורמה android.software.home_screen.

3.8.2. ווידג'טים

ב-Android מוגדר סוג רכיב, API ומחזור חיים תואמים שמאפשרים לאפליקציות לחשוף 'AppWidget' למשתמש הקצה [משאבים, 18]. הטמעות במכשירים שתומכות בהטמעת ווידג'טים במסך הבית חייבות לעמוד בדרישות הבאות ולהצהיר על תמיכה בתכונה android.software.app_widgets בפלטפורמה.

מרכזי האפליקציות במכשירים חייבים לכלול תמיכה מובנית ב-AppWidget, ולהציג למשתמש אפשרויות בממשק המשתמש להוספה, להגדרה, להצגה ולהסרה של AppWidget ישירות מתוך מרכז האפליקציות.
הטמעות במכשירים חייבות להיות מסוגלות ליצור עיבוד (רנדור) של ווידג'טים בגודל 4 על 4 בתצוגת רשת רגילה. (פרטים נוספים זמינים בהנחיות לעיצוב של ווידג'טים של אפליקציות במסמכי העזרה של Android SDK‏ [משאבים, 18].
הטמעות של מכשירים שכוללות תמיכה במסך הנעילה חייבות לתמוך בווידג'טים של אפליקציות במסך הנעילה.

3.8.3. התראות

מערכת Android כוללת ממשקי API שמאפשרים למפתחים להודיע למשתמשים על אירועים משמעותיים [מקורות מידע, 19] באמצעות תכונות החומרה והתוכנה של המכשיר.

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

בנוסף, ההטמעה חייבת להציג בצורה נכונה את כל המשאבים (סמלים, קובצי אודיו וכו') שסופקו ב-API‏ [מקורות מידע, 20] או במדריך הסגנון של סמלי סטטוס/סרגל המערכת [מקורות מידע, 21]. מפתחי מכשירים יכולים לספק חוויית משתמש חלופית להתראות, ששונה מזו שסופקת בהטמעת העזר של Android בקוד פתוח. עם זאת, מערכות התראות חלופיות כאלה חייבות לתמוך במשאבי התראות קיימים, כפי שמתואר למעלה.

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

3.8.4. חיפוש

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

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

3.8.5. הודעות קופצות

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

3.8.6. עיצובים

מערכת Android מספקת 'עיצובים' כמנגנון לאפליקציות כדי להחיל סגנונות על פעילות או אפליקציה שלמה. Android 4.3 כולל נושא 'Holo' או 'הולוגרפית' כקבוצה של סגנונות מוגדרים שמפתחי אפליקציות יכולים להשתמש בהם אם הם רוצים להתאים את המראה והתחושה של הנושא ל-Holo כפי שהוגדר ב-Android SDK‏ [משאבים, 24]. אסור לשנות בהטמעות במכשירים אף אחד מהמאפיינים של נושא Holo שנחשפים לאפליקציות [Resources, 25].

גרסת Android 4.3 כוללת עיצוב חדש בשם 'ברירת המחדל של המכשיר', שהוא קבוצה של סגנונות מוגדרים שמפתחי אפליקציות יכולים להשתמש בהם כדי להתאים את המראה והתחושה של העיצוב של המכשיר כפי שהוגדר על ידי מי שמטמיע את המכשיר. הטמעות במכשירים יכולות לשנות את מאפייני העיצוב של DeviceDefault שנחשפים לאפליקציות [משאבים, 25].

3.8.7. טפטים מונפשים

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

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

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

3.8.8. תצוגת האפליקציות האחרונות

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

3.8.9. ניהול קלט

ב-Android 4.3 יש תמיכה בניהול קלט ותמיכה בעורכי שיטות קלט של צד שלישי. הטמעות במכשירים שמאפשרות למשתמשים להשתמש בשיטות קלט של צד שלישי במכשיר חייבות להצהיר על תכונת הפלטפורמה android.software.input_methods ולתמוך בממשקי IME API כפי שהוגדר במסמכי התיעוד של Android SDK.

הטמעות של מכשירים שמצהירות על התכונה android.software.input_methods חייבות לספק מנגנון שזמין למשתמשים להוספה ולהגדרה של שיטות קלט של צד שלישי. בהטמעות במכשירים חייב להופיע ממשק ההגדרות בתגובה לכוונה android.settings.INPUT_METHOD_SETTINGS.

3.8.10. שלט רחוק למדיה במסך הנעילה

Android 4.3 כולל תמיכה ב-Remote Control API שמאפשר לאפליקציות מדיה להתמזג עם לחצני הפעלה שמוצגים בתצוגה מרחוק, כמו מסך הנעילה של המכשיר [מקורות מידע, 74]. הטמעות של מכשירים שתומכות במסך נעילה במכשיר ומאפשרות למשתמשים להוסיף ווידג'טים למסך הבית חייבות לכלול תמיכה בהטמעת פקדים מרחוק במסך הנעילה של המכשיר [מקורות מידע, 69].

3.8.11. חלומות

גרסת Android 4.3 כוללת תמיכה בשומרי מסך אינטראקטיביים שנקראים Dreams‏ [משאבים, 76]. Dreams מאפשר למשתמשים לבצע אינטראקציה עם אפליקציות כשמכשיר הטעינה לא פעיל או מחובר למטען שולחני. הטמעות במכשירים חייבות לכלול תמיכה ב-Dreams ולספק למשתמשים אפשרות להגדיר את Dreams.

3.9 ניהול מכשירים

Android 4.3 כולל תכונות שמאפשרות לאפליקציות עם תמיכה באבטחה לבצע פונקציות של ניהול המכשיר ברמת המערכת, כמו אכיפת מדיניות סיסמאות או ביצוע איפוס נתונים מרחוק, באמצעות Android Device Administration API‏ [משאבים, 27]. הטמעות במכשירים חייבות לספק הטמעה של המחלקה DevicePolicyManager [משאבים, 28]. הטמעות של מכשירים שכוללות תמיכה במסך הנעילה חייבות לתמוך במגוון המלא של כללי המדיניות לניהול המכשיר שמוגדרים במסמכי התיעוד של Android SDK‏ [מקורות מידע, 27].

3.10 נגישות

ב-Android 4.3 יש שכבת נגישות שעוזרת למשתמשים עם מוגבלויות לנווט במכשירים שלהם בקלות רבה יותר. בנוסף, ב-Android 4.3 יש ממשקי API לפלטפורמה שמאפשרים להטמעות של שירותי נגישות לקבל קריאות חזרה (callbacks) לאירועים של משתמשים ושל מערכות, וליצור מנגנוני משוב חלופיים, כמו המרת טקסט לדיבור, משוב הפיזי (haptic) וניווט באמצעות טרקלבל או מקש כיוון [מקורות מידע, 29]. בהטמעות במכשירים חייבת להיות הטמעה של מסגרת הנגישוּת של Android שתואמת להטמעה שמוגדרת כברירת מחדל ב-Android. באופן ספציפי, הטמעות של מכשירים חייבות לעמוד בדרישות הבאות.

הטמעות במכשירים חייבות לתמוך בהטמעות של שירותי נגישות של צד שלישי דרך ממשקי ה-API של android.accessibilityservice‏ [מקורות מידע, 30].
הטמעות במכשירים חייבות ליצור אירועים מסוג AccessibilityEvents ולהעביר אותם לכל הטמעות AccessibilityService הרשומים באופן שתואם להטמעה שמוגדרת כברירת מחדל ב-Android.
הטמעות במכשירים חייבות לספק מנגנון שזמין למשתמשים כדי להפעיל ולהשבית שירותי נגישות, וחובה להציג את הממשק הזה בתגובה לכוונה android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

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

3.11 המרת טקסט לדיבור (TTS)

מערכת Android 4.3 כוללת ממשקי API שמאפשרים לאפליקציות להשתמש בשירותי המרה של טקסט לדיבור (TTS), ומאפשרת לספקי שירותים לספק הטמעות של שירותי TTS [מקורות מידע, 32]. הטמעות במכשירים חייבות לעמוד בדרישות הבאות שקשורות למסגרת ה-TTS של Android:

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

4. תאימות של אריזת אפליקציות

הטמעות במכשירים חייבות להתקין ולהריץ קובצי Android מסוג ‎.apk שנוצרו באמצעות הכלי aapt שכלול ב-Android SDK הרשמי [מקורות מידע, 33].

אסור להרחיב את הטמעות המכשירים בפורמטים של קובצי APK‏ [Resources, 34], Android Manifest‏ [Resources, 35], קוד בייט של Dalvik‏ [Resources, 17] או קוד בייט של renderscript, באופן שימנע את ההתקנה וההפעלה הנכונים של הקבצים האלה במכשירים תואמים אחרים. מי שמטמיע את Dalvik במכשיר צריך להשתמש בהטמעה של Dalvik במקור (upstream) ובמערכת לניהול החבילות של ההטמעה הזו.

5. תאימות למולטימדיה

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

5.1. קודקים של מדיה

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

לתשומת ליבך, Google ו-Open Handset Alliance לא מצהירות שהקודקים האלה לא כפופים לפטנטים של צד שלישי. מי שמתכוון להשתמש בקוד המקור הזה במוצרי חומרה או תוכנה, צריך לדעת שיכול להיות שיהיו צורך ברישיונות פטנט מבעלי הפטנט הרלוונטיים כדי להטמיע את הקוד הזה, כולל בתוכנות קוד פתוח או בתוכנות שיתופיות.

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

סוג	פורמט / קודק	במקודד	מפענח	פרטים	סוגי קבצים / פורמטים של מאגרים
אודיו	MPEG-4 AAC Profile‏ (AAC LC)	חובה להטמעות במכשירים שכוללות חומרה של מיקרופון ומגדירות את `android.hardware.microphone`.	חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.1* עם תדירויות דגימה סטנדרטיות של 8 עד 48kHz.	3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4,‏ ‎.m4a) AAC גולמי ADTS‏ (‎.aac, ‏ פענוח ב-Android 3.1 ואילך, קידוד ב-Android 4.0 ואילך, אין תמיכה ב-ADIF) MPEG-TS‏ (‎.ts, לא ניתן לדלג, Android 3.0 ואילך)
	פרופיל MPEG-4 HE AAC‏ (AAC+)	חובה להטמעות במכשירים שכוללות חומרה של מיקרופון ומגדירות את android.hardware.microphone	חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.1* עם תדירויות דגימה רגילות של 16 עד 48kHz.
	פרופיל MPEG-4 HE AAC v2‏ (enhanced AAC+)		חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.1* עם תדירויות דגימה רגילות של 16 עד 48kHz.
	סוג אובייקט אודיו MPEG-4‏ ER AAC ELD (Enhanced Low Delay AAC)	חובה להטמעות במכשירים שכוללות חומרה של מיקרופון ומגדירות את android.hardware.microphone	חובה	תמיכה בתוכן מונו/סטריאו עם קצב דגימה סטנדרטי של 16 עד 48kHz.
	AMR-NB	חובה להטמעות במכשירים שכוללות חומרה של מיקרופון ומגדירות את `android.hardware.microphone`.	חובה	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)
	AMR-WB	חובה להטמעות במכשירים שכוללות חומרה של מיקרופון ומגדירות את `android.hardware.microphone`.	חובה	9 שיעורי דגימה מ-6.60kbit/s עד 23.85kbit/s, בתדירות דגימה של 16kHz	3GPP‏ (‎.3gp)
	FLAC		חובה (Android 3.1 ואילך)	מונו/סטריאו (ללא ערוצים מרובים). תדירויות דגימה של עד 48kHz (אבל מומלץ להשתמש בתדירויות של עד 44.1kHz במכשירים עם פלט של 44.1kHz, כי המכשיר להקטנת תדירות הדגימה מ-48kHz ל-44.1kHz לא כולל מסנן מסוג 'מסנן מסנן נמוך'). מומלץ 16 ביט, לא מוחל טשטוש (dither) ב-24 ביט.	FLAC‏ (‎.flac) בלבד
	MP3		חובה	מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR)	MP3‏ (‎.mp3)
	MIDI		חובה	MIDI מסוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה בפורמטים של רינגטונים RTTTL/RTX,‏ OTA ו-iMelody	סוג 0 ו-1 (‎.mid,‏ ‎.xmf,‏ ‎.mxmf) RTTTL/RTX‏ (‎.rtttl, ‎.rtx) OTA‏ (‎.ota) iMelody‏ (‎.imy)
	Vorbis		חובה		Ogg‏ (‎.ogg) Matroska‏ (‎.mkv)
	PCM/WAVE	חובה	חובה	PCM לינארי של 8 ביט ו-16 ביט** (שיעורים עד למגבלה של החומרה).חובה שתהיה במכשירים תמיכה בתדירויות דגימה להקלטה של PCM גולמי בתדרים של 8,000,‏ 16,000 ו-44,100Hz	WAVE‏ (‎.wav)
תמונה	JPEG	חובה	חובה	Base+progressive	JPEG‏ (‎.jpg)
	GIF		חובה		GIF ‏(‎.gif)
	PNG	חובה	חובה		PNG ‏(‎.png)
	BMP		חובה		BMP ‏(‎.bmp)
	WEBP	חובה	חובה		WebP ‏(‎.webp)
וידאו	H.263	חובה להטמעות במכשירים שכוללות חומרה של מצלמה ומגדירות את `android.hardware.camera` או את `android.hardware.camera.front`.	חובה		3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4)
	H.264 AVC	חובה להטמעות במכשירים שכוללות חומרה של מצלמה ומגדירות את `android.hardware.camera` או את `android.hardware.camera.front`.	חובה	פרופיל Baseline (BP)	3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4) MPEG-TS‏ (‎.ts, אודיו AAC בלבד, לא ניתן לדלג, Android 3.0 ואילך)
	MPEG-4 SP		חובה		3GPP‏ (‎.3gp)
	VP8	חובה (Android 4.3 ואילך)	חובה (Android 2.3.3 ואילך)		WebM‏ (‎.webm) ו-Matroska‏ (‎.mkv, Android 4.0 ואילך)***

*הערה: נדרש רק דאונמיקס של תוכן 5.0/5.1. הקלטה או עיבוד של יותר מ-2 ערוצים הם אופציונליים.
**הערה: חובה לצלם PCM ליניארי של 16 ביט. לא חובה לבצע צילום PCM ליניארי של 8 ביט.
***הערה: הטמעות במכשירים אמורות לתמוך בכתיבת קובצי Matroska WebM.

5.2 קידוד וידאו

הטמעות של מכשירי Android שכוללות מצלמה אחורית ומצהירות על android.hardware.camera צריכות לתמוך בפרופילים הבאים של קידוד וידאו H.264.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD (כשהחומרה תומכת בכך)
רזולוציית וידאו	176 x 144 פיקסלים	480 x 360 פיקסלים	‎1280 x 720 פיקסלים
קצב מסגרות של סרטון	12 fps	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	56 Kbps	500Kbps ומעלה	2Mbps ומעלה
קודק אודיו	AAC-LC	AAC-LC	AAC-LC
ערוצי אודיו	1 (מונו)	2 (סטריאו)	2 (סטריאו)
קצב העברת נתוני אודיו	24 Kbps	128 Kbps	192 Kbps

הטמעות של מכשירי Android שכוללות מצלמה אחורית ומצהירות על android.hardware.camera צריכות לתמוך בפרופילים הבאים של קידוד וידאו ב-VP8

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p (אם יש תמיכה בחומרה)	HD 1080p (אם יש תמיכה בחומרה)
רזולוציית וידאו	320 x 180 פיקסלים	640 x 360 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	800 Kbps	2 Mbps	4Mbps	10Mbps

5.3 פענוח וידאו

הטמעות של מכשירי Android אמורות לתמוך בפרופילים הבאים של פענוח וידאו ב-VP8 וב-H.264.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p (אם יש תמיכה בחומרה)	HD 1080p (אם יש תמיכה בחומרה)
רזולוציית וידאו	320 x 180 פיקסלים	640 x 360 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	800 Kbps	2 Mbps	8Mbps	‎20 Mbps

5.4. הקלטת אודיו

כשאפליקציה משתמשת ב-API android.media.AudioRecord כדי להתחיל להקליט שידור אודיו, הטמעות של מכשירים שכוללות חומרה של מיקרופון ומצהירות על android.hardware.microphone חייבות לדגום ולהקליט אודיו בכל אחד מההתנהגויות הבאות:

המכשיר אמור להציג מאפייני אמפליטודה לעומת תדרים שטוחיים יחסית, באופן ספציפי, ±3 dB, מ-100Hz עד 4000Hz
יש להגדיר את רגישות הקלט של האודיו כך שמקור עם רמת הספק של 90dB (SPL) בתדר 1,000Hz יניב ערך RMS של 2,500 לדגימות של 16 ביט.
רמות האמפליטודה של PCM אמורות לעקוב באופן לינארי אחרי השינויים ב-SPL של הקלט בטווח של לפחות 30dB, מ-18dB ל-12dB ביחס ל-90dB SPL במיקרופון.
העיוות ההרמוני הכולל צריך להיות קטן מ-1% עבור 1kHz ברמת קלט של 90dB SPL.

בנוסף למפרטי ההקלטה שלמעלה, כשאפליקציה מתחילה להקליט שידור אודיו באמצעות מקור האודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

אם יש עיבוד להפחתת רעש, חובה להשבית אותו.
אם יש בקרת רווח אוטומטית, חובה להשבית אותה.

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

5.5. זמן אחזור אודיו (audio latency)

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

למטרות הקטע הזה:

'זמן אחזור של פלט' מוגדר כמרווח הזמן שבין הזמן שבו אפליקציה כותבת פריים של נתונים בקידוד PCM לבין הזמן שבו המאזין החיצוני יכול לשמוע את הצליל התואם או שהמתמר יכול לזהות אותו.
'זמן אחזור פלט קר' מוגדר כזמן האחזור של הפלט לפריים הראשון, כשמערכת הפלט של האודיו הייתה במצב חוסר פעילות ומושבתת לפני הבקשה.
'זמן אחזור רצוף בפלט' מוגדר כזמן האחזור בפלט של פריים נוסף, אחרי שהמכשיר כבר מפעיל אודיו.
'זמן אחזור קלט' הוא מרווח הזמן שבין הצגת צליל חיצוני במכשיר לבין הזמן שבו אפליקציה קוראת את המסגרת התואמת של נתונים בקידוד PCM
'זמן אחזור קלט קר' מוגדר כסכום של זמן הקלט שאבד וזמן האחזור של הקלט לפריים הראשון, כשמערכת קלט האודיו הייתה במצב חוסר פעילות ומושבתת לפני הבקשה
'זמן אחזור קלט רציף' מוגדר כזמן האחזור של הקלט בפריימים הבאים, בזמן שהמכשיר כבר מתעד אודיו.
'OpenSL ES PCM buffer queue API' היא קבוצת ממשקי ה-API של OpenSL ES שקשורים ל-PCM ב-Android NDK. למידע נוסף, ראו NDK_root/docs/opensles/index.html

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

זמן אחזור של פלט במצב התחלתי (cold) של 100 אלפיות השנייה או פחות
זמן אחזור רציף של הפלט של 45 אלפיות השנייה או פחות

אם הטמעת המכשיר עומדת בדרישות הקטע הזה אחרי כיול ראשוני, כשמשתמשים ב-OpenSL ES PCM buffer queue API, לצורך זמן אחזור רצוף של פלט וזמן אחזור קר של פלט במכשיר פלט אודיו נתמך אחד לפחות, יכול להיות שהיא תדווח על תמיכה באודיו עם זמן אחזור נמוך על ידי דיווח על התכונה 'android.hardware.audio.low-latency' דרך הכיתה android.content.pm.PackageManager. [מקורות מידע, 37] לעומת זאת, אם ההטמעה במכשיר לא עומדת בדרישות האלה, אסור לדווח על תמיכה באודיו עם זמן אחזור קצר.

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

הטמעות של מכשירים שכוללות חומרה של מיקרופון ומצהירות על android.hardware.microphone צריכות לעמוד בדרישות הבאות לגבי זמן האחזור של קלט האודיו:

זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות
זמן אחזור רציף של קלט של 50 אלפיות השנייה או פחות

5.6. פרוטוקולי רשת

המכשירים חייבים לתמוך בפרוטוקולים של רשתות המדיה להפעלת אודיו ווידאו, כפי שמפורט במסמכי התיעוד של Android SDK‏ [מקורות מידע, 58]. באופן ספציפי, המכשירים חייבים לתמוך בפרוטוקולים הבאים של רשתות מדיה:

RTSP‏ (RTP, ‏ SDP)
HTTP(S) progressive streaming
טיוטת פרוטוקול של HTTP(S) Live Streaming, גרסה 3 [מקורות מידע, 59]

6. תאימות של כלים ואפשרויות למפתחים

6.1 כלים למפתחים

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

Android Debug Bridge‏ (נקרא adb) [מקורות מידע, 33]
הטמעות במכשירים חייבות לתמוך בכל הפונקציות של adb כפי שמתואר ב-Android SDK. הדימון adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Android Debug Bridge.
ב-Android 4.3 יש תמיכה ב-adb מאובטח. Secure adb מאפשר להשתמש ב-adb במארחים מוכרים ומאומתים. הטמעות במכשירים חייבות לתמוך ב-adb מאובטח.
Dalvik Debug Monitor Service (נקרא גם ddms) [מקורות מידע, 33]
הטמעות במכשירים חייבות לתמוך בכל התכונות של ddms כפי שמפורט ב-Android SDK. מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חובה לספק תמיכה בכל פעם שהמשתמש הפעיל את Android Debug Bridge, כפי שמתואר למעלה.
Monkey [משאבים, 36]
הטמעות במכשירים חייבות לכלול את מסגרת Monkey ולהפוך אותה לזמינה לשימוש באפליקציות.
SysTrace [מקורות מידע, 33]
הטמעות במכשירים חייבות לתמוך בכלי systrace כפי שמתואר ב-Android SDK. Systrace חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Systrace.

רוב המערכות מבוססות-Linux ומערכות Apple Macintosh מזהות מכשירי Android באמצעות הכלים הרגילים של Android SDK, ללא תמיכה נוספת. עם זאת, במערכות Microsoft Windows בדרך כלל נדרש מנהל התקן למכשירי Android חדשים. (לדוגמה, כדי להשתמש במזהי ספקים חדשים ולפעמים במזהי מכשירים חדשים, נדרשים מנהלי USB מותאמים אישית למערכות Windows). אם הטמעת מכשיר לא מזוהה על ידי הכלי adb כפי שסופק ב-Android SDK הסטנדרטי, מחשבי הטמעת המכשיר חייבים לספק מנהלי התקנים של Windows שמאפשרים למפתחים להתחבר למכשיר באמצעות פרוטוקול adb. חובה לספק את מנהלי ההתקנים האלה ל-Windows XP,‏ Windows Vista,‏ Windows 7 ו-Windows 8, גם בגרסאות 32 ביט וגם בגרסאות 64 ביט.

6.2 אפשרויות למפתחים

ב-Android 4.3 יש תמיכה במפתחים שמאפשרת להם להגדיר הגדרות שקשורות לפיתוח אפליקציות. הטמעות במכשירים חייבות לפעול בהתאם ל-Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח אפליקציות [מקורות מידע, 77]. בהטמעה של Android במקור, תפריט האפשרויות למפתחים מוסתר כברירת מחדל, והמשתמשים יכולים להפעיל אותו אחרי שלוחצים שבע (7) פעמים על הפריט בתפריט 'הגדרות' > 'מידע על המכשיר' > 'מספר Build'. הטמעות במכשירים חייבות לספק חוויה עקבית של אפשרויות למפתחים. באופן ספציפי, בהטמעות של מכשירים חובה להסתיר את האפשרויות למפתחים כברירת מחדל, וחובה לספק מנגנון להפעלת האפשרויות למפתחים שתואמת להטמעה של Android במקור.

7. תאימות חומרה

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

עדיין חייבות להופיע הגדרות מלאות של הכיתות (כפי שמתועד ב-SDK) לממשקי ה-API של הרכיב
חובה להטמיע את ההתנהגויות של ה-API כ-no-ops באופן סביר כלשהו
שיטות API חייבות להחזיר ערכי null במקרים שבהם מותר לעשות זאת במסמכי התיעוד של ה-SDK
שיטות API חייבות להחזיר הטמעות של מחלקות ללא פעולה (no-op) שבהן ערכים null אסורים לפי מסמכי התיעוד של ה-SDK
אסור לשיטות API להוציא חריגים שלא מתועדים במסמכי התיעוד של ה-SDK

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

הטמעות של מכשירים חייבות לדווח באופן מדויק על מידע מדויק לגבי הגדרות החומרה באמצעות השיטות getSystemAvailableFeatures() ו-hasSystemFeature(String) בכיתה android.content.pm.PackageManager. [Resources, 37]

7.1. תצוגה וגרפיקה

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

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

'גודל פיזי באלכסון' הוא המרחק בסנטימטרים בין שני פינות מנוגדות של החלק המאיר של המסך.
'dpi' (נקודות לאינץ') הוא מספר הפיקסלים שמקובצים בשטח אופקי או אנכי של אינץ' אחד. כאשר מוצגים ערכי dpi, גם הערך של dpi אופקי וגם הערך של dpi אנכי חייבים להיות בטווח.
'יחס גובה-רוחב' הוא היחס בין המידה הארוכה של המסך למידה הקצרה. לדוגמה, מסך בגודל 480x854 פיקסלים יהיה 854 / 480 = 1.779, או בערך '16:9'.
'פיקסל שלא תלוי בדחיסות' (dp) הוא יחידת הפיקסלים הווירטואלית שמותאמת למסך של 160dpi, ומחושבת לפי הנוסחה: pixels = dps * (density / 160).

7.1.1. הגדרת מסך

גודל מסך

מסגרת ממשק המשתמש של Android תומכת במגוון גדלים שונים של מסכים, ומאפשרת לאפליקציות לשלוח שאילתה לגבי גודל המסך של המכשיר (נקרא גם 'פריסת המסך') באמצעות android.content.res.Configuration.screenLayout עם SCREENLAYOUT_SIZE_MASK. הטמעות במכשירים חייבות לדווח על גודל המסך הנכון כפי שמוגדר במסמכי התיעוד של Android SDK‏ [משאבים, 38] ומוכתב על ידי פלטפורמת Android במקור. באופן ספציפי, הטמעות במכשירים חייבות לדווח על גודל המסך הנכון בהתאם למאפייני המסך הלוגיים הבאים של פיקסלים שאינם תלויים בדחיסות (dp).

גודל המסך של המכשירים חייב להיות לפחות 426dp x 320dp ('קטן')
במכשירים שמדווחים על גודל מסך 'רגיל', גודל המסך חייב להיות לפחות 480dp x 320dp.
במכשירים שמדווחים על גודל מסך 'גדול', גודל המסך חייב להיות לפחות 640dp x 480dp.
במכשירים שמדווחים על גודל מסך 'גדול במיוחד', גודל המסך חייב להיות לפחות 960‎ dp x 720‎ dp

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

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

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

יחס הגובה-רוחב של המסך

יחס הגובה-רוחב חייב להיות בין 1.3333 (4:3) ל-1.85 (16:9).

דחיסות מסך

מסגרת ממשק המשתמש של Android מגדירה קבוצה של צפיפות לוגיות רגילות כדי לעזור למפתחי אפליקציות לטרגט את משאבי האפליקציה. הטמעות במכשירים חייבות לדווח על אחת מהצפיפויות הלוגיות הבאות של מסגרת Android באמצעות ממשקי ה-API של android.util.DisplayMetrics, וחייבות להריץ אפליקציות בצפיפות הרגילה הזו.

120dpi, שנקרא 'ldpi'
160dpi, שנקרא 'mdpi'
213dpi, שנקרא 'tvdpi'
240dpi, שנקרא גם 'hdpi'
320dpi, שנקרא 'xhdpi'
480dpi, שנקרא גם 'xxhdpi'
640dpi, שנקרא 'xxxhdpi'

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

7.1.2. מדדי רשת המדיה

הטמעות של מכשירים חייבות לדווח על ערכים נכונים לכל מדדי התצוגה שמפורטים ב-android.util.DisplayMetrics [משאבים, 39].

7.1.3. כיוון מסך

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

המכשירים חייבים לדווח על הערך הנכון של הכיוון הנוכחי של המכשיר בכל פעם שמתבצעת שאילתה באמצעות android.content.res.Configuration.orientation,‏ android.view.Display.getOrientation() או ממשקי API אחרים.

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

המכשירים חייבים לדווח על כיווני המסך שנתמכים בהם (android.hardware.screen.portrait ו/או android.hardware.screen.landscape) ועל כיוון אחד לפחות שנתמך. לדוגמה, מכשיר עם מסך אופקי קבוע, כמו טלוויזיה או מחשב נייד, חייב לדווח רק על android.hardware.screen.landscape.

7.1.4. האצת גרפיקה 2D ו-3D

הטמעות במכשירים חייבות לתמוך גם ב-OpenGL ES 1.0 וגם ב-2.0, כפי שמתואר בפירוט במסמכי התיעוד של Android SDK. הטמעות במכשירים אמורות לתמוך ב-OpenGL ES 3.0 במכשירים שיכולים לתמוך ב-OpenGL ES 3.0. הטמעות במכשירים חייבות לתמוך גם ב-Android Renderscript, כפי שמפורט במסמכי התיעוד של Android SDK‏ [Resources, 8].

הטמעות של מכשירים חייבות גם לזהות את עצמן בצורה נכונה בתור תומכות ב-OpenGL ES 1.0, ב-OpenGL ES 2.0 או ב-OpenGL ES 3.0. כלומר:

ממשקי ה-API המנוהלים (למשל באמצעות השיטה GLES10.getString()) חייבים לדווח על תמיכה ב-OpenGL ES 1.0 וב-OpenGL ES 2.0
ממשקי ה-API של OpenGL ב-C/C++ (כלומר, אלה שזמינים לאפליקציות דרך libGLES_v1CM.so,‏ libGLES_v2.so או libEGL.so) חייבים לדווח על תמיכה ב-OpenGL ES 1.0 וב-OpenGL ES 2.0.
הטמעות של מכשירים שמצהירות על תמיכה ב-OpenGL ES 3.0 חייבות לתמוך בממשקי API מנוהלים של OpenGL ES 3.0 ולכלול תמיכה בממשקי API מקומיים של C/C++. בהטמעות במכשירים שמצהירות על תמיכה ב-OpenGL ES 3.0, קובץ libGLESv2.so חייב לייצא את סמלי הפונקציות של OpenGL ES 3.0 בנוסף לסמלי הפונקציות של OpenGL ES 2.0.

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

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

ב-Android 4.3 יש מנגנון שמאפשר לאפליקציות להצהיר שהן רוצות להפעיל האצת חומרה לגרפיקה 2D ברמת האפליקציה, הפעילות, החלון או התצוגה באמצעות תג מניפסט android:hardwareAccelerated או קריאות ישירות ל-API‏ [מקורות מידע, 9].

ב-Android 4.3, בהטמעות של מכשירים חובה להפעיל את שיפור המהירות באמצעות חומרה כברירת מחדל, וחובה להשבית את שיפור המהירות באמצעות חומרה אם המפתח מבקש זאת, על ידי הגדרת android:hardwareAccelerated="false" או השבתת שיפור המהירות באמצעות חומרה ישירות דרך Android View APIs.

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

Android 4.3 כולל אובייקט TextureView שמאפשר למפתחים לשלב ישירות טקסטורות של OpenGL ES שמואצלות בחומרה כיעדים לעיבוד בתוך היררכיית ממשק המשתמש. הטמעות במכשירים חייבות לתמוך ב-API של TextureView, וחובה שהן יפעלו באופן עקבי עם הטמעת Android במקור.

Android 4.3 כולל תמיכה ב-EGL_ANDROID_RECORDABLE, מאפיין של EGLConfig שמציין אם ה-EGLConfig תומך ברינדור ל-ANativeWindow שמקליט תמונות לסרטון. הטמעות במכשירים חייבות לתמוך בתוסף EGL_ANDROID_RECORDABLE [משאבים, 79].

7.1.5. מצב תאימות לאפליקציות מדור קודם

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

7.1.6. סוגי מסכים

מסכי הטמעה של מכשירים מסווגים לאחד משני סוגים:

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

הטמעות במכשירים עם פיקסלים קבועים

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

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

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

לדוגמה, טאבלט בגודל 7 אינץ' באלכסון עם רזולוציה של 1024x600 פיקסלים נחשב להטמעה של תצוגה גדולה עם פיקסלים קבועים ב-mdpi. אם המכשיר מכיל יציאת וידאו שפועלת ברזולוציה של 720p או 1080p, ההטמעה במכשיר חייבת לשנות את הגודל של הפלט כך שהאפליקציות יפעלו רק בחלון גדול ב-mdpi, ללא קשר לשימוש במסך עם פיקסלים קבועים או ביציאת וידאו.

הטמעות במכשירים עם פיקסלים משתנים

הטמעות של מכשירים עם פיקסלים משתנים חייבות לתמוך באחת מהרזולוציות הבאות, או בשתיהן: 1280x720 או 1920x1080 (כלומר 720p או 1080p). הטמעות של מכשירים עם מסכים של פיקסלים משתנים אסור שתכללו תמיכה במצבים או בהגדרות מסך אחרים. הטמעות של מכשירים עם מסכים של פיקסלים משתנים עשויות לשנות את ההגדרה או את המצב של המסך במהלך זמן הריצה או במהלך האתחול. לדוגמה, משתמש ב-set-top box יכול להחליף מסך 720p במסך 1080p, וההטמעה במכשיר עשויה להשתנות בהתאם.

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

1280x720 (נקרא גם 720p): גודל מסך 'גדול', דחיסות 'tvdpi' (213dpi)
1920x1080 (נקראת גם 1080p): גודל מסך 'גדול', דחיסות 'xhdpi' (320dpi)

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

7.1.7. טכנולוגיית המסך

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

המכשירים חייבים לתמוך במסכים שיכולים לבצע רינדור של גרפיקה צבעונית ב-16 ביט, ורצוי שתהיה תמיכה במסכים שיכולים לבצע רינדור של גרפיקה צבעונית ב-24 ביט.
המכשירים חייבים לתמוך במסכים שיכולים לבצע רינדור של אנימציות.
יחס הגובה-רוחב של הפיקסלים (PAR) בטכנולוגיית התצוגה שבה נעשה שימוש חייב להיות בין 0.9 ל-1.1. כלומר, יחס הגובה-רוחב של הפיקסלים חייב להיות קרוב לריבוע (1.0) עם טולרנס של 10%.

7.1.8. מסכים חיצוניים

ב-Android 4.3 יש תמיכה במסך משני כדי לאפשר שיתוף מדיה וממשקי API למפתחים לגישה למסכים חיצוניים. אם המכשיר תומך במסך חיצוני באמצעות חיבור קווי, אלחוטי או צג מובנה נוסף, ההטמעה של המכשיר חייבת לכלול את ממשק ה-API של מנהל המסך כפי שמתואר במסמכי התיעוד של Android SDK‏ [מקורות מידע, 75]. בהטמעות של מכשירים שתומכות בפלט וידאו מאובטח ויכולות לתמוך במשטחים מאובטחים, חובה להצהיר על תמיכה ב-Display.FLAG_SECURE. באופן ספציפי, הטמעות של מכשירים שמצהירות על תמיכה ב-Display.FLAG_SECURE חייבות לתמוך ב-HDCP 2.x ואילך במסכים אלחוטיים של Miracast, או ב-HDCP 1.2 ואילך במסכים עם חיבור קווי. ההטמעה של Android בקוד פתוח ב-upstream כוללת תמיכה במסכים אלחוטיים (Miracast) ומחוברים (HDMI) שעומדים בדרישות האלה.

7.2. התקני קלט

7.2.1. מקלדת

הטמעות במכשירים:

חובה לכלול תמיכה ב-Input Management Framework (שמאפשר למפתחים של צד שלישי ליצור מנועי ניהול קלט – כלומר מקלדת וירטואלית), כפי שמפורט בכתובת http://developer.android.com
חובה לספק לפחות הטמעה אחת של מקלדת וירטואלית (ללא קשר לכך שיש מקלדת פיזית)
יכולות לכלול הטמעות נוספות של מקלדות וירטואליות
יכול להיות שתכלול מקלדת חומרה
אסור לכלול מקלדת חומרה שלא תואמת לאחד מהפורמטים שצוינו בשדה android.content.res.Configuration.keyboard‏[Resources, 40] (כלומר, QWERTY או 12 מפתחות)

הטמעות במכשירים:

אפשר להשמיט אפשרות ניווט ללא מגע (כלומר, אפשר להשמיט טרקר-בול, משטח משחק או גלגלת)
חובה לדווח על הערך הנכון של android.content.res.Configuration.navigation‏[Resources, 40]
חובה לספק מנגנון חלופי סביר של ממשק משתמש לבחירה ולעריכה של טקסט, שתואמת למנועי ניהול קלט. ההטמעה של Android בקוד פתוח במקור כוללת מנגנון בחירה שמתאים לשימוש במכשירים שאין בהם מקורות קלט לניווט שאינם מגע.

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

מערכת Android 4.3 כוללת תמיכה בפעולות עזרה [מקורות מידע, 63]. בהטמעות במכשירים, הפעולה של העזרה חייבת להיות זמינה למשתמש בכל שלב כשאפליקציות פועלות. אפשר להטמיע את הפונקציה הזו באמצעות מפתחות חומרה או תוכנה.

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

במפתחות הניווט להטמעה במכשיר חייב להיות שימוש בחלק נפרד מהמסך, שלא זמין לאפליקציות, ואסור שהם יסתירו או יפריעו בדרך אחרת לחלק מהמסך שזמין לאפליקציות.
בהטמעות של מכשירים חייב להיות זמין חלק מהמסך לאפליקציות שעומדות בדרישות שמפורטות בקטע 7.1.1.
בהטמעות במכשירים חובה להציג את מקשי הניווט כשאפליקציות לא מציינות מצב של ממשק המשתמש של המערכת, או כשהן מציינות את הערך SYSTEM_UI_FLAG_VISIBLE.
כשאפליקציות מציינות את הערך SYSTEM_UI_FLAG_LOW_PROFILE, חייבים להציג את מקשי הניווט במצב 'פרופיל נמוך' (למשל, כהה) שלא מפריע.
בהטמעות במכשירים חייבים להסתיר את מקשי הניווט כשאפליקציות מצביעות על SYSTEM_UI_FLAG_HIDE_NAVIGATION.
הטמעת המכשיר חייבת להציג לאפליקציות מקש תפריט כשה-targetSdkVersion <= 10, ואסור להציג מקש תפריט כשה-targetSdkVersion > 10.

7.2.4. קלט במסך מגע

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

צריכה להיות תמיכה בצבעים עם מעקב עצמאי מלא, אם מערכת הקלט של המכשיר תומכת בכמה צבעים
חובה לדווח על הערך של android.content.res.Configuration.touchscreen [Resources, 40] התואם לסוג מסך המגע הספציפי במכשיר

ב-Android 4.3 יש תמיכה במגוון מסכי מגע, משטחי מגע ומכשירים מזויפים להזנת קלט מגע. הטמעות של מכשירים מבוססי מסך מגע משויכות למסך [מקורות מידע, 81] כך שהמשתמש מרגיש שהוא מבצע פעולות ישירות בפריטים במסך. מכיוון שהמשתמש נוגע ישירות במסך, המערכת לא זקוקה לאמצעי עזר נוספים כדי לציין את האובייקטים שבהם מבצעים פעולות. לעומת זאת, ממשק מגע מזויף מספק מערכת קלט משתמש שמתקרבת לקבוצת משנה של יכולות של מסך מגע. לדוגמה, עכבר או שלט רחוק שמניעים סמן במסך דומים למגע, אבל המשתמש צריך קודם להצביע או להתמקד ואז ללחוץ. מכשירים רבים לקליטת נתונים, כמו עכבר, משטח מגע, עכבר אוויר מבוסס-ג'ירו, סמן ג'ירו, ג'ויסטיק ומשטח מגע עם תמיכה במספר נקודות מגע, יכולים לתמוך באינטראקציות מזויפות של מגע. Android 4.0 כולל את קבוע התכונה android.hardware.faketouch, שמתאים למכשיר קלט לא מגע (כלומר מבוסס-סמן) באיכות גבוהה, כמו עכבר או משטח מגע, שיכול לדמות בצורה הולמת קלט מבוסס-מגע (כולל תמיכה בתנועות בסיסיות), ומציין שהמכשיר תומך בקבוצת משנה של פונקציונליות של מסך מגע. הטמעות במכשירים שמצהירות על תכונת המגע המזויף חייבות לעמוד בדרישות לגבי מגע מזויף שמפורטות בסעיף 7.2.5.

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

7.2.5. קלט מגע מזויף

הטמעות במכשירים שמצהירות על תמיכה ב-android.hardware.faketouch

חובה לדווח על המיקום המוחלט של הסמן במסך בקואורדינטות X ו-Y, ולהציג סמן חזותי במסך [מקורות מידע, 80]
חובה לדווח על אירוע מגע עם קוד הפעולה [Resources, 80] שמציין את שינוי המצב שמתרחש כשהסמן עובר ל-down או ל-up במסך [Resources, 80]
חובה לתמוך בסמן down ו-up על אובייקט במסך, כדי לאפשר למשתמשים לדמות הקשה על אובייקט במסך
חובה לתמוך בתנועת הסמן down, בתנועת הסמן up, בתנועת הסמן down ואז בתנועת הסמן up באותו מקום על אובייקט במסך, בתוך ערך סף זמן, כדי לאפשר למשתמשים לדמות הקשה כפולה על אובייקט במסך [מקורות מידע, 80]
חובה לתמוך בסמן down בנקודה שרירותית במסך, בסמן שנע לנקודה שרירותית אחרת במסך, ואז בסמן up, שמאפשר למשתמשים לדמות גרירה במגע
חובה לתמוך בסמן down, ולאחר מכן לאפשר למשתמשים להזיז את האובייקט במהירות למיקום אחר במסך, ואז בסמן up במסך, שמאפשר למשתמשים להעיף אובייקט במסך

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

7.2.6. מיקרופון

יכול להיות שבהטמעות של מכשירים לא יהיה מיקרופון. עם זאת, אם הטמעה של מכשיר שוללת מיקרופון, אסור לדווח על קבוע התכונה android.hardware.microphone, וצריך להטמיע את ממשק ה-API להקלטת אודיו כ-no-ops, בהתאם לקטע 7. לעומת זאת, הטמעות של מכשירים שיש בהם מיקרופון:

חובה לדווח על קבוע התכונה android.hardware.microphone
צריכה לעמוד בדרישות באיכות האודיו שמפורטות בקטע 5.4
צריך לעמוד בדרישות לגבי זמן האחזור של האודיו שמפורטות בקטע 5.5

7.3. חיישנים

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

חובה לדווח במדויק על נוכחות או על היעדר של חיישנים לפי הסיווג android.content.pm.PackageManager. [Resources, 37]
חובה להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות SensorManager.getSensorList() ושיטות דומות
חייב לפעול באופן סביר בכל ממשקי ה-API האחרים של החיישנים (לדוגמה, על ידי החזרת true או false בהתאם כשאפליקציות מנסים לרשום מאזינים, לא להפעיל מאזינים של חיישנים כשהחיישנים המתאימים לא נמצאים וכו').
חובה לדווח על כל מדידות החיישן באמצעות הערכים הרלוונטיים של המערכת הבינלאומית של יחידות (כלומר, המדדים) לכל סוג חיישן, כפי שהוגדר במסמכי התיעוד של Android SDK‏ [Resources, 41]

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

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

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

7.3.1. מד תאוצה

מומלץ לכלול בהטמעות במכשירים מד תאוצה ב-3 צירים. אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים, הוא:

צריכה להיות אפשרות לשלוח אירועים ב-120Hz או יותר. שימו לב שלמרות שצוינה למעלה ש'מומלץ' להשתמש בתדירות של גלאי התאוצה ב-Android 4.3, בהגדרת התאימות של גרסה עתידית אנחנו מתכננים לשנות את ההמלצה הזו ל'חובה'. כלומר, הסטנדרטים האלה הם אופציונליים ב-Android 4.3, אבל יהיו חובה בגרסאות עתידיות. אנחנו ממליצים מאוד למכשירים קיימים וחדשים עם Android 4.3 לעמוד בדרישות האלה ב-Android 4.3 כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
חייב להיות תואם למערכת הקואורדינטות של חיישן Android כפי שמפורט ב-Android APIs (ראו [מקורות מידע, 41])
חייב להיות מסוגל למדוד מירידה חופשית עד פי שניים מהכבידה (2g) או יותר בכל וקטור תלת-ממדי
חייב להיות דיוק של 8 ביט או יותר
סטיית התקן חייבת להיות לא יותר מ-0.05 m/s^2

7.3.2. מגנטומטר

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

חייבת להיות אפשרות לשלוח אירועים בתדירות של 10Hz או יותר
חייבת להיות תואמת למערכת הקואורדינטות של חיישן Android כפי שמפורט ב-Android APIs (ראו [מקורות מידע, 41]).
חייב להיות מסוגל לדגום טווח של עוצמות שדה שמספיק כדי לכסות את השדה הגיאומגנטי
חייב להיות דיוק של 8 ביט או יותר
סטיית התקן חייבת להיות לא יותר מ-0.5 µT

7.3.3. GPS

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

7.3.4. ג'ירוסקופ

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

חייב להיות פיצוי טמפרטורה
חייב להיות מסוגל למדוד שינויים בכיוון עד 5.5*Pi רדיאנים לשנייה (כלומר, כ-1,000 מעלות לשנייה)
צריכה להיות אפשרות לשלוח אירועים בתדר של 200Hz או יותר. שימו לב שלמרות שצוין למעלה ש'מומלץ' להשתמש בתדירות של הגירוסקופ ב-Android 4.3, בהגדרת התאימות של גרסה עתידית אנחנו מתכננים לשנות את ההמלצה הזו ל'חובה'. כלומר, הסטנדרטים האלה הם אופציונליים ב-Android 4.3, אבל יהיו חובה בגרסאות עתידיות. אנחנו ממליצים מאוד למכשירים קיימים וחדשים עם Android 4.3 לעמוד בדרישות האלה ב-Android 4.3 כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
חייב להיות דיוק של 12 ביט או יותר
סטיית התקן חייבת להיות קטנה מ-1e-7 rad^2 / s^2 לכל Hz (סטיית התקן לכל Hz, או rad^2 / s). ניתן לשנות את סטיית התקן בהתאם לשיעור הדגימה, אבל היא חייבת להיות מוגבלת בערך הזה. במילים אחרות, אם מודדים את השונות של הגירוסקופ בקצב דגימה של 1Hz, היא לא אמורה להיות גדולה מ-1e-7 rad^2/s^2.
חובה לכלול חותמות זמן קרובות ככל האפשר למועד שבו התרחש אירוע החומרה. צריך להסיר את זמן האחזור הקבוע.

7.3.5. ברומטר

הטמעות במכשירים עשויות לכלול ברומטר (כלומר חיישן של לחץ אוויר סביבתי). אם הטמעת המכשיר כוללת ברומטר, היא:

חייבת להיות אפשרות לשלוח אירועים בתדירות של 5Hz ומעלה
חובה שיהיו לו רמת דיוק מספקת כדי לאפשר הערכת גובה
חייב להיות פיצוי טמפרטורה

7.3.6. מדחום

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

7.3.7. פוטומטר

הטמעות במכשירים עשויות לכלול פוטומטרים (כלומר חיישן אור סביבתי).

7.3.8. חיישן קירבה

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

7.4. קישוריות נתונים

7.4.1. טלפוניה

המונח 'טלפוניה', כפי שהוא מופיע בממשקי ה-API של Android 4.3 ובמסמך הזה, מתייחס באופן ספציפי לחומרה שקשורה לביצוע שיחות קוליות ושליחת הודעות SMS דרך רשת GSM או CDMA. יכול להיות ששיחות הקול האלה יתבצעו באמצעות מעבר חבילות (packet-switched) ויכול להיות שלא, אבל למטרות Android 4.3 הן נחשבות ללא קשר לחיבור נתונים שעשוי להיות מיושם באמצעות אותה רשת. במילים אחרות, הפונקציונליות של 'טלפוניה' וממשקי ה-API של Android מתייחסים באופן ספציפי לשיחות קוליות ולהודעות SMS. לדוגמה, הטמעות של מכשירים שלא יכולות לבצע שיחות או לשלוח/לקבל הודעות SMS אסור לדווח על התכונה 'android.hardware.telephony' או על תכונות משנה שלה, גם אם הן משתמשות ברשת סלולרית לחיבור נתונים.

אפשר להשתמש ב-Android 4.3 במכשירים שלא כוללים חומרה של טלפוניה. כלומר, Android 4.3 תואם למכשירים שאינם טלפונים. עם זאת, אם הטמעת המכשיר כוללת טלפון GSM או CDMA, חובה שתהיה בה תמיכה מלאה ב-API של הטכנולוגיה הזו. הטמעות במכשירים שלא כוללות חומרה של טלפוניה חייבות ליישם את ממשקי ה-API המלאים כ-no-ops.

7.4.2. IEEE 802.11‏ (Wi-Fi)

הטמעות של מכשירי Android 4.3 אמורות לכלול תמיכה בפורמט אחד או יותר של 802.11‏ (b/g/a/n וכו') אם הטמעת המכשיר כוללת תמיכה ב-802.11, חובה להטמיע את Android API התואם.

בהטמעות של מכשירים חובה להטמיע את ה-API של ה-Multicast כפי שמתואר במסמכי ה-SDK [Resources, ‏ 62]. הטמעות במכשירים שכוללות תמיכה ב-Wi-Fi חייבות לכלול תמיכה ב-DNS של קבוצות מרובות (mDNS). אסור להטמיע במכשירים מסננים לחבילות mDNS (224.0.0.251) בשום שלב של הפעולה, כולל כשהמסך לא במצב פעיל.

7.4.2.1. Wi-Fi ישיר

הטמעות של מכשירים אמורות לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi peer-to-peer). אם הטמעת המכשיר כוללת תמיכה ב-Wi-Fi Direct, חובה להטמיע את Android API התואם כפי שמתואר במסמכי העזרה של ה-SDK [משאבים, 68]. אם הטמעה של מכשיר כוללת תמיכה ב-Wi-Fi Direct, היא:

חובה לתמוך בפעולה רגילה של Wi-Fi
צריך לתמוך בפעולה בו-זמנית של Wi-Fi ו-Wi-Fi Direct

7.4.3. Bluetooth

הטמעות של מכשירים אמורות לכלול משדר-מקלט Bluetooth. הטמעות של מכשירים שכוללות משדר-מקלט Bluetooth חייבות להפעיל את ה-API של Bluetooth שמבוסס על RFCOMM כפי שמתואר במסמכי התיעוד של ה-SDK, ולהצהיר על תכונת החומרה android.hardware.bluetooth‏ [משאבים, 42]. בהטמעות של מכשירים, צריך להטמיע פרופילים רלוונטיים של Bluetooth, כמו A2DP,‏ AVRCP,‏ OBEX וכו', בהתאם למכשיר.

הטמעות של מכשירים שכוללות תמיכה ב-Bluetooth GATT (פרופיל מאפיינים גנרי) כדי לאפשר תקשורת עם מכשירים עם Bluetooth Smart או Smart Ready חייבות להפעיל את ה-API של Bluetooth שמבוסס על GATT כפי שמתואר במסמכי התיעוד של ה-SDK ולהצהיר על תכונת החומרה android.hardware.bluetooth_le‏ [משאבים, 42].

7.4.4. תקשורת מטווח קצר

הטמעות של מכשירים אמורות לכלול משדר-מקלט וחומרה קשורה לתקשורת מטווח קצר (NFC). אם הטמעה של מכשיר כוללת חומרה של NFC, היא:

חובה לדווח על התכונה android.hardware.nfc מהשיטה android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37]
חייבת להיות לו יכולת לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים:
- חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum,‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
  - NfcA‏ (ISO14443-3A)
  - NfcB‏ (ISO14443-3B)
  - NfcF‏ (JIS 6319-4)
  - IsoDep‏ (ISO 14443-4)
  - סוגי תגים של NFC Forum מס' 1, 2, 3, 4 (מוגדרים על ידי NFC Forum)
צריכה להיות לה אפשרות לקרוא ולכתוב הודעות NDEF באמצעות סטנדרטי ה-NFC הבאים. שימו לב: תקני ה-NFC שמפורטים בהמשך מוגדרים כ'מומלצים' לגרסה Android 4.3, אבל בהגדרת התאימות לגרסה עתידית הם צפויים להשתנות ל'חובה'. כלומר, הסטנדרטים האלה הם אופציונליים ב-Android 4.3, אבל יהיו נדרשים בגרסאות עתידיות. במכשירים קיימים וחדשים עם Android 4.3, מומלץ מאוד לעמוד בדרישות האלה ב-Android 4.3 כדי שתוכלו לשדרג אותם לגרסאות העתידיות של הפלטפורמה.
- NfcV‏ (ISO 15693)
חייבת להיות מסוגלת להעביר ולקבל נתונים באמצעות התקנים והפרוטוקולים הבאים של רשתות עמיתים-לעמיתים:
- ISO 18092
- LLCP 1.0 (הוגדר על ידי NFC Forum)
- SDP 1.0 (הוגדר על ידי NFC Forum)
- פרוטוקול NDEF Push [מקורות מידע, 43]
- SNEP 1.0 (הוגדר על ידי NFC Forum)
חובה לכלול תמיכה ב-Android Beam‏ [משאבים, 65]:
- חובה להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF תקינות שהתקבלו על ידי שרת ה-SNEP שמוגדר כברירת מחדל חייבות להישלח לאפליקציות באמצעות ה-intent‏ android.nfc.ACTION_NDEF_DISCOVERED. השבתת Android Beam בהגדרות לא מורידה את ההגבלה על שליחת הודעת NDEF נכנסת.
- הטמעות של מכשירים חייבות לפעול בהתאם ל-intent של android.settings.NFCSHARING_SETTINGS כדי להציג את הגדרות השיתוף ב-NFC [מקורות מידע, 67].
- חובה להטמיע את שרת ה-NPP. הודעות שמתקבלות בשרת ה-NPP חייבות לעבור עיבוד באותו אופן שבו הן עוברות עיבוד בשרת ברירת המחדל של SNEP.
- חובה להטמיע לקוח SNEP ולנסות לשלוח NDEF P2P יוצא לשרת SNEP שמוגדר כברירת מחדל כש-Android Beam מופעל. אם לא נמצא שרת SNEP שמוגדר כברירת מחדל, הלקוח חייב לנסות לשלוח לשרת NPP.
- חובה לאפשר לפעילויות בחזית להגדיר את הודעת ה-NDEF היוצאת מסוג P2P באמצעות android.nfc.NfcAdapter.setNdefPushMessage,‏ android.nfc.NfcAdapter.setNdefPushMessageCallback ו-android.nfc.NfcAdapter.enableForegroundNdefPush.
- צריך להשתמש בתנועה או באישור במסך, כמו 'מצמידים כדי להעביר', לפני שליחת הודעות NDEF יוצאות מסוג P2P.
- צריך להפעיל את Android Beam כברירת מחדל
- חובה לתמוך בהעברת חיבור NFC ל-Bluetooth כשהמכשיר תומך בפרופיל Bluetooth Object Push. הטמעות של מכשירים חייבות לתמוך בהעברת חיבור ל-Bluetooth כשמשתמשים ב-android.nfc.NfcAdapter.setBeamPushUris, על ידי הטמעת המפרטים 'העברת חיבור גרסה 1.2' [מקורות מידע, 60] ו'התאמה פשוטה ומאובטחת של Bluetooth באמצעות NFC גרסה 1.0' [מקורות מידע, 61] של NFC Forum. בהטמעה כזו, צריך להשתמש בבקשות SNEP GET להחלפת בקשת ההעברה או לבחירת רשומות באמצעות NFC, וצריך להשתמש בפרופיל Bluetooth Object Push להעברת הנתונים בפועל ב-Bluetooth.
חובה לבצע סקירה של כל הטכנולוגיות הנתמכות במצב NFC discovery.
צריך להיות במצב חשיפת NFC כשהמכשיר פעיל, המסך פעיל ומסך הנעילה פתוח.

(שימו לב: אין קישורים זמינים לכולם למפרטים של JIS,‏ ISO ו-NFC Forum שצוינו למעלה).

בנוסף, הטמעות של מכשירים עשויות לכלול תמיכה בקורא/בכותב בטכנולוגיות MIFARE הבאות.

MIFARE Classic‏ (NXP MF1S503x‏ [Resources, 44],‏ MF1S703x‏ [Resources, 45])
MIFARE Ultralight‏ (NXP MF0ICU1‏ [Resources, 46],‏ MF0ICU2‏ [Resources, 47])
NDEF ב-MIFARE Classic‏ (NXP AN130511‏ [מקורות מידע, 48],‏ AN130411‏ [מקורות מידע, 49])

שימו לב שגרסת Android 4.3 כוללת ממשקי API לסוגי MIFARE האלה. אם הטמעת המכשיר תומכת ב-MIFARE בתפקיד קורא/כותב, היא:

חובה להטמיע את ממשקי ה-API התואמים של Android כפי שמתואר ב-Android SDK
חובה לדווח על התכונה com.nxp.mifare מהשיטה android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37] שימו לב שזו לא תכונה רגילה של Android, ולכן היא לא מופיעה כקבועה בכיתה PackageManager.
אסור להטמיע את ממשקי ה-API התואמים של Android או לדווח על התכונה com.nxp.mifare, אלא אם המערכת מטמיעה גם תמיכה כללית ב-NFC כפי שמתואר בקטע הזה

אם הטמעת המכשיר לא כוללת חומרת NFC, אסור להצהיר על התכונה android.hardware.nfc מהשיטה android.content.pm.PackageManager.hasSystemFeature() [מקורות מידע, 37], וצריך להטמיע את Android 4.3 NFC API כפעולה ללא תוצאה (no-op).

מאחר שהכיתות android.nfc.NdefMessage ו-android.nfc.NdefRecord מייצגות פורמט של ייצוג נתונים שלא תלוי בפרוטוקול, יש להטמיע את ממשקי ה-API האלה בהטמעות של מכשירים, גם אם הן לא כוללות תמיכה ב-NFC או הצהרה על התכונה android.hardware.nfc.

7.4.5. יכולת רשת מינימלית

הטמעות של מכשירים חייבות לכלול תמיכה באחת או יותר מהצורות של רשתות נתונים. באופן ספציפי, הטמעות במכשירים חייבות לכלול תמיכה לפחות בתקן נתונים אחד עם קצב העברה של 200Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישות האלה כוללות את EDGE,‏ HSPA,‏ EV-DO,‏ 802.11g,‏ Ethernet וכו'.

הטמעות של מכשירים שבהם תקן רשת פיזי (כמו Ethernet) הוא חיבור הנתונים הראשי, צריכות לכלול גם תמיכה לפחות בתקן נתונים אלחוטי נפוץ אחד, כמו 802.11‏ (Wi-Fi).

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

7.5. מצלמות

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

7.5.1. מצלמה אחורית

הטמעות של מכשירים צריכות לכלול מצלמה אחורית. אם הטמעת המכשיר כוללת מצלמה אחורית, היא:

חייבת להיות לה רזולוציה של לפחות 2 מגה-פיקסלים
צריכה להיות הטמעה של התכונה 'מיקוד אוטומטי בחומרה' או 'מיקוד אוטומטי בתוכנה' במנהל המצלמה (שקופה לתוכנת האפליקציה)
יכול להיות שיש להם חומרה עם מיקוד קבוע או חומרה עם EDOF (עומק שדה מורחב)
יכול להיות שיכלול הבזק. אם המצלמה כוללת פלאש, אסור שהנורה של הפלאש תידלק בזמן שמופיעה מופע של android.hardware.Camera.PreviewCallback על פני השטח של תצוגה מקדימה של המצלמה, אלא אם האפליקציה הפעלה את הפלאש באופן מפורש על ידי הפעלת המאפיינים FLASH_MODE_AUTO או FLASH_MODE_ON של אובייקט Camera.Parameters. חשוב לדעת שהאילוץ הזה לא חל על אפליקציית המצלמה המובנית של המכשיר, אלא רק על אפליקציות צד שלישי שמשתמשות ב-Camera.PreviewCallback.

7.5.2. מצלמה קדמית

הטמעות של מכשירים עשויות לכלול מצלמה קדמית. אם הטמעה של מכשיר כוללת מצלמה קדמית, היא:

חייבת להיות לה רזולוציה של לפחות VGA (כלומר, 640x480 פיקסלים)
אסור להשתמש במצלמה קדמית כברירת מחדל ל-Camera API. כלומר, ל-Camera API ב-Android 4.3 יש תמיכה ספציפית במצלמות קדמיות, ואסור להגדיר את ה-API בהטמעות של מכשירים כך שיתייחס למצלמה הקדמית כמצלמה האחורית שמוגדרת כברירת מחדל, גם אם היא המצלמה היחידה במכשיר.
יכולות לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות הפונות לאחור, כפי שמתואר בקטע 7.5.1.
חובה לשקף אופקית (כלומר להציג בתמונת מראה) את השידור שמוצג באפליקציה ב-CameraPreview, באופן הבא:

אם אפשר לסובב את הטלפון במהלך ההטמעה במכשיר (למשל באופן אוטומטי באמצעות תאוצה או באופן ידני באמצעות קלט של המשתמש), חובה להציג את התצוגה המקדימה של המצלמה במראה אופקי ביחס לכיוון הנוכחי של המכשיר.
אם האפליקציה הנוכחית ביקשה במפורש שמסך המצלמה יוזז באמצעות קריאה ל-method‏ android.hardware.Camera.setDisplayOrientation() [Resources, 50], תצוגה המקדימה של המצלמה חייבת להיות מוחזרת ביחס אופקית ביחס לכיוון שצוין באפליקציה.
אחרת, חובה לשקף את התצוגה המקדימה לאורך הציר האופקי שמוגדר כברירת מחדל במכשיר.

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

7.5.3. התנהגות Camera API

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

אם אפליקציה אף פעם לא התקשרה ל-android.hardware.Camera.Parameters.setPreviewFormat(int), המכשיר חייב להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני התצוגה המקדימה שסופקו להודעות החזרה (callbacks) של האפליקציה.
אם אפליקציה רושמת מופע של android.hardware.Camera.PreviewCallback והמערכת קוראת לשיטה onPreviewFrame() כשפורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] שמועברים אל onPreviewFrame() חייבים להיות בפורמט הקידוד NV21. כלומר, NV21 חייב להיות ברירת המחדל.
הטמעות במכשירים חייבות לתמוך בפורמט YV12 (כפי שמצוין בערך הקבוע android.graphics.ImageFormat.YV12) לקטע המקדים של התמונה במצלמה, גם במצלמה הקדמית וגם במצלמה האחורית. (המצלמה והקודק של וידאו בחומרה יכולים להשתמש בכל פורמט פיקסלים מקורי, אבל ההטמעה במכשיר חייבת לתמוך בהמרה ל-YV12).

הטמעות במכשירים חייבות ליישם את Camera API המלא שכלול במסמכי התיעוד של Android 4.3 SDK‏ [משאבים, 51], ללא קשר לכך שהמכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא מיקוד אוטומטי עדיין חייבות לקרוא לכל המכונות הרשמות של android.hardware.Camera.AutoFocusCallback (למרות שאין לכך רלוונטיות למצלמה ללא מיקוד אוטומטי). שימו לב שההנחה הזו רלוונטית גם למצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך "לזייף" את קריאות החזרה של ה-API כפי שמתואר.

הטמעות של מכשירים חייבות לזהות כל שם פרמטר שמוגדר כקבוע במחלקה android.hardware.Camera.Parameters ולכבד אותו, אם החומרה הבסיסית תומכת בתכונה. אם חומרת המכשיר לא תומכת בתכונה מסוימת, ה-API צריך לפעול כפי שמתואר במסמכים. לעומת זאת, בהטמעות במכשירים אסור להכיר או לכבד קבועות מחרוזת שמועברות ל-method‏ android.hardware.Camera.setParameters(), מלבד אלה שמתועדות כקבועות ב-android.hardware.Camera.Parameters. כלומר, הטמעות במכשירים חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה, אם החומרה מאפשרת זאת, ואסור להן לתמוך בסוגי פרמטרים מותאמים אישית של מצלמה. לדוגמה, הטמעות של מכשירים שתומכות בצילום תמונות באמצעות שיטות צילום עם טווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר המצלמה Camera.SCENE_MODE_HDR‏[מקורות מידע, 78]).

הטמעות במכשירים חייבות לשדר את הכוונה Camera.ACTION_NEW_PICTURE בכל פעם שצולמת תמונה חדשה במצלמה והרשומה של התמונה נוספה למאגר המדיה.

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

7.5.4. כיוון המצלמה

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

7.6. זיכרון ואחסון

7.6.1. נפח זיכרון ואחסון מינימלי

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

בהטמעות במכשירים חייב להיות לפחות 512MB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה. כלומר, מחיצה /data חייבת להיות לפחות 512MB. אנחנו מומלצים מאוד להשתמש במכשירים עם Android 4.3 עם לפחות 1GB של אחסון לא נדיף לנתונים הפרטיים של האפליקציה, כדי שתוכלו לשדרג אותם לגרסאות העתידיות של הפלטפורמה.

ממשקי ה-API של Android כוללים מנהל הורדות שאפליקציות יכולות להשתמש בו כדי להוריד קובצי נתונים [משאבים, 56]. הטמעת מנהל ההורדות במכשיר חייבת לאפשר להוריד קבצים בודדים בגודל של 100MB לפחות למיקום ברירת המחדל 'מטמון'.

7.6.2. אחסון משותף של אפליקציות

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

בהטמעות של מכשירים חובה להגדיר אחסון משותף שמחובר כברירת מחדל, "מחוץ לקופסה". אם האחסון המשותף לא מוצמד לנתיב /sdcard ב-Linux, המכשיר חייב לכלול קישור סימבולי של Linux מ-/sdcard לנקודת הצירוף בפועל.

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

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

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

הטמעת המכשיר אמורה להיות תואמת למארח ה-MTP של Android, Android File Transfer‏ [משאבים, 57].
הטמעת המכשיר אמורה לדווח על סוג מכשיר USB מסוג 0x00.
הטמעת המכשיר אמורה לדווח על שם ממשק USB מסוג MTP.

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

כדאי להביא שתי דוגמאות נפוצות. אם הטמעת המכשיר כוללת חריץ לכרטיס SD כדי לעמוד בדרישת האחסון המשותף, חובה לכלול במכשיר כרטיס SD בנפח 1GB או יותר בפורמט FAT, כפי שהוא נמכר למשתמשים, וחובה לחבר אותו כברירת מחדל. לחלופין, אם הטמעה של מכשיר משתמשת באחסון פנימי קבוע כדי לעמוד בדרישות האלה, נפח האחסון חייב להיות 1GB או יותר, והוא חייב להיות מותקן ב-/sdcard (או ש-/sdcard חייב להיות קישור סימבולי למיקום הפיזי אם הוא מותקן במקום אחר).

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

7.7. USB

הטמעות של מכשירים אמורות לכלול יציאת לקוח USB ויציאת מארח USB.

אם הטמעת המכשיר כוללת יציאת לקוח USB:

היציאה חייבת להיות מתחברת למארח USB עם יציאת USB-A רגילה
היציאה אמורה להשתמש בפורמט micro USB בצד המכשיר. אנחנו ממליצים מאוד למכשירים קיימים וחדשים עם Android 4.3 לעמוד בדרישות האלה ב-Android 4.3 כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
היציאה אמורה להיות ממוקמת במרכז הקצה. בהטמעות של מכשירים, צריך למקם את היציאה בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או להפעיל סיבוב של המסך בתוכנה בכל האפליקציות (כולל מסך הבית), כדי שהמסך יוצג בצורה נכונה כשהמכשיר מונח כך שהיציאה נמצאת בתחתית. במכשירים קיימים וחדשים עם Android 4.3, מומלץ מאוד לעמוד בדרישות האלה ב-Android 4.3 כדי שתוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
אם יש במכשיר יציאות אחרות (כמו יציאת טעינה שאינה USB), היא אמורה להיות באותו קצה כמו יציאת ה-micro-USB
המכשיר חייב לאפשר למארח שמחובר אליו לגשת לתוכן של נפח האחסון המשותף באמצעות אחסון בנפח גדול ב-USB או באמצעות Media Transfer Protocol (פרוטוקול העברת מדיה).
חובה להטמיע את המפרט ואת ה-API של Android Open Accessory כפי שמתואר במסמכי התיעוד של Android SDK, וצריך להצהיר על תמיכה בתכונה החומרה android.hardware.usb.accessory [משאבים, 52]
חובה להטמיע את ה-USB audio class כפי שמתואר במסמכי התיעוד של Android SDK‏ [Resources, 66]
צריך להטמיע תמיכה במפרט הטעינה של סוללות USB‏ [מקורות מידע, 64] מכשירים קיימים וחדשים עם Android 4.3 מומלצים מאוד לעמוד בדרישות האלה ב-Android 4.3 כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה

אם הטמעת המכשיר כוללת יציאת מארח USB:

יכול להיות שייעשה שימוש בפורמט יציאה לא סטנדרטי, אבל אם כן, חובה לשלוח את המכשיר עם כבל או כבלים שמתאימים את היציאה ל-USB-A סטנדרטי.
חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וצריך להצהיר על תמיכה בתכונה החומרה android.hardware.usb.host [Resources, 53]

בהטמעות של מכשירים חובה להטמיע את Android Debug Bridge. אם הטמעת המכשיר משמיטה יציאת לקוח USB, חובה להטמיע את Android Debug Bridge דרך רשת מקומית (כמו Ethernet או 802.11)

8. תאימות לביצועים

הטמעות של מכשירים חייבות לעמוד במדדי הביצועים העיקריים של מכשיר תואם ל-Android 4.3, כפי שמפורטים בטבלה הבאה:

מדד	סף ביצועים	תגובות
שעת ההשקה של האפליקציה	האפליקציות הבאות אמורות להשיק בזמן שצוין. דפדפן: פחות מ-1,300 אלפיות שנייה אנשי קשר: פחות מ-700 אלפיות השנייה הגדרות: פחות מ-700 אלפיות השנייה	זמן ההפעלה נמדד כזמן הכולל לטעינת פעילות ברירת המחדל של האפליקציה, כולל הזמן שנדרש להפעלת תהליך Linux, לטעינת חבילת Android במכונה הווירטואלית של Dalvik ולקריאה ל-onCreate.
בקשות בו-זמניות	כשמפעילים כמה אפליקציות, הפעלה מחדש של אפליקציה שכבר פועלת צריכה להימשך פחות מזמן ההפעלה המקורי.

9. תאימות של מודל האבטחה

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

9.1. הרשאות

הטמעות במכשירים חייבות לתמוך במודל ההרשאות של Android כפי שמוגדר במסמכי התיעוד למפתחים של Android‏ [משאבים, 54]. באופן ספציפי, ההטמעות חייבות לאכוף כל הרשאה שמוגדרת כפי שמתואר במסמכי התיעוד של ה-SDK. אסור להשמיט, לשנות או להתעלם מהרשאות. אפשר להוסיף הרשאות נוספות להטמעות, בתנאי שמחרוזות מזהה ההרשאה החדשות לא נמצאות במרחב השמות android.*.

9.2. בידוד של UID ותהליכים

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

9.3. הרשאות למערכת הקבצים

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

9.4. סביבות הפעלה חלופיות

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

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

אסור להעניק לממשקי זמן ריצה חלופיים גישה למשאבים שמוגנים באמצעות הרשאות שלא נשלחו בבקשה בקובץ AndroidManifest.xml של סביבת זמן הריצה, באמצעות המנגנון <uses-permission>.

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

סביבות זמן ריצה חלופיות חייבות לציית למודל של ארגז החול של Android. פרטים נוספים:

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

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

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

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

9.5. תמיכה בכמה משתמשים

ב-Android 4.3 יש תמיכה במספר משתמשים ותמיכה בבידוד מלא של משתמשים [מקורות מידע, 70].

הטמעות של מכשירים חייבות לעמוד בדרישות הבאות שקשורות לתמיכה בכמה משתמשים [משאבים, 71]:

מכיוון שההתנהגות של ממשקי ה-API של הטלפון במכשירים עם כמה משתמשים לא מוגדרת כרגע, בממשקי מכשיר שמצהירים על android.hardware.telephony אסור להפעיל תמיכה בכמה משתמשים.
הטמעות במכשירים חייבות ליישם לכל משתמש מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות בממשקי ה-API [משאבים, 54]
ב-Android 4.3 יש תמיכה בפרופילים מוגבלים. זוהי תכונה שמאפשרת לבעלי המכשיר לנהל משתמשים נוספים ואת היכולות שלהם במכשיר. בעזרת פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות למשתמשים נוספים, ולנהל הגבלות מפורטות יותר על האפליקציות שזמינות בסביבות האלה. הטמעות של מכשירים שכוללות תמיכה במספר משתמשים חייבות לכלול תמיכה בפרופילים מוגבלים. בפרויקט קוד הפתוח של Android, שנמצא ב-upstream, יש הטמעה שעומדת בדרישות האלה.

לכל מופע משתמש במכשיר Android חייבות להיות ספריות אחסון חיצוניות נפרדות ומבודדות. הטמעות במכשירים עשויות לאחסן נתונים של כמה משתמשים באותו נפח או באותה מערכת קבצים. עם זאת, ההטמעה במכשיר חייבת להבטיח שאפליקציות שנמצאות בבעלות של משתמש מסוים ופועלות בשם המשתמש הזה לא יכולות להכין רשימה של נתונים שנמצאים בבעלות של משתמש אחר, לקרוא אותם או לכתוב בהם. חשוב לזכור שמדיה נשלפת, כמו חריצי כרטיסי SD, יכולה לאפשר למשתמש אחד לגשת לנתונים של משתמש אחר באמצעות מחשב מארח. לכן, הטמעות של מכשירים שמשתמשות במדיה נשלפת לממשקי ה-API של האחסון החיצוני חייבות להצפין את התוכן של כרטיס ה-SD אם מופעלת תמיכה בכמה משתמשים, באמצעות מפתח שנשמר רק במדיה שלא ניתן להסיר ושרק למערכת יש גישה אליה. מכיוון שהדבר ימנע מ-PC מארח לקרוא את המדיה, תצטרכו להעביר את הטמעות המכשירים ל-MTP או למערכת דומה כדי לספק למחשבים המארחים גישה לנתונים של המשתמש הנוכחי. בהתאם, אפשר להפעיל את התכונה 'שימוש בכמה משתמשים' בהטמעות של מכשירים, אבל לא מומלץ לעשות זאת אם הם משתמשים במדיה נשלפת [משאבים, 72] לאחסון חיצוני ראשי. ב-upstream של Android Open Source Project יש הטמעה שמשתמשת באחסון הפנימי של המכשיר לממשקי API לאחסון חיצוני של אפליקציות. מומלץ להשתמש בהגדרה הזו ובהטמעת התוכנה הזו בהטמעות של מכשירים. בהטמעות של מכשירים שכוללות כמה נתיבים לאחסון חיצוני, אסור לאפליקציות ל-Android לכתוב באחסון החיצוני המשני.

9.6. אזהרה לגבי SMS פרימיום

מערכת Android 4.3 כוללת תמיכה באזהרה למשתמשים על כל הודעת SMS פרימיום יוצאת [מקורות מידע, 73] . הודעות Premium SMS הן הודעות טקסט שנשלחות לשירות רשום אצל ספק, שעשויות לגרום לחיוב של המשתמש. הטמעות במכשירים שמצהירות על תמיכה ב-android.hardware.telephony חייבות להזהיר את המשתמשים לפני שליחת הודעת SMS למספרים שזוהו באמצעות ביטויים רגולריים שהוגדרו בקובץ /data/misc/sms/codes.xml במכשיר. ב-upstream של פרויקט Android Open Source יש הטמעה שעומדת בדרישות האלה.

9.7. תכונות אבטחה בליבה

Sandbox של Android ב-Android 4.3 כולל תכונות שיכולות להשתמש במערכת אמצעי הבקרה (MAC) החובה של SELinux ובתכונות אבטחה אחרות בליבה של Linux. הטמעות במכשירים חייבות לתמוך ב-SELinux MAC. שימו לב שבפרויקט הקוד הפתוח של Android יש הטמעה שעומדת בדרישות האלה.

SELinux או כל תכונות אבטחה שמוטמעות מתחת למסגרת של Android חייבות לשמור על תאימות לאפליקציות קיימות. התכונות האלה אמורות להיות בלתי גלויות למשתמשים ולמפתחים. אסור שהמשתמשים או המפתחים יוכלו להגדיר את התכונות האלה. אם ממשק API כלשהו להגדרת מדיניות חשוף לאפליקציה שיכולה להשפיע על אפליקציה אחרת (למשל Device Administration API), אסור שממשק ה-API יאפשר הגדרות שמשביתות את התאימות. כדי להבטיח תאימות מתמשכת, ההטמעה של ההפניה מאפשרת להשתמש ב-SELinux במצב מתיר ותומכת בעדכוני מדיניות דינמיים בלי צורך לעדכן את קובץ האימג' של המערכת. הטמעות של מכשירים באמצעות SELinux חייבות לתמוך במצב ההרשאה הזה, לתמוך בעדכוני מדיניות דינמיים ולתעד כל הפרות מדיניות בלי לשבור אפליקציות או להשפיע על התנהגות המערכת. בהטמעות שמשתמשות ב-SELinux, צריך לטעון את המדיניות מקובץ /sepolicy במכשיר. ב-upstream של פרויקט Android Open Source יש הטמעה שעומדת בדרישות האלה. בהטמעות במכשירים, כדאי להשתמש בהטמעת העזרה בפרויקט הקוד הפתוח של Android, והן חייבות להיות תואמות לקוד המקור בפרויקט הקוד הפתוח של Android.

10. בדיקת תאימות של תוכנות

הטמעות של מכשירים חייבות לעבור את כל הבדיקות שמתוארות בקטע הזה.

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

10.1. חבילה לבדיקות תאימות (CTS)

הטמעות של מכשירים חייבות לעבור את Android Compatibility Test Suite‏ (CTS)‏[מקורות מידע, 2] שזמין בפרויקט Android Open Source, באמצעות תוכנת האספקה הסופית במכשיר. בנוסף, למטמיעים של מכשירים מומלץ להשתמש בהטמעת העזר ב-Android Open Source Tree ככל האפשר, וחובה להבטיח תאימות במקרים של עמימות ב-CTS ובכל הטמעה מחדש של חלקים מקוד המקור של העזר.

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

10.2. CTS Verifier

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

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

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

10.3. אפליקציות עזר

מחשבי המכשיר חייבים לבדוק את תאימות ההטמעה באמצעות האפליקציות הבאות בקוד פתוח:

האפליקציות 'אפליקציות ל-Android' [משאבים, 55]
Replica Island (זמינה בחנות Google Play)

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

11. תוכנה שניתן לעדכן

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

אפשר להשתמש בכל שיטה, בתנאי שהיא יכולה להחליף את כל התוכנות שמותקנות מראש במכשיר. לדוגמה, כל אחת מהגישות הבאות תעמוד בדרישות האלה:

הורדות Over-the-air (OTA) עם עדכון אופליין באמצעות הפעלה מחדש
עדכונים 'מחוברים' בחיבור USB ממחשב מארח
עדכונים 'אופליין' באמצעות הפעלה מחדש ועדכון מקובץ באחסון נשלף

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

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

12. יצירת קשר

אפשר לפנות למחברים של המסמך בכתובת compatibility@android.com כדי לקבל הבהרות ולדווח על בעיות שלא מופיעות במסמך.

הגדרת תאימות ל-Android 4.3 קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

תוכן העניינים

1. מבוא