Merge "[VTS][AWARE]Setting callbacktype type to invalid value before invoking HIDL call" into qt-dev
diff --git a/audio/common/5.0/types.hal b/audio/common/5.0/types.hal
index e1279ee..33a8d62 100644
--- a/audio/common/5.0/types.hal
+++ b/audio/common/5.0/types.hal
@@ -331,7 +331,13 @@
/**
* A channel mask per se only defines the presence or absence of a channel, not
- * the order. See AUDIO_INTERLEAVE_* for the platform convention of order.
+ * the order.
+ *
+ * The channel order convention is that channels are interleaved in order from
+ * least significant channel mask bit to most significant channel mask bit,
+ * with unused bits skipped. For example for stereo, LEFT would be first,
+ * followed by RIGHT.
+ * Any exceptions to this convention are noted at the appropriate API.
*
* AudioChannelMask is an opaque type and its internal layout should not be
* assumed as it may change in the future. Instead, always use functions
diff --git a/current.txt b/current.txt
index e6ac705..5742d66 100644
--- a/current.txt
+++ b/current.txt
@@ -412,6 +412,7 @@
cd1757867a5e3a3faa362e785239515870d1a3c9ce756c6f0cf0f0fd8aac2547 android.hardware.radio@1.2::types
722b3595548ed7f1953b6e0143dc842d4d6e290ff009a134eb518d7c17a09347 android.hardware.radio@1.2::types # b/112486807
e78cf871f9fd1c072874e481e06e18e2681763cf2aa38c1fd777d53bab4eb69b android.hardware.sensors@1.0::types
+c28859a334c1f540dea0a7d4f0baef0551ba76a3232f53c936196543ee35bc4d android.hardware.sensors@1.0::types # b/133264933
3d01e29e8129186f7567c4f9c8bee7480a0768e587b1be9b28adb0a6cbec6bf2 android.hardware.tv.cec@1.0::types
1722ad002317b1fae1400de709e90f442d94ef22864e05f7a12af48c32e8edc8 android.hardware.usb@1.1::types
29c8da7a13c40d488f569c812441d5754ee45bdcdb8ce6564f524b708d10a057 android.hardware.vibrator@1.1::types
@@ -428,6 +429,7 @@
1b0500367ed2b32a841667ac3200edf3d3a164e8004aca445ff1b085ac831e93 android.hardware.audio@5.0::IStreamOutCallback
83e365479cc77d8717c155e1787ee668cd2ae4c557b467cf75b8e7cd53697ad8 android.hardware.audio@5.0::types
07d17800b298331e90d4ea5d8ba19a1ae3fe9c1dbff08d9f75fd3ade09496d67 android.hardware.audio.common@5.0::types
+b3c1ec989f317b9a36eac10f4e7b66aad2997302156899481553a67476e148dd android.hardware.audio.common@5.0::types # b/133453897
f269297866765b95ddd1825676cc8a772f0c7c9863286df596fc302781a42ff5 android.hardware.audio.effect@5.0::IAcousticEchoCancelerEffect
fa187b602d8939644ef708ed7627f2e3deac97899a4bda1de07f2ff126abe243 android.hardware.audio.effect@5.0::IAutomaticGainControlEffect
e1bf864ccb8458c0da1dcc74a2e748b1dca8ac360df590591cf82d98292d7981 android.hardware.audio.effect@5.0::IBassBoostEffect
diff --git a/sensors/1.0/types.hal b/sensors/1.0/types.hal
index e91820c..cbbe92f 100644
--- a/sensors/1.0/types.hal
+++ b/sensors/1.0/types.hal
@@ -1008,10 +1008,40 @@
AINFO_VEC3_CALIBRATION,
/**
- * Location and orientation of sensor element in the device frame: origin is
- * the geometric center of the mobile device screen surface; the axis
- * definition corresponds to Android sensor definitions.
- * float[12]: 3x4 matrix in row major order
+ * Provides the orientation and location of the sensor element in terms of
+ * the Android coordinate system. This data is given as a 3x4 matrix
+ * consisting of a 3x3 rotation matrix (R) concatenated with a 3x1 location
+ * vector (t). The rotation matrix provides the orientation of the Android
+ * device coordinate frame relative to the local coordinate frame of the
+ * sensor. Note that assuming the axes conventions of the sensor are the
+ * same as Android, this is the inverse of the matrix applied to raw
+ * samples read from the sensor to convert them into the Android
+ * representation. The location vector represents the translation from the
+ * origin of the Android sensor coordinate system to the geometric center
+ * of the sensor, specified in millimeters (mm).
+ *
+ * float[12]: 3x4 matrix in row major order [R; t]
+ *
+ * Example:
+ * This raw buffer: {0, 1, 0, 0, -1, 0, 0, 10, 0, 0, 1, -2.5}
+ * Corresponds to this 3x4 matrix:
+ * 0 1 0 0
+ * -1 0 0 10
+ * 0 0 1 -2.5
+ * The sensor is oriented such that:
+ * - the device X axis corresponds to the sensor's local -Y axis
+ * - the device Y axis corresponds to the sensor's local X axis
+ * - the device Z axis and sensor's local Z axis are equivalent
+ * In other words, if viewing the origin of the Android coordinate
+ * system from the positive Z direction, the device coordinate frame is
+ * to be rotated 90 degrees counter-clockwise about the Z axis to align
+ * with the sensor's local coordinate frame. Equivalently, a vector in
+ * the Android coordinate frame may be multiplied with R to rotate it
+ * 90 degrees clockwise (270 degrees counter-clockwise), yielding its
+ * representation in the sensor's coordinate frame.
+ * Relative to the origin of the Android coordinate system, the physical
+ * center of the sensor is located 10mm in the positive Y direction, and
+ * 2.5mm in the negative Z direction.
*/
AINFO_SENSOR_PLACEMENT,