在 Android 的 L 版本中，我們將停止支持某些傳感器 HAL 版本。唯一受支持的版本是SENSORS_DEVICE_API_VERSION_1_0和SENSORS_DEVICE_API_VERSION_1_3 。
在下一個版本中，我們也可能會放棄對 1_0 的支持。
1_0 沒有批處理的概念。如果可能，所有使用 1_0 的設備都應該升級到 1_3。
1_1 和 1_2 的批處理概念定義不佳，不再受支持
當前使用 1_1 或 1_2 的所有設備都必須升級到 1_3。
在 1_3 中，我們簡化了批處理的概念，並引入了喚醒傳感器。
要升級到 1_3，請遵循下面列出的更改。
實現批處理功能
即使您不實現批處理（您的硬件沒有 FIFO），您也必須實現batch功能。 batch用於設置給定傳感器的採樣週期和最大報告延遲。它取代了setDelay 。 setDelay將不再被調用。
如果您不實現batch ，您可以通過簡單地使用提供的sampling_period_ns參數調用現有的setDelay函數來實現批處理。
實現刷新功能
即使不實現批處理，也必須實現flush功能。
如果不實現批處理， flush必須生成一個META_DATA_FLUSH_COMPLETE事件並返回 0（成功）。
更改您的 sensors_poll_device_t.common.version
your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3
將新字段添加到傳感器的定義中
在定義每個傳感器時，除了通常的sensor_t字段：
.name = "My magnetic field Sensor", .vendor = "My company", .version = 1, .handle = mag_handle, .type = SENSOR_TYPE_MAGNETIC_FIELD, .maxRange = 200.0f, .resolution = CONVERT_M, .power = 5.0f, .minDelay = 16667,
您還必須設置新字段，定義在 1_0 和 1_3 之間：
.fifoReservedEventCount = 0, .fifoMaxEventCount = 0, .stringType = 0, .requiredPermission = 0, .maxDelay = 200000 .flags = SENSOR_FLAG_CONTINUOUS_MODE,
fifoReservedEventCount ：如果不實現批處理，則將此設置為 0。
fifoMaxEventCount ：如果不實現批處理，則將此設置為 0
stringType ：對於所有官方 android 傳感器（那些在 sensors.h 中定義的傳感器）設置為 0，因為該值將被框架覆蓋。對於非官方的傳感器，請參閱sensor_t了解如何設置它的詳細信息。
requiredPermission ：這是應用程序訪問傳感器所需的權限。您通常可以為所有傳感器將其設置為 0，但HEART_RATE類型的傳感器必須將其設置為SENSOR_PERMISSION_BODY_SENSORS.
maxDelay ：此值很重要，您需要根據傳感器及其驅動程序的能力進行設置。
該值僅針對連續和變化傳感器定義。它是與該傳感器支持的最低頻率相對應的兩個傳感器事件之間的延遲。當通過batch功能請求較低頻率時，將改為以該頻率生成事件。框架或應用程序可以使用它來估計批處理 FIFO 何時可能已滿。如果此值設置不正確，CTS 將失敗。對於一次性和特殊報告模式傳感器，將maxDelay設置為 0。
對於連續傳感器，將其設置為允許的最大採樣週期（以微秒為單位）。
以下適用於period_ns 、 maxDelay和minDelay ：
-
period_ns以納秒為單位，而maxDelay/minDelay以微秒為單位。 -
maxDelay應始終適合 32 位有符號整數。僅出於二進制兼容性的原因，它在 64 位架構上被聲明為 64 位。
flags ：此字段定義傳感器的報告模式以及傳感器是否為喚醒傳感器。
如果您不實施批處理，並且只是從 1.0 遷移到 1.3，請將其設置為：
SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE用於一次性傳感器
SENSOR_FLAG_CONTINUOUS_MODE用於連續傳感器SENSOR_FLAG_ON_CHANGE_MODE用於變化傳感器，接近度除外SENSOR_FLAG_SPECIAL_REPORTING_MODE用於具有特殊報告模式的傳感器（傾斜檢測器除外）。
SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE用於接近傳感器和 Android 官方傾斜檢測傳感器。
從 1_1 或 1_2 升級時的注意事項
batch功能現在幾乎總是成功，即使對於不支持批處理的傳感器，也與超時參數的值無關。batch函數可能失敗的唯一情況是內部錯誤，或sensor_handle,錯誤，或負sampling_period_ns_週期_ns 或負max_report_latency_ns。- 傳感器是否支持批處理是由它的
fifoMaxEventCount是否大於 0 來定義的。（在以前的版本中，它是基於batch()的返回值。） - 支持批處理的傳感器始終處於我們之前版本中所說的“批處理模式”：即使
max_report_latency_ns參數為 0，傳感器仍必須進行批處理，這意味著當 SoC 進入掛起模式時，事件必須存儲在 FIFO 中. - 不再使用
batch函數的flags參數。DRY_RUN和WAKE_UPON_FIFO_FULL都已棄用，並且永遠不會傳遞給batch函數。 - 批處理超時參數現在稱為
max_report_latency參數。