Equivalent replacement for deprecated Sensor.TYPE_ORIENTATION
<p>I am looking for a solution that replaces the deprecated Android sensor <code>Sensor.TYPE_ORIENTATION</code>.</p>

<p>The most reported solution is to combine <code>Sensor.TYPE_ACCELEROMETER</code> and <code>Sensor.TYPE_MAGNETIC_FIELD</code>, then calculate a rotation matrix by using <a href="https://developer.android.com/reference/android/hardware/SensorManager.html#getRotationMatrix(float[],%20float[],%20float[],%20float[])" rel="noreferrer"><code>SensorManager#getRotationMatrix</code></a> and obtain the Euler angles by using <a href="https://developer.android.com/reference/android/hardware/SensorManager.html#getOrientation(float[],%20float[])" rel="noreferrer"><code>SensorManager#getOrientation</code></a>.
Another reported solution is to use <code>Sensor.TYPE_ROTATION_VECTOR</code>, which also ends up with a rotation matrix and the Euler angles by using <code>SensorManager#getOrientation</code></p>

<p>Unfortunately those behave totally different to <code>TYPE_ORIENTATION</code> when rotating the mobile device. Try both types while your phone is laying on the desk and then turning it up (pitch) to 90° (the screen is now directly facing to you). The calculated Euler angles of azimuth and roll get really wild (cause of something called the <a href="https://en.wikipedia.org/wiki/Gimbal_lock" rel="noreferrer">Gimbal lock</a> problem) while the degree values retrieved with <code>TYPE_ORIENTATION</code> are pretty stable (not accurate but quite ok). Every value (yaw, pitch and roll) of <code>TYPE_ORIENTATION</code> seems to be some kind of "projected" degree without having the Gimbal Lock problem.</p>

<p>What would be a way to get similar degrees (for yaw, roll and pitch) without using the depreciated <code>TYPE_ORIENTATION</code> sensor (maybe from the rotation matrix)? How does the <code>TYPE_ORIENTATION</code> algorithm does it internally?</p>