הגדרת התאימות ל-Android 4.1
גרסה 3
תאריך העדכון האחרון: 24 יוני 2013
זכויות הבעלות הכוללות שייכות ל-Google Inc. © 2012.
compatibility@android.com
תוכן העניינים
1. מבוא
2. מקורות מידע
3. תוכנה
3.1. ניהול תאימות של ממשקי API
3.2. תאימות Soft API
3.2.1. הרשאות
3.2.2. פרמטר buildrs
3.2.3. תאימות לכוונה
3.2.3.1. Core Application Intents
3.2.3.2. שינוי של כוונת הרכישה
3.2.3.3. מרחבי שמות של כוונות
3.2.3.4. שידור כוונות
3.3. תאימות API מקורי
3.3.1 Application Binary Interfaces
3.4. תאימות לאינטרנט
3.4.1. תאימות WebView
3.4.2. תאימות לדפדפנים
3.5. תאימות התנהגות של API
3.6. מרחבי שמות של ממשקי API
3.7. תאימות למכונות וירטואליות
3.8. תאימות לממשק המשתמש
3.8.1. ווידג'טים
3.8.2. התראות
3.8.3. חיפוש
3.8.4. הודעות קופצות
3.8.5. עיצובים
3.8.6. Live Wal papers
3.8.7. תצוגת האפליקציות האחרונות
3.8.8. ניהול קלט הגדרות
3.8.9. שליטה מרחוק במסך הנעילה
3.9 ניהול המכשיר
3.10 נגישות
3.11 המרת טקסט לדיבור
4. תאימות של אריזת אפליקציה
5. תאימות למולטימדיה
5.1. קודקי מדיה
5.2. קידוד וידאו
5.3. הקלטת אודיו
5.4. זמן אחזור אודיו
5.5. פרוטוקולים לרשת
6. תאימות כלים למפתחים
7. תאימות חומרה
7.1. תצוגה וגרפיקה
7.1.1. הגדרתהמסך
7.1.2. מדדי רשת המדיה
7.1.3. כיוון המסך
7.1.4. תאימות גרפיקה 2D ו-3D
7.1.5. מצב תאימות של אפליקציה קודמת7.1.6.
סוגי מסכים
7.1.7. טכנולוגיית מסך
7.2. בput Devices
7.2.1. מקלדת
7.2.2. ניווט ללא מגע
7.2.3. מקשי ניווט
7.2.4. קלט ממסך מגע
7.2.5. קלט מגע מזויף
7.2.6. מיקרופון
7.3. חיישנים
7.3.1. מד תאוצה
7.3.1. תאוצה
7.3.2. מגנטומטר
7.3.3. GPS
7.3.4. ג'ירוסקופ
7.3.5. Barometer
7.3.6. תרמומטר
7.3.7. פוטומטרים
7.3.8. חיישן קרבה
7.4. קישוריות נתונים
7.4.1. טלפוניה
7.4.2. IEEE 802.11 (WiFi)
7.4.2.1. Wi-Fi ישיר
7.4.3. Bluetooth
7.4.4. תקשורת מטווח קצר
7.4.5. יכולת רשת מינימלית
7.5. ameras
7.5.1. מצלמה אחורית
7.5.2. מצלמה קדמית
7.5.3. התנהגות Camera API
7.5.4. כיוון המצלמה
7.6. זיכרון ואחסון
7.6.1. זיכרון ואחסון מינימלי
7.6.2. אחסון משותף של אפליקציה
7.7. USB
8. תאימות ביצועים
9. תאימות למודל אבטחה
9.1. הרשאות
9.2. בידוד של UID ותהליכים
9.3. הרשאות מערכת הקבצים
9.4. סביבות הפעלה חלופיות
10. בדיקת תאימות תוכנה
10.1. חבילה לבדיקות תאימות (CTS)
10.2. CTS Verifier
10.3. אפליקציות עזר
11. תוכנה ניתנת לעדכון
12. יצירת קשר איתנו
נספח א - נוהל הבדיקה של Bluetooth
1. מבוא
במסמך הזה מפורטות הדרישות שצריך לעמוד בהן כדי שהמכשירים
יהיו תואמים ל-Android 4.1.
השימוש במילים 'חובה', 'אסור', 'נדרש', 'צריך', 'אסור', 'צריך',
'מומלץ', 'יכול' ו'אופציונלי' הוא בהתאם לתקן IETF שמוגדר ב-RFC2119
[מקורות מידע, 1].
במסמך הזה, הביטוי 'מפעיל מכשיר' או 'מפעיל' מתייחס לאדם או
לארגון שמפתחים פתרון חומרה/תוכנה שפועל ב-Android 4.1. 'הטמעה
במכשיר' או 'הטמעה' היא הפתרון לחומרה או לתוכנה שפותח.
כדי להיחשב כמכשיר תואם ל-Android 4.1, הטמעות המכשיר חייבות לעמוד
בדרישות שמוצגות בהגדרת התאימות הזו, כולל כל המסמכים
שמשולבים באמצעות הפניה.
אם ההגדרה הזו או בדיקות התוכנה המתוארות בקטע 10 לא מפורטות,
לא ברורות או לא מלאות, האחריות על הטמעת המכשיר היא לוודא
תאימות להטמעות הקיימות.
לכן, פרויקט הקוד הפתוח של Android [מקורות, 3] הוא גם הקוד המקורי
וגם ההטמעה המועדפת של Android. מפתחי המכשיר מומלצים
לבסס את ההטמעות שלהם עד כמה שאפשר על קוד המקור 'במעלה הזרם' שזמין בפרויקט Android Open Source.
אפשר להחלפה תיאורטית חלק
מהרכיבים בהטמעות חלופיות, אבל לא מומלץ לעשות זאת, כי הצלחה במבחני התוכנה תהיה
קשה
משמעותית יותר. האחריות של מי שמטמיע את ה-API היא לוודא
תאימות התנהגותית מלאה להטמעה הרגילה של Android, כולל
חבילה לבדיקות תאימות (CTS) ומעבר לה. לבסוף, חשוב לזכור שהחלפות ו
שינויים של רכיבים מסוימים אסורים באופן מפורש לפי המסמך הזה.
2. מקורות מידע
1. רמות הדרישה של IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. סקירה כללית על תוכנית התאימות של Android:
http://source.android.com/compatibility/index.html
3. פרויקט קוד פתוח של Android: http://source.android.com/
4. הגדרות ומסמכי תיעוד של API:
http://developer.android.com/reference/packages.html
5. מידע על ההרשאות ב-Android:
http://developer.android.com/reference/android/Manifest.permission.html
6. מידע על android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7. Android 4.1 al owed version strings:
http://source.android.com/compatibility/4.1/versions.html
8. Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9. שיפור המהירות באמצעות חומרה:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10. הקלאס android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12. יכולות אופליין של HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13. תג וידאו ב-HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14. HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/
15. מסד נתונים באינטרנט A של HTML5/W3CPI: http://www.w3.org/TR/webdatabase/
16. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17. מפרט המכונה הווירטואלית של Dalvik: זמין בקוד המקור של Android,בכתובת
dalvik/docs
18. AppWidgets:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19. התראות:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20. משאבי אפליקציה: http://code.google.com/android/reference/available-
resources.html
21. מדריך סגנון סמל בשורת הסטטוס:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22. Search Manager:
http://developer.android.com/reference/android/app/SearchManager.html
23. הודעות Toast: http://developer.android.com/reference/android/widget/Toast.html
24. עיצובים: http://developer.android.com/guide/topics/ui/themes.html
25. הקלאס R.style: http://developer.android.com/reference/android/R.style.html
26. Live Wal papers: http://developer.android.com/resources/articles/live-
wal papers.html
27. ניהול מכשירי Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28. הקלאס android.app.admin.DevicePolicyManager:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29. ממשקי API של Android Accessibility Service:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30. Android Accessibility APIs:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31. פרויקט Eyes Free: http://code.google.com/p/eyes-free
32. ממשקי API להמרת טקסט לדיבור:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33. מאמרי עזרה של הכלים (adb, aapt, dms):
http://developer.android.com/guide/developing/tools/index.html
34. תיאור קובץ apk של Android:
http://developer.android.com/guide/topics/fundamentals.html
35. קובצי מניפסט: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36. כלי בדיקה של Monkey:
https://developer.android.com/studio/test/other-testing-tools/monkey
37. רשימת התכונות של החומרה והכיתה android.content.pm.PackageManager
ב-Android
http://developer.android.com/reference/android/content/pm/PackageManager.html
38. תמיכה במספר מסכים:
http://developer.android.com/guide/practices/screens_support.html
39. android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40. android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41. android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42. Bluetooth API:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43. פרוטוקול Push של NDEF: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47. MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48. MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49. MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50. API לכיוון המצלמה:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51. android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52. Android Open Accessories:
http://developer.android.com/guide/topics/usb/accessory.html
53. USB Host API: http://developer.android.com/guide/topics/usb/host.html
54. מידע על אבטחה והרשאות ב-Android:
http://developer.android.com/guide/topics/security/security.html
55. אפליקציות ל-Android: http://code.google.com/p/apps-for-android
56. הקלאס android.app.DownloadManager:
http://developer.android.com/reference/android/app/DownloadManager.html
57. Android File Transfer: http://www.android.com/filetransfer
58. פורמטים של מדיה ב-Android: http://developer.android.com/guide/appendix/media-
formats.html
59. פרוטוקול Draft ל-HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60. העברת חיבור ב-NFC: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61. התאמה פשוטה ומאובטחת של Bluetooth באמצעות NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62. Wifi Multicast API:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
63. Action Assist:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64. מפרט טעינה USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66. אודיו ב-USB ב-Android:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67. הגדרות שיתוף ה-NFC ב-Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68. Wi-Fi Direct (Wi-Fi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69. Media Remote Control Client:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70. Motion Event API:
http://developer.android.com/reference/android/view/MotionEvent.html
71. הגדרת קלט מגע: http://source.android.com/tech/input/touch-
devices.html
חלק גדול מהמקורות האלה נגזרים ישירות או בעקיפין מ-Android 4.1 SDK,
והם יהיו פונקציונליים זהים למידע שבדוקומנטציה של ה-SDK. בכל
מקרה שבו הגדרת התאימות הזו או חבילת המבחנים לתאימות לא תואמות
למסמכי התיעוד של ה-SDK, מסמכי התיעוד של ה-SDK נחשבים למקוריים.
כל הפרטים הטכניים שסופקו במקורות המידע שכללו למעלה נחשבים
לחלק מההגדרה הזו של תאימות.
3. תוכנה
3.1. תאימות API מנוהלת
סביבת ההרצה המנוהלת (מבוססת-Dalvik) היא הכלי הראשי לאפליקציות Android
. ממשק תכנות האפליקציות (API) של Android הוא קבוצת ממשקי הפלטפורמה של
Android שחשופים לאפליקציות שפועלות בסביבה המנוהלת של
VM. הטמעות במכשירים חייבות לספק הטמעות מלאות,
כולל כל ההתנהגויות המתוועדות, של כל API מתועד שחשוף על ידי Android
4.1 SDK [מקורות מידע, 4].
הטמעות של מכשירים Mאסור להשמיט אף ממשק API מנוהל, לשנות ממשקי API או
חתימות, לסטות מההתנהגות המתוועדת או לכלול פעולות חסרות תוכן, למעט במקרים
ספציפיים שמתירים כך בהגדרת התאימות הזו.
הגדרת התאימות הזו מאפשרת להחמיץ ממשקי API מסוימים של Android
בהטמעות של מכשירים מסוימים. במקרים כאלה, חיוני
ש-APIs יהיו עדיין קיימים וייפעלו בצורה סבירה. בקטע 7 מפורטות
הדרישות הספציפיות לתרחישים כאלה.
3.2. תאימות ל-API רך
בנוסף לממשקי ה-API המנוהלים שמפורטים בקטע 3.1, Android כולל גם ממשק API 'רך' משמעותי
שזמין רק בסביבת זמן הריצה, בצורה של דברים כמו כוונות (Intents), הרשאות ו
מאפיינים דומים של אפליקציות Android שלא ניתן לאכוף בזמן הידור
האפליקציה.
3.2.1. הרשאות
מפתחי מכשירים חייבים לתמוך בכל קבועי ההרשאות ואכיף אותם, כפי ש
מתועד בדף העזרה בנושא הרשאות [מקורות, 5]. לתשומת ליבכם: בסעיף 10
מפורטות דרישות נוספות שקשורות למודל האבטחה של Android.
3.2.2. פרמטרים של גרסה
ממשקי ה-API של Android כוללים מספר קבועים בכיתה android.os.Build
[Resources, 6] שנועדו לתאר את המכשיר הנוכחי. כדי לספק ערכים עקביים ו
משמעותיים בכל הטמעות המכשירים,הטבלה הבאה כוללת
הגבלות נוספות על הפורמטים של הערכים האלה, שאליהם הטמעות המכשירים חייבות
לציית.
פרמטר
הערות
הגרסה של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. השדה הזה חייב לכלול
android.os.Build.VERSION.RELEASE
אחד מערכים של מחרוזות שהוגדרו בקטע [Resources, 7].
הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות צד שלישי.
android.os.Build.VERSION.SDK
ב-Android 4.1, השדה הזה חייב לכלול את הערך השלם 16.
הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי.
android.os.Build.VERSION.SDK_INT
ב-Android 4.1, השדה הזה חייב לכלול את הערך השלם 16.
ערך שנבחר על ידי מפתח המכשיר שמציין את גרסת ה-build הספציפית של מערכת Android
שפועלת כרגע, בפורמט קריא לבני אדם. אסור להשתמש שוב בערך הזה ב-builds שונים שזמינים למשתמשי קצה של
android.os.Build.VERSION.INCREMENTAL
. השימוש האופטימלי בשדה הזה הוא כדי לציין איזה מספר גרסה או מזהה שינוי בבקרת מקורות הקוד
שימש ליצירת הגרסה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, חוץ מזה שאסור
להיות nul או המחרוזת הריקה ("").
ערך שנבחר על ידי מפתח המכשיר שמזהה את חומרת הפנימית הספציפית שנעשה בה שימוש במכשיר, ב
פורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של המעבד
android.os.Build.BOARD
שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCI בן 7 ביט ולהתאים לביטוי הרגולרי
"^[a-zA-Z0-9.,_-]+$".
ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את השם של החברה, הארגון, האדם הפרטי וכו'
שמייצרים את המכשיר, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את יצרן הציוד המקורי
android.os.Build.BRAND
ו/או את הספק שמכרו את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCI בן 7 ביט, ותואם ל
ביטוי הרגולרי "^[a-zA-Z0-9.,_-]+$".
השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של הקוד המקורי.ראו קטע 3.3: תאימות
android.os.Build.CPU_ABI
לממשק API מקורי.
השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של הקוד המקורי. ראו קטע 3.3: תאימות I
android.os.Build.CPU_ABI2
ל-AP.
ערך שנבחר על ידי מי שמטמיע את המכשיר, ומזהה את ההגדרה או הגרסה הספציפית של הגוף
android.os.Build.DEVICE
(לפעמים נקרא 'עיצוב תעשייתי') של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-
ASCI בן 7 ביט, ותואם לביטוי הרגולרי '^[a-zA-Z0-9.,_-]+$'.
מחרוזת שמזהה באופן ייחודי את ה-build הזה. היא צריכה להיות קריאה באופן סביר לבני אדם. היא חייבת לעמוד בפורמט הזה
:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
לדוגמה:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
ה-fingerprint אסור לכלול תווי רווח. אם יש בשדות אחרים שכלולים בתבנית שלמעלה
תווים של רווח לבן, חובה להחליף אותם בטביעת האצבע של ה-build בתווית אחרת, כמו התו
קו תחתי ("_"). הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCI בן 7 ביט.
השם של החומרה (משורת הפקודה של הליבה או מ-/proc). הוא צריך להיות קריא במידה סבירה
android.os.Build.HARDWARE
לאנשים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCI בן 7 ביט ולהתאים לביטוי הרגולרי ^[a-
zA-Z0-9.,_-]+$.
מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט שקריא לבני אדם. אין
דרישות
ל-android.os.Build.HOST
לגבי הפורמט הספציפי של השדה הזה, חוץ מזה שאסור שיהיה nul או המחרוזת הריקה ("").
מזהה שנבחר על ידי מפתח המכשיר כדי להפנות לגרסת build ספציפית, בפורמט שקריא לבני אדם. השדה
הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל צריך להגדיר ערך
android.os.Build.ID
משמעותי כדי שמשתמשי קצה יוכלו להבחין בין גרסאות build של תוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד
כ-ASCI בן 7 ביט, ולהתאים לביטוי הרגולרי ^[a-zA-Z0-9.,_-]+$.
השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות על
android.os.Build.MANUFACTURER
הפורמט הספציפי של השדה הזה, חוץ מזה שאסור שיהיה nul או המחרוזת הריקה ("").
ערך שנבחר על ידי מפתח המכשיר שמכיל את השם של המכשיר כפי שידוע למשתמש הסופי. הערך של
android.os.Build.MODEL
צריך להיות זהה לשם שמשמש לשיווק ולמכירה של המכשיר למשתמשי קצה. אין
דרישות לגבי הפורמט הספציפי של השדה הזה, חוץ מזה שאסור שיהיה ערך nul או המחרוזת הריקה ("").
ערך שנבחר על ידי מפתח המכשיר שמכיל את שם הפיתוח או שם הקוד של המוצר
android.os.Build.PRODUCT
(SKU). היא חייבת להיות קריאה לבני אדם, אבל לא היא מיועדת לצפייה על ידי משתמשי קצה. הערך בשדה
חייב להיות ניתן לקידוד כ-ASCI בן 7 ביט, ולהתאים לביטוי הרגולרי ^[a-zA-Z0-9.,_-]+$.
מספר סידורי של חומרה, אם הוא זמין. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCI בן 7 ביט, ולהתאים
android.os.Build.SERIAL
לביטוי הרגולרי "^([a-zA-Z0-9]{0,20})$".
רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, ומשמשים להבדלה נוספת בין גרסאות build. לדוגמה,
android.os.Build.TAGS
"unsigned,debug". הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCI בן 7 ביט, ותואם לביטוי הרגולרי
"^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME
ערך שמייצג את חותמת הזמן של מועד ה-build.
ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את הגדרת זמן הריצה של ה-build. השדה הזה
צריך לכלול אחד מהערכים התואמים לשלושת ההגדרות הנפוצות של סביבת זמן הריצה של Android: "user",
android.os.Build.TYPE
"userdebug", או "eng". הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCI בן 7 ביט ולהתאים לביטוי הרגולרי
^[a-zA-Z0-9.,_-]+$.
שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות על
android.os.Build.USER
הפורמט הספציפי של השדה הזה, חוץ מזה שאסור שיהיה nul או המחרוזת הריקה ("").
3.2.3. תאימות ל-Intent
הטמעות במכשירים חייבות לכבד את מערכת Intent של Android עם צירוף רופף,
כפי שמתואר בקטעים הבאים. המשמעות של 'הפעלה' היא שהמפתח שמטמיע את המכשיר
חייב לספק פעילות או שירות של Android שמציינים מסנן Intent תואם, ו
מקשרים להתנהגות הנכונה ומטמיעים אותה לכל דפוס Intent שצוין.
3.2.3.1. כוונות מרכזיות של אפליקציות
בפרויקט Android upstream מוגדרות כמה אפליקציות מרכזיות, כמו אנשי קשר,
יומן, גלריית תמונות, נגן מוזיקה וכו'. מפתחי מכשירים יכולים להחליף
את האפליקציות האלה בגרסאות חלופיות.
עם זאת, כל גרסה חלופית כזו חייבת לעמוד באותו דפוס Intent שסופק
על ידי הפרויקט ב-upstream. לדוגמה, אם מכשיר מכיל נגן מוזיקה אלטרנטיבי,
הוא עדיין צריך לעמוד בדרישות של תבנית הכוונה שנשלחת מאפליקציות צד שלישי כדי לבחור שיר.
האפליקציות הבאות נחשבות לאפליקציות ליבה של מערכת Android:
שעון שולחני
דפדפן
יומן
אנשי קשר
גלריה
חיפוש גלובלי
מרכז האפליקציות
מוזיקה
הגדרות
אפליקציות הליבה של מערכת Android כוללות רכיבי פעילות או שירות שונים
שנחשבים "ציבוריים". כלומר, המאפיין "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 האלה, או למנוע מאפליקציות צד שלישי לקשר את עצמן לדפוסים האלה ולשלוט בהם
. האיסור הזה כולל, בין היתר,
השבתה של ממשק המשתמש 'בורר', שמאפשר למשתמש לבחור בין כמה
אפליקציות שמטפלות באותו דפוס Intent.
עם זאת, הטמעות במכשירים עשויות לספק פעילויות ברירת מחדל לדפוסי URI
ספציפיים (למשל http://play.google.com) אם הפעילות שמוגדרת כברירת מחדל מספקת מסנן ספציפי יותר
ל-URI של הנתונים. לדוגמה, מסנן כוונה שמציין את URI הנתונים
"http://www.android.com" ספציפי יותר ממסנן הדפדפן עבור "http://". הטמעות
במכשירים חייבות לספק ממשק משתמש כדי שמשתמשים יוכלו לשנות את הפעילות שמוגדרת כברירת מחדל
לכוונות.
3.2.3.3. מרחבי שמות של Intent
אסור להטמיע במכשירים רכיבים של Android שמכבדים
תבניות חדשות של Intent או של Broadcast Intent באמצעות ACTION, CATEGORY או מחרוזת מפתח
אחרת במרחב השמות android.* או com.android.*. מפתחי מכשירים אסור
לכלול רכיבי Android שמכבדים תבניות חדשות של Intent או Broadcast Intent
באמצעות ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב חבילה ששייך ל
ארגון אחר. מפתחי מכשירים אסור להם לשנות או להרחיב אף אחד מהתבניות של Intent
שנעשה בהן שימוש באפליקציות העיקריות המפורטות בקטע 3.2.3.1. הטמעות במכשירים יכולות
לכלול תבניות Intent באמצעות מרחבי שמות שמשויכים בבירור וללא ספק ל
ארגון שלהן.
האיסור הזה דומה לאיסור שצוין לגבי כיתות של שפת Java בקטע
3.6.
3.2.3.4. שידור Intents
אפליקציות של צד שלישי סומכות על הפלטפורמה כדי לשדר Intents מסוימים כדי להודיע להם
על שינויים בסביבת החומרה או התוכנה. מכשירים תואמים ל-Android
חייבים להעביר את ה-Intents של השידור הציבורי בתגובה לאירועי
מערכת מתאימים. הסבר על כוונות שידור מפורט במסמכי התיעוד של ה-SDK.
3.3. תאימות API מקורי
3.3.1 ממשקי Application Binary
קוד מנוהל שפועל ב-Dalvik יכול להפעיל קוד מקורי שסופק בקובץ ה-
.apk של האפליקציה כקובץ ELF .so שעבר קמפלקציה עבור ארכיטקטורת חומרת המכשיר המתאימה.
קוד מקורי תלוי במידה רבה בטכנולוגיית המעבד הבסיסית, לכן ב-Android
מוגדרים מספר ממשקי Application Binary Interfaces (ABIs) ב-Android NDK, בקובץ
docs/CPU-ARCH-ABIS.html. אם הטמעה של מכשיר תואמת ל-ABI אחד או יותר
שנקבע, צריך להטמיע תאימות עם Android NDK, כפי שמתואר בהמשך.
אם הטמעה של מכשיר כוללת תמיכה ב-ABI של Android, היא:
חייבת לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי להפעיל
קוד native, באמצעות הסמנטיקה הרגילה של Java Native Interface (JNI).
חייבת להיות תואמת למקור (כלומר תואמת לכותרת) ותואמת לבינארי (עבור
ה-ABI) עם כל הספריות הנדרשות ברשימה שלמטה
חייבת לדווח באופן מדויק על Application Binary Interface (ABI) ה-native שתומך
במכשיר, באמצעות ה-API android.os.Build.CPU_ABI
חייבת לדווח רק על ABIs שמתועדים בגרסה העדכנית של Android
NDK, בקובץ docs/CPU-ARCH-ABIS.txt
מומלץ לבנות אותה באמצעות קוד המקור וקובצי הכותרות שזמינים בפרויקט הקוד הפתוח upstream של Android
APIs הקוד ה-native הבאים חייבים להיות זמינים לאפליקציות שכוללות קוד native:
libc (ספריית C)
libm (ספריית מתמטיקה)
תמיכה מינימלית ב-C++
ממשק JNI
liblog (רישום ביומן ב-Android)
libz (דחיסת Zlib)
libdl (מקשר דינמי)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (ניהול פני השטח של OpenGL native)
libjnigraphics.so
libOpenSLES.so (תמיכה באודיו של OpenSL ES 1.0.1)
libOpenMAXAL.so (תמיכה ב-OpenMAX AL 1.0.1)
libandroid.so (תמיכה בפעילות native של Android)
תמיכה ב-OpenGL, כפי שמתואר בהמשך
לתשומת ליבכם: בגרסאות עתידיות של Android NDK עשויה להיכלל תמיכה ב-
ABIs נוספים.
אם הטמעה של מכשיר לא תואמת ל-ABI קיים שהוגדר מראש,
אסור לדווח על תמיכה בכל ABI בכלל .
התאמה של קוד מקורי היא אתגר. לכן, חשוב להדגיש ש
מפתחי מכשירים מומלצים מאוד להשתמש בהטמעות upstream
של הספריות שצוינו למעלה כדי לעזור לוודא תאימות.
3.4. תאימות לאינטרנט
3.4.1. תאימות ל-WebView
ביישום הקוד הפתוח של Android נעשה שימוש במנוע העיבוד של WebKit כדי
להטמיע את android.webkit.WebView. מכיוון שלא אפשר לפתח
חבילת בדיקות מקיפה למערכת עיבוד גרפי באינטרנט, מפתחי מכשירים חייבים להשתמש
בגרסת ה-build הספציפית של WebKit במהלך הטמעת WebView. בפרט:
הטמעות android.webkit.WebView של המכשיר חייבות להתבסס
על גרסת ה-build 534.30 של WebKit מהעץ של Android Open Source upstream
ב-Android 4.1. ה-build הזה כולל קבוצה ספציפית של תיקוני
פונקציונליות ואבטחה ל-WebView. מפתחים שמטמיעים את WebView במכשירים יכולים לכלול בהתאמות אישיות להטמעת
WebKit. עם זאת, ההתאמות האישיות האלה לא יכולות לשנות את
ההתנהגות של WebView, כולל התנהגות הרינדור.
המחרוזת של סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הזה:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של
הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של
android.os.Build.VERSION.RELEASE
הערך של המחרוזת $(LOCALE) צריך לעמוד בהסכמי ISO לגבי
קוד המדינה והשפה, וצריך להתייחס ל-
locale המוגדר הנוכחי של המכשיר
הערך של המחרוזת $(MODEL) חייב להיות זהה לערך של
android.os.Build.MODEL
הערך של המחרוזת $(BUILD) חייב להיות זהה לערך של
android.os.Build.ID
בהטמעות של WebView במכשירים אפשר להשמיט את המילה Mobile במחרוזת של סוכן המשתמש
רכיב WebView צריך לכלול תמיכה בחלקים רבים ככל האפשר של HTML5
[מקורות מידע, 11]
. לפחות, הטמעות במכשירים חייבות לתמוך בכל
ממשקי ה-API האלה שמשויכים ל-HTML5 ב-WebView:
מטמון אפליקציה/פעולה אופליין [מקורות, 12]
התג <video> [מקורות, 13]
מיקום גיאוגרפי [Resources, 14]
בנוסף, הטמעות במכשירים חייבות לתמוך ב-HTML5/W3C webstorage API
[מקורות, 15], ויש לתמוך ב-HTML5/W3C IndexedDB API [מקורות,
16]. שימו לבשגופים שאחראים על תקני פיתוח האינטרנט עוברים תהליך מעבר שבו הם מעדיפים
IndexedDB על פני webstorage, ו-IndexedDB צפוי להפוך לרכיב נדרש
בגרסה עתידית של Android.
ממשקי API של HTML5, כמו כל ממשקי ה-API של JavaScript, חייבים להיות מושבתים כברירת מחדל ב-WebView,
אלא אם המפתח מפעיל אותם באופן מפורש באמצעות ממשקי ה-API הרגילים של Android.
3.4.2. תאימות לדפדפנים
הטמעות במכשירים חייבות לכלול אפליקציית דפדפן עצמאית לגלישה באינטרנט של
משתמשים בכלל. הדפדפן העצמאי יכול להתבסס על טכנולוגיית דפדפן
אחרת מ-WebKit. עם זאת, גם אם משתמשים באפליקציית דפדפן חלופית, רכיב
android.webkit.WebView שסופק לאפליקציות של צד שלישי חייב
להתבסס על WebKit, כפי שמתואר בקטע 3.4.1.
בהטמעות יכולה להופיע מחרוזת בהתאמה אישית של סוכן משתמש באפליקציית
הדפדפן העצמאית.
אפליקציית הדפדפן העצמאית (בין אם היא מבוססת על אפליקציית הדפדפן של WebKit
ב-upstream או על תחליף של צד שלישי) צריכה לכלול תמיכה בחלקים רבים ככל האפשר של
HTML5 [מקורות מידע, 11]. לפחות, הטמעות במכשירים חייבות לתמוך
בכל אחד מממשקי ה-API האלה שמשויכים ל-HTML5:
פעולה במצב אוף-ליין/מטמון אפליקציה [מקורות מידע, 12]
התג <video> [מקורות מידע, 13]
מיקום גיאוגרפי [מקורות מידע, 14]
בנוסף, הטמעות במכשירים חייבות לתמוך ב-HTML5/W3C webstorage API
[מקורות מידע, 15], וצריכות לתמוךב-HTML5/W3C IndexedDB API [מקורות מידע,
16]. הערה: כיוון שגופי התקנים של פיתוח אתרים עוברים לשימוש ב-
IndexedDB במקום ב-webstorage, צפוי ש-IndexedDB יהיה רכיב נדרש
בגרסה עתידית של Android.
3.5. תאימות התנהגותית של API
ההתנהגויות של כל אחד מסוגי ה-API (מנוהל, רך, מקורי ואינטרנט) חייבות להיות
עקביות עם ההטמעה המועדפת של הפרויקט
בקוד פתוח של Android ב-upstream [מקורות מידע, 3]. חלק מאזורי התאימות הספציפיים הם:
אסור שמכשירים ישנו את ההתנהגות או הסמנטיקה של Intent רגיל
אסור שמכשירים ישנו את מחזור החיים או את הסמנטיקה של מחזור החיים של סוג ספציפי
של רכיב מערכת (כמו Service, Activity, ContentProvider וכו')
אסור שמכשירים ישנו את הסמנטיקה של הרשאה רגילה
הרשימה שלמעלה לא מפורטת. חבילה לבדיקות תאימות (CTS) בודקת
חלקים משמעותיים מהפלטפורמה לצורך בדיקת תאימות התנהגותית, אבל לא הכול .
האחריות להבטיח תאימות התנהגותי לפרויקט הקוד הפתוח של Android היא של המטמיע.
לכן, מפתחי מכשירים צריכים להשתמש בקוד
המקור שזמין דרך פרויקט Android Open Source Project במידת האפשר, במקום
להטמיע מחדש חלקים משמעותיים של המערכת.
3.6. מרחבי שמות של ממשקי API
ב-Android פועלים לפי המוסכמות של מרחבי השמות של החבילות והכיתות שמוגדרות בשפת התכנות Java
. כדי לוודא תאימות עם אפליקציות של צד שלישי,
מפתחי המכשירים אסור להם לבצע שינויים אסורים (ראו בהמשך) במרחבי השמות
של החבילות האלה:
java.*
javax.*
sun.*
android.*
com.android.*
שינויים אסורים כוללים:
הטמעות של מכשירים אסור שישנו את ממשקי ה-API שגלויים לציבור ב
פלטפורמת Android על ידי שינוי חתימות של שיטות או כיתות, או על ידי הסרה
של כיתות או שדות של כיתות.
מפתחי הטמעות של מכשירים יכולים לשנות את ההטמעה הבסיסית של ממשקי ה-API, אבל
שינויים כאלה אסור שישפיעו על ההתנהגות המצוינת ועל
החתימה בשפת Java של כל ממשק API שגלוי לציבור.
מפתחי הטמעות של מכשירים אסור שיוסיפו אל
ממשקי ה-API שלמעלה רכיבים שגלויים לציבור (כמו
כיתות או ממשקים, או שדות או שיטות לכיתות או לממשקים קיימים).
'רכיב שחשוף לכולם' הוא כל מבנה שלא מעוטר בסמן
@hide כפי שמשתמשים בו בקוד המקור של Android ב-upstream. כלומר, מפתחי
המכשירים אסור להם לחשוף ממשקי 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 (DEX)
ובסמנטיקה של המכונה הווירטואלית של Dalvik [מקורות מידע, 17].
הטמעות במכשירים חייבות להגדיר את Dalvik כדי להקצות זיכרון בהתאם
לפלטפורמת Android ב-upstream, וכפי שצוין בטבלה הבאה. (הגדרות של גודל המסך ודחיסות המסך מפורטות
בקטע 7.1.1).
לתשומת ליבכם: ערכי הזיכרון שצוינו בהמשך נחשבים לערכים מינימליים, ויכול להיות שבהטמעה של המכשיר יוקצה יותר זיכרון לכל אפליקציה.
גודל מסך
צפיפות מסך
זיכרון אפליקציה
קטן / רגיל / גדול
ldpi / mdpi
16MB
קטן / רגיל / גדול
tvdpi / hdpi
32MB
קטן / רגיל / גדול
xhdpi
64MB
גדול במיוחד
mdpi
32MB
גדול במיוחד
tvdpi / hdpi
64MB
גדול במיוחד
xhdpi
128MB
3.8. תאימות ממשק המשתמש
3.8.1.ווידג'טים
ב-Android מוגדר סוג רכיב ו-API ומחזור חיים תואמים שמאפשרים
לאפליקציות לחשוף 'AppWidget' למשתמש הקצה [מקורות, 18]. הגרסת העזרה של Android
בקוד פתוח כוללת אפליקציית מרכז אפליקציות שכוללת תכונות ממשק
המשתמש שמאפשרות למשתמש להוסיף, להציג ולהסיר AppWidgets מ
מסך הבית.
הטמעות במכשירים עשויות להחליף חלופה ל-Launcher המומלץ (כלומר
מסך הבית). מרכזי התוכנה החלופיים צריכים לכלול תמיכה מובנית ב-AppWidgets,
ולספק למשתמשים אפשרויות ממשק משתמש להוספה, להגדרה, להצגה ולהסרה של
AppWidgets ישירות במרכז התוכנה. אפשר להשמיט מרכזי הפעלה חלופיים את רכיבי
ממשק המשתמש האלה, אבל אם הם יושמט, הטמעת המכשיר חייבת
לספק אפליקציה נפרדת שנגישה ממרכז ההפעלה ומאפשרת למשתמשים להוסיף,
להגדיר, להציג ולסיר AppWidgets.
הטמעות במכשירים חייבות להיות מסוגלות ליצור וידג'טים בגודל 4 x 4 ב
גודל הרשת הסטנדרטי. (פרטים נוספים זמינים בהנחיות לעיצוב של ווידג'טים של אפליקציות במסמכי התיעוד של Android SDK
[משאבים, 18]).
3.8.2. התראות
מערכת Android כוללת ממשקי API שמאפשרים למפתחים להודיע למשתמשים על אירועים משמעותיים
[מקורות מידע, 19], באמצעות תכונות החומרה והתוכנה של המכשיר.
חלק מ-APIs מאפשרים לאפליקציות להציג התראות או למשוך תשומת לב באמצעות
חומרה, במיוחד באמצעות צליל, רטט ואור. הטמעות במכשיר חייבות
לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר במסמכי העזרה של
ה-SDK, ובמידת האפשר עם החומרה של הטמעת המכשיר.
לדוגמה, אם הטמעה במכשיר כוללת ויברטור, חייבים
להטמיע בצורה נכונה את ממשקי ה-API של הרטט. אם ביישום המכשיר חסרה חומרה, חייבים להטמיע את
ממשקי ה-API התואמים כ-no-ops. שימו לב שההתנהגות הזו
מתוארת באופן מפורט בקטע 7.
בנוסף, ההטמעה חייבת להציג באופן תקין את כל המשאבים (סמלים, קובצי
אודיו וכו') שסופקו ב-APIs [מקורות מידע, 20], או במדריך העיצוב של סמלי
הסטטוס/סרגל המערכת [מקורות מידע, 21]. מפתחי מכשירים יכולים לספק חוויית
משתמש חלופית להתראות ששונה מזו שסופקת על ידי הטמעת
הקוד הפתוח של Android
. עם זאת, מערכות התראות חלופיות כאלה חייבות לתמוך במשאבי
התראות קיימים, כפי שצוין למעלה.
ב-Android 4.1 יש תמיכה בהתראות עשירות, כמו תצוגות אינטראקטיביות להתראות
מתמשכות. הטמעות במכשירים חייבות להציג ולבצע התראות
עשירות כראוי, כפי שמתועד ב-Android APIs.
3.8.3. חיפוש
מערכת Android כוללת ממשקי API [מקורות מידע, 22] שמאפשרים למפתחים לשלב חיפוש ב
אפליקציות שלהם, ולהציג את הנתונים של האפליקציות בחיפוש המערכת הגלובלי.
באופן כללי, הפונקציונליות הזו מורכבת מממשק משתמש יחיד ברמת המערכת
שמאפשר למשתמשים להזין שאילתות, מציג הצעות כשהמשתמשים מקלידים ומציג
תוצאות. ממשקי ה-API של Android מאפשרים למפתחים לעשות שימוש חוזר בממשק הזה כדי לספק חיפוש
בתוך האפליקציות שלהם, ומאפשרים למפתחים לספק תוצאות לממשק המשתמש המשותף של החיפוש
הגלובלי.
הטמעות במכשירים חייבות לכלול ממשק משתמש יחיד, משותף וחיפוש ברמת המערכת
שיכול להציג הצעות בזמן אמת בתגובה לקלט של המשתמש. הטמעות
במכשירים חייבות להטמיע את ממשקי ה-API שמאפשרים למפתחים לעשות שימוש חוזר בממשק
המשתמש הזה כדי לספק חיפוש בתוך האפליקציות שלהם. הטמעות במכשירים
חייבות ליישם את ממשקי ה-API שמאפשרים לאפליקציות של צד שלישי להוסיף הצעות ל
תיבת החיפוש כשהיא פועלת במצב חיפוש גלובלי. אם לא
הותקנו אפליקציות של צד שלישי שמשתמשות בפונקציונליות הזו, התנהגות ברירת המחדל צריכה להיות הצגת
תוצאות והצעות של מנועי חיפוש אינטרנט.
3.8.4. הודעות 'טוסט'
אפליקציות יכולות להשתמש ב-Toast API (שמוגדר בקטע [Resources, 23]) כדי להציג למשתמש הקצה מחרוזות קצרות שאינן
מודאליות, ונעלמות לאחר פרק זמן קצר. הטמעות
במכשירים חייבות להציג הודעות Toast מאפליקציות למשתמשי קצה באופן
גלוי במיוחד.
3.8.5. עיצובים
מערכת Android מספקת 'עיצובים' כמנגנון לאפליקציות, שמאפשר להחיל סגנונות על
פעילות או אפליקציה שלמות. ב-Android 3.0 הושק עיצוב חדש 'Holo' או 'הולוגרפית'
כקבוצה של סגנונות מוגדרים שמפתחי אפליקציות יכולים להשתמש בהם אם הם רוצים להתאים
את המראה והתחושה של עיצוב Holo כפי שהוגדרו ב-Android SDK [מקורות מידע, 24]. אסור לשנות בהטמעות במכשיר אף אחד ממאפייני העיצוב של Holo שחשופים ל
אפליקציות [משאבים, 25].
ב-Android 4.0 הושק עיצוב חדש 'ברירת המחדל של המכשיר' כקבוצה של סגנונות מוגדרים ש
מפתחי אפליקציות יכולים להשתמש בהם אם הם רוצים להתאים את המראה והתחושה לעיצוב
המכשיר כפי שהוגדר על ידי מפעיל המכשיר. יכול להיות שהטמעות של מכשירים ישנו את מאפייני העיצוב של
DeviceDefault שגלויים לאפליקציות [מקורות, 25].
3.8.6. טפטים דינמיים
ב-Android מוגדר סוג רכיב ו-API ותקופת חיים תואמים שמאפשרים
לאפליקציות לחשוף למשתמש הסופי טפט דינמי אחד או יותר [מקורות מידע, 26].
טפטים דינמיים הם אנימציות, דוגמאות או תמונות דומות עם יכולות
קלט מוגבלות שמוצגות כטפט, מאחורי אפליקציות אחרות.
חומרה נחשבת ככזו שיכולה להפעיל באמינות טפטים חיוניים אם היא יכולה להפעיל את כל
הטפטים החיוניים, ללא מגבלות על הפונקציונליות, ברזולוציה סבירה ללא
השפעות שליליות על אפליקציות אחרות. אם מגבלות בחומרה גורמות לתמונות רקע
ו/או לאפליקציות לקרוס, לפעול באופן לא תקין, לצרוך יותר מדי חשמל מהמעבד או מהסוללה, או
לרוץ בקצב פריימים נמוך בלתי קביל, החומרה נחשבת לא כשירה להפעלת
תמונה רקע דינמית. לדוגמה, חלק מהטפטים החיים עשויים להשתמש בהקשר Open GL 1.0 או 2.0
כדי לרנדר את התוכן שלהם. השימוש ברקע החי לא יפעל באופן מהימן בחומרה
שאינה תומכת במספר הקשרים של OpenGL, כי השימוש ברקע החי בקשר
OpenGL עלול להיכנס בהתנגשות עם אפליקציות אחרות שגם הן משתמשות בקשר OpenGL.
הטמעות של מכשירים שיכולות להריץ טפטים חיים באמינות כפי שמתואר
למעלה צריכות להטמיע טפטים חיים. אסור להטמיע טפטים חיים במכשירים שנקבע שהם לא
מריצים טפטים חיים באופן מהימן כפי שמתואר למעלה.
3.8.7. תצוגת אפליקציות מהזמן האחרון
קוד המקור ב-Android 4.1 ב-upstream כולל ממשק משתמש להצגת אפליקציות
מהזמן האחרון באמצעות תמונה בגודל תצוגה ממוזערת של המצב הגרפי של האפליקציה ב
רגע שבו המשתמש עזב את האפליקציה בפעם הקודמת. יכול להיות שהטמעות במכשירים ישנו או
יסירו את ממשק המשתמש הזה, אבל בגרסה עתידית של Android אנחנו מתכננים להשתמש
בפונקציונליות הזו באופן נרחב יותר. במערכות הטמעה של מכשירים מומלץ
להשתמש בממשק המשתמש של Android 4.1 ב-upstream (או בממשק
דומה שמבוסס על תמונות ממוזערות) לאפליקציות מהזמן האחרון, אחרת יכול להיות שהן לא יהיו תואמות לגרסת Android
עתידית.
3.8.8. הגדרות ניהול קלט
ב-Android 4.1 יש תמיכה במנועי ניהול קלט. ממשקי ה-API של Android 4.1
מאפשרים לממשקי IME מותאמים אישית של אפליקציות לציין הגדרות שניתן לשנות על ידי המשתמשים. הטמעות במכשירים
חייבות לכלול דרך למשתמש לגשת להגדרות ה-IME בכל שלב שבו מוצג IME
שמספק הגדרות כאלה של משתמשים.
3.8.9. שליטה מרחוק ממסך הנעילה
ב-Android 4.0 הוכנסה תמיכה ב-Remote Control API שמאפשרת לאפליקציות מדיה
להשתלב עם רכיבי ה-UI להפעלה שמוצגים בתצוגה מרחוק כמו מסך הנעילה
של המכשיר [מקורות מידע, 69]. הטמעות של מכשירים צריכות לכלול תמיכה ב
הטמעת פקדים מרחוק במסך הנעילה של המכשיר.
3.9 ניהול מכשירים
Android 4.1 כולל תכונות שמאפשרות לאפליקציות עם מודעות אבטחה לבצע פונקציות
ניהול מכשירים ברמת המערכת, כמו אכיפה של מדיניות סיסמאות או
ביצוע איפוס נתונים מרחוק, באמצעות Android Device Administration API [מקורות מידע,
27]. הטמעות של מכשירים חייבות לספק הטמעה של הקלאס
DevicePolicyManager [מקורות מידע, 28], וצריך שתהיה להן תמיכה בטווח המלא של
מדיניות ניהול המכשיר שמוגדרת במסמכי התיעוד של Android SDK [מקורות מידע,
27].
הערה: חלק מהדרישות שמפורטות למעלה הן 'מומלץ' לגרסה
Android 4.1, אבל בהגדרת התאימות לגרסה עתידית הדרישות האלה
ישתנו ל'חובה'. כלומר, הדרישות האלה הן אופציונליות ב-Android 4.1 אבל יהיו
חובה בגרסה עתידית. מומלץ מאוד למכשירים קיימים וחדשים עם Android 4.1 לעמוד בדרישות האלה ב-Android 4.1, אחרת הם לא
יוכלו לעמוד בדרישות התאימות ל-Android כשיתבצע שדרוג לגרסה העתידית.
3.10 נגישות
ב-Android 4.1 יש שכבת נגישות שמסייעת למשתמשים עם מוגבלות לנווט
במכשירים שלהם בקלות רבה יותר. בנוסף, ב-Android 4.1 יש פלטפורמות API שמאפשרות
להטמיע שירותי נגישות כדי לקבל החזרים על אירועים של משתמשים ומערכת
וליצור מנגנונים חלופיים למשוב, כמו המרה טקסט לדיבור,
משוב חזותי והנחיה לניווט במסך המסך הקדמי /במסך הנווט [מקורות, 29].הטמעות במכשירים
חייבות לספק הטמעה של מסגרת הנגישוּת של Android בהתאם
להטמעה שמוגדרת כברירת מחדל ב-Android. בפרט, הטמעות של מכשירים חייבות
לעמוד בדרישות הבאות.
הטמעות במכשיר חייבות לתמוך בהטמעות של שירותי נגישות
של צד שלישידרך ממשקי ה-API של android.accessibilityservice [מקורות מידע,
30].
הטמעות במכשיר חייבות ליצור אירועי AccessibilityEvents ולשלוח
את האירועים האלה לכל הטמעות AccessibilityService הרשומים ב
אופן שתואם להטמעה שמוגדרת כברירת מחדל ב-Android.
הטמעות במכשיר חייבות לספק מנגנון שגלוי למשתמשים כדי להפעיל
ולשבית שירותי נגישות, והן חייבות להציג את הממשק הזה בתגובה
לכוונת android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
בנוסף, הטמעות של מכשירים צריכות לספק הטמעה של
שירות נגישות במכשיר, וכן לספק מנגנון שמאפשר למשתמשים
להפעיל את שירות הנגישות במהלך הגדרת המכשיר. הטמעה בקוד פתוח
של שירות נגישות זמינה בפרויקט Eyes Free [מקורות מידע, 31].
3.11 המרת טקסט לדיבור
גרסת Android 4.1 כוללת ממשקי API שמאפשרים לאפליקציות להשתמש בשירותי המרת טקסט לדיבור (TTS)
, ומאפשרת לספקי שירותים לספק הטמעות של שירותי TTS
[מקורות מידע, 32]. הטמעות במכשירים חייבות לעמוד בדרישות האלה שקשורות ל
מסגרת Android TTS :
הטמעות במכשירים חייבות לתמוך ב-APIs של מסגרת Android TTS ו
צריכות לכלול מנוע TTS שתומך בשפות הזמינות ב
מכשיר. שימו לב שתוכנת Android בקוד פתוח במעלה הזרם כוללת הטמעה של מנוע TTS עם
תכונות מלאות.
הטמעות במכשירים חייבות לתמוך בהתקנה של מנועי TTS של צד שלישי.
הטמעות במכשירים חייבות לספק ממשק שגלוי למשתמשים שמאפשר
למשתמשים לבחור מנוע TTS לשימוש ברמת המערכת.
4. תאימות אריזת אפליקציות
הטמעות מכשירים חייבות להתקין ולהריץ קובצי Android ".apk" כפי שיוצר
הכלי"aapt" שכלול ב-Android SDK הרשמי [מקורות מידע, 33].
אסור להרחיב הטמעות של מכשירים בפורמטים שלהקובץ .apk [Resources, 34], Android
Manifest [Resources, 35], קוד בייט של Dalvik [Resources, 17], או קוד בייט של renderscript
בדרך כזו שתימנע ההתקנה של הקבצים האלהוהפעלה שלהם כראוי
במכשירים אחרים שתואמים. מפתחי הטמעה של מכשירים צריכים להשתמש בהטמעה הקודמת
של Dalvik, ובמערכת
לניהול חבילות של הטמעת העזר.
5. תאימות למולטימדיה
הטמעות של מכשירים חייבות לכלול לפחות צורה אחת של פלט אודיו, כמו
רמקולים, שקע אוזניות, חיבור לרמקולים חיצוניים וכו'.
5.1. קודקים למדיה
הטמעות במכשירים חייבות לתמוך בפורמטים המרכזיים של המדיה שצוינו במסמכי התיעוד של
Android SDK [משאבים, 58] למעט במקרים שמתוארים באופן מפורש במסמך הזה
. במיוחד, הטמעות המכשיר חייבות לתמוך בפורמטים של מדיה,
מקודדים, מפענחים, סוגי קבצים ופורמטים של קונטיינרים שמוגדרים בטבלאות שלמטה. כל
קודקי הווידאו האלה מסופקים כהטמעות תוכנה בהטמעה המועדפת של Android
מפרויקט הקוד הפתוח של Android.
לתשומת ליבך: Google ו-Open Handset Alliance לא מציגות
טענות שקודקי ה-codec האלה לא מוגבלים ברישיונות פטנטים של צדדים שלישיים.
מי שמעוניין להשתמש בקוד המקור הזה במוצרי חומרה או תוכנה מתבקש
לדעת שהטמעות של הקוד הזה, כולל בתוכנות קוד פתוח
או בתוכנות חינמיות, עשויות לדרוש רישיונות פטנטים מבעלי הפטנטים הרלוונטיים.
הערה: בטבלאות האלה לא מפורטות דרישות ספציפיות לשיעורי ביטר ברוב קודקי הווידאו
כי חומרת המכשיר הנוכחית לא תומכת בהכרח בשיעורי ביטר שמתאימים
בדיוק לשיעורי הביטר הנדרשים שצוינו בסטנדרטים הרלוונטיים. במקום זאת, הטמעות
במכשירים צריכות לתמוך בקצב הנתונים הגבוה ביותר המעשי בחומרה, עד
המגבלות שמוגדרות במפרטים.
סוגי קובץ /
פורמט /
סוג
קידוד
פענוח
פרטים
מאגר
קודק
פורמטים
תמיכה ב
חובה
מונו/סטריאו/5.0/5.1*
MPEG-4
חובה להטמעות במכשירים
תוכן עם
פרופיל AAC
שכולל חומרה של מיקרופון
חובה
דגימה רגילה
(AAC LC)
והגדרת
3GPP
שיעורים מ-8 עד 48
android.hardware.microphone.
(.3gp)
kHz.
MPEG-4
תמיכה ב
(.mp4,
MPEG-4
מונו/סטריאו/5.0/5.1*
.m4a)
תוכן HE AAC
עם
ADTS raw
חובה
פרופיל
דגימה רגילה
AAC (.aac,
(AAC+)
שיעורים מ-16 עד 48
פענוח ב-
kHz.
Android
3.1 ואילך,
נדרשת תמיכה ב-
MPEG-4
כדי שהמכשיר
יוכל לקודד
בפורמטים
מונו/סטריאו/5.0/5.1*
HE AAC v2
הטמעות שכוללות
תוכן
ב-Android
עם
חומרה
של מיקרופון
בגרסה
4.0 ואילך,
דגימה רגילה
של ADIF
(לא
מוגדרת
קצב
דגימה של 16 עד 48
AAC+)
android.hardware.microphone
נתמכ)
kHz.
MPEG-TS
MPEG-4
(.ts, not
Audio
REQUIRED for device
Support for
seekable,
Object Type
implementations that include
mono/stereo content
Android
ER AAC
microphone hardware and
REQUIRED
with standard
3.0+)
ELD
define
sampling rates from
(Enhanced
android.hardware.microphone
16 to 48 kHz.
זמן השהיה קצר
AAC)
חובה
חובה להטמעות במכשירים
4.75 עד 12.2 kbps
AMR-NB
שכוללות חומרה של מיקרופון
חובה
3GPP (.3gp)
טעימות ב-8kHz
ומגדירות
android.hardware.microphone.
חובה
חובה להטמעות במכשירים
9 שיעורים מ-6.60
AMR-WB
שכוללים חומרה של מיקרופון
חובה
kbit/s עד 23.85 kbit/s
3GPP (.3gp)
ומגדירים
טעימות ב-16kHz
android.hardware.microphone.
מונו/סטריאו (ללא
ערוצים מרובים).
אודיו
תדירויות דגימה עד
48 kHz (אבל עד
44.1 kHz מומלץ
במכשירים עם
פלט FLAC
נדרש
ב-44.1 kHz,
כי
ה-48
FLAC (.flac)
(Android 3.1 ואילך)
ל-44.1
downsampler
לא
כולל
מסנן
תדריף נמוך). מומלץ
16 ביט; לא
מיושם
dither עבור 24
ביט.
מונו/סטריאו 8-
320Kbps קבוע
MP3
חובה
MP3 (.mp3)
(CBR) או קצב ביט
משתנה (VBR)
סוג 0 ו
MIDI סוג 0 ו-1.
1 (.mid,
DLS Version 1 ו-
.xmf, .mxmf)
2. XMF ו-Mobile
RTTTL/RTX
MIDI
חובה
XMF. תמיכה בפורמטים של רינגטונים
(.rtttl, .rtx)
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
ו-iMelody
(.imy)
Ogg (.ogg)
Vorbis
חובה
Matroska
(.mkv)
PCM לינאריים ב-8 ביט וב-16 ביט
(שיעורי
קצב
עד לגבול
החומרה).המכשירים
חייבים לתמוך
PCM/WAVE
חובה
חובה
WAVE (.wav)
שיעורי
דגימה לצילום
PCM גולמי
ברחשי
44100, 16000 ו-8000
Hz
JPEG
חובה
חובה
Base+progressive
JPEG (.jpg)
GIF
חובה
GIF (.gif)
תמונה
PNG
חובה
חובה
PNG (.png)
BMP
חובה
BMP (.bmp)
WEBP
חובה
חובה
WebP (.webp)
חובה
חובה להטמעות במכשירים
3GPP
שכוללות חומרת מצלמה ו
(.3gp)
H.263
חובה
הגדרת android.hardware.camera
MPEG-4
או
(.mp4)
android.hardware.camera.front.
3GPP
(.3gp)
חובה
MPEG-4
(.mp4)
חובה להטמעות במכשירים
MPEG-TS
שכוללות חומרה של מצלמה ו
פרופיל בסיס
וידאו
H.264 AVC
חובה
(.ts, AAC
define android.hardware.camera
(BP)
אודיו בלבד,
או
לא
android.hardware.camera.front.
seekable,
Android
3.0+)
MPEG-4
חובה
3GPP (.3gp)
SP
WebM (.webm)
חובה
וגם Matroska
VP8
(Android
(.mkv, Android
2.3.3+)
4.0+)
*הערה: נדרש רק מיקס לאחור של תוכן 5.0/5.1; הקלטה או עיבוד של יותר מ-2
ערוצים אופציונליים. **הערה: חייב להשתמש בתהליך צילום PCM לינארי של 16 ביט. לא חובה לצלם PCM
לינארי ב-8 ביט.
5.2 קידוד וידאו
הטמעות של מכשירי Android שכוללות מצלמה אחורית ומצהירות
על android.hardware.camera צריכות לתמוך בפרופילים הבאים של קידוד וידאו.
HD (כשהחומרה
SD (באיכות נמוכה) SD (באיכות גבוהה)
תומכת
H.264 Baseline
H.264 Baseline
קודק וידאו
H.264 Baseline Profile
Profile
Profile
וידאו
176 x 144 px
480 x 360 px
1280 x 720 px
רזולוציה
פריים וידאו 12 fps
30 fps
30 fps
קצב
500 Kbps או
קצב ביטר וידאו 56 Kbps
2 Mbps או יותר
יותר
קודק אודיו AAC-LC
AAC-LC
AAC-LC
אודיו
1 (מונו)
2 (סטריאו)
2 (סטריאו)
ערוצים
קצב ביטר אודיו 24 Kbps
128 Kbps
192 Kbps
5.3. הקלטת אודיו
כשאפליקציה משתמשת ב-API android.media.AudioRecord כדי להתחיל להקליט
סטרימינג של אודיו, הטמעות של מכשירים שכוללות חומרה של מיקרופון ו
מצהירות על android.hardware.microphone חייבות לדגום ולהקליט אודיו עם כל אחד
מההתנהגויות הבאות:
המכשיר צריך להציג מאפייני
אמפליטודה שטוחים יחסית לעומת תדרים, באופן ספציפי, ±3 dB, מ-100 Hz עד 4000 Hz
רגישות הקלט של האודיו צריכה להיות מוגדרת כך שמקור של רמת הספק של קול
(SPL) של 90 dB ב-1000 Hz יניב RMS של 2500 לדגימות של 16 ביט.
רמות האמפליטודה של PCM צריכות לעקוב באופן ליניארי אחרי השינויים ברמת ה-SPL של הקלט במהלך
טווח של לפחות 30 dB מ--18 dB עד +12 dB יחסית ל-90 dB SPL במיקרופון.
העיוות ההרמוני הכולל צריך להיות קטן מ-1% עבור 1Khz ברמת
קלט של 90 dB SPL.
בנוסף למפרטי ההקלטה שלמעלה, כשאפליקציה מתחילה
להקליט שידור אודיו באמצעות
מקור האודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:
עיבוד לביטול רעשים, אם קיים, חייב להיות מושבת.
שליטה אוטומטית בעוצמת הקול, אם קיימת, חייבת להיות מושבתת.
הערה: חלק מהדרישות שמפורטות למעלה הן 'מומלצות' ל-
Android 4.1, אבל בהגדרת התאימות לגרסה עתידית אנחנו מתכננים לשנות את הדרישות האלה
ל'חובה'. כלומר, הדרישות האלה הן אופציונליות ב-Android 4.1 אבל יהיו
חובה בגרסה עתידית. מומלץ מאוד למכשירים קיימים וחדשים עם Android 4.1 לעמוד בדרישות האלה ב-Android 4.1, אחרת הם לא
יוכלו לעמוד בדרישות התאימות ל-Android כשיתבצע שדרוג לגרסה העתידית.
5.4. זמן האחזור של האודיו
זמן האחזור של האודיו מוגדר באופן כללי כמרווח הזמן בין הזמן שבו האפליקציה מבקשת
פעולת הפעלה או הקלטה של אודיו, לבין הזמן שבו ההטמעה במכשיר
מתחילה את הפעולה בפועל. סוגים רבים של אפליקציות סומכים על זמני אחזור קצרים כדי לקבל
אפקטים בזמן אמת, כמו אפקטים קוליים או תקשורת VOIP. הטמעות מכשירים
שכוללות חומרה של מיקרופון ומצהירות על android.hardware.microphone
צריכות לעמוד בכל דרישות זמן האחזור לאודיו המפורטות בקטע הזה. בקטע 7
מפורטים התנאים שבהם חומרת המיקרופון עשויה להימחק על ידי
הטמעות במכשירים.
לצורכי הקטע הזה:
"זמן אחזור פלט קר" מוגדר כמרווח הזמן שבין הרגע שבו אפליקציה
מבקשת הפעלה חוזרת של אודיו לבין הרגע שבו הצליל מתחיל להישמע, כשמערכת האודיו
לא פעלה ובוצעה השבתה לפני הבקשה
"זמן אחזור פלט חם" מוגדר כמרווח הזמן שבין הרגע שבו אפליקציה
מבקשת הפעלה חוזרת של אודיו לבין הרגע שבו הצליל מתחיל להישמע, כשמערכת האודיו
פעלה לאחרונה אבל לא פעילה כרגע (כלומר, שקט)
"זמן אחזור פלט רציף" מוגדר כמרווח הזמן שבין הרגע שבו
אפליקציה מנפיקה טעימת אודיו להפעלה ולבין הרגע שבו הרמקול מפעיל פיזית
את הצליל המתאים, כשהמכשיר מפעיל כרגע אודיו
"זמן אחזור קלט קר" מוגדר כמרווח הזמן שבין הרגע שבו אפליקציה
מבקשת הקלטה של אודיו לבין הרגע שבו הטעימת הראשונה מתקבלת באפליקציה
דרך החזרה (call back), כשמערכת האודיו והמיקרופ
לא פעלו ובוצעה השבתה לפני הבקשה
"זמן אחזור קלט רציף" מוגדר כמרווח הזמן שבין הרגע שבו מתרחש צליל סביבתי לבין
הרגע שבו הטעימת האודיו המתאימה מתקבלת באפליקציה
דרך החזרה (call back), כשהמכשיר במצב הקלטה
בהתאם להגדרות שלמעלה, הטמעות מכשירים צריכות לציית לכל אחד מ
המאפיינים האלה:
זמן אחזור פלט קר של 100 מיליארד אלפיות שנייה או פחות
זמן אחזור פלט חם של 10 מיליארד אלפיות שנייה או פחות
זמן אחזור פלט רציף של 45 מיליארד אלפיות שנייה או פחות
זמן אחזור קלט קר של 100 מיליארד אלפיות שנייה או פחות
זמן אחזור קלט רציף של 50 מיליארד אלפיות שנייה או פחות
הערה: למרות שהדרישות המפורטות למעלה מוגדרות כ'צריך' ב-Android 4.1,
בהגדרת התאימות לגרסה עתידית מתוכנן לשנות את הדרישות האלה ל'חובה'.
כלומר, הדרישות האלה הן אופציונליות ב-Android 4.1 אבל יהיו חובה בגרסה
עתידית. אנחנו ממליצים מאוד
למכשירים קיימים וחדשים עם Android 4.1 לעמוד בדרישות האלה ב-Android 4.1, אחרת לא תהיה להם אפשרות
לעמוד בדרישות התאימות ל-Android כשהם ישודרגו לגרסה העתידית.
אם הטמעת המכשיר עומדת בדרישות של הקטע הזה, יכול להיות שהיא תדווח
על תמיכה באודיו עם זמן אחזור קצר, על ידי דיווח על התכונה "android.hardware.audio.low-
latency" דרך הקלאס android.content.pm.PackageManager. [Resources, 37]
לעומת זאת, אם הטמעת המכשיר לא עומדת בדרישות האלה, אסור
לא לדווח על תמיכה באודיו עם זמן אחזור קצר.
5.5. פרוטוקולים רשת
המכשירים חייבים לתמוך בפרוטוקולים של רשתות המדיה להפעלת אודיו ווידאו כפי
שצוין במסמכי התיעוד של Android SDK [מקורות, 58]. בפרט, המכשירים
חייבים לתמוך בפרוטוקולים הבאים של רשתות מדיה:
RTSP (RTP, SDP)
HTTP(S) progressive streaming
HTTP(S) Live Streaming draft protocol, Version 3 [Resources, 59]
6. תאימות לכלי הפיתוח
הטמעות במכשירים חייבות לתמוך בכלים לפיתוח ב-Android שסופקו ב-
Android SDK. במיוחד, מכשירים תואמים ל-Android חייבים להיות תואמים ל:
Android Debug Bridge (נקרא גם adb) [מקורות מידע, 33]
הטמעות של מכשירים חייבות לתמוך בכל הפונקציות של adb כפי שמתועד ב-
Android SDK. ה-daemon של adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, ו
חייב להיות מנגנון שזמין למשתמשים כדי להפעיל את Android Debug
Bridge.
Dalvik Debug Monitor Service (הידוע כ-ddms) [מקורות מידע, 33]
הטמעות של מכשירים חייבות לתמוך בכל התכונות של ddms כפי שמפורט ב-
Android SDK. מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חובה שתהיה תמיכה בכל פעם שהמשתמש מפעיל את Android
Debug Bridge, כפי שמתואר למעלה.
Monkey [מקורות מידע, 36]
הטמעות במכשירים חייבות לכלול את מסגרת Monkey, ולהפוך אותה
לזמינה לאפליקציות לשימוש.
רוב המערכות מבוססות-Linux והמערכות של Apple Macintosh מזהה מכשירי Android
באמצעות כלים סטנדרטיים של Android SDK, ללא תמיכה נוספת. עם זאת, מערכות Microsoft
Windows בדרך כלל דורשות דרייבר למכשירי Android חדשים. (לדוגמה,
למזהי ספקים חדשים ולפעמים למזהי מכשירים חדשים נדרשים דריברי USB בהתאמה אישית למערכות
Windows). אם הכלי adb לא מזהה הטמעה של מכשיר כפי
שסופק ב-SDK הסטנדרטי של Android, מפתחי המכשיר חייבים לספק מנהלי
התקנים ל-Windows כדי לאפשר למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.
הדרייברים האלה חייבים להיות זמינים ל-Windows XP, Windows Vista ו-Windows 7, גם בגרסת 32 ביט וגם בגרסת 64 ביט.
7. תאימות חומרה
אם מכשיר כולל רכיב חומרה ספציפי שיש לו API מתאים ל
מפתחים של צד שלישי, הטמעת המכשיר חייבת להטמיע את ה-API הזה כפי שמתואר במסמכי התיעוד של Android SDK.
אם ממשק API ב-SDK מתקשר עם
רכיב חומרה שצוין כאופציונלי וההטמעה במכשיר
לא כוללת את הרכיב הזה:
הגדרות השלמות של הכיתות (כפי שמתועד ב-SDK) לממשקי ה-API של
הרכיב חייבות להישאר במצב פעיל
התנהגויות ה-API חייבות להוטמע כפעולות לא יעילות באופן סביר
שיטות ה-API חייבות להחזיר ערכים null במקרים שמותר לפי התיעוד
ב-SDK
שיטות ה-API חייבות להחזיר הטמעות של פעולות לא יעילות של כיתות במקרים שערכים null
לא מותרים לפי התיעוד
ב-SDK
שיטות ה-API אסור שיזרקו החרגות שלא מתועדות
בתיעוד
דוגמה אופיינית לתרחיש שבו הדרישות האלה חלות היא ממשק ה-API לטלפון:
גם במכשירים שאינם טלפונים, צריך להטמיע את ממשקי ה-API האלה כפעולות לא יעילות באופן סביר.
הטמעות של מכשירים חייבות לדווח באופן מדויק על פרטי הגדרת
החומרה באמצעות השיטות getSystemAvailableFeatures() ו-hasSystemFeature(String)
בכיתה android.content.pm.PackageManager. [Resources, 37]
7.1. תצוגה וגרפיקה
ב-Android 4.1 יש תכונות שמתאמות באופן אוטומטי את נכסי האפליקציה ופרסות
ממשק המשתמש בהתאם למכשיר, כדי לוודא שאפליקציות של צד שלישי יפעלו בצורה טובה במגוון
הגדרות חומרה [מקורות מידע, 38]. חובה להטמיע כראוי
את ממשקי ה-API וההתנהגויות האלה, כפי שמפורט בקטע הזה.
היחידות שמצוינות בדרישות בקטע הזה מוגדרות באופן הבא:
'גודל פיזי באלכסון' הוא המרחק באינצ' בין שני פינות מנוגדות
של החלק המאיר של המסך.
'dpi' (נקודות לאינץ') הוא מספר הפיקסלים שמקובצים בשטח
אופקי או אנכי של אינץ' אחד. אם מופיעים ערכים של dpi, גם ה-dpi האופקי וגם
ה-dpi האנכי צריכים להימצא בטווח.
"יחס גובה-רוחב" הוא היחס בין המאפיין הארוך יותר של המסך לבין
המאפיין הקצר יותר. לדוגמה, מסך בגודל 480x854 פיקסלים יהיה 854 / 480 =
1.779, או בערך '16:9'.
'פיקסל לא תלוי צפיפות' או ("dp") הוא יחידת הפיקסלים הווירטואלית שמותאמת למסך ב-160
dpi, ומחושבת כפי הנוסחה: pixels = dps * (density / 160).
7.1.1. הגדרת מסך
גודל מסך
מסגרת ממשק המשתמש של Android תומכת במגוון גדלים שונים של מסך, ומאפשרת
לאפליקציות לבצע שאילתה לגבי גודל מסך המכשיר (נקרא גם 'פריסת מסך') דרך
android.content.res.Configuration.screenLayout עם
SCREENLAYOUT_SIZE_MASK. הטמעות של מכשירים חייבות לדווח על גודל
המסך הנכון כפי שהוגדר במסמכי התיעוד של Android SDK [משאבים, 38] והוא נקבע על ידי
פלטפורמת Android במעלה הזרם. בפרט, הטמעות של מכשירים צריכות לדווח על
גודל המסך הנכון בהתאם למימדי המסך הלוגיים (dp)
שאינם תלויים בצפיפות.
המכשירים חייבים להכיל מסכים בגודל של לפחות 426 dp x 320 dp ('קטן')
מכשירים שמדווחים על גודל מסך 'רגיל' חייבים להכיל מסכים בגודל של לפחות 480
dp x 320 dp
מכשירים שמדווחים על גודל מסך 'גדול' חייבים להכיל מסכים בגודל של לפחות 640
dp x 480 dp
מכשירים שמדווחים על גודל מסך 'גדול במיוחד' חייבים להכיל מסכים בגודל של לפחות 960
dp x 720 dp
בנוסף, המכשירים חייבים להכיל מסכים בגודל של לפחות 2.5 אינץ' בגודל פיזי אלכסוני
.
אסור לשנות אף פעם את גודל המסך שמדווח על ידי המכשירים.
אפליקציות יכולות לציין באילו גדלי מסך הן תומכות באמצעות המאפיין <supports-
screens> בקובץ AndroidManifest.xml. הטמעות במכשירים חייבות
לכבד כראוי את התמיכה הצהירה של אפליקציות במסכים בגדלים smal, normal, large ו-xlarge
, כפי המתואר במסמכי התיעוד של Android SDK.
יחס הגובה-רוחב של המסך
יחס הגובה-רוחב חייב להיות בין 1.3333 (4:3) ל-1.85 (16:9).
צפיפות מסך
מסגרת ממשק המשתמש של Android מגדירה קבוצה של צפיפויות לוגיות סטנדרטיות כדי לעזור
למפתחי אפליקציות לטרגט משאבי אפליקציה. הטמעות במכשירים חייבות
לדווח על אחת מהצפיפויות הלוגיות הבאות של מסגרת Android דרך
API android.util.DisplayMetrics, וחייבות להריץ אפליקציות בצפיפות הרגילה הזו
.
120 dpi, המכונה 'ldpi'
160 dpi, המכונה 'mdpi'
213 dpi, המכונה 'tvdpi'
240 dpi, המכונה 'hdpi'
320 dpi, המכונה 'xhdpi'
480 dpi, המכונה 'xxhdpi'
יש להגדיר במימושים של המכשיר את צפיפות המסגרת הרגילה של Android ש
הכי קרובה מבחינה מספרית לצפיפות הפיזית של המסך, אלא אם צפיפות המסגרת הלוגית
הכי קרובה מבחינה מספרית לצפיפות הפיזית של המסך, אלא אם צפיפות המסגרת הלוגית
גורמת לגודל המסך המדווח להיות קטן מהגודל המינימלי הנתמך. אם הצפיפות הסטנדרטית של
מסגרת Android שקרובה מבחינה מספרית לצפיפות הפיזית מובילה לגודל
מסך קטן יותר מגודל המסך הקטן והתואמת הנתמך (רוחב 320 dp),
הטמעות המכשיר צריכות לדווח על הצפיפות
הסטנדרטית הנמוכה הבאה של מסגרת Android.
7.1.2. מדדי תצוגה
הטמעות במכשירים חייבות לדווח על ערכים נכונים לכל מדדי התצוגה שמוגדרים ב-
android.util.DisplayMetrics [Resources, 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. הטמעות במכשירים חייבות גם
לתמוך ב-Android Renderscript, כפי שמפורט במסמכי התיעוד של Android SDK
[מקורות מידע, 8].
הטמעות במכשיר חייבות גם לזהות את עצמן בצורה נכונה כאלה שתומכות
ב-OpenGL ES 1.0 ו-2.0. כלומר:
ה-API המנוהלים (למשל, דרך השיטה GLES10.getString()) חייבים לדווח על
תמיכה ב-OpenGL ES 1.0 וב-2.0
ה-API של OpenGL ב-C/C++ (כלומר, אלה שזמינים לאפליקציות דרך
libGLES_v1CM.so, libGLES_v2.so או libEGL.so) חייבים לדווח על תמיכה ב-
OpenGL ES 1.0 וב-2.0.
אפשר להטמיע במכשירים כל תוסף OpenGL ES רצוי.
עם זאת, הטמעות במכשירים חייבות לדווח דרך OpenGL ES APIs מנוהלים ו
APIs מקומיים על מחרוזות התוספים שהן תומכות בהן, ומנגד אסור לדווח
על מחרוזות תוספים שהן לא תומכות בהן.
לתשומת ליבכם: ב-Android 4.1 יש תמיכה באפליקציות שיכולות לציין אופציונלית ש
הן דורשות פורמטים ספציפיים לדחיסת טקסטורות של OpenGL. הפורמטים האלה הם בדרך כלל ספציפיים לספק.
ב-Android 4.1 לא נדרש להטמיע
פורמט ספציפי של דחיסת טקסטורה בהטמעות במכשירים. עם זאת, הם צריכים לדווח באופן מדויק על כל
פורמטי דחיסת הטקסטורה שהם כן תומכים בהם, באמצעות השיטה getString() ב-
OpenGL API.
ב-Android 4.1 יש מנגנון שמאפשר לאפליקציות להצהיר שהן רוצות
להפעיל האצהרה חומרית לגרפיקה 2D ברמת האפליקציה, הפעילות, החלון או
התצוגה באמצעות שימוש בתג manifest android:hardwareAccelerated או באמצעות
קריאות API ישירות [מקורות מידע, 9].
ב-Android 4.1, הטמעות במכשירים חייבות להפעיל שיפור מהירות באמצעות חומרה
לפי ברירת המחדל, וחייבות להשבית שיפור מהירות באמצעות חומרה אם המפתח מבקש זאת
על ידי הגדרת android:hardwareAccelerated="false" או השבתת שיפור מהירות באמצעות חומרה
ישירות דרך Android View APIs.
בנוסף, הטמעות במכשירים חייבות להציג התנהגות שתואמת למסמכי התיעוד של Android
SDK בנושא האצת חומרה [מקורות מידע, 9].
Android 4.1 כולל אובייקט TextureView שמאפשר למפתחים לשלב ישירות
טקסטורות OpenGL ES המואצות חומרה כמטרות עיבוד בהיררכיית ממשק המשתמש.
הטמעות במכשירים חייבות לתמוך ב-TextureView API, ו חייבות להציג
התנהגות עקבית עם הטמעת Android ב-upstream.
7.1.5. מצב תאימות לאפליקציות מדור קודם
ב-Android 4.1 מוגדר 'מצב תאימות' שבו המסגרת פועלת במצב
'רגיל' שתואם לגודל המסך (רוחב 320dp) לטובת אפליקציות
מדור קודם שלא פותחו לגרסאות ישנות של Android שקדמו לעצמאות
מגודל המסך. הטמעות במכשירים חייבות לכלול תמיכה במצב התאימות
של אפליקציות קודמות כפי שהוטמע בקוד הפתוח של Android במעלה הזרם. כלומר,
הטמעות במכשירים אסור שישנו את הטריגרים או הסף שבהם
מצב התאימות מופעל, ואסור שישנו את ההתנהגות של
מצב התאימות עצמו.
7.1.6. סוגים של מסכים
מסכים להטמעה במכשיר מוגדרים כאחד משני הסוגים:
הטמעות של תצוגות עם פיקסלים קבועים: המסך הוא לוח יחיד שתומך
רק ברוחב וגובה של פיקסל יחיד. בדרך כלל המסך משולב פיזית
במכשיר. דוגמאות: טלפונים ניידים, טאבלטים וכו'.
הטמעות של תצוגות עם פיקסלים משתנים: בהטמעת המכשיר אין
מסך מוטמע והיא כוללת יציאת פלט וידאו כמו VGA, HDMI או
יציאה אלחוטית לתצוגה, או שהיא כוללת מסך מוטמע שיכול לשנות
את המימדים של הפיקסלים. דוגמאות לכך הן טלוויזיות, ממירים וכו'.
הטמעות של מכשירים עם פיקסלים קבועים
הטמעות של מכשירים עם פיקסלים קבועים יכולות להשתמש במסכים בכל גודל פיקסלים,
בתנאי שהן עומדות בדרישות שהוגדרו בהגדרת התאימות הזו.
הטמעות עם פיקסלים קבועים עשויות לכלול יציאת וידאו לשימוש עם תצוגה
חיצונית. עם זאת, אם המסך הזה ישמש אי פעם להפעלת אפליקציות, המכשיר חייב לעמוד
בדרישות הבאות:
המכשיר חייב לדווח על אותן הגדרות מסך ומדדי תצוגה, כפי שמתוארים
בקטעים 7.1.1 ו-7.1.2, כמו במסך עם הפיקסלים הקבועים.
המכשיר חייב לדווח על אותן צפיפות לוגית כמו במסך עם הפיקסלים הקבועים.
המכשיר חייב לדווח על אותן מידות מסך כמו במסך עם הפיקסלים הקבועים, או כמוהן כמעט
.
לדוגמה, טאבלט בגודל אלכסוני של 7" עם רזולוציה של 1024x600 פיקסלים נחשב
להטמעה של מסך גדול ב-mdpi עם פיקסלים קבועים. אם המכשיר מכיל יציאת
וידאו שמציגה ברזולוציה 720p או 1080p, הטמעת המכשיר חייבת לשנות את
התצוגה כדי שהאפליקציות יפעלו רק בחלון mdpi גדול, ללא קשר לכך
אם המסך עם הפיקסלים הקבועים או יציאת הווידאו נמצאים בשימוש.
הטמעות במכשירים עם פיקסלים משתנים
הטמעות במכשירים עם פיקסלים משתנים חייבות לתמוך באחת מהרזולוציות הבאות, או בשתיהן: 1280x720 או
1920x1080 (כלומר, 720p או 1080p). אסור להטמיע במכשירים עם מסכים
שכוללים פיקסלים משתנים תמיכה בכל הגדרה או מצב מסך אחרים. הטמעות
של מכשירים עם מסכים של פיקסלים משתנים עשויות לשנות את ההגדרה או
את המצב של המסך במהלך זמן הריצה או במהלך האתחול. לדוגמה, משתמש במכשיר סטרימינג יכול להחליף מסך
720p במסך 1080p, וההטמעה של המכשיר עשויה להשתנות
בהתאם.
יש לדווח על הקטגוריות הבאות
של הגדרות במכשירים נוספים עם פיקסלים משתנים בגודל הפיקסלים:
1280x720 (נקרא גם 720p): גודל מסך 'גדול', דחיסות 'tvdpi' (213 dpi)
1920x1080 (נקרא גם 1080p): גודל מסך 'גדול', דחיסות 'xhdpi' (320 dpi)
חשוב להבהיר: הטמעות מכשירים עם פיקסלים משתנים בגודל מוגבלות ל-
720p או 1080p ב-Android 4.1, וצריך להגדיר אותן לדיווח על קטגוריות של גודל מסך ו-
דחיסות כפי שצוין למעלה.
7.1.7. טכנולוגיית מסך
פלטפורמת Android כוללת ממשקי API שמאפשרים לאפליקציות ליצור גרפיקה עשירה
במסך. המכשירים חייבים לתמוך בכל ה-APIs האלה כפי שמוגדרים ב-Android SDK
, אלא אם צוין כך במפורש במסמך הזה. בפרט:
המכשירים חייבים לתמוך במסכים שיכולים ליצור גרפיקה צבעונית ב-16 ביט ו
צריכים לתמוך במסכים שיכולים ליצור גרפיקה צבעונית ב-24 ביט.
המכשירים חייבים לתמוך במסכים שיכולים ליצור אנימציות.
לטכנולוגיית המסך שנעשה בה שימוש חייבת להיות יחס גובה-רוחב (PAR) של הפיקסלים בין 0.9
ל-1.1. כלומר, יחס הגובה-רוחב בפיקסלים חייב להיות קרוב לריבוע (1.0) עם התראה
של 10%.
7.2. התקני קלט
7.2.1. מקלדת
הטמעות במכשיר:
חובה לכלול תמיכה ב-Input Management Framework (שמאפשר למפתחים של צד שלישי ליצור מנועי ניהול קלט – כלומר מקלדת וירטואלית) כפי שמפורט בכתובת http://developer.android.com
חובה לספק לפחות הטמעה אחת של מקלדת וירטואלית (ללא קשר לכך שקיימת
מקלדת פיזית)
מותר לכלול הטמעות נוספות של מקלדת וירטואלית
מותר לכלול מקלדת חומרה
אסור לכלול מקלדת חומרה שלא תואמת לאחד מהפורמטים
שצוינו ב-android.content.res.Configuration.keyboard [Resources, 40]
(כלומר, QWERTY, או 12 מפתחות)
7.2.2.
ניווט ללא מגע
הטמעות במכשירים:
מותר להשמיט אפשרות ניווט ללא מגע (כלומר, אפשר להשמיט טרקר-בל, משטח D או
גלגלת)
חובה לדווח על הערך הנכון של
android.content.res.Configuration.navigation [Resources, 40]
חובה לספק מנגנון חלופי סביר של ממשק משתמשלבחירה ולעריכה של
טקסט, תואם למנועי ניהול קלט.
תוכנת Android הקוד הפתוח במעלה הזרם כוללת מנגנון בחירה
שמתאים לשימוש במכשירים שחסרים להם קלטי ניווט לא מגע.
7.2.3. מקשי ניווט
הפונקציות 'דף הבית', 'תפריט' ו'חזרה' הן חיוניות למודל הניווט ב-Android
. הטמעות במכשירים חייבות להפוך את הפונקציות האלה לזמינות למשתמש
בכל הפעמים כשמריצים אפליקציות. אפשר להטמיע את הפונקציות האלה באמצעות
לחצנים פיזיים ייעודיים (כמו לחצני מגע מכניים או קיבלוּסיים), או
להטמיע אותן באמצעות מקשי תוכנה ייעודיים, תנועות, לוח מגע וכו'. Android
4.1 תומך בשתי ההטמעות.
ב-Android 4.1 נוספה תמיכה בפעולת עזרה [מקורות מידע, 63]. הטמעות
במכשירים חייבות להפוך את פעולת הסיוע לזמינה למשתמש תמיד כש
מריצים אפליקציות. אפשר להטמיע את הפונקציה הזו באמצעות מפתחות חומרה או תוכנה
.
הטמעות במכשירים יכולות להשתמש בחלק נפרד מהמסך כדי להציג את
מקשי הניווט, אבל אם הן עושות זאת, הן חייבות לעמוד בדרישות הבאות:
הטמעות במכשירים חייבות להשתמש בחלק נפרד מהמסך
שלא זמין לאפליקציות, והן אסור שיסתירו או יפריעו באופן אחר
לחלק מהמסך שזמין לאפליקציות.
הטמעות במכשירים חייבות להקצות חלק מהמסך
לאפליקציות שעומד בדרישות שמפורטות בקטע 7.1.1.
הטמעות במכשירים חייבות להציג את מקשי הניווט כשהאפליקציות
לא מציינות מצב של ממשק משתמש מערכת, או כשהן מציינות את הערך SYSTEM_UI_FLAG_VISIBLE.
הטמעות במכשירים חייבות להציג את מקשי הניווט בפרופיל נמוך (למשל, כהה)
כאשר האפליקציות מציינות את הערך
SYSTEM_UI_FLAG_LOW_PROFILE.
בהטמעות של מכשירים חובה להסתיר את מקשי הניווט כשהאפליקציות
מציינות את הערך SYSTEM_UI_FLAG_HIDE_NAVIGATION.
בהטמעות של מכשירים חובה להציג מקש תפריט לאפליקציות כש
targetSdkVersion <= 10 ואסור להציג מקש תפריט כש
targetSdkVersion > 10.
בהטמעות של מכשירים חובה להציג חלק מהמסך לאפליקציות
שעומדות בדרישות שמוגדרות בקטע 7.1.1.
7.2.4. קלט מסך מגע
יש להטמיע במכשירים מערכת קלט של סמןמכל סוג מה (
כמו עכבר, או מגע). עם זאת, אם הטמעה של מכשיר לא תומכת במערכת קלט של
משקף, אסור להפיק דיווח על המאפיין android.hardware.touchscreen או
android.hardware.faketouch. הטמעות מכשיר ש
כוללות מערכת קלט של סמן:
צריך שתהיה תמיכה במעקב מלא ועצמאי אחרי סמנים, אם מערכת הקלט של המכשיר
תומכת במספר סמנים
חייבת לדווח על הערך של android.content.res.Configuration.touchscreen
[Resources, 40] cהתואמת לסוג של מסך המגע הספציפי ב
מכשיר
Android 4.0 כולל תמיכה במגוון מסכי מגע, משטחי מגע ומכשירי קלט לא אותנטיים
. הטמעות של מכשירים מבוססי מסך מגע משויכות למסך
[מקורות מידע, 71] כך שהמשתמש מרגיש שהוא מבצע פעולות ישירות על
הפריטים במסך. מכיוון שהמשתמש נוגע ישירות במסך, המערכת לא
דורשת אף תכונה נוספת כדי לציין את האובייקטים שאותם מפעילים. לעומת זאת, ממשק מגע מזויף מספק מערכת קלט משתמש שדומה ל
קבוצת משנה של יכולות מסך המגע.
לדוגמה, עכבר או שלט רחוק שמניעים
סמן במסך דומים למגע, אבל המשתמשים צריכים קודם לצבוע או להתמקד
ואז ללחוץ. מכשירי קלט רבים כמו עכבר, מסך מגע, עכבר אוויר מבוסס-ג'ירו,
חיישן ג'ירו, ג'ויסטיק ומשטח מגע רב-מגע יכולים לתמוך באינטראקציות מגע מזויפות.
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. Fake touch input
Device implementations that declare support for android.hardware.faketouch
MUST report the absolute X and Y screen positions of the pointer location and
display a visual pointer on the screen[Resources, 70]
MUST report touch event with the action code [Resources, 70] that specifies the
state change that occurs on the pointer going down or up on the screen
[Resources, 70]
MUST support pointer down and up on an object on the screen, which al ows
users to emulate tap on an object on the screen
MUST support pointer down, pointer up, pointer down then pointer up in the same
place on an object on the screen within a time threshold, which al ows users to
emulate double tap on an object on the screen [Resources, 70]
MUST support pointer down on an arbitrary point on the screen, pointer move to
any other arbitrary point on the screen, fol owed by a pointer up, which al ows
users to emulate a touch drag
MUST support pointer down then al ow users to quickly move the object to a
different position on the screen and then pointer up on the screen, which al ows
users to fling an object on the screen
Devices that declare support for android.hardware.faketouch.multitouch.distinct
MUST meet the requirements for faketouch above, and MUST also support distinct
tracking of two or more independent pointer inputs.
7.2.6. מיקרופון
יכול להיות שבהטמעות של מכשירים לא יהיה מיקרופון. עם זאת, אם הטמעה של מכשיר
משמיטה מיקרופון, אסור להיאסף דיווח על הקבועה
של התכונה android.hardware.microphone, וצריך להטמיע את ה-API להקלטת אודיו כ-no-ops, לפי קטע 7.
לעומת זאת, הטמעות של מכשירים שיש להם מיקרופון:
חייבים לדווח על הקבועה
של התכונה android.hardware.microphone
צריך לעמוד בדרישות איכות האודיו בקטע 5.4
צריך לעמוד בדרישות זמן האחזור להפעלת אודיו בקטע 5.5
7.3. חיישנים
Android 4.1 כולל ממשקי API לגישה למגוון סוגים של חיישנים. בדרך כלל,
הטמעות במכשירים יכולות להשמיט את החיישנים האלה, כפי שמצוין בקטעים המשניים הבאים
. אם מכשיר כולל סוג חיישן ספציפי שיש לו API מתאים
למפתחים של צד שלישי, הטמעת המכשיר חייבת להטמיע את ה-API כפי שמתואר
במסמכי התיעוד של Android SDK. לדוגמה, הטמעות במכשירים:
חובה לדווח באופן מדויק על הנוכחות או היעדרות של חיישנים בהתאם לכיתה
android.content.pm.PackageManager. [מקורות, 37]
חובה להחזיר רשימת חיישנים מדויקת שתומכת
ב-SensorManager.getSensorList() ובשיטות דומות
חובה להתנהג בצורה סבירה בכל ה-APIs האחרים של חיישנים (לדוגמה, להחזיר true
או false כפי הצורך כשאפליקציות מנסו לרשום מאזינים, לא להפעיל
מאזינים לחישנים כשהחיישנים המתאימים לא קיימים; וכו')
חובה לדווח על כל המדידות של החיישנים באמצעות הערכים הרלוונטיים של
המערכת הבינלאומית של יחידות (כלומר מטריות) לכל סוג חיישן כפי שהוגדרו במסמכי
התיעוד של Android SDK [מקורות, 41]
הרשימה שלמעלה לא מפורטת במלואה; ההתנהגות המתוועדת של Android SDK
נחשבת למקור הסמכותי.
חלק מסוגי החיישנים הם סינתטיים, כלומר אפשר לקבל אותם מנתונים שסופקו על ידי
חיישן אחד או יותר אחרים. (דוגמאות: חיישן הכיוון וחישן התאוצה
לינארי). יש להטמיע את סוגי החיישנים
האלה בהטמעות של מכשירים, כשהן כוללות את החיישנים הפיזיים הנדרשים.
ב-Android 4.1 הוצגה האפשרות של חיישן 'סטרימינג', כלומר חיישן
שמחזיר נתונים באופן רציף, ולא רק כשהנתונים משתנים. הטמעות
במכשירים חייבות לספק באופן רציף דוגמאות נתונים מחזוריות לכל API
שצוין במסמכי התיעוד של Android 4.1 SDK כחיישן סטרימינג.
7.3.1. מד תאוצה
הטמעות במכשירים צריכות לכלול מד תאוצה ב-3 צירים. אם הטמעה במכשיר
כוללת תאוצה של 3 צירים, היא:
צריכה להיות מסוגלת לשלוח אירועים ברקע ב-120 Hz או יותר. שימו לב ש
תדירות האצ"ל שלמעלה צוינה כ'צריך' ב-Android 4.1, אבל ב
הגדרת התאימות לגרסה עתידית מתוכנן לשנות את היא ל
'חובה'. כלומר, הסטנדרטים האלה אופציונליים ב-Android 4.1 אבל יהיו
חובה בגרסאות עתידיות. מכשירים קיימים וחדשים עם Android 4.1
מומלצים מאוד לעמוד בדרישות האלה ב-Android 4.1 כדי
שיהיה להם אפשרות לשדרג לגרסאות הפלטפורמה העתידיות
חייבים לעמוד במערכת הקואורדינטות של חיישן Android כפי שמפורט ב-
Android API (ראו [מקורות מידע, 41])
חייבים להיות מסוגלים למדוד מירידה חופשית עד פי שניים מהכבידה (2g) או יותר
בכל וקטור תלת-ממדי
חייבים להיות מדויקים ל-8 ביט או יותר
חייבים להיות בעלי סטיית תקן שלא עולה על 0.05 m/s^2
7.3.2. מגנטומטר
יש לכלול במימושים של מכשירים מגנטומטר של 3 צירים (כלומר מצפן). אם
מכשיר כולל מגנטומטר שלוש-צירי, הוא:
חייב להיות מסוגל לספק אירועים ב-10 Hz או יותר
חייב לעמוד בדרישות של מערכת הקואורדינטות של חיישן Android כפי שמפורט ב-
Android APIs (ראו [מקורות מידע, 41]).
חייב להיות מסוגל לדגום טווח של עוצמות שדה מתאימות כדי לכסות את
השדה הגיאומגנטי
חייב להכיל 8 ביט של דיוק או יותר
חייב להכיל סטיית תקן של לא יותר מ-0.5 µT
7.3.3. GPS
הטמעות של מכשירים צריכות לכלול מקלט GPS. אם הטמעת המכשיר
כוללת מקלט GPS, צריך לכלול שיטה כלשהי של 'GPS בסיוע'
כדי לצמצם את זמן הנעילה של ה-GPS.
7.3.4. גירוסקופ
הטמעות של מכשירים צריכות לכלול גירוסקופ (כלומר חיישן לשינוי זוויתי).
מכשירים לא צריכים לכלול חיישן גירוסקופ אלא אם גם חיישן תאוצה ב-3 צירים
כלול. אם הטמעה של מכשיר כוללת גירוסקופ, היא:
חייבת לכלול תיקון טמפרטורה
חייבת להיות מסוגלת למדוד שינויים בכיוון עד 5.5*Pi
רדיאנים/שנייה (כלומר, כ-1,000 מעלות לשנייה)
צריכה להיות מסוגלת לשלוח אירועים ב-200 Hz או יותר. שימו לב ש
תדירות הגירוסקופ שצוינה למעלה מוגדרת כ'צריך' ב-Android 4.1, אבל
בהגדרת התאימות לגרסה עתידית מתוכנן לשנות את היא ל-
'חובה'. כלומר, הסטנדרטים האלה אופציונליים ב-Android 4.1 אבל יהיו
חובה בגרסאות עתידיות. מכשירים קיימים ומכשירים חדשים שפועלים ב-Android 4.1
מומלצים מאוד לעמוד בדרישות האלה ב-Android 4.1 כדי
שיהיה להם אפשרות לשדרג לגרסת הפלטפורמה העתידית
חייבים להכיל דיוק של 12 ביטים או יותר
חייבים להכיל שונות של לא יותר מ-1e-7 rad^2 / s^2 לכל Hz (שונות לכל Hz,
או rad^2 / s). השונות יכולה להשתנות בהתאם לשיעור הדגימה, אבל היא חייבת
להיות מוגבלת על ידי הערך הזה. במילים אחרות, אם מודדים את השונות של הג'ירוסקופ
ברצת דגימה של 1 Hz, היא לא יכולה להיות גדולה מ-1e-7 rad^2/s^2.
חובה לכלול חותמות זמן כמה שיותר קרובות לזמן שבו אירוע החומרה התרחש
. צריך להסיר את זמן האחזור הקבוע.
7.3.5. ברומטר
הטמעות של מכשירים עשויות לכלול ברומטר (כלומר חיישן לחץ אוויר סביבתי). אם
הטמעת המכשיר כוללת ברומטר, היא:
חייבת להיות מסוגלת לשלוח אירועים ב-5 Hz או יותר
חייבת להיות מדויקת כדי לאפשר הערכה של הגובה
חייבת לכלול תיקון לטמפרטורה
7.3.7. מדחום
הטמעות של מכשירים יכולות אבל לא צריכות לכלול מדחום (כלומר
חיישן טמפרטורה). אם הטמעה של מכשיר כוללת מדחום, היא חייבת
למדוד את הטמפרטורה של מעבד המכשיר. אסור למדוד טמפרטורה
אחרת. (שימו לב שסוג החיישן הזה הוצא משימוש בממשקי ה-API של Android 4.1).
7.3.7. פוטומטר
הטמעות של מכשירים עשויות לכלול פוטומטר (כלומר חיישן אור רגיש לסביבה).
7.3.8. חיישן קרבה
יכול להיות שרכיבי הטמעה במכשיר יכללו חיישן קרבה. אם הטמעה של מכשיר
כוללת חיישן קירבה, היא חייבת למדוד את הקירבה של אובייקט ב
אותו כיוון כמו המסך. כלומר, חיישן הקרבה חייב להיות מכוון לזיהוי
אובייקטים קרובים למסך, כי המטרה הראשית של סוג החיישן הזה היא לזהות
טלפון בשימוש של המשתמש. אם הטמעה של מכשיר כוללת חיישן קרבה עם
כיוון אחר, אסור שתהיה גישה אליו דרך ממשק ה-API הזה. אם להטמעה במכשיר
יש חיישן קרבה, הוא חייב להכיל דיוק של ביט אחד או יותר.
7.4. קישוריות נתונים
7.4.1. טלפוניה
המונח 'טלפוניה', כפי שהוא מופיע בממשקי ה-API של Android 4.1 ובמסמך הזה, מתייחס באופן ספציפי ל
חומרה שקשורה לביצוע שיחות קוליות ושליחת הודעות SMS דרך רשת GSM או
רשת CDMA. יכול להיות שהשיחות הקוליות האלה יתבצעו באמצעות מעבר חבילות (packet-switched) או לא, אבל
לצורכי Android 4.1
הן נחשבות כבלתי תלויות בחיבור נתונים כלשהו שעשוי להיות מיושם באמצעות אותה רשת. במילים אחרות, הפונקציות והממשקי ה-API של
'טלפוניה' ב-Android מתייחסים באופן ספציפי לשיחות קוליות ול-SMS. לדוגמה, הטמעות
של מכשירים שלא יכולות לבצע שיחות או לשלוח/לקבל הודעות SMS חייבות
לא לדווח על התכונה 'android.hardware.telephony' או על תכונות משנה שלה, ללא קשר
לשימוש שלהן ברשת סלולרית לחיבור נתונים.
אפשר להשתמש ב-Android 4.1 במכשירים שלא כוללים חומרה טלפונית. כלומר,
Android 4.1 תואם למכשירים שאינם טלפונים. עם זאת, אם הטמעה
של מכשיר כוללת טלפוניה GSM או CDMA, חובה להטמיע תמיכה מלאה
ב-API של הטכנולוגיה הזו. הטמעות במכשירים שאינן כוללות חומרה
טלפונית חייבות להטמיע את ממשקי ה-API המלאים כ-no-ops.
7.4.2. IEEE 802.11 (WiFi)
הטמעות של מכשירי Android 4.1 צריכות לכלול תמיכה בצורה אחת או יותר
של 802.11 (b/g/a/n וכו') אם הטמעה של מכשיר כוללת תמיכה ב-802.11,
חובה להטמיע את Android API המתאים.
הטמעות של מכשירים חייבות להטמיע את ממשק ה-API לרשתות מרובות-כתובת כפי המתואר במסמכי התיעוד של ה-SDK
[משאבים, 62]. הטמעותשל מכשירים שכוללות תמיכה ב-Wifi
חייבות לתמוך ב-DNS מרובי-כתובת (mDNS). אסור להטמיע במכשירים מסננים של חבילות
mDNS (224.0.0.251) בכל שלב של הפעולה, כולל כשהמסך לא במצב
פעיל.
7.4.2.1. Wi-Fi Direct
הטמעות של מכשירים צריכות לכלול תמיכה ב-Wifi direct (Wi-Fi peer-to-peer). אם
הטמעה של מכשיר כוללת תמיכה ב-Wifi direct, חובה להטמיע את
Android API המתאים כפי המתואר במסמכי התיעוד של ה-SDK [מקורות מידע, 68]. אם
הטמעת המכשיר כוללת תמיכה ב-Wifi direct, אז היא:
חייבת לתמוך בפעולה רגילה של Wi-Fi
צריכה לתמוך בפעולה בו-זמנית של Wi-Fi ו-wifi Direct
7.4.3. הטמעות של מכשירי Bluetooth
צריכות לכלול משדר-מקלט Bluetooth. הטמעות
של מכשירים שכוללות משדר-מקלט Bluetooth חייבות להפעיל את ממשק ה-API של Bluetooth שמבוסס על RFCOMM-
כפי שמתואר במסמכי התיעוד של ה-SDK [מקורות מידע, 42]. הטמעות
של מכשירים צריכות להטמיע פרופילים רלוונטיים של Bluetooth, כמו A2DP,
AVRCP, OBEX וכו' בהתאם למכשיר.
חבילת הבדיקות לתאימות כוללת תרחישים שכוללים פעולה בסיסית של Android
RFCOMM Bluetooth API. עם זאת, מכיוון ש-Bluetooth הוא פרוטוקול תקשורת
בין מכשירים, אי אפשר לבדוק אותו באופן מלא באמצעות בדיקות יחידה שפועלות במכשיר יחיד.
כתוצאה מכך, הטמעות מכשירים חייבות גם לעבור את נוהל הבדיקה
האנושי של Bluetooth המתואר בנספח א'.
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 Tag Types 1, 2, 3, 4 (מוגדר על ידי NFC Forum)
רצוי שתהיה לו יכולת לקרוא ולכתוב הודעות NDEF באמצעות תקני
ה-NFC הבאים. שימו לב שסטנדרטים ה-NFC שלמטה מוגדרים כ
'מומלץ' ב-Android 4.1, אבל בהגדרת התאימות לגרסה עתידית
מתוכנן לשנות את הסטנדרטים האלה ל'חובה'. כלומר, התקנים האלה אופציונליים ב-
Android 4.1 אבל יהיו חובה בגרסאות עתידיות. מומלץ מאוד למכשירים קיימים וחדשים
עם Android 4.1 לעמוד
בדרישות האלה ב-Android 4.1 כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה
.
NfcV (ISO 15693)
חייב להיות מסוגל להעביר ולקבל נתונים באמצעות הפרוטוקולים והתקנים הבאים של
peer-to-peer:
ISO 18092
LLCP 1.0 (מוגדר על ידי NFC Forum)
SDP 1.0 (מוגדר על ידי NFC Forum)
פרוטוקול דחיפת NDEF [מקורות מידע, 43]
SNEP 1.0 (מוגדר על ידי NFC Forum)
חייב לכלול תמיכה ב-Android Beam [מקורות מידע, 65]:
חייב להטמיע את השרת ברירת המחדל של SNEP. חובה לשלוח לאפליקציות
הודעות NDEF תקינות
שמתקבלות בשרת SNEP שמוגדר כברירת מחדל באמצעות הכוונה android.nfc.ACTION_NDEF_DISCOVERED. אסור להשבית את
Android Beam בהגדרות כדי להשבית את שליחת
ההודעה הנכנסת של NDEF.
הטמעות של מכשירים חייבות לכבד את ה-intent
android.settings.NFCSHARING_SETTINGS כדי להציג את ההגדרות של שיתוף
NFC [Resources, 67].
חובה להטמיע את שרת ה-NPP. הודעות שמתקבלות על ידי שרת NPP
חייבות לעבור עיבוד באותו אופן כמו שרת ברירת המחדל של SNEP.
חייבים להטמיע לקוח SNEP ולנסות לשלוח הודעות NDEF P2P יוצאות
לשרת ברירת המחדל של SNEP כש-Android Beam מופעל. אם לא נמצא שרת
SNEP שמוגדר כברירת מחדל, הלקוח חייב לנסות לשלוח לשרת
NPP.
חובה לאפשר לפעילויות בחזית להגדיר הודעה של NDEF ב-P2P יוצאת
באמצעות android.nfc.NfcAdapter.setNdefPushMessage, ו-
android.nfc.NfcAdapter.setNdefPushMessageCal back, ו-
android.nfc.NfcAdapter.enableForegroundNdefPush.
מומלץ להשתמש במחווה או באישור במסך, כמו 'מצמידים ל-
Beam', לפני ששולחים הודעות של NDEF ב-P2P יוצאות.
מומלץ להפעיל Android Beam כברירת מחדל
חובה לתמוך בהעברת חיבור NFC ל-Bluetooth כשהמכשיר
תומך בפרופיל של העברת אובייקטים ב-Bluetooth. הטמעות של מכשירים חייבות
לתמוך בהעברת חיבור ל-Bluetooth כשמשתמשים ב-
android.nfc.NfcAdapter.setBeamPushUris, על ידי הטמעת המפרטים של
"Connection Handover version 1.2" [מקורות מידע, 60] ושל "Bluetooth Secure Simple Pairing Using NFC version 1.0" [מקורות מידע, 61] מ-
NFC Forum.
הטמעה כזו של SHOULD משתמשת בבקשות SNEP GET
להחלפת בקשת ההעברה או הרשומות שנבחרו דרך NFC, ו
חובה להשתמש בפרופיל ה-Bluetooth Object Push לצורך העברת הנתונים בפועל ב-Bluetooth
.
חובה לבצע סריקה לכל הטכנולוגיות הנתמכות בזמן שמכשיר במצב הפעלה עם המסך
פעיל ומסך הנעילה לא נעול.
(הערה: קישורים שגלויים לכול לא זמינים למפרטים של JIS, ISO ו-NFC Forum
שצוינו למעלה).
הטמעות נוספות של מכשירים עשויות לכלול תמיכה בקורא/בכותב ל
טכנולוגיות MIFARE הבאות.
MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
NDEF on MIFARE Classic (NXP AN130511 [Resources, 48], AN130411
[Resources, 49])
הערה:ב-Android 4.1 יש ממשקי API לסוגי MIFARE האלה. אם הטמעה
של מכשיר תומכת ב-MIFARE בתפקיד קורא/כותב, היא:
חייבת להטמיע את Android APIs התואמים כפי שמתועד ב-
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() [Resources, 37],
וצריך להטמיע את ממשק ה-API של NFC ב-Android 4.1 כפעולה ללא תוצאה.
כי הכיתות 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 megapixels
צריכה לכלול מיקוד אוטומטי חומרה, או מיקוד אוטומטי תוכנה שהוטמע
במנהל המצלמה (שקוף לתוכנת האפליקציה)
יכולה לכלול חומרה עם מיקוד קבוע או EDOF (עומק שדה מורחב)
יכולה לכלול פלאש. אם המצלמה כוללת פלאש, אסור לנורה של הפלאש
להאיר בזמן שמכונה חזרה של android.hardware.Camera.PreviewCal נרשמה
בפנים תצוגה מקדימה של מצלמה, אלא אם האפליקציה
הפעילה באופן מפורש את הפלאש על ידי הפעלת המאפיינים FLASH_MODE_AUTO או FLASH_MODE_ON
של אובייקט Camera.Parameters. חשוב לזכור שהאילוץ הזה לא חל על אפליקציית המצלמה המובנית של
המכשיר, אלא רק על אפליקציות של צד שלישי
שמשתמשות ב-Camera.PreviewCallback.
7.5.2. מצלמה קדמית
הטמעות של מכשירים עשויות לכלול מצלמה קדמית. אם הטמעה של מכשיר
כוללת מצלמה קדמית, היא:
חייבת להיות ברזולוציה של לפחות VGA (כלומר, 640x480 פיקסלים)
אסור להשתמש במצלמה קדמית כברירת המחדל ל-Camera API. כלומר,
ל-Camera API ב-Android 4.1 יש תמיכה ספציפית במצלמות קדמיות, ו
בהטמעות של המכשיר אסור להגדיר את ה-API כך שיתייחס למצלמה
הקדמית כמצלמה האחורית שמוגדרת כברירת מחדל, גם אם היא המצלמה היחידה במכשיר.
אפשר לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות
אחוריות, כפי שמתואר בקטע 7.5.1.
חובה לשקף (כלומר להציג בתמונת מראה) את הסטרימינג שמוצג על ידי אפליקציה ב-
CameraPreview, באופן הבא:
אם ההטמעה של המכשיר יכולה להסתובב על ידי המשתמש (למשל
באופן אוטומטי באמצעות תאוצה או באופן ידני באמצעות קלט של המשתמש),
התצוגה המקדימה של המצלמה חייבת להיות בתמונת מראה אופקית ביחס לכיוון הנוכחי של המכשיר.
אם האפליקציה הנוכחית ביקשה באופן מפורש שהתצוגה של המצלמה
תסתובב באמצעות קריאה ל-
android.hardware.Camera.setDisplayOrientation() [Resources, 50]
שיטה, התצוגה המקדימה של המצלמה חייבת להיות בתמונת מראה אופקית ביחס לכיוון
שצוין על ידי האפליקציה.
אחרת, התצוגה המקדימה חייבת להיות בתמונת מראה לאורך
הציר האופקי שמוגדר כברירת מחדל במכשיר.
חייב לשקף את התמונה שמוצגת על ידי התצוגה המקדימה של הפוסט באותו אופן שבו מוצגת התמונה בזרם התצוגה המקדימה של המצלמה
. (אם הטמעת המכשיר לא תומכת
בצפייה לאחור, הדרישה הזו כמובן לא חלה.)
אסור להציג במראה הפוכה את התמונה הסטטית הסופית שצולמה או את הזרמים של הווידאו שהוחזרו ל
גיבויים של הקריאה לאפליקציה או הועברו לאחסון מדיה
7.5.3. התנהגות API של מצלמה
הטמעות של מכשירים חייבות להטמיע את ההתנהגויות הבאות עבור ממשקי ה-API הקשורים למצלמה, גם למצלמה הקדמית וגם למצלמה האחורית:
1.
אם אף אפליקציה אף פעם לא הפעילה
את ה-method android.hardware.Camera.Parameters.setPreviewFormat(int), אז
המכשיר חייב להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני
התצוגה המקדימה שסופקו לקריאות החזרה של האפליקציה.
2. אם אפליקציה רושמת מכונה של android.hardware.Camera.PreviewCallback
והמערכת קוראת לשיטה onPreviewFrame() כשפורמט
התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] שמועברים אל onPreviewFrame()
צריכים להיות בפורמט הקידוד NV21. כלומר, NV21 חייב להיות ברירת המחדל.
3. הטמעות במכשירים חייבות לתמוך בפורמט YV12 (כפי שמצוין בערך הקבוע
android.graphics.ImageFormat.YV12) לתצוגות המקדימה של המצלמה גם
במצלמה הקדמית וגם במצלמה האחורית. (המצלמה וגם המקודד של וידאו בחומרה יכולים
להשתמש בכל פורמט מקורי של פיקסלים, אבל
ההטמעה של המכשיר חייבת לתמוך בהמרה ל-YV12).
בהטמעות של מכשירים חייבים להטמיע את גרסת Camera API המלאה שכלולה במסמכי התיעוד של Android
4.1 SDK [מקורות, 51]), רללא קשר לכך שהמכשיר כולל
מיקוד אוטומטי חומרה או יכולות אחרות. לדוגמה, מצלמות ללא מיקוד אוטומטי
חייבות עדיין להפעיל כל מכונות android.hardware.Camera.AutoFocusCallback
הרשומה (למרות שלא יש לכך רלוונטיות למצלמה ללא מיקוד אוטומטי). לתשומת ליבכם:
הדבר רלוונטי גם למצלמות קדמיות. לדוגמה, למרות שרוב המצלמות
הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך "לזייף" את הקריאות החוזרות של ה-API כפי שמתואר
.
הטמעות של מכשירים חייבות לזהות ולכבד כל שם פרמטר שהוגדר כ
קבועה בכיתה android.hardware.Camera.Parameters, אם החומרה
הבסיסית תומכת בתכונה. אם חומרת המכשיר לא תומכת בתכונה, ה-
API חייב לפעול כפי שמתועד. לעומת זאת, אסור להטמיע במכשירים ערכי קבועים של מחרוזות שמועברים ל-
שיטה android.hardware.Camera.setParameters() חוץ מאלה שמתועדים כערכי קבועים ב-
android.hardware.Camera.Parameters.
כלומר, הטמעות
במכשיר חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה אם החומרה
מאפשרת זאת, ואסור להן לתמוך בסוגי פרמטרים מותאמים אישית של המצלמה.
הטמעות במכשירים חייבות להעביר את הכוונה Camera.ACTION_NEW_PICTURE
בכל פעם שמצלמים תמונה חדשה במצלמה והרשומה של התמונה נוספה
לאחסון המדיה.
הטמעות במכשירים חייבות להעביר את ה-Intent Camera.ACTION_NEW_VIDEO
בכל פעם שמצלמים סרטון חדש במצלמה והרשומה של התמונה נוספה
לאחסון המדיה.
7.5.4. כיוון המצלמה
שתי המצלמות, הקדמית והאחורית, אם קיימות, חייבות להיות מוכוונות כך שהמימד הארוך
של המצלמה יתיישר עם המימד הארוך של המסך. כלומר, כש
המכשיר מוחזק בפריסה לרוחב, המצלמות חייבות לצלם תמונות בפריסה
לרוחב. הכלל הזה חל ללא קשר לכיוון הטבעי של המכשיר, כלומר
הוא חל על מכשירי 'לרוחב' ועל מכשירי 'לאורך'.
7.6. זיכרון ואחסון
7.6.1. זיכרון ואחסון מינימלי
הטמעות של מכשירים חייבות לכלול לפחות 340MB זיכרון שזמין לליבת המערכת
ולמרחב המשתמש. ה-340MB חייבים להיות בנוסף לכל זיכרון שמוקצה לרכיבי
חומרה כמו רדיו, וידאו וכו', שלא נמצאים בשליטת
הליבה.
בהטמעות במכשירים חייבת להיות נפח אחסון לא תנודתי של לפחות 350MB
לנתונים הפרטיים של האפליקציה. כלומר, מחיצה /data חייבת להיות בגודל של לפחות 350MB.
ממשקי ה-API של Android כוללים מנהל הורדות שיכול לשמש אפליקציות להורדת
קבצי נתונים [מקורות מידע, 56]. הטמעת מנהל ההורדות
במכשיר חייבת לאפשר הורדה של קבצים בודדים בגודל של לפחות 100MB למיקום
ברירת המחדל 'מטמון'.
7.6.2. אחסון משותף לאפליקציות
הטמעות של מכשירים חייבות לספק אחסון משותף לאפליקציות. נפח האחסון
המשותף שצריך לספק חייב להיות לפחות 1GB.
הטמעות במכשירים חייבות להיות מוגדרות עם אחסון משותף שמורכב כברירת מחדל,
"מתוך הקופסה". אם האחסון השיתופי לא מוטמע בנתיב Linux /sdcard, אז
המכשיר חייב לכלול קישור סמלי של Linux מ-/sdcard לנקודת החיבור האמיתית.
בהטמעות של מכשירים חובה לאכוף כפי שמתועד את
ההרשאה android.permission.WRITE_EXTERNAL_STORAGE באחסון המשותף.
אחסון משותף חייב להיות ניתן לכתיבה בכל אפליקציה שנקבלת את ההרשאה
.
יכול להיות שבהטמעות של מכשירים יהיה חומרה לאחסון נייד שגלוי למשתמשים,
כמו כרטיס Secure Digital. לחלופין, יכול להיות שמימושים במכשירים יוקצו
אחסון פנימי (לא נשלף) כאחסון משותף לאפליקציות.
ללא קשר לסוג האחסון המשותף שבו נעשה שימוש, הטמעות של מכשירים חייבות
לספק מנגנון כלשהו לגישה לתוכן של האחסון המשותף ממחשב
מארח, כמו אחסון בנפח גדול (UMS) ב-USB או פרוטוקול העברת מדיה (MTP).
הטמעות של מכשירים יכולות להשתמש באחסון בנפח גדול ב-USB, אבל עדיף להשתמש בפרוטוקול
העברת המדיה. אם הטמעת המכשיר תומכת ב-Media Transfer Protocol:
הטמעת המכשיר צריכה להיות תואמת למארח ה-
MTP של Android, Android File Transfer [Resources, 57].
הטמעת המכשיר צריכה לדווח על סיווג מכשיר USB של 0x00.
הטמעת המכשיר צריכה לדווח על שם ממשק USB של 'MTP'.
אם להטמעת המכשיר חסרים יציאות USB, חובה לספק למחשב מארח
גישה לתוכן של אחסון השיתופי באמצעים אחרים, כמו מערכת
קבצים ברשת.
כדאי להביא שתי דוגמאות נפוצות. אם הטמעת המכשיר כוללת
חריץ לכרטיס SD כדי לעמוד בדרישת האחסון המשותף, חובה לכלול במכשיר כפי שנמכר למשתמשים כרטיס SD בפורמט FAT
בגודל 1GB או גדול ממנו, וחייבים
לטעון אותו למכשיר כברירת מחדל. לחלופין, אם הטמעה של מכשיר משתמשת באחסון
פנימי קבוע כדי לעמוד בדרישה הזו, האחסון חייב להיות בגודל 1GB או יותר ו
מוטמע ב-/sdcard (או ש-/sdcard חייב להיות קישור סמלי למיקום הפיזי אם הוא
מוטמע במקום אחר).
הטמעות של מכשירים שכוללות כמה נתיבים לאחסון שיתופי (כמו גם
חריץ לכרטיס SD וגם אחסון פנימי שיתופי) צריכות לשנות את האפליקציות העיקריות כמו
סורק המדיה ו-ContentProvider כדי לתמוך בצורה שקיפות בקבצים שנמצאים בשני
המיקומים.
7.7. USB
הטמעות של מכשירים צריכות לכלול יציאת לקוח USB, וכן צריכות לכלול יציאת מארח
USB.
אם הטמעת המכשיר כוללת יציאת לקוח USB:
היציאה חייבת להיות ניתנת לחיבור למארח USB עם יציאת USB-A רגילה
היציאה צריכה להשתמש בפורמט micro USB בצד המכשיר.
במכשירים קיימים ומכשירים חדשים שפועלת בהם מערכת Android 4.1 מומלץ מאוד לעמוד
בדרישות האלה ב-Android 4.1 כדי שיהיה אפשר לשדרג אותם לגרסת הפלטפורמה העתידית
היציאה צריכה להיות מרכזית במרכז הקצה.
הטמעות מכשירים
צריכות להציב את היציאה בחלק התחתון של המכשיר (בהתאם לכיוון
הטבעי) או להפעיל סיבוב מסך בתוכנה לכל האפליקציות (כולל מסך
הבית), כדי שהתצוגה תתאר בצורה נכונה כשהמכשיר מוטה כאשר היציאה
בחלק התחתון. מכשירים קיימים וחדשים עם Android 4.1 מומלצים מאוד
לעמוד בדרישות האלה ב-Android 4.1 כדי שיוכלו
לשדרג לגרסאות עתידיות של הפלטפורמה.
אם למכשיר יש יציאות אחרות (למשל, יציאת טעינה שאינה USB),
היא צריכה להיות
באותו קצה כמו יציאת ה-micro-USB
המכשיר חייב לאפשר למארח שמחובר אליו לגשת לתוכן של
נפח האחסון המשותף באמצעות אחסון בנפח גדול ב-USB או באמצעות פרוטוקול העברת
מדיה
המכשיר חייב ליישם את המפרט ואת ה-API של Android Open Accessory כפי שמתואר
במסמכי העזרה של Android SDK, וגם להצהיר על תמיכה
בתכונה החומרה android.hardware.usb.accessory [מקורות מידע, 52]
המכשיר חייב ליישם את סיווג האודיו של USB כפי שמתואר
במסמכי העזרה של Android SDK [מקורות מידע, 66]
המכשיר צריך ליישם תמיכה במפרט הטעינה של סוללות USB
[מקורות מידע, 64] מכשירים קיימים וחדשים עם Android 4.1 מומלצים מאוד
לעמוד בדרישות האלה ב-Android 4.1 כדי שיוכלו
לשדרג לגרסאות עתידיות של הפלטפורמה
אם הטמעת המכשיר כוללת יציאת מארח USB:
היא עשויה להשתמש בפורמט יציאה לא סטנדרטי, אבל אם כן,
היא חייבת להימכר עם כבל או
כבלים שמתאימים את היציאה ל-USB-A סטנדרטי
המכשיר חייב ליישם את ה-API של מארח USB ב-Android כפי שמתואר
במסמכי העזרה של Android SDK, וגם להצהיר על תמיכה
בתכונה החומרה
android.hardware.usb.host [מקורות מידע, 53]
הטמעות של מכשירים חייבות ליישם את Android Debug Bridge. אם הטמעה
של מכשיר לא כוללת יציאת לקוח USB, חובה להטמיע את Android Debug Bridge
דרך רשת אזורית (למשל Ethernet או 802.11)
8. תאימות ביצועים
הטמעות מכשירים חייבות לעמוד במדדי הביצועים העיקריים של מכשיר תואם Android 4.1
שמוגדרים בטבלה שלמטה:
מדד
סף ביצועים
הערות
האפליקציות הבאות
צריכות להיפתח בתוך הזמן
שצוין.
זמן ההפעלה נמדד כ
זמן הכולל להשלמת הטעינה של
הדפדפן: פחות
מפעילות ברירת המחדל של האפליקציה,
אפליקציה
1300ms
כולל הזמן שדרוש להפעלת
זמן ההפעלה
אנשי קשר: פחות
ממנהל Linux, טעינה של
חבילת
Android ל-Dalvik VM, והפעלת
הגדרות: פחות
onCreate.
700ms
כש
הופעלו
כמה אפליקציות,
ההפעלה מחדש
של אפליקציה שכבר
פועלת
בו-זמנית אחרי שהיא
הופעל
חייבת
לקחת פחות
מזמני ההפעלה
המקוריים.
9. תאימות מודל אבטחה
הטמעות מכשירים חייבות להטמיע מודל אבטחה שתואם למודל אבטחה הפלטפורמה
של Android, כפי שהוא מוגדר במסמך התיעוד בנושא אבטחה והרשאות ב-
APIs [משאבים, 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 ששותף על ידי כל
האפליקציות שמשתמשות בסביבת זמן הריצה החלופית
אסור להשתמש בסביבות זמן ריצה חלופיות ובאפליקציות שהותקנו באמצעות סביבות זמן ריצה חלופיות בקונטיינר של אפליקציה אחרת שמתקינים במכשיר, למעט דרך
המנגנונים הרגילים של Android לזיהוי משתמש ששותף ומסמך חתימה
אסור להפעיל סביבות זמן ריצה חלופיות עם גישה לקונטיינרים שתואמים לאפליקציות אחרות ב-Android, להעניק גישה לקונטיינרים כאלה לסביבות זמן ריצה חלופיות או להעניק גישה לסביבות זמן ריצה חלופיות לאפליקציות אחרות
אסור להעניק לסביבות זמן ריצה חלופיות הרשאות של סופר-משתמש (root) או של מזהה משתמש אחר, להעניק לסביבות זמן ריצה חלופיות הרשאות של סופר-משתמש (root) או של מזהה משתמש אחר לאפליקציות אחרות או להעניק הרשאות כאלה לאפליקציות אחרות מתוך סביבות זמן ריצה חלופיות.
קבצי ה-APK של סביבות זמן ריצה חלופיות יכולים להיכלל בתמונה המערכת של הטמעה
במכשיר, אבל חובה לחתום עליהן במפתח שונה מהמפתח שמשמש לחתימה על
אפליקציות אחרות שכלולות בהטמעה במכשיר.
כשמתקינים אפליקציות, סביבות זמן ריצה חלופיות חייבות לקבל הסכמה מהמשתמשים ל
הרשאות Android שבהן האפליקציה משתמשת. כלומר, אם אפליקציה צריכה להשתמש
במשאב של מכשיר שיש לו הרשאה מתאימה ב-Android (כמו
מצלמה, GPS וכו'), סביבת זמן הריצה החלופית חייבת להודיע למשתמש שהאפליקציה
תהיה בעלת גישה למשאבים האלה. אם סביבת זמן הרצה לא מתעדת
יכולות אפליקציה בדרך הזו, סביבת זמן הרצה חייבת לפרוס רשימת
הרשאות שנמצאות בבעלות סביבת זמן הרצה עצמה כשמתקינים אפליקציה כלשהי באמצעות סביבת זמן הרצה הזו.
10. בדיקת תאימות תוכנה
הטמעות מכשירים חייבות לעבור את כל הבדיקות המתוארות בקטע הזה.
עם זאת, חשוב לזכור שאף חבילת בדיקות תוכנה לא מקיפה את כל האפשרויות. לכן,
אנחנו ממליצים מאוד לאנשים שמטמיעים את הרכיבים במכשירים לבצע את המספר המינימלי האפשרי של
שינויים בהטמעה המומלצת והמקובלת של Android 4.1
שזמינה בפרויקט Android Open Source. כך נוכל להפחית את הסיכון ל
הכנסת באגים שיוצרים אי-תאימות שדורשת עבודה מחדש ועדכונים פוטנציאליים למכשיר
.
10.1. חבילת בדיקות תאימות
הטמעות של מכשירים חייבות לעבור את חבילת הבדיקות לתאימות של Android (CTS)
[מקורות מידע, 2] שזמינה בפרויקט הקוד הפתוח של Android, באמצעות תוכנת המשלוח
הסופית במכשיר. בנוסף, מפתחי מכשירים צריכים להשתמש ב
הטמעת העזרה שבעץ הקוד הפתוח של Android כמה שיותר, ו
חייבים לוודא תאימות במקרים של ערפול ב-CTS ולכל
הטמעות מחדש של חלקים מקוד המקור של העזרה.
ה-CTS מיועד להפעלה במכשיר אמיתי. כמו כל תוכנה, גם ה-CTS
עשוי להכיל באגים. ה-CTS יופיע בגרסאות שונות בלי קשר להגדרת התאימות
הזו, ויכול להיות שיושקו כמה תיקונים של ה-CTS עבור Android 4.1. הטמעות
של מכשיר חייבות לעבור את גרסת ה-CTS העדכנית ביותר שזמינה בזמן השלמת תוכנת
המכשיר.
10.2. CTS Verifier
הטמעות של מכשירים חייבות להריץ באופן תקין את כל התרחישים הרלוונטיים ב-CTS
Verifier. כלי האימות של CTS נכלל בחבילת בדיקות התאימות, והוא מיועד
להפעלה על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא ניתן לבדוק באמצעות
מערכת אוטומטית, כמו הפעולה הנכונה של מצלמה וחיישנים.
ב-CTS Verifier יש בדיקות לסוגים רבים של חומרה, כולל חומרה מסוימת
שאופציונלית. הטמעות של מכשירים חייבות לעבור את כל הבדיקות של החומרה ש
יש להם. לדוגמה, אם למכשיר יש מכשיר תאוצה, הוא חייב
להריץ בצורה נכונה את תרגיל הבדיקה של מכשיר התאוצה ב-CTS Verifier. ניתן לדלג או להשמיט תרחישים בדיקה של תכונות שצוינו
כאופציונליות במסמך הגדרת התאימות הזה.
כל מכשיר וכל גרסת build חייבים להפעיל באופן תקין את CTS Verifier, כפי שצוין למעלה.
עם זאת, מכיוון שגרסאות build רבות דומות מאוד, מפתחי מכשירים לא צפויים
להפעיל באופן מפורש את CTS Verifier בגרסאות build ששונות רק בדרכים טריוויאליות. במיוחד,
הטמעות מכשיר ששונות מהטמעה שעברה את CTS
Verifer רק בקבוצה של השפות המקומיות, המיתוג וכו' יכולות להשמיט את הבדיקה של CTS Verifier
.
10.3. אפליקציות עזר
מפתחי מכשירים חייבים לבדוק את תאימות ההטמעה באמצעות האפליקציות הפתוחות
ההבאות:
האפליקציות 'אפליקציות ל-Android' [Resources, 55]
Replica Island (זמינה ב-Android Market)
כל אפליקציה שלמעלה חייבת להיפתח ולהתנהג בצורה תקינה בהטמעה, כדי ש
ההטמעה תחשב כמתאימה.
11. תוכנה ניתנת לעדכון
הטמעות של מכשירים חייבות לכלול מנגנון להחלפת כל תוכנת
המערכת. המנגנון לא נדרש לבצע שדרוגים "בזמן אמת" - כלומר, יכול להיות שתצטרכו להפעיל מחדש את המכשיר
.
אפשר להשתמש בכל שיטה, בתנאי שהיא יכולה להחליף את כל התוכנה
שמותקנת מראש במכשיר. לדוגמה, כל אחת מהגישות הבאות תעמוד
בדרישה הזו:
הורדות אוויר (OTA) עם עדכון אופליין באמצעות הפעלה מחדש
עדכונים 'מחוברים' דרך USB ממחשב מארח
עדכונים 'אופליין' באמצעות הפעלה מחדש ועדכון מתוך קובץ אחסון נייד
מנגנון העדכון שנעשה בו שימוש חייב לתמוך בעדכונים בלי מחיקה של נתוני המשתמשים. כלומר,
מנגנון העדכון חייב לשמור על נתונים פרטיים של אפליקציה ועל נתונים
ששותפו באפליקציה. לתשומת ליבכם: תוכנת Android ב-upstream כוללת מנגנון עדכון
שעומד בדרישות האלה.
אם מתגלה שגיאה בהטמעה של מכשיר אחרי שפורסם אבל במהלך
תקופת החיים הסבירה של המוצר שנקבעה בשיתוף פעולה עם
צוות התאימות של Android ומשפיעה על התאימות של אפליקציות של צד שלישי, המטמיע
של המכשיר חייב לתקן את השגיאה באמצעות עדכון תוכנה זמין שאפשר
להחיל לפי המנגנון שתיארנו.
12. יצירת קשר איתנו
אפשר לפנות למחברים של המסמך באימייל compatibility@android.com לקבלת הבהרות
ולציין בעיות שלא מופיעות במסמך.
נספח א - נוהל בדיקת Bluetooth
חבילת בדיקות התאימות כוללת תרחישים שכוללים פעולה בסיסית של Android
RFCOMM Bluetooth API. עם זאת, מכיוון ש-Bluetooth הוא פרוטוקול תקשורת
בין מכשירים, אי אפשר לבדוק אותו באופן מלא באמצעות בדיקות יחידה שפועלות במכשיר יחיד.
כתוצאה מכך, הטמעות מכשירים חייבות גם לעבור את נוהל הבדיקה
של Bluetooth בפעולה אנושית שמתואר בהמשך.
תהליך הבדיקה מבוסס על אפליקציית הדוגמה BluetoothChat שכלולה בעץ הפרויקט בקוד פתוח של Android
. התהליך מחייב שני מכשירים:
הטמעה של מכשיר נבחן שבו פועלת גרסה של התוכנה שרוצים לבדוק
הטמעה נפרדת של מכשיר שכבר ידוע שהוא תואם, וגם
מודל מהטמעת המכשיר שנבדקת – כלומר,
הטמעה של מכשיר 'מוכרת ותקינה'
בתהליך הבדיקה שמתואר בהמשך, המכשירים האלה נקראים 'מכשיר נבחן' ו'מכשיר ידוע
ותקין', בהתאמה.
הגדרה והתקנה
1. יוצרים את BluetoothChat.apk באמצעות 'make samples' מעץ קוד מקור של Android
2. מתקינים את BluetoothChat.apk במכשיר הידוע כתקין
3. מתקינים את BluetoothChat.apk במכשיר הנבחר
בדיקת השליטה ב-Bluetooth באמצעות אפליקציות
1. מריצים את BluetoothChat במכשיר הנבחר, כש-Bluetooth מושבת
2. מוודאים שמכשיר הבחירה מפעיל את ה-Bluetooth, או שמוצגת למשתמש
תיבת דו-שיח כדי להפעיל את ה-Bluetooth
בודקים התאמה ותקשורת
1. פותחים את אפליקציית Bluetooth Chat בשני המכשירים
2. מגדירים את המכשיר המוכר כמכשיר גלוי מתוך BluetoothChat (באמצעות ה
תפריט)
3. במכשיר הנבחר, מחפשים מכשירי Bluetooth מתוך BluetoothChat
(באמצעות התפריט) ומתאימים למכשיר הידוע כתקין
4. שולחים 10 הודעות או יותר מכל מכשיר, ומוודאים שהמכשיר השני
מקבל אותן בצורה תקינה
5. סוגרים את אפליקציית BluetoothChat בשני המכשירים על ידי לחיצה על דף הבית
6. מבטלים את ההתאמה של כל מכשיר מהמכשיר השני באמצעות אפליקציית ההגדרות של המכשיר
בודקים את ההתאמה והתקשורת בכיוון ההפוך
1.
פותחים את אפליקציית Bluetooth Chat בשני המכשירים.
2. מגדירים את המכשיר המתאים כמכשיר גלוי מתוך BluetoothChat (באמצעות התפריט
).
3. במכשיר הידוע כתקין, סורקים מכשירי Bluetooth מתוך BluetoothChat
(באמצעות התפריט) ומתאימים למכשיר הנבחר.
4. שולחים 10 הודעות מכל מכשיר, ומוודאים שהמכשיר השני
מקבל אותן בצורה תקינה.
5. סוגרים את אפליקציית Bluetooth Chat בשני המכשירים על ידי לחיצה חוזרת על 'הקודם' כדי להגיע למרכז האפליקציות
.
בדיקת השקות מחדש
1. מפעילים מחדש את אפליקציית Bluetooth Chat בשני המכשירים.
2. שולחים 10 הודעות מכל מכשיר, ומוודאים שהמכשיר השני
מקבל אותן בצורה תקינה.
הערה: בחלק מהבדיקות שלמעלה יש מקרים שבהם מסיימים קטע בדיקה באמצעות הלחצן 'דף הבית', ו
בחלק באמצעות הלחצן 'הקודם'. הבדיקות האלה הן לא עודפות ולא אופציונליות: המטרה היא
לבדוק ש-Bluetooth API והמקבץ פועלים בצורה תקינה גם כשפעילויות
מסתיימות באופן מפורש (דרך הלחיצה של המשתמש על 'הקודם', שגורמת לקריאה finish()), וגם כשהן נשלחות
באופן משתמע לרקע (דרך הלחיצה של המשתמש על 'דף הבית'). חובה לבצע כל רצף בדיקות
כפי שמתואר.
