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

בדף הזה מפורטים ההבדלים בין הגרסאות של Camera 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
‫
Vendor test suite הושק לצד Treble.

ממשקי API של מצלמות

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

‫Camera API1

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

  • ממשקי Camera API1 לאפליקציות. אפליקציות מצלמה שמבוססות על Camera API1 אמורות לפעול כמו במכשירים שפועלות בהם גרסאות Android קודמות.
  • גרסאות של Camera HAL. כולל תמיכה ב-Camera HAL1.0.

Camera API2

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

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

  • LEGACY: המכשירים האלה חושפים יכולות לאפליקציות באמצעות ממשקי Camera API2, שהן בערך אותן יכולות שנחשפות לאפליקציות באמצעות ממשקי 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 המלאים עדיין צריכים לעבור את בדיקות Camera API2 CTS. עם זאת, המכשיר פועל במצב Camera API2 LEGACY (שבו הקריאות ל-Camera API2 ממופות באופן מושגי לקריאות ל-Camera API1), כך שכל בדיקות ה-CTS של Camera API2 שקשורות לתכונות או ליכולות שמעבר ל-Camera API1 מדולגות באופן אוטומטי.

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

הדרישות לשימוש ב-VTS

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

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

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

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

יכול להיות שהקלטת וידאו ב-API1 תניח שהמצלמה ומקודד הווידאו נמצאים באותו תהליך. כשמשתמשים ב-API1 ב:

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

    מצלמה ומדיה ב-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 camera and media stack in API1 on HAL1

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

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

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

    מצלמה ומדיה ב-Android 7.0 ב-API2 ב-HAL3

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

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

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

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

אימות

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

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

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

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

‫Android 10

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

Camera API

Camera HAL

גרסאות ה-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: קריאה חוזרת סינכרונית ששכבת HAL של המצלמה קוראת כדי לבקש מהשרת של המצלמה מאגרי נתונים. מידע נוסף זמין במאמר בנושא requestStreamBuffers.
  • ‫returnStreamBuffers: קריאה חוזרת סינכרונית של 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

Camera module

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

2.5

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

2.4

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

‫Android 9

בגרסה Android 9 הושקו העדכונים הבאים בממשק camera API2 ובממשק HAL.

Camera API

  • הגרסה כוללת את multi-camera 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

עדכונים לגבי 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, הטמעות של Camera HAL של ספקים חייבות להיות binderized. ‫Android 8.0 כוללת גם את השיפורים העיקריים הבאים בשירות המצלמה:

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

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

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

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

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

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

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

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

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

השם של ה-method הוא android.hardware.camera2.CameraDevice#createCustomCaptureSession. כדאי לצפות בסרטונים הבאים: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

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

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

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

3.4

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

  • מוסיפים ANDROID_SENSOR_OPAQUE_RAW_SIZE מטא-נתונים סטטיים כחובה אם יש תמיכה בפורמט RAW_OPAQUE.
  • אם נתמך פורמט RAW כלשהו, צריך להוסיף ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE static metadata כמאפיין חובה.
  • החלפת השדה 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 שמסופקים על ידי framework ל-HAL ב-process_capture_request עשויים להיות חדשים בכל שלב.
  • הוספת תמיכה בתוצאות חלקיות. יכול להיות שהפונקציה process_capture_result תיקרא כמה פעמים עם קבוצת משנה של התוצאות הזמינות לפני שהתוצאה המלאה תהיה זמינה.
  • הוספת תבנית ידנית אל camera3_request_template. אפליקציות יכולות להשתמש בתבנית הזו כדי לשלוט בהגדרות הצילום ישירות.
  • לשנות את המפרטים של זרם הקלט ושל הזרם הדו-כיווני.
  • שינוי נתיב החזרה של מאגר הקלט. המאגר מוחזר ב-process_capture_result במקום ב-process_capture_request.

‫3.1

שינוי קל ב-HAL עם יכולות מורחבות:

  • ‫configure_streams מעביר את דגלי השימוש של הצרכנים ל-HAL.
  • flush call to drop all in-flight requests/buffers as fast as possible.

3.0

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

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

2.0

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

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

1.0

‫HAL (שכבת הפשטה לחומרה) של מצלמת Android הראשונית (Android 4.0) [camera.h]:

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

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

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

2.4

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

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

2.3

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

2.2

בגרסה הזו של מודול המצלמה נוספה תמיכה בתגי ספקים מהמודול, ובוטל השימוש ב-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 יכול להיות נתמך על ידי המודול הזה והמכשירים שלו.