背景介紹：
The Android Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the Compatibility Test Suite (CTS). While CTS checks those APIs and functions that can be automated, CTS Verifier provides tests for those APIs and functions that cannot be tested on a stationary device without manual input, like audio quality, touchscreen, accelerometer, camera, etc. [1]
谷歌推行CTS測試的目的，是為了保證開發的應用都可以在所有的Android裝置上正常運作。測試項全部通過的裝置可以獲得Android官方認證。一般來說手機廠商會強制要求所有測試項必須符合Android标準，而具體實作方式則有配件供應商來提供。
最早Google從 Android 5.0 開始強制推行 CTS， 不幸的是早期的CTS 自身就存在不少bug, 感興趣的同學可以去 git 上瞻仰一下 Google 工程師送出的fix描述。而且即使 Google 的親兒子 Neux5/7/9 都有很多測試項不通過。同時一些大廠并不買賬，比如 Samsung，LG， HTC 等，更不用提國内廠商了。不過随着軟硬體技術的不斷進步，和Google的堅持，手機廠商越來越重視 Android CTS 的測試标準。測試項 All Pass 是配件供應商必須保證的前提。
本系列文章将介紹CTS Verifier Sensor部分的需求分析，失敗分析和解決方法（以Android CTS Verifier 6.0_r9 為例）。
1. Android CTS Verifer Sensor 測試項
Android CTS Veifier Sensor 部分一共有11個大項，每一個大測試項裡面又包含幾個到幾十個不等的小測試項。
其中Accelerometer Measurement Tests, Gyroscope Measurement Test, Magnetic Field Measurement Tests, Rotation Vector CV Crosscheck, Sensor Batching Tests 和 Significant Motion Tests測試均需要有測試人員手動配合做規定的測試動作。其餘的測試項将由CTS Verifier 自動執行測試。
2. 執行和結果
測試時點選測試項，按照提示内容操作。CTS Verifier 應用會要求關閉或打開一些系統設定如飛行模式，位置資訊，自動翻轉等，避免影響測試結果。
測試執行完或中止後，會現實測試結果提示資訊。全部通過時隻有一個”PASS”的按鈕，有失敗的測試項則出現兩個按鈕”PASS ANYWAY” 和 “FAIL”。”PASS ANYWAY”是 Google 給自己留的台階，因為某些大廠是不關心是否 All pass 所有測試項的。估計 Google 也不能(gan)說這些廠商的裝置不符合 Android 要求不于認證。[2]
所有測試項執行完後可以點選右上角的儲存按鈕，測試結果相關的資訊會以報告的形式儲存到本地。如果有測試項失敗，報告裡會找到一些有用的log 幫助定位原因。另外也可以借助 adb 指令，如 adb shell logcat 儲存裝置執行 CTS 測試項時所有的系統資訊 log，這對分析失敗原因很有幫助。
在正式開始前，先了解一下 Android CTS 測試中最重要的概念：timestamp (時間戳)。
Android CTS 幾乎所有的測試項都跟這個 timestamp 有關。Android CTS Verifier 中使用的最主要的時間源是：SystemClock.elapsedRealtimeNanos()
elapsedRealtime() and elapsedRealtimeNanos() return the time since the system was booted, and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick even when the CPU is in power saving modes, so is the recommend basis for general purpose interval timing.
它是基于System.nanoTime()
long nanoTime ()
Returns the current value of the running Java Virtual Machine's high-resolution time source, in nanoseconds.
不過SystemClock.elapsedRealTimeNanos() 是 Android CTS Verifier 應用獲得的時間的方法，即 Java 層調用的方法。在使用 C++ 語言的 HAL 層 和 C 語言的 Linux Kernel 層不能通路。通過分析Android 的源代碼我們找到了替代方法/函數。
Android HAL 層有一個 int64_t android :: elapsedRealtime()
#include <utils/SystemClock.h>
/*
* native public static long elapsedRealtime();
*/
int64_t elapsedRealtime()
{
#ifdef HAVE_ANDROID_OS
static int s_fd = -;
if (s_fd == -) {
int fd = open("/dev/alarm", O_RDONLY);
if (android_atomic_cmpxchg(-, fd, &s_fd)) {
close(fd);
}
}
struct timespec ts;
int result = ioctl(s_fd,
ANDROID_ALARM_GET_TIME(ANDROID_ALARM_ELAPSED_REALTIME), &ts);
if (result == ) {
int64_t when = seconds_to_nanoseconds(ts.tv_sec) + ts.tv_nsec;
return (int64_t) nanoseconds_to_milliseconds(when);
} else {
// XXX: there was an error, probably because the driver didn't
// exist ... this should return
// a real error, like an exception!
int64_t when = systemTime(SYSTEM_TIME_MONOTONIC);
return (int64_t) nanoseconds_to_milliseconds(when);
}
#else
int64_t when = systemTime(SYSTEM_TIME_MONOTONIC);
return (int64_t) nanoseconds_to_milliseconds(when);
#endif
}
相應的在 Linux Kernel裡找到對應的函數：ktime_t alarm_get_elapsed_realtime(void)
#include <linux/android_alarm.h>
ktime_t alarm_get_elapsed_realtime(void)
{
ktime_t now;
unsigned long flags;
struct alarm_queue *base = &alarms[ANDROID_ALARM_ELAPSED_REALTIME];
spin_lock_irqsave(&alarm_slock, flags);
now = base->stopped ? base->stopped_time : ktime_get_real();
now = ktime_sub(now, base->delta);
spin_unlock_irqrestore(&alarm_slock, flags);
return now;
}
實際應用中，采用在 HAL 層調用android::elpasedRealtime(), 還是在 Linux Kernel 裡調用 alarm_get_elapsed_realtime()，取決于廠商自己的實作架構。
一般來說有一下幾種類型: （recommended, but not necessary. if you have a better idear, please do share! :)）
- MTK platform， 每一個Virtural Sensor data 由相應的 Linux Driver 通過上報 Input Event 的方式到 HAL 層。HAL 隻負責收集資料然後通過回調傳回給上層(Sensor Framework)。是以這種方式比較适合在 Linux Kernel 裡調用alarm_get_elpased_realtime();
- Qualcomm ADSP (or non-ADSP) Platform, Algorithm library 運作在 HAL 層，資料采集和Fusion處理都在 HAL 層。這種方式就比較适合采用 android::elapsedRealTime();
- Sensor Hub / MCU solution, non OS (non Linux kernel), 如果是連接配接到Android 裝置上，則最好采用 android::elapsedRealTime()的方式做處理；
[1] Android CTS Verifier 官方網址: https://source.android.com/compatibility/cts/verifier.html
[2] PASS ANYWAY原則（Don’t ask me where’s it from）：
- 廠商清楚失敗的原因；
- 如果廠商認為是軟體bug，則必須準備好一個patch to fix(不是立即提供);
- 如果廠商認為由 Android 自身已知的issue導緻，則提供該issue的 AOSP 連結；
-