תמיכה בגרסת המצלמה

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

טרמינולוגיה

בדף הזה נעשה שימוש במונחים הבאים:

Camera API1

המסגרת של המצלמה ברמת האפליקציה במכשירי Android מגרסה 4.4 ומטה, שנחשפת באמצעות הכיתה android.hardware.Camera.

Camera API2

המסגרת של המצלמה ברמת האפליקציה במכשירי Android מגרסה 5.0 ואילך, שחשופה דרך החבילה android.hardware.camera2.

Camera HAL

שכבת מודול המצלמה שמוטמעת על ידי ספקי SoC. המסגרות הציבוריות ברמת האפליקציה מבוססות על HAL של המצלמה.

Camera HAL3.1

גרסת HAL של מכשיר המצלמה ששוחררה עם Android 4.4.

Camera HAL3.2

גרסת ה-HAL של מכשיר המצלמה שפורסמה עם Android 5.0.

Camera API1 CTS

קבוצה של בדיקות CTS למצלמה שפועלות מעל Camera API1.

Camera API2 CTS

קבוצה נוספת של בדיקות CTS למצלמה שפועלות מעל Camera API2.

טרבל

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

HIDL

שפת הגדרה לבניית ממשק HAL, שנוספה ל-Treble ומשמשת לציון הממשק בין HAL לבין המשתמשים שלו.

VTS

חבילת בדיקות של ספקים שנוספה ל-Treble.

ממשקי API של מצלמה

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

Camera API1

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

• ממשקי Camera API1 לאפליקציות אפליקציות מצלמה שנוצרו על סמך Camera API‏ 1 אמורות לפעול כמו שהן פועלות במכשירים עם גרסאות Android ישנות יותר.
• גרסאות HAL של מצלמה כולל תמיכה ב-Camera HAL1.0.

Camera API2

מסגרת Camera API2 חושפת לאפליקציה אמצעי בקרה ברמה נמוכה יותר של המצלמה, כולל תהליכי צילום רצוף/סטרימינג יעילים ללא העתקה (zero-copy) ואמצעי בקרה לכל פריים של חשיפת התמונה, הגברה, שיפור איזון הלבן, המרת צבע, הסרת רעשי רקע, חידוד ועוד. לפרטים נוספים, צפו ב סקירה הכללית בסרטון של Google I/O.

מערכת Android מגרסה 5.0 ואילך כוללת את Camera API2. עם זאת, יכול להיות שמכשירים עם Android מגרסה 5.0 ואילך לא תומכים בכל התכונות של Camera API2. המאפיין android.info.supportedHardwareLevel, שאפליקציות יכולות לשלוח לגביו שאילתות דרך ממשקי Camera API2, מדווח על אחד מרמות התמיכה הבאות:

• LEGACY: במכשירים האלה, האפליקציות יכולות לגשת ליכולות שדומות לאלה שגלומות בממשקי Camera API1. קוד המסגרות הקודם מתרגם קריאות ל-Camera API2 לקריאות ל-Camera API1. מכשירי קודמים לא תומכים בתכונות של Camera API2, כמו אמצעי בקרה לכל פריים.
• LIMITED: המכשירים האלה תומכים בחלק מהיכולות של Camera API2 (אבל לא בכלן), וצריך להשתמש ב-Camera HAL מגרסה 3.2 ומעלה.
• FULL: המכשירים האלה תומכים בכל היכולות העיקריות של Camera API2, וצריך להשתמש ב-Camera HAL מגרסה 3.2 ואילך וב-Android מגרסה 5.0 ואילך.
• LEVEL_3: המכשירים האלה תומכים בעיבוד חוזר של YUV ובצילום תמונות RAW, וגם בתצורות נוספות של פלט הווידאו.
• EXTERNAL: המכשירים האלה דומים למכשירי LIMITED, עם כמה יוצאים מן הכלל. לדוגמה, יכול להיות שלא ידווחו חלק מהנתונים של החיישן או העדשה, או ששיעורי הפריימים יהיו פחות יציבים. הרמה הזו משמשת למצלמות חיצוניות, כמו מצלמות רשת מסוג USB.

יכולות ספציפיות נחשפות דרך המאפיין android.request.availableCapabilities בממשקי Camera API2. במכשירי FULL נדרשות, בין היתר, היכולות MANUAL_SENSOR ו-MANUAL_POST_PROCESSING. היכולת RAW היא אופציונלית גם במכשירי FULL. מכשירי LIMITED יכולים לפרסם כל קבוצת משנה של היכולות האלה, כולל אף אחת מהן. עם זאת, תמיד צריך להגדיר את היכולת BACKWARD_COMPATIBLE.

רמת החומרה הנתמכת במכשיר, וכן היכולות הספציפיות של Camera API2 שנתמכות בו, זמינות בתור דגלים הבאים כדי לאפשר ל-Google Play לסנן אפליקציות מצלמה של Camera API2.

• android.hardware.camera.hardware_level.full
• android.hardware.camera.capability.raw
• android.hardware.camera.capability.manual_sensor
• android.hardware.camera.capability.manual_post_processing

דרישות CTS

מכשירי Android מגרסה 5.0 ואילך חייבים לעבור את בדיקות המצלמה של Camera API1 CTS,‏ Camera API2 CTS ו-CTS Verifier.

מכשירים שלא כוללים הטמעה של Camera HAL3.2 ולא יכולים לתמוך בממשקי Camera API2 המלאים עדיין צריכים לעבור את בדיקות ה-CTS של Camera API2. עם זאת, המכשיר פועל במצב LEGACY של Camera API2 (שבו הקריאות ל-Camera API2 ממפות באופן קונספטואלי לקריאות ל-Camera API1), כך שכל בדיקות ה-CTS של Camera API2 שקשורות לתכונות או ליכולות מעבר ל-Camera API1 נדלגות באופן אוטומטי.

במכשירים ישנים, בדיקות CTS של Camera API2 שפועלות משתמשות בממשקים וביכולות הציבוריים הקיימים של Camera API1, ללא דרישות חדשות. באגים שנחשפו (שגורמים לכישלון ב-CTS של Camera API2) הם באגים שכבר קיימים ב-HAL הקיים של המצלמה במכשיר, ולכן הם יימצאו על ידי אפליקציות קיימות של Camera API1. אנחנו לא מצפים ליותר מדי באגים מהסוג הזה (עם זאת, צריך לתקן את כל הבאגים האלה כדי לעבור את בדיקות ה-CTS של Camera API2).

הדרישות ל-VTS

מכשירי Android מגרסה 8.0 ואילך עם הטמעות HAL ב-binder חייבים לעבור את בדיקות ה-VTS של המצלמה.

הקשחת מסגרת המצלמה

כדי לשפר את האבטחה של מסגרת המדיה והמצלמה, ב-Android 7.0 השירות של המצלמה הועבר מ-mediaserver. החל מ-Android 8.0, כל HAL של מצלמה שמקושר באמצעות binder פועל בתהליך נפרד משירות המצלמה. ייתכן שהספקים יצטרכו לבצע שינויים ב-HAL של המצלמה, בהתאם לגרסאות ה-API ו-HAL שבשימוש. בקטעים הבאים מפורטים השינויים הארכיטקטוניים ב-AP1 וב-AP2 עבור HAL1 ו-HAL3, וכן הדרישות הכלליות.

שינויים בארכיטקטורה של API1

כשמצלמים סרטון באמצעות API1, יכול להיות שהמצלמה ומקודד הווידאו נמצאים באותו תהליך. כשמשתמשים ב-API1 ב-:

• HAL3, שבו שירות המצלמה משתמש ב-BufferQueue כדי להעביר מאגרים בין תהליכים, אין צורך בעדכון של הספק.

  

  איור 1. מקבץ של מצלמה ומדיה ב-Android 7.0 ב-API1 ב-HAL3

• HAL1, שתומך בהעברת מטא-נתונים במאגרי וידאו, הספקים חייבים לעדכן את ה-HAL כך שישתמש ב-kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource לא נתמך יותר ב-Android 7.0).

  

  איור 2. מקבץ המצלמה והמדיה של Android 7.0 ב-API1 ב-HAL1

שינויים בארכיטקטורה של API2

ב-API2 ב-HAL1 או ב-HAL3, BufferQueue מעביר מאגרים כדי שהנתיבים האלה ימשיכו לפעול. הארכיטקטורה של Android 7.0 ל-API2 ב-:

• HAL1 לא מושפע מהמעבר של cameraservice, ולא נדרש עדכון של הספק.
• HAL3 מושפע, אבל אין צורך בעדכון של הספק:

  

  איור 3. מקבץ של מצלמה ומדיה ב-Android 7.0 ב-API2 ב-HAL3

דרישות נוספות

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

• כללי. מכשירים דורשים רוחב פס נוסף בגלל IPC, שעלול להשפיע על תרחישים לדוגמה של שימוש במצלמה שזמן הוא גורם קריטי בהם, כמו צילום וידאו במהירות גבוהה. ספקים יכולים למדוד את ההשפעה בפועל על ידי הפעלת android.hardware.camera2.cts.PerformanceTest ואפליקציית Google Camera לצילום וידאו במהירות גבוהה של 120/240 FPS. בנוסף, נדרשת כמות קטנה של זיכרון RAM נוסף כדי ליצור את התהליך החדש.
• העברת מטא-נתונים במאגרי וידאו (HAL1 בלבד). אם HAL1 מאחסן מטא-נתונים במקום נתוני מסגרת YUV אמיתיים במאגרי וידאו, ה-HAL צריך להשתמש ב-kMetadataBufferTypeNativeHandleSource כסוג של מאגר המטא-נתונים ולהעביר את VideoNativeHandleMetadata במאגרי וידאו. (האפשרות kMetadataBufferTypeCameraSource לא נתמכת יותר ב-Android 7.0). בעזרת VideoNativeHandleMetadata, מסגרות המצלמה והמדיה יכולות להעביר את מאגרי הווידאו בין תהליכים על ידי ביצוע סריאליזציה וביטול סריאליזציה של הלחצנים המקוריים בצורה נכונה.
• כתובת של מאגר מטמון לא תמיד שומרת את אותו מאגר (HAL3 בלבד). לכל בקשת צילום, HAL3 מקבל כתובות של מאגרים. HAL לא יכול להשתמש בכתובות כדי לזהות מאגרים כי הכתובות יכולות לאחסן עוד מאגר אחרי ש-HAL מחזיר את המאגר. צריך לעדכן את ה-HAL כך שישתמש במזהי מאגרים כדי לזהות את המאגרים. לדוגמה, HAL מקבל את כתובת ה-handle של מאגר הנתונים A, שמאחסן את ה-handle של מאגר הנתונים A. אחרי ש-HAL מחזיר את ה-buffer handle‏ A, כתובת ה-buffer handle‏ A עשויה לאחסן את ה-buffer handle‏ B בפעם הבאה ש-HAL יקבל אותו.
• עדכון כללי המדיניות של SELinux עבור cameraserver אם מדיניות SELinux ספציפית למכשיר מעניקה ל-mediaserver הרשאות להפעיל את המצלמה, צריך לעדכן את מדיניות SELinux כדי לתת ל-cameraserver את ההרשאות המתאימות. אנחנו ממליצים לא להעתיק את כללי המדיניות של SELinux ב-mediaserver ל-cameraserver (כי בדרך כלל ל-mediaserver ול-cameraserver נדרשים משאבים שונים במערכת). ל-Cameraserver צריכות להיות רק ההרשאות הנדרשות לביצוע הפונקציות של המצלמה, וכל ההרשאות הלא נחוצות שקשורות למצלמה ב-Mediaserver צריכות להימחק.
• הפרדה בין Camera HAL לבין cameraserver ב-Android 8.0 ואילך, בנוסף, מפרידים את Camera HAL המקושר בתהליך שונה מ-cameraserver. ה-IPC עובר דרך ממשקים שהוגדרו ב-HIDL.

אימות

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

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

היסטוריית הגרסאות של Camera HAL

ברשימת המשימות לבדיקת Camera HAL תוכלו למצוא רשימה של בדיקות שזמינות להערכת Android Camera HAL.

Android 10

ב-Android 10 יש את העדכונים הבאים.

Camera API

• שיפורים במצלמות מרובות שמאפשרים להשתמש במצלמות פיזיות בנפרד או באמצעות מצלמות לוגיות תואמות, על ידי הסתרת מזהי המצלמות הפיזיות. תמיכה במספר מצלמות
• היכולת לבדוק אם תצורת סשן מסוימת נתמכת, בלי התקורה בביצועים שנובעת מיצירת סשן חדש. מידע נוסף זמין במאמר CameraDevice.
• יכולת לאחזר הגדרות מומלצות של סטרימינג לתרחיש שימוש נתון, כדי לשפר את הביצועים ואת יעילות האנרגיה של הלקוח. מידע נוסף זמין במאמר getRecommendedStreamConfigurationMap.
• תמיכה ב פורמט תמונה של JPEG עומק. פרטים נוספים זמינים במפרט של Dynamic Depth.
• תמיכה ב פורמט התמונה HEIC. תמונות HEIF
• שיפורים בפרטיות. כדי שאפשר יהיה לאחזר מ- CameraCharacteristics מפתחות מסוימים, הלקוח צריך הרשאות CAMERA. מידע נוסף זמין במאמר getKeysNeedingPermission.

Camera HAL

הגרסאות הבאות של Camera HAL מתעדכנות ב-Android 10.

3.5

ICameraDevice

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

ICameraDeviceSession

• isReconfigurationNeeded:‏ שיטה שמציינת למסגרת המצלמה אם נדרשת הגדרה מחדש מלאה של הסטרימינג לערכים אפשריים חדשים של פרמטרים של סשנים. כך תוכלו למנוע עיכובים מיותרים בהגדרה מחדש של המצלמה. שאילתת הגדרה מחדש של סשן
• ממשקי API לניהול מאגרים (buffers) של HAL: ממשקי ה-API האלה מאפשרים ל-HAL של המצלמה לבקש מאגרים מהמסגרת של המצלמה רק כשיש צורך בכך, במקום לצרף כל בקשת צילום למאגרים המשויכים שלה לאורך צינור עיבוד הנתונים של המצלמה. כך אפשר לחסוך זיכרון באופן משמעותי.
  • signalStreamFlush: אות ל-HAL ששירות המצלמה עומד לבצע את הפעולה configureStreams_3_5 וש-HAL צריך להחזיר את כל המאגרים של השידורים הייעודיים.
  • configureStreams_3_5: דומה ל-ICameraDevice3.4.configureStreams, אבל בנוסף, המונה streamConfigCounter מסופק כדי לבדוק אם יש תנאי מרוץ בין הקריאות ל-configureStreams_3_5 ול-signalStreamFlush.

עדכונים לגבי ICameraDeviceCallback:

• requestStreamBuffers: callback סינכרוני שנקרא על ידי HAL המצלמה כדי לבקש מאגרים משרת המצלמה. מידע נוסף זמין במאמר requestStreamBuffers.
• returnStreamBuffers: קריאה חוזרת (callback) סינכרונית ל-HAL של המצלמה כדי להחזיר מאגרי פלט לשרת המצלמה. מידע נוסף זמין במאמר returnStreamBuffers.

3.4

המפתחות הבאים מתווספים למטא-נתונים של המצלמה ב-Android 10.

• פורמטים של תמונות
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
  • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
• תגי מטא-נתונים של מצלמה
  • ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
  • ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
  • ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
  • ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
  • ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
  • ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
  • ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
  • ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
  • ANDROID_HEIC_INFO_SUPPORTED
  • ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
• יכולות
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
• ערכים למַפְתח ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
• הגדרות זמינות של שידור עומק דינמי
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
• הגדרות זמינות של שידורי HEIC
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

מודול מצלמה

הגרסאות הבאות של מודולי המצלמה מתעדכנות ב-Android 10.

2.5

• הוספת השיטה notifyDeviceStateChange למכשירים כדי להודיע ל-HAL של המצלמה כששינויים פיזיים, כמו קיפול, משפיעים על המצלמה ועל הניתוב.

2.4

• במכשירים שפועלים עם רמת API 29 ואילך חובה לדווח על true עבור isTorchModeSupported.

Android 9

במהדורת Android 9 נוספו העדכונים הבאים לממשק ה-HAL ול-API2 של המצלמה.

Camera API

• הוספת ממשק API למספר מצלמות כדי לשפר את התמיכה במכשירים עם כמה מצלמות שמכוונות לאותו כיוון, ומאפשרת תכונות כמו בוקה וזום חלק. כך אפליקציות יכולות להציג כמה מצלמות במכשיר כיחידה לוגית אחת (מצלמה לוגית). אפשר גם לשלוח בקשות צילום למכשירי מצלמה נפרדים שנכללים במצלמה לוגית אחת. תמיכה במספר מצלמות
• הוספת פרמטרים של סשנים. פרמטרים של סשן הם קבוצת משנה של פרמטרים זמינים לתיעוד, שיכולים לגרום לעיכובים חמורים בעיבוד אם משנים אותם. אפשר לצמצם את העלויות האלה אם לקוחות מעבירים את הערכים הראשוניים שלהם במהלך האתחול של סשן הצילום. פרמטרים של סשנים
• הוספת מפתחות נתונים של ייצוב אופטי (OIS) לצורך ייצוב ואפקטים ברמת האפליקציה. מידע נוסף זמין במאמר STATISTICS_OIS_SAMPLES.
• הוספת תמיכה בפלאש חיצוני. מידע נוסף זמין במאמר CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
• הוספת כוונה למעקב אחר תנועה ב-CAPTURE_INTENT. מידע נוסף זמין במאמר CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
• הוצאה משימוש של LENS_RADIAL_DISTORTION והוספה של LENS_DISTORTION במקומה.
• הוספת מצבי תיקון עיוות ב-CaptureRequest. מידע נוסף זמין במאמר DISTORTION_CORRECTION_MODE.
• הוספת תמיכה במצלמות USB/UVC חיצוניות במכשירים נתמכים. מידע נוסף זמין במאמר INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

Camera HAL

3.4

עדכונים לגבי ICameraDeviceSession

• configureStreams_3_4: הוספת תמיכה ב-sessionParameters ובמצלמות לוגיות.
• processCaptureRequest_3_4: נוספה תמיכה בהכללת מזהי מצלמות פיזיות במבנה של מקור הנתונים.

עדכונים לגבי ICameraDeviceCallback

• processCaptureResult_3_4: הוספת מטא-נתונים פיזיים של המצלמה לתוצאות הצילום.

3.3

המפתחות הבאים מתווספים למטא-נתונים של המצלמה ב-Android 9.

• יכולות
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
• תגי מטא-נתונים של מצלמה
  • ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
  • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
  • ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
  • ANDROID_LENS_POSE_REFERENCE
  • ANDROID_LENS_DISTORTION
  • ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
  • ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
  • ANDROID_STATISTICS_OIS_DATA_MODE
  • ANDROID_STATISTICS_OIS_TIMESTAMPS
  • ANDROID_STATISTICS_OIS_X_SHIFTS
  • ANDROID_STATISTICS_OIS_Y_SHIFTS

Android 8.0

במהדורת Android 8.0 מוצגת Treble. ב-Treble, הטמעות של HAL של מצלמה של ספקים חייבות להיות ממומשות ב-binder. ב-Android 8.0 יש גם את השיפורים העיקריים הבאים בשירות המצלמה:

• משטחים משותפים: הפעלת מספר משטחים שמשתמשים באותו OutputConfiguration
• System API למצבי מצלמה מותאמים אישית
• onCaptureQueueEmpty

מידע נוסף על התכונות האלה זמין בקטעים הבאים.

משטחים משותפים

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

פרטים נוספים זמינים enableSurfaceSharing במסמכי התיעוד למפתחים.

System API למצבי מצלמה מותאמים אישית

ב-Camera API הציבורי מוגדרים שני מצבי הפעלה: הקלטה רגילה והקלטה במהירות גבוהה מוגבלת. יש להם סמנטיקה שונה למדי. לדוגמה, במצב מהירות גבוהה אפשר להשתמש בשני פלטים ספציפיים לכל היותר בו-זמנית. יצרני ציוד מקורי (OEM) שונים הביעו עניין בהגדרת מצבים מותאמים אישית אחרים ליכולות ספציפיות לחומרה. בפועל, המצב הוא רק מספר שלם שמוענק ל-configure_streams. מידע נוסף זמין במאמר: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

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

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

שם ה-method הוא android.hardware.camera2.CameraDevice#createCustomCaptureSession. מידע נוסף זמין במאמר: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

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

onCaptureQueueEmpty

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

ממשק HIDL של המצלמה

ממשק Camera HIDL הוא שינוי מקיף של ממשק Camera HAL שמשתמש ב-API יציב שהוגדר על ידי HIDL. כל התכונות והיכולות של המצלמה שהוצגו בגרסאות הקודמות האחרונות 3.4 ו-2.4 (למודול המצלמה) הן גם חלק מההגדרות של HIDL.

3.4

תוספות קלות למטא-נתונים נתמכים ושינויים בתמיכה ב-data_space:

• מוסיפים מטא-נתונים סטטיים של ANDROID_SENSOR_OPAQUE_RAW_SIZE כחובה אם יש תמיכה בפורמט RAW_OPAQUE.
• מוסיפים את המטא-נתונים הסטטיים ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE כחובה אם יש תמיכה בפורמט RAW כלשהו.
• שינוי השדה camera3_stream_t data_space להגדרה גמישה יותר, באמצעות הגדרת הגרסה 0 של קידוד מרחב הנתונים.
• תוספות כלליות של מטא-נתונים שזמינות לשימוש ב-HALv3.2 ואילך:
  • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
  • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
  • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
  • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
  • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
  • ANDROID_SENSOR_OPAQUE_RAW_SIZE
  • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

גרסה משנית של HAL עם יכולות מורחבות:

• עדכונים לממשקי ה-API של עיבוד חוזר של נתוני OPAQUE ו-YUV.
• תמיכה בסיסית במאגרי פלט של עומק.
• הוספת השדה data_space ל-camera3_stream_t.
• הוספת שדה רוטציה ל-camera3_stream_t.
• הוספה של מצב הפעולה של הגדרת מצב הסטרימינג של camera3 ל-camera3_stream_configuration_t.

3.2

גרסה משנית של HAL עם יכולות מורחבות:

• הוצאה משימוש של get_metadata_vendor_tag_ops. במקום זאת, אתם צריכים להשתמש ב-get_vendor_tag_ops ב-camera_common.h.
• הוצאה משימוש של register_stream_buffers. כל מאגרי ה-gralloc שסופקו על ידי המסגרת ל-HAL ב-process_capture_request יכולים להיות חדשים בכל שלב.
• הוספת תמיכה בתוצאות חלקיות. יכול להיות ש-process_capture_result ייכלל מספר פעמים עם קבוצת משנה של התוצאות הזמינות לפני שהתוצאה המלאה תהיה זמינה.
• מוסיפים תבנית ידנית אל camera3_request_template. אפליקציות יכולות להשתמש בתבנית הזו כדי לשלוט ישירות בהגדרות הצילום.
• עיבוד מחדש של המפרטים של מקור הנתונים והזרם הדו-כיווני.
• שינוי נתיב ההחזרה של מאגר הקלט. מאגר הנתונים מוחזר ב-process_capture_result במקום ב-process_capture_request.

3.1

גרסה משנית של HAL עם יכולות מורחבות:

• configure_streams מעביר את דגלים של שימוש של צרכנים ל-HAL.
• קריאה ל-flush כדי לבטל את כל הבקשות או מאגרי הנתונים שנמצאים בטיפול במהירות האפשרית.

3.0

הגרסה הראשונה של HAL עם יכולות מורחבות:

• שינוי בגרסה הראשית כי ה-ABI שונה לחלוטין. אין שינוי ביכולות החומרה הנדרשות או במודל התפעול לעומת הגרסה 2.0.
• ממשקי בקשת קלט ורשימה של תורים של זרמים שעברו עריכה: המערכת מבצעת קריאה ל-HAL עם הבקשה הבאה, ומאגרי הנתונים של הזרמים כבר הוסרו מהתור. התמיכה במסגרת סנכרון נכללת, והיא נחוצה להטמעות יעילות.
• הטריגרים הועברו לבקשות, ורוב ההתראות הועברו לתוצאות.
• כל קריאות החזרה (callbacks) במסגרת אוחדו למבנה אחד, וכל שיטות ההגדרה אוחדו לקריאה אחת של initialize().
• הגדרת הסטרימינג הפכה לקריאה אחת כדי לפשט את ניהול הסטרימינג. מקורות נתונים דו-כיווניים מחליפים את המבנה STREAM_FROM_STREAM.
• סמנטיקה של מצב מוגבל למכשירי חומרה ישנים או מוגבלים.

2.0

גרסה ראשונית של HAL עם יכולות מורחבות (Android 4.2) [camera2.h]:

• מספיק כדי להטמיע את ה-API הקיים של android.hardware.Camera.
• מאפשרת להשתמש בתור ZSL בשכבת שירות המצלמה.
• לא נבדקו תכונות חדשות כמו שליטה ידנית בצילום, צילום בפורמט RAW של Bayer, עיבוד מחדש של נתוני RAW וכו'.

1.0

HAL ראשוני של מצלמת Android‏ (Android 4.0) [camera.h]:

• המרות משכבת הפשטה של CameraHardwareInterface ב-C++‎.
• תמיכה ב-android.hardware.Camera API.

היסטוריית הגרסאות של מודול המצלמה

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

2.4

בגרסה הזו של מודול המצלמה נוספו השינויים הבאים ב-API:

1. תמיכה במצב פנס. המסגרת יכולה להפעיל את מצב הפנס בכל מכשיר מצלמה שיש לו יחידת פלאש, בלי לפתוח את מכשיר המצלמה. למכשיר המצלמה יש עדיפות גבוהה יותר לגישה ליחידה של הפלאש מאשר למודול המצלמה. פתיחת מכשיר המצלמה משביתה את הפנס אם הוא הופעל דרך ממשק המודול. במקרה של התנגשויות משאבים, למשל כשמתבצעת קריאה ל-open() כדי לפתוח מכשיר מצלמה, מודול ה-HAL של המצלמה צריך להודיע למסגרת באמצעות קריאה חוזרת (callback) לסטטוס של מצב הפנס שהמצב הזה כבוי.
2. תמיכה במצלמה חיצונית (לדוגמה, מצלמה עם חיבור USB לחיבור בזמן הפעלה). בעדכוני ה-API צוין שהמידע הסטטי של המצלמה זמין רק כשהמצלמה מחוברת ומוכנה לשימוש במצלמות חיצוניות עם חיבור מהיר. קריאות לקבלת מידע סטטי הן קריאות לא חוקיות כשסטטוס המצלמה הוא לא CAMERA_DEVICE_STATUS_PRESENT. המסגרת מסתמכת רק על קריאות חזרה (callbacks) של שינוי סטטוס המכשיר כדי לנהל את רשימת המצלמות החיצוניות הזמינות.
3. טיפים לבחירת מצלמה נוספה תמיכה באפשרות לציין במפורש את מספר מכשירי המצלמה שאפשר לפתוח ולהשתמש בהם בו-זמנית. כדי לציין שילובים חוקיים של מכשירים, תמיד צריך להגדיר את השדות resource_cost ו-conflicting_devices במבנה camera_info שמוחזר על ידי הקריאה get_camera_info.
4. שיטת האתחול של המודול השירות של המצלמה קורא לזה אחרי טעינת מודול ה-HAL, כדי לאפשר אתחול חד-פעמי של ה-HAL. היא נקראת לפני שמפעילים שיטות אחרות של המודול.

2.3

בגרסה הזו של מודול המצלמה נוספה תמיכה במכשירי HAL של מצלמות קודמות בקוד פתוח. אם אותו מכשיר יכול לתמוך במספר גרסאות של ממשק API למכשיר, ה-framework יכול להשתמש בו כדי לפתוח את מכשיר המצלמה כמכשיר HAL בגרסה נמוכה יותר. קריאת הפתיחה הרגילה של מודול החומרה (common.methods->open) ממשיכה לפתוח את מצלמת המכשיר בגרסה הנתמכת האחרונה, שהיא גם הגרסה שמופיעה ב-camera_info_t.device_version.

2.2

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

2.1

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

2.0

מודולי מצלמה שמדווחים על מספר הגרסה הזה מיישמים את הגרסה השנייה של ממשק ה-HAL של מודול המצלמה. מכשירי מצלמה שאפשר לפתוח באמצעות המודול הזה עשויים לתמוך בגרסה 1.0 או בגרסה 2.0 של ממשק ה-HAL של מכשיר המצלמה. השדה device_version של camera_info תמיד תקין. השדה static_camera_characteristics של camera_info תקין אם השדה device_version הוא 2.0 ואילך.

1.0

מודולי מצלמה שמדווחים על מספרי הגרסה האלה מיישמים את ממשק ה-HAL הראשוני של מודול המצלמה. כל מכשירי המצלמה שאפשר לפתוח באמצעות המודול הזה תומכים רק בגרסה 1 של HAL של מכשיר המצלמה. השדות device_version ו-static_camera_characteristics של camera_info לא תקינים. המודול הזה והמכשירים שלו יכולים לתמוך רק ב-API android.hardware.Camera.