Crash on Xiaomi Devices (Android 13) after 16KB page size update

[hyperhug]

Summary

After updating Dissonance and Opus libraries to the latest version with 16KB page size support, the application is experiencing crashes on Xiaomi devices running Android 13. The crash occurs in the native audio recording system (libaudioclient.so).

Crash Details

Crash Signature: SIGSEGV

Crash Location: android::AudioRecord::isLongTimeZeroData(void const*, int)

Status: In production

Stack Trace

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 11882 >>> com.example.app <

backtrace:
  #00  pc 0x000000000006e9f0  /system/lib64/libaudioclient.so (android::AudioRecord::isLongTimeZeroData(void const*, int)+128)
  #01  pc 0x000000000006de60  /system/lib64/libaudioclient.so (android::AudioRecord::processAudioBuffer()+1752)
  #02  pc 0x000000000006d490  /system/lib64/libaudioclient.so (android::AudioRecord::AudioRecordThread::threadLoop()+288)
  #03  pc 0x00000000000136d0  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+424)
  #04  pc 0x00000000000d1f60  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+144)
  #05  pc 0x00000000000f57c8  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208)
  #06  pc 0x000000000008f1bc  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68)

Impact Statistics

Overall Impact (Last 60 Days)

• Affected Users: 2,880 (2.88K)
• Total Events: 51,900 (51.9K)
• Last Occurred: 4 hours ago
• Primary Android Version: Android 13 (SDK 33)
• Issue Visibility: Foreground (100%)

Affected Devices

Device	Affected Users	% of Total	Events	% of Events	RAM (Total)	System on Chip
Redmi sweet	1,480	51.4%	23,329	45.0%	~7,934 MB	Qualcomm SM7150
Xiaomi nabu	296	10.3%	4,066	7.8%	6,144 MB (5,769 MB)	Qualcomm SM8150
POCO alioth	208	7.2%	3,957	7.6%	~7,886 MB	Qualcomm SMB250
POCO garnet	196	6.8%	8,306	16.0%	~10,827 MB	Qualcomm SM7435
Xiaomi pipa	116	4.0%	2,107	4.1%	~7,980 MB	Qualcomm SM8250
POCO vayu	115	4.0%	1,919	3.7%	~7,863 MB	Qualcomm SM8150
Redmi garnet	97	3.4%	3,089	6.0%	8,192 MB (7,656 MB)	Qualcomm SM7435
POCO redwood	62	2.2%	1,270	2.4%	~7,539 MB	Qualcomm SM7325
Xiaomi courbet	43	1.5%	609	1.2%	6,144 MB (5,840 MB)	Qualcomm SM7150
POCO marble	32	1.1%	1,022	2.0%	~11,702 MB	QTI SM7475
Other devices	235	8.1%	2,226	4.2%	Various	Various

Key Observations

1. Device Distribution: Predominantly affects Xiaomi/Redmi/POCO devices
2. Top Affected Device: Redmi sweet accounts for over half of all affected users (51.4%)
3. Chipset Pattern: Primarily impacts Qualcomm Snapdragon chipsets (SM7xxx and SM8xxx series)
4. Android Version: Exclusively affects Android 13 (SDK 33) devices
5. Memory Range: Devices with 4-12 GB RAM are affected

Why we think that it's Dissonance that's causing it

In the latest open testing release, we removed Dissonance completely and the crash has stopped occurring. This confirms that the issue was directly related to the Dissonance library's incompatibility with Xiaomi's Android 13 audio implementation when using 16KB page size.

Unfortunately, we cannot back test it to see if previous versions of Dissonance are still working because Google Play Store has stopped receiving libraries that are not 16KB aligned.

Screenshots from Google Play Developer Console

[martindevans]

As far as I can see from the docs support for 16KB page size was introduced in Android 15 (announcement: https://android-developers.googleblog.com/2024/08/adding-16-kb-page-size-to-android.html) and that version supported both 4KB and 16KB. Versions < Android 15 do not support the new 16KB aligned pages.

I haven't published an app on the play store, but from reading the docs it looks like the best solution here is to create an Android App Bundle (https://developer.android.com/guide/app-bundle) which contains both the new and old libAudioPluginDissonance.so. Then set minSdkVersion=35 for the newer version, that way older devices will receive the 4KB aligned file and newer ones will receive the 16KB aligned one.

If you need the older binaries, please email me your invoice number and I'll send you a copy of them.

[hyperhug]

Starting November 1st, 2025, all new apps and updates to existing apps submitted to Google Play and targeting Android 15+ devices must support 16 KB page sizes.

Unfortunately, there is no mechanism for shipping anything not 16KB to Google Play Store after November 1st, 2025. Also, there was never a support for shipping different .so files in an aab file for different SDK APIs.

[martindevans]

Maybe I'm misunderstanding the situation, but it looks like Google themselves have basically killed those phones - the device requires 4KB page size but you're not allowed to ship that.

I'm happy to help if there's something I can do, but at the moment I don't see any possible fixes or workarounds.

[hyperhug]

One clarification first: 16 KB-aligned native libraries do load and run on older Android versions. Older devices still use a 4 KB kernel page size, but the ELF format allows larger alignment values, and Android’s loader maps the binary normally. So there is no inherent incompatibility between 16 KB alignment and Android 13 or earlier.

What we’re seeing in our production data is different: after updating to the 16 KB-aligned versions of your libraries, we get reproducible (from the data in the Google Play Store, we, however, weren't able to reproduce this crash on our Xiaomis) crashes inside the Android 13 audio stack on Xiaomi devices (see the backtrace into android::AudioRecord and the device distribution in the report). When we remove Dissonance entirely, the crashes stop, and this is the only change. That strongly indicates the failure is triggered by the new 16 KB build of the plugin.

The devices themselves are not the issue, they successfully load the library. The problem appears during runtime when the audio recording buffer is used, suggesting that something about the updated native code or its alignment is exposing a vendor-specific bug or an unexpected assumption in your current 16 KB builds.

So the concern isn’t that these devices “require 4 KB pages.” They don’t. They can run 16 KB-aligned binaries. The issue is that your 16 KB version seems to be interacting badly with Xiaomi’s Android 13 audio implementation, and the crash disappears when Dissonance is removed.

If you need additional traces or build information to investigate, I will do my best to provide them.

[martindevans]

I understand, thanks for the detailed explanation. I was focusing too much of the page size thing.

The native audio plugin included with Dissonance does not interact directly with the Android audio system. The Unity microphone API provides input and a Unity AudioSource does the playback. The audio plugin does interact with Unity internally, but only in the playback system not in recording.

The original backtrace:

backtrace:
  #00  pc 0x000000000006e9f0  /system/lib64/libaudioclient.so (android::AudioRecord::isLongTimeZeroData(void const*, int)+128)
  #01  pc 0x000000000006de60  /system/lib64/libaudioclient.so (android::AudioRecord::processAudioBuffer()+1752)
  #02  pc 0x000000000006d490  /system/lib64/libaudioclient.so (android::AudioRecord::AudioRecordThread::threadLoop()+288)
  #03  pc 0x00000000000136d0  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+424)
  #04  pc 0x00000000000d1f60  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+144)
  #05  pc 0x00000000000f57c8  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208)
  #06  pc 0x000000000008f1bc  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68)

Is clearly coming from inside the recording system. That's completely under the control of Unity, through the Microphone API. I suspect when you disabled Dissonance the issue disappeared because you stopped using the mic.

Since you can't reproduce this locally it's going to be tricky to debug.

I would suggest simply trying to call Microphone.Start and playing back the audio locally (without Dissonance involvement), that would narrow down the issue. Is that something you can try?

Another option would be to modify BasicMicrophoneCapture.StartCapture (Assets/Plugins/Dissonance/Core/Audio/Capture/BasicMicrophoneCapture.cs, line 50). Add a check for devices that had this crash and return null. This will disable audio capture but not playback. If that works, then we know the issue is somewhere inside microphone recording (i.e. probably a Unity bug).

[IgorGalimski]

We also see the same crash on xioami devices on Unity 6000.3.9f1 and 6000.3.11f1. Currently it's 50-60% of all our crashes
@martindevans You dont have ideas how to fix it or get around it?

[martindevans]

Unfortunately we never made any progress on debugging this issue last time.

Are you able to reproduce this crash locally? That will help a lot with tracking it down!

[IgorGalimski]

@martindevans
We have 2 users who experienced this crash permanently. How we can collaborate together in order to narrow down this crash?

[martindevans]

There are really only 3 places that Dissonance itneracts with the audio pipeline:

• Recording (through Unity Microphone.Record)
• Playback (through a normal audio source)
• Playback (with a native audio plugin, used for e.g. AEC)

The logs above mention AudioRecordThread::threadLoop() leading me to think the issue in in the mic capture.

If those users are happy to help you test things, I think the first step would be to have a simple test scene that just calls Microphone.Start and plays back the audio locally. Something like this (adapted from Unity docs).

using UnityEngine;

public class Example : MonoBehaviour
{
    void Start()
    {
        var caps = Microphone.GetDevicCaps(null, out var min, out var max);

        AudioSource audioSource = GetComponent<AudioSource>();
        audioSource.clip = Microphone.Start(null, true, 10, min);
        audioSource.Play();
    }
}

If that works, we know the issue is not in the basic Microphone capture system.

[IgorGalimski]

There are really only 3 places that Dissonance itneracts with the audio pipeline:

• Recording (through Unity Microphone.Record)
• Playback (through a normal audio source)
• Playback (with a native audio plugin, used for e.g. AEC)

The logs above mention AudioRecordThread::threadLoop() leading me to think the issue in in the mic capture.

If those users are happy to help you test things, I think the first step would be to have a simple test scene that just calls Microphone.Start and plays back the audio locally. Something like this (adapted from Unity docs).

using UnityEngine;

public class Example : MonoBehaviour
{
void Start()
{
var caps = Microphone.GetDevicCaps(null, out var min, out var max);

    AudioSource audioSource = GetComponent<AudioSource>();
    audioSource.clip = Microphone.Start(null, true, 10, min);
    audioSource.Play();
}

}
If that works, we know the issue is not in the basic Microphone capture system.

@martindevans
thanks for the code. We tried this code and the game didn't crash

[martindevans]

Ok that's good, at least we know the basic Unity mic API works! Could you try this:

using UnityEngine;

public class Example : MonoBehaviour, IMicrophoneSubscriber
{
    void Start()
    {
        var mic = AddComponent<Dissonance.Audio.Capture.BasicMicrophoneCapture>();
        mic.StartCapture(null);
    }

    void ReceiveMicrophoneData(ArraySegment<float> buffer, WaveFormat format)
    {
        Debug.Log($"Received: {format.SampleRate}");
    }

    void Reset()
    {
    }
}

This uses the Dissonance microphone capture behaviour, which is a little more complex. In particular Dissonance asks the hardware for a specific sample rate, wheras the previous test just used the minimum rate the hardware supports.

If possible, please capture logs from this test with Dissonance logging set to Debug (Window > Dissonance > Diagnostics). That will help a lot!

[IgorGalimski]

Ok that's good, at least we know the basic Unity mic API works! Could you try this:

using UnityEngine;

public class Example : MonoBehaviour, IMicrophoneSubscriber
{
    void Start()
    {
        var mic = AddComponent<Dissonance.Audio.Capture.BasicMicrophoneCapture>();
        mic.StartCapture(null);
    }

    void ReceiveMicrophoneData(ArraySegment<float> buffer, WaveFormat format)
    {
        Debug.Log($"Received: {format.SampleRate}");
    }

    void Reset()
    {
    }
}

This uses the Dissonance microphone capture behaviour, which is a little more complex. In particular Dissonance asks the hardware for a specific sample rate, wheras the previous test just used the minimum rate the hardware supports.

If possible, please capture logs from this test with Dissonance logging set to Debug (Window > Dissonance > Diagnostics). That will help a lot!

Our user tried this code and didn't received the crash. We cant collect logs, because we just send an apk to the user and he installs it and lunch
If there is no crash - what else can we do? Is it possible from our side to bypass using unity microphone and write a native wrapper for it instead of using unity?