Following an exhaustive log trail, it is clear that we are correctly requesting a supported input sampling rate to AAudio on the device causing the issue. Analyzing the recorded file, we're clearly getting 33% of the samples that should be recorded over the time period requested to the Microphone API, which aligns exactly with the 16000/48000 ratio. A similar theory was tried with a 8000Hz recording, still aligning with the theory that the device is providing samples recorded at 48000Hz, but labeling the file as a recorded at 16000Hz.

Following the Android logs, we can observe the following entries when we're opening the stream in `OutputAAudio::recordStart` with the expected values, so far so good!
```
03-11 06:15:53.039 28554 28637 I AAudio : AAudioStreamBuilder_openStream() called ----------------------------------------
03-11 06:15:53.039 28554 28637 I AudioStreamBuilder: rate = 16000, channels = 1, channelMask = 0x80000001, format = 5, sharing = SH, dir = INPUT
```

These next log entries following the AAudio stream start call are very close, revealing the sequence of operations at a low level. Since I did only one recording during this log and nothing else, I am very confident that this reflects the chain of events of our recording session.
```
03-11 06:15:53.058 28554 28637 D AAudio : AAudioStream_requestStart(s#2) called --------------
...
03-11 06:15:53.062 1563 28722 V APM_AudioPolicyManager: getInputForAttr() source 6, sampling rate 16000, format 0x1, channel mask 0x10, session 2929, flags 0x10 attributes={ Content type: AUDIO_CONTENT_TYPE_MUSIC Usage: AUDIO_USAGE_UNKNOWN Source: AUDIO_SOURCE_VOICE_RECOGNITION Flags: 0x100 Tags: } requested device ID 23
...
03-11 06:15:53.069 1453 2413 D AHAL: AudioStream: Start: 4505: Enter
...
03-11 06:15:53.069 1489 17165 D AGM: graph_module: configure_hw_ep_media_config: 659 rate 48000 bw 16 ch 1, data_fmt 1 <---- !!!
```

We can see that we're requesting to start the stream we configured earlier, then the middlemen `APM_AudioPolicyManager` and `AHAL` finally forward it to the last layer: `AGM` (Qualcomm's Audio Graph Manager). At that level, the stream is created with a 48000Hz rate.

This is beyond our reach, and very specific to this device OEM integration. The issue was also present when using a bluetooth device supporting the same range of sampling rates, and similar investigations on a Google Pixel 6 not exhibiting this issue revealed that `AGM` was not used in the audio pipeline, rather a process called `audio_hw`. This is likely a bug in the integration of `AGM` by `AHAL` or `APM_AudioPolicyManager`.