Intercom (DMR) does not offer sound (neither from microphone/speaker nor from a headset)
Opened this issue · 8 comments
Since I was able to get Intercom app to work
ADeadTrousers/android_device_Unihertz_Atom_XL_EEA#1
there was no sound output.
I didn't noticed that because I had no second phone to test it.
So after I bought myself another phone for testing I didn't hear a thing.
Therefore I tried to get my hands on the mediatek sourcecode specifically the frameworks/av portion with the MTK_AUDIO additions. I was pointed to a specific site where I downloaded the latest version (in my opinion) and after quite some ordeal I was able to successfully build a modded LOS frameworks/av.
That didn't change a thing though. Intercom app is still treating me with silence. However during my testing I found out it does work with a headset.
If I'm not completely wrong this could only means two things:
A mediatek modification isn't really needed (otherwise the audio jack wouldn't work).
Something else is preventing the app from "initialising" a channel on the default audio devices.
I had some issues with getting the audio jack to work:
ADeadTrousers/android_device_Unihertz_Atom_LXL#4
So there seem to be an different approach on accessing the audio jack than all of the other audio devices. Policy?!?!
To be able to build the modded frameworks/av I had to remove the USE_CUSTOM_AUDIO_POLICY setting. I found out LOS points to a qcom (qualcom?) implementation which isn't compatible with the mediatek source code.
Therefore my guess is there is something odd policy wise but I can't find any differences between stock and LOS in the XML configuration files.
First clue:
[08-01 18:59:28.354 458:3418 E/alsa_device_proxy]
proxy_open() pcm_is_ready() failed: cannot open device '/dev/snd/pcmC1D0p': Permission denied
Checking while Intercom app is running confirms that there are in fact two new devices /dev/snd/pcmC1D0p and /dev/snd/pcmC1D0c. My guess is that they are created by extmodule or another part of agold/Intecom/mediatek.
[08-01 18:59:26.880 607:3364 D/ExtModule]
exec_cmd system chown root:root /dev/snd/pcmC1D0p start!
[08-01 18:59:26.896 607:3364 D/ExtModule]
exec_cmd system chown root:root /dev/snd/pcmC1D0p finish!
According to a quick search in the stock files alsa_device_proxy belongs to /vendor/lib[64]/libalsautils.so.
So it's also a vendor thing. And the process 458 it belongs to is /vendor/bin/hw/android.hardware.audio@5.0-service-mediatek and runs as user audioserver.
Checking the sepolicies I can't find any missing entries so I assume the problem lies on the file permissions itself. Process is running as audioserver while the device is belonging to root as forced by extmodule.
Next I'll probably need to check the permissions on stock rom.
I've tried to change the permission via ueventd.mt6771.rc but that didn't work.
Probably 'cause it gets applied only once at startup. So I need a way for that to get applied when a new device is "detected".
I would love to get this solved.
The permissions on the stock rom are root/root as well.
Is there any update on your investigation?
I believe Unihertz did something similar for Intercom to the audio framework as Mediatek did for FMRadio. My findings in the closed source code I was able to get my hands on suggest that Mediatek modified the api so they could use proprietary codecs like divx amongst others. In order to get FMRadio to work I tried to do the same modifications on the LOS sources but that prevented the LOS parts of the rom to output sound. So I reverted everything and focused on libfmjni.so which I later found an older Mediatek implementation (Android 9) I was able to get to work. It's basically a form of settings file in form of a library. Therefore it was an easy fix as I could use LOS built in FMRadio app and didn't need to modify everything to support the stock FMRadio app.
So what does this all have to do with Intercom?
I think Unihertz just did the same thing with Intercom. They seem to have utilized the changes Mediatek used to tap into the audio subsystem. Sadly there is no source code to back up my believe as Intercom is a third party app not reletad to Mediatek and there is also no open source implementation as a basis like there is for FMRadio. The permission problems I found earlier could be completly unrelated as the stock FMRadio didn't use the fm and audio devices directly but rather "connected" them inside the audio subsystem.
The only thing that give me a little bit of hope is the fact that the needed parts for Intercom to work (extmodule and others) are scattered around in the system and vendor partition. This isn't really allowed by selinux and if one does so reguardless there needs to be some kind of shim to connected these parts (or some holes punched into the security system like Meditek did with the audio subsystem). As I tried to replicated the selinux rules in system the same way (or even more lenient) as they are in vendor nothing changed at all. Even the same selinux error messages were thrown as if the rules weren't there at all. So my conclusion here is that vendor rules must be "stronger" than system rules.
So why do I have faint hopes?
Unihertz is currently doing their Android 11 release and I'm hoping they need to change the approach for the inclusion of Intercom/extmodule to a point where it is a little bit more compliant and useable for modders like my.
Since the switch to 18.1 neither microphone/speaker nor a headset offers any sound from Intercom app.
Hi @ADeadTrousers thank you so much for your work so far on this. I was wondering if there has been any updates? I recently aquired an AtomXL I'm willing to experiment with and help more if desired, however I would greatly appreciate a resources guide / walkthrough to get up to speed. I have some android experience but not a ton, but have good skills otherwise reversing.
Hi @chancecardona .
No big updates yet. All I did until now is making sure I copied everything related to the DMR correctly over to LOS. After that I was capturing and checking logs during the intercom app was running. But I couldn't find anything mayor that isn't working or at least anything that caught my attention. Figuring out that with 17.1 I was able to hear something with the headset connected was a lucky find. But since 18.1 it is dead silent. So I focused more on my other problems (recovery encryption, key assignment).
A user on xda informed me that he tinkered with the app itself and modified it for landscape mode and other gimmicks. He also found out that if you deactivate usb autorouting in the developer options you might be able to get it work but it didn't for me most of the time. Sometimes I had to do a restart and other times even that didn't help at all. And since 18.1 I haven't got any luck at all.
Now I'm pretty much chasing after everything related to audio I can find. Recently I got aware of a technique called "libshim" and I'm currently trying to get it to work so I can fix some long running problems with "cannot locate symbol" errors in the logs. Maybe this could help? There are some "codecs" (like divx) that were included with the stock rom that I couldn't copy onto LOS cause otherwise it won't boot due to said missing symbols. Maybe the app is using these codecs?