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

בדף הזה מפורטים ההבדלים בין הגרסאות של 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
‫
חבילת מקרים לבדיקה של ספק הושקה לצד 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 המלאים עדיין צריכים לעבור את בדיקות ה-CTS של Camera API2. עם זאת, המכשיר פועל במצב 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 ב-API1 ב-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, צריך לעדכן אותו כך שישתמש ב-buffer handles כדי לזהות את המאגרים. לדוגמה, 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 מופרד בנוסף בתהליך שונה מ-cameraservice. ה-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

מודול המצלמה

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

2.5

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

2.4

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

‫Android 9

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

Camera API

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

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

פלטפורמות משותפות

התכונה הזו מאפשרת להשתמש רק במערכת אחת של מאגרי נתונים זמניים כדי להפעיל שני פלטים, כמו תצוגה מקדימה וקידוד וידאו, וכך להפחית את צריכת החשמל והזיכרון. כדי לתמוך בתכונה הזו, יצרני המכשירים צריכים לוודא שההטמעות של camera HAL ו-gralloc HAL יכולות ליצור מאגרי gralloc שמשמשים כמה צרכנים שונים (כמו hardware composer/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 כדי להפסיק את כל הבקשות או המאגרים בתהליך כמה שיותר מהר.

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]:

  • הומר משיטת הפשטת חומרה (HAL) של 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 מגרסה נמוכה יותר של HAL אם אותו מכשיר יכול לתמוך בכמה גרסאות של 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.