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

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

טרמינולוגיה

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

Camera API1
המסגרת של המצלמה ברמת האפליקציה במכשירי Android מגרסה 4.4 ומטה, שנחשפת באמצעות הכיתה android.hardware.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.
CTS API1 של המצלמה
קבוצה של בדיקות CTS למצלמה שפועלות מעל Camera API1.
Camera API2 CTS
קבוצה נוספת של בדיקות CTS למצלמה שפועלות מעל Camera API2.
טרבל
מפרידה בין ההטמעה של הספק (תוכנה ברמה נמוכה למכשיר ספציפית שנכתבה על ידי יצרני סיליקון) ממסגרת Android OS באמצעות ממשק חדש של הספק.
hiDL
שפת הגדרת ממשק HAL שהושקה ב-Treble ומשמשת לציון הממשק בין HAL למשתמשים.
VTS
חבילת בדיקות של ספקים שנוספה ל-Treble.

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

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

Camera API1

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

  • ממשקי Camera API1 לאפליקציות אפליקציות מצלמה שמובנות על גבי Camera API1 אמורות לפעול כפי שהן פועלות במכשירים שבהם פועלות גרסאות 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. הקוד של frameworks מדור קודם מתרגם באופן רעיוני קריאות ל- Camera API2 לקריאות API1 של Camera; מכשירים מדור קודם לא תומכים בתכונות של 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.

מכשירים שלא כוללים הטמעת מצלמה HAL3.2 ולא תומכים בממשקים המלאים של Camera API2 עדיין צריכים לעבור את הבדיקות של Camera API2 CTS. עם זאת, המכשיר פועל במצב 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, שבה שירות המצלמה משתמש ב-BuffQueue כדי להעביר מאגרי נתונים זמניים בין תהליכים, לא נדרש עדכון ספק.

    סטאק של מצלמה ומדיה ב-Android 7.0 ב-API1 ב-HAL3

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

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

    מצלמה וסטאק מדיה של Android 7.0 ב-API1 ב-HAL1

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

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

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

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

    מצלמה ומקבץ מדיה של Android 7.0 ב-API2 ב-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 במאגרי וידאו. (ב-Android 7.0 כבר אין תמיכה ב-kMetadataBufferTypeCameraSource.) בעזרת VideoNativeHandleMetadata, מסגרות המצלמה והמדיה יכולות להעביר את מאגרי הווידאו בין תהליכים על ידי ביצוע סריאליזציה וביטול סריאליזציה של הלחצנים המקוריים בצורה נכונה.
  • הכתובת של מאגר הנתונים הזמני לא תמיד מאוחסנת במאגר הנתונים הזמני (HAL3 בלבד). בכל בקשת תיעוד, HAL3 מקבל כתובות של כינויים למאגרי נתונים זמניים. HAL לא יכול להשתמש בכתובות כדי לזהות מאגרים כי הכתובות יכולות לאחסן עוד מאגר אחרי ש-HAL מחזיר את המאגר. צריך לעדכן את ה-HAL כך שישתמש במזהי מאגרים כדי לזהות את המאגרים. לדוגמה, HAL מקבל את כתובת א' של נקודת האחיזה למאגר הנתונים הזמני, ששומרת את נקודת האחיזה א' למאגר הנתונים הזמני. אחרי ש-HAL מחזיר את נקודת האחיזה א' למאגר הנתונים הזמני, הכתובת א' עשויה לשמור את נקודת האחיזה למאגר הנתונים B בפעם הבאה שה-HAL יקבל אותה.
  • עדכון כללי המדיניות של SELinux עבור cameraserver אם מדיניות SELinux ספציפית למכשיר מעניקה ל-mediaserver הרשאות להפעיל את המצלמה, צריך לעדכן את מדיניות SELinux כדי לתת ל-cameraserver את ההרשאות המתאימות. אנחנו לא מעודדים שכפול של מדיניות SELinux של שרת המדיה לשרת המצלמה (כי שרת המדיה ושרת המצלמה בדרך כלל דורשים משאבים שונים במערכת). ל-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

מצלמה עם HAL

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

3.5

ICameraDevice

ICameraDeviceSession

  • isReconfigurationNeeded:‏ שיטה שמציינת למסגרת המצלמה אם נדרשת הגדרה מחדש מלאה של הסטרימינג לערכים אפשריים חדשים של פרמטרים של סשנים. כך ניתן למנוע עיכובים מיותרים בהגדרות האישיות של המצלמה. שאילתת הגדרה מחדש של סשן
  • ממשקי API לניהול מאגר נתונים זמני עם 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 כוללת את העדכונים הבאים לממשק API2 ו-HAL של המצלמה.

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

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 של הספק צריכות להיות bindered. ב-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.

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 לא כוללת שינויים ביכולות החומרה הנדרשות או במודל התפעולי.
  • ממשקי בקשת הקלט ועומס הבקשות של הסטרימינג עברו עריכה: ה-Framework קורא ל-HAL עם הבקשה הבאה, ומאגרי ה-buffer של הסטרימינג כבר הוסרו מהתור. היא כוללת תמיכה ב-framework, והיא נחוצה להטמעה יעילה.
  • טריגרים הועברו לבקשות, רוב ההתראות הפכו לתוצאות.
  • כל קריאות החזרה (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.
  • תמיכה ב-android.hardware.Camera API.

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

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

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

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