IssueTracker

Andreas, are you the correct person to investigate here?

I'm not. Ashutosh?

This is interesting. The rotation vector (or any sensor for that matter) should not perform differently from the Java API  at the native API.  Villus, I could not access the video on the bug you linked to. Can you please attach it to this bug ?

Sure, no problem - attaching the videos here.

Ashutosh, have you had a chance to take a look here?

On Pixel 2 `adb logcat` reports its using 200000us sampling period.
This is 5Hz (SENSOR_DELAY_NORMAL), instead of the desired/expected 50Hz (SENSOR_DELAY_GAME).

01-10 16:14:10.800  794  820 D CHRE    : @ 2685.808: +: id 10, otherClientPresent 1, mode 3
01-10 16:14:10.803  794  820 D CHRE    : @ 2685.811: [ImuCal] Dynamic sensor configuration: high-performance.
01-10 16:14:10.803  794  820 D CHRE    : @ 2685.811: sensorType 9 allowed 1: mergedMode 3, otherClientPresent 1
01-10 16:14:10.803  794  820 I VSC    : @ 2685.811: [VSC SLPI] VscSensor type 65545: Enabling with report period 0 and sampling period 200000000
01-10 16:14:10.803  794  820 I VSC    : @ 2685.811: {Fusion} configure fusion 9 200000us 0us.
01-10 16:14:10.804  794  820 I VSC    : @ 2685.811: [VSC] Request sensor 65537, sample_duration 14 ms, report_duration 0 ms
01-10 16:14:10.804  794  820 I VSC    : @ 2685.812: [VSC] Request sensor 65540, sample_duration 5 ms, report_duration 0 ms
01-10 16:14:10.805  794  820 D CHRE    : @ 2685.812: sensorType 11 allowed 1: mergedMode 3, otherClientPresent 1
01-10 16:14:10.807  794  820 D CHRE    : @ 2685.815: sensorType 13 allowed 0: mergedMode 3, otherClientPresent 0
01-10 16:14:10.810  794  820 I VSC    : @ 2685.818: [VSC SLPI] VscSensor type 65546: Enabling with report period 0 and sampling period 200000000
01-10 16:14:10.811  794  820 I VSC    : @ 2685.818: {Fusion} configure fusion 10 200000us 0us.
01-10 16:14:10.811  794  820 I VSC    : @ 2685.818: [VSC] Request sensor 65537, sample_duration 14 ms, report_duration 0 ms
01-10 16:14:10.811  794  820 I VSC    : @ 2685.819: [VSC] Request sensor 65540, sample_duration 5 ms, report_duration 0 ms
01-10 16:14:10.814  794  820 I VSC    : @ 2685.822: [VSC SLPI] VscSensor type 65547: Enabling with report period 0 and sampling period 200000000
01-10 16:14:10.815  794  820 I VSC    : @ 2685.822: {Fusion} configure fusion 11 200000us 0us.
01-10 16:14:10.815  794  820 I VSC    : @ 2685.823: [VSC] Request sensor 65537, sample_duration 14 ms, report_duration 0 ms
01-10 16:14:10.816  794  820 I VSC    : @ 2685.824: [VSC] Request sensor 65540, sample_duration 5 ms, report_duration 0 ms
01-10 16:14:10.816  794  820 I VSC    : @ 2685.824: [VSC] Request sensor 65538, sample_duration 14 ms, report_duration 0 ms

If I replace:
        ASensorEventQueue_enableSensor(sSensorEventQueue, sensor);
        ASensorEventQueue_setEventRate(sSensorEventQueue, sensor, 20000);
with:
        success = ASensorEventQueue_registerSensor(sSensorEventQueue, sensor, 20000, 0);

in `Sensors.cpp` in the above `AndroidGyroNDK.zip` project, then sensors appear to update at the expected rate.

Nice find, but it seems that this workaround requires the min sdk version to be at least 26, which would exclude a lot of phones.

Acknowledged.

The fact that `ASensorEventQueue_registerSensor(sSensorEventQueue, sensor, 20000, 0)` works demonstrates that the sensor can provide updates at 50Hz via native code.

So, now we need to get the older API variant to work:
        ASensorEventQueue_enableSensor(sSensorEventQueue, sensor);
        ASensorEventQueue_setEventRate(sSensorEventQueue, sensor, 20000);

As best I can tell, that second line is not actually doing anything.

Thanks Fred. Do you mind if we pick this up after the Android FC & Bootcamp (2/9) ?

Any update here?

Thank you for the thorough report with test app (and your patience).

In the Pixel 2 case, this is a bug in the sensor HAL implementation for certain sensor types, where the device is unable to properly change the sampling rate after the sensor has been enabled. Since the pre-26 NDK API only allows for enabling a sensor with a default rate, this bug means that the subsequent call to ASensorEventQueue_setEventRate has no effect, so unfortunately there is no workaround possible in pure native code. Although I can't dig into the inner workings of other devices, I suspect it's the same issue there as well (in the Pixel 2 case the issue lies in integration with code supplied by a prominent chipset vendor).

I can think of two ways to work around this issue:

1. Use ASensorEventQueue_registerSensor only on devices running API 26+. To avoid link-time issues when running on an older platform that doesn't provide this function, you can access it through dlsym() like so:

#include <dlfcn.h>

typedef int (NDK_registerSensorFunction)(
  ASensorEventQueue *queue, int32_t samplingPeriodUs, int64_t maxBatchReportLatency);

if (<API level >= 26>) {
  void *handle = dlopen("libandroid.so", RTLD_LAZY);
  if (handle != NULL) {
    NDK_registerSensorFunction *registerSensor = (NDK_registerSensorFunction *)
        dlsym(handle, "ASensorEventQueue_registerSensor");
    if (fptr != NULL) {
      registerSensor(queue, samplingPeriod, 0);
    }
    // probably want to call dlclose() too
  }
}

2. Like in the comments from your sample application, add a Java-level request for the sensor before initializing the NDK sensor request. There can only be 1 effective sampling rate for a sensor, which is always the fastest of all open requests. So assuming that no other app is already asking for the sensor, this will guarantee that the sensor is enabled with the rate you want, and the NDK client will get updates at the intended rate. This workaround should avoid the issue on pre-API 26 devices as well, but it imposes some overhead - you might be able to avoid leaving the Java client enabled with a flow like this (haven't tested this but should work in theory):
 
 a. Enable sensor from Java at expected rate (e.g. 200Hz)
 b. Enable sensor at NDK (with default rate)
 c. Set event rate in NDK to rate matching (a)
 d. Disable Java request


Hopefully you'll be able to use one of these two approaches to address the issue for devices in the wild. I'll also look into fixing the root cause in Pixel 2, plus notify the chipset vendor, and see about adding new CTS tests to ensure that future/upgrading devices are not afflicted by this problem.

This issue happens also to Samsung J7

Marking this as fixed now, because (1) this issue is addressed in Pixel 2 with Android P, (2) the vendor has been notified of the problem and has made the fix available for propagation, and (3) a future version of Android will enforce that this bug does not exist through CTS testing.