Android CTS Verifier Sensor Test Cases (1)

背景介绍：
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 = -1;
    if (s_fd == -1) {
        int fd = open("/dev/alarm", O_RDONLY);
        if (android_atomic_cmpxchg(-1, fd, &s_fd)) {
            close(fd);
        }
    }
    struct timespec ts;
    int result = 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);
    }
#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 链接；
-