背景介紹：
TheAndroidCompatibility 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測試的目的，是為了保證開發(fā)的應用都可以在所有的Android設備上正常運行。測試項全部通過的設備可以獲得Android官方認證。一般來說手機廠商會強制要求所有測試項必須符合Android標準，而具體實現(xiàn)方式則有配件供應商來提供。
最早Google從 Android 5.0 開始強制推行 CTS， 不幸的是早期的CTS 自身就存在不少bug, 感興趣的同學可以去 git 上瞻仰一下 Google 工程師提交的fix描述。而且即使 Google 的親兒子 Neux5/7/9 都有很多測試項不通過。同時一些大廠并不買賬，比如 Samsung，LG， HTC 等，更不用提國內(nèi)廠商了。不過隨著軟硬件技術(shù)的不斷進步，和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測試均需要有測試人員手動配合做規(guī)定的測試動作。其余的測試項將由CTS Verifier 自動執(zhí)行測試。
2. 執(zhí)行和結(jié)果
測試時點擊測試項，按照提示內(nèi)容操作。CTS Verifier 應用會要求關閉或打開一些系統(tǒng)設置如飛行模式，位置信息，自動翻轉(zhuǎn)等，避免影響測試結(jié)果。
測試執(zhí)行完或中止后，會現(xiàn)實測試結(jié)果提示信息。全部通過時只有一個”PASS”的按鈕，有失敗的測試項則出現(xiàn)兩個按鈕”PASS ANYWAY” 和 “FAIL”?！盤ASS ANYWAY”是 Google 給自己留的臺階，因為某些大廠是不關心是否 All pass 所有測試項的。估計 Google 也不能(gan)說這些廠商的設備不符合 Android 要求不于認證。[2]
所有測試項執(zhí)行完后可以點擊右上角的保存按鈕，測試結(jié)果相關的信息會以報告的形式保存到本地。如果有測試項失敗，報告里會找到一些有用的log 幫助定位原因。另外也可以借助 adb 命令，如 adb shell logcat 保存設備執(zhí)行 CTS 測試項時所有的系統(tǒng)信息 log，這對分析失敗原因很有幫助。
在正式開始前，先了解一下 Android CTS 測試中最重要的概念：timestamp(時間戳)。
Android CTS 幾乎所有的測試項都跟這個 timestamp 有關。Android CTS Verifier 中使用的最主要的時間源是：SystemClock.elapsedRealtimeNanos()
elapsedRealtime()andelapsedRealtimeNanos()returnthetimesincethesystem was booted,andinclude deep sleep. This clockisguaranteedtobe monotonic,andcontinuestotick even whentheCPUisinpower saving modes, soistherecommend basisforgeneral purpose interval timing.它是基于System.nanoTime()long nanoTime ()Returnsthecurrent valueoftherunningJava Virtual Machine's high-resolutiontimesource,innanoseconds.
SystemClock.elapsedRealTimeNanos() 是 Android CTS Verifier
應用獲得的時間的方法，即 Java 層調(diào)用的方法。在使用 C++ 語言的 HAL 層 和 C 語言的 Linux Kernel
層不能訪問。通過分析Android 的源代碼我們找到了替代方法/函數(shù)。
Android HAL 層有一個int64_t android :: elapsedRealtime()
#include /*
* native public static long elapsedRealtime();
*/int64_t elapsedRealtime(){#ifdef HAVE_ANDROID_OSstaticints_fd = -1;if(s_fd == -1) {intfd = open("/dev/alarm", O_RDONLY);if(android_atomic_cmpxchg(-1, fd, &s_fd)) {? ? ? ? ? ? close(fd);? ? ? ? }? ? }structtimespec ts;intresult = ioctl(s_fd,? ? ? ? ? ? ANDROID_ALARM_GET_TIME(ANDROID_ALARM_ELAPSED_REALTIME), &ts);if(result ==0) {? ? ? ? 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);? ? }#elseint64_t when = systemTime(SYSTEM_TIME_MONOTONIC);return(int64_t) nanoseconds_to_milliseconds(when);#endif}
29
30
31
32
33
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
相應的在 Linux Kernel里找到對應的函數(shù)：ktime_t alarm_get_elapsed_realtime(void)
#include ktime_t alarm_get_elapsed_realtime(void){? ? ktime_t now;? ? unsignedlongflags;structalarm_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);returnnow;}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
1
2
3
4
5
6
7
8
9
10
11
12
13
14
實際應用中，采用在 HAL 層調(diào)用android::elpasedRealtime(), 還是在 Linux Kernel 里調(diào)用 alarm_get_elapsed_realtime()，取決于廠商自己的實現(xiàn)架構(gòu)。
一般來說有一下幾種類型: （recommended, but not necessary. if you have a better idear, please do share! :)）
MTK platform， 每一個Virtural Sensor data 由相應的 Linux Driver 通過上報 Input
Event 的方式到 HAL 層。HAL 只負責收集數(shù)據(jù)然后通過回調(diào)返回給上層(Sensor Framework)。所以這種方式比較適合在
Linux Kernel 里調(diào)用alarm_get_elpased_realtime();
Qualcomm ADSP (or non-ADSP) Platform, Algorithm library 運行在 HAL 層，數(shù)據(jù)采集和Fusion處理都在 HAL 層。這種方式就比較適合采用 android::elapsedRealTime();
Sensor Hub / MCU solution, non OS (non Linux kernel), 如果是連接到Android 設備上，則最好采用 android::elapsedRealTime()的方式做處理；
-----------------------------------------------------------------------------
[1] Android CTS Verifier 官方網(wǎng)址: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 鏈接；
