Intercom (amateur radio) is not able to properly initiate
ADeadTrousers opened this issue · 37 comments
According to logcat the app tries to connect to a port on the device.
ExtModuleManager: createCmdSocketListenThread IOException e:java.net.ConnectException: failed to connect to /127.0.0.1 (port 9980) from /:: (port 40610): connect failed: ECONNREFUSED (Connection refused)
We need to find out what particular service is running on this port in the stock ROM.
I need someone willing to run the following in stock ROM
cat /proc/net/tcpThen look for the service on port 9980 and run the next one too
cat /data/system/packages.list | grep '<The UID of the process>'I saw one entry on 26FC (9980), with a UID of 0:
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:26FC 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 18743 1 0000000000000000 100 0 0 10 0
When I tried to run the next cat on packages.list, I got "Permission Denied". I assume this means I need root to access, but I don't know how to root without TWRP for this phone. If you've got any ideas, let me know
There is a way of integrating Magisk into the boot.img of the downloadable stock rom update and then flashing the whole thing with the MTK SPflash Tool. But that means you will loose all data on the phone so you also need to do a full backup and restore and depending on the apps you have on your phone this could take some time until everything is back the way it used to be before. (I did this once out o curiosity and wasn't aware of the data loss)
Let's get back to the task at hand:
UID = 0 means that it's running as a root process. So the inode is the next best thing we have.
Various sources on the internet (I'm no expert on this) suggest that one need to search with stat through /proc/*/fd/* to find the exact pid and program name. The command netstat -tp would do the same. BUT both of these require root access.
Another source suggests the command lsof -i and then use ps to identify the process but it seems that the option -i is not supported on Android.
So identifying the process/inode is a dead end for now.
Could you please try to run adb logcat > intercom.txt and then start Intercom. As soon the init is finished cancel (CTRL+C) the logcat and then check the new file intercom.txt. Maybe some valuable information is exposed there. Thanks in advance.
So, initializing Intercom hijacks all USB connectivity aside from charging, to the point where I have to reboot to get back into debugging or any other data-based connection. intercom.txt ends up being blank, even if I add -L for before the previous reboot. I thought about trying to run it as a shell command, but I think it would probably come up blank, or otherwise I would be unable to stop the command after I lose debugging anyway. It doesn't seem like any logcat parameters can account for this but I could be wrong.
Sh..
Alternatively you could try to run logcat with a local terminal app.
Didn't even realize I could. Here's what I came up with
--------- beginning of main
10-18 17:14:54.750 9099 9099 E GraphicExt: GraphicExtModuleLoader::CreateGraphicExtInstance false
10-18 17:15:30.342 10692 10692 W bash : type=1400 audit(0.0:332): avc: granted { execute } for name="logcat" dev="sdc41" ino=6801265 scontext=u:r:untrusted_app_27:s0:c3,c257,c512,c768 tcontext=u:object_r:app_data_file:s0:c3,c257,c512,c768 tclass=file
10-18 17:15:30.362 10692 10692 W bash : type=1400 audit(0.0:333): avc: granted { execute } for name="logcat" dev="sdc41" ino=6801265 scontext=u:r:untrusted_app_27:s0:c3,c257,c512,c768 tcontext=u:object_r:app_data_file:s0:c3,c257,c512,c768 tclass=file
10-18 17:15:30.362 10692 10692 W bash : type=1400 audit(0.0:334): avc: granted { execute_no_trans } for path="/data/data/com.termux/files/usr/bin/logcat" dev="sdc41" ino=6801265 scontext=u:r:untrusted_app_27:s0:c3,c257,c512,c768 tcontext=u:object_r:app_data_file:s0:c3,c257,c512,c768 tclass=file
10-18 17:15:30.362 10692 10692 W bash : type=1400 audit(0.0:335): avc: granted { execute } for name="dash" dev="sdc41" ino=6801187 scontext=u:r:untrusted_app_27:s0:c3,c257,c512,c768 tcontext=u:object_r:app_data_file:s0:c3,c257,c512,c768 tclass=file
10-18 17:15:30.362 10692 10692 W logcat : type=1400 audit(0.0:336): avc: granted { execute } for path="/data/data/com.termux/files/usr/bin/dash" dev="sdc41" ino=6801187 scontext=u:r:untrusted_app_27:s0:c3,c257,c512,c768 tcontext=u:object_r:app_data_file:s0:c3,c257,c512,c768 tclass=file
10-18 17:15:31.982 9099 9119 D Surface : Surface::disconnect(this=0x74180e1000,api=1)
10-18 17:15:32.007 9099 9099 V PhoneWindow: DecorView setVisiblity: visibility = 4, Parent = android.view.ViewRootImpl@c6229e1, this = DecorView@3949306[TermuxActivity]
10-18 17:15:48.479 9099 9099 V PhoneWindow: DecorView setVisiblity: visibility = 0, Parent = android.view.ViewRootImpl@c6229e1, this = DecorView@3949306[TermuxActivity]
10-18 17:15:48.492 9099 9099 E GraphicExt: GraphicExtModuleLoader::CreateGraphicExtInstance false
10-18 17:15:48.492 9099 9119 D Surface : Surface::connect(this=0x74180e1000,api=1)
10-18 17:15:48.494 9099 9119 D mali_winsys: EGLint new_window_surface(egl_winsys_display *, void *, EGLSurface, EGLConfig, egl_winsys_surface **, EGLBoolean) returns 0x3000
10-18 17:15:48.494 9099 9119 D Surface : Surface::setBufferCount(this=0x74180e1000,bufferCount=3)
10-18 17:15:48.494 9099 9119 D Surface : Surface::allocateBuffers(this=0x74180e1000)
That looks like just the startup of logcat itself. :(
I just tried it myself but even with su I only get a few lines and then it stops. Seems like logcat stops as soon as it gets no data anymore.
The next best thing I could think of is to use one of the many logcat reader apps.
Logcat Reader by Darshan Parajuli looks promising and should work without root.
I was afraid so but unsure. However, Logcat Reader seems to work pretty well. It looks like the PID is 14619 under UID 1000. I see the name com.agold.intercom, and I assume the other similar names are just functions of the same app. I've attached the full log and a version filtered for that PID. Both are pretty long.
Intercom.txt
IntercomFiltered.txt
I think we finally got it.
Just for your information: com.agold.intercom is the app itself.
Anyway, the interesting part in you log starts at "10-19 17:26:57.526 14619:14652".
It looks like some kind of "audio" device with a command and an audio channel is being accessed. (Very promising)
PID 628 (named ExtModule in the log) is on the listening end of the communication ("has a connect 8, port is 9980")
With the command ps -A either from the terminal app or adb shell you should be able to identify the missing service.
(Maybe you should do the logcat once more just in case the PID changed in the meantime)
P.S.:
I also see that you pressed the red key on the side at "10-19 17:27:02.536".
Logs are a great source of information ;)
Okay, new problem. The terminal app only shows two entries, bash and ps. Based on running the adb shell command, the service is only running with Intercom active. Even if I initialize it, then exit Intercom and immediately plug it into my computer and run the shell command (for some reason that works today), nothing shows up on the most recent Intercom PID, even though I do get a separate PID listed as com.agold.intercom. Unsurprisingly, I think the "Exit" button to stop Intercom is stopping the service instantly. I went into the developer options while it was running and looked at the service list, where it was called IComService, but that's not anything we didn't already have from the log.
I actually I doubt I pressed the red key unless by accident, since I don't currently have it set to PTT. I may have pushed the PTT button on-screen though. I did it during at least one attempt, I just don't remember if it was the logged one. I did just hear my first chatter today though, while trying to run ps in the terminal app. Never had a chance to test it out before.
Okay, new problem. The terminal app only shows two entries,
bashandps. Based on running theadb shellcommand, the service is only running with Intercom active. Even if I initialize it, then exit Intercom and immediately plug it into my computer and run the shell command (for some reason that works today), nothing shows up on the most recent Intercom PID, even though I do get a separate PID listed ascom.agold.intercom. Unsurprisingly, I think the "Exit" button to stop Intercom is stopping the service instantly. I went into the developer options while it was running and looked at the service list, where it was calledIComService, but that's not anything we didn't already have from the log.
Checking your previous log (the longer one) once more at 10-19 17:26:57.277 you can see that com.agold.intercom is started by forking a child process with the PID 14619. The listening process on port 9980 with the ID 628 first comes up at 10-19 17:26:57.527. Prior to that there is no forking or any other mentioning of this PID. Therefore it must have been already running before the log started.
What is the result of adb shell and ps -A?
Here are the results of adb shell ps -A both before and after running Intercom, and the logcat from the initialization process in between.
PS.txt
Intercom2.txt
Intercom2.txt: [10-21 11:26:54.994 628:638 I/ExtModule] has a connect 6, port is 9980
Same PID so it must be continously running since the previous logcat.
PS.txt: root 628 1 188136 2208 0 0 S extmodule
Shit... extmodule... really?
It looks like I need to do some more research.
Yeah that's why I assumed I hadn't gotten anything useful, since we'd already talked about extmodule on 628 and that's all I found on yesterday's PS.
In a last attempt I searched the stock rom files once more.
And I really found our ominous extmodule. It's an executable inside /system/bin. Because the permissions of the folder prevented a direct access nautilus wasn't able to find it. So I thought extmodule was some kind of generic name for user-mode kernel modules 👎
Anyway, I won't get anything done the next couple of days but when I get back to my flat I'll try a new build with the extmodule integrated.
Anything useful in there? vv
cat extmodule.txt
It's clearly logging DMR activity even though I didn't have it running.
edit: what timing lol. Running that also caused an audio glitch on my desktop for 10-20sec
Thanks for you help. Just a little update to let you know what I'm currently struggling with:
I checked out all selinux settings for extmodule from the compiled cil-files of the stock rom and copied them in this rom.
But now the phone won't boot at all and I'm stuck at the bootloader. I had this behaviour before and the only thing I could do was to remove the selinux parts I previously added.
No problem. Let me know of anything else I can do.
I'm kinda curious how Unihertz's service dept would respond to an information request. I'd try it myself just for giggles, but I think that the more detailed and concise the request is, the more likely it goes right to an engineer and back again with something useful. Couldn't hurt to mention that this project would open the device up to the privacy-oriented market, too.
It's been a while...
I tried various approaches to get this fixed but now I'm at a dead end. First I tried to copy all of the selinux settings emanating from extmodule so that it has everything it needs. Then I also copied all binaries from that info but with no luck.
Next up I tried to fix every avc: deinied from boot to make sure a missing permission doesn't hold me back there.
But in the end all of this was in vain:
The phones "vendor" partition doesn't get overridden by this ROM. The phone still uses the stock vendor, which isn't actually so bad because supposedly this saved me a lot of work. So I only needed to copy everything in "system" and not from "vendor" and that meant half of the work I previously did was for nothing (or maybe not because I learned a great deal regarding selinux).
But the real frustrating part was finding out what the real problem with the extmodule was and for that I only would have had to read my logs more carefully: extmodule wasn't able to access the device /dev/ttyACM0.
Now here comes the funny part:
I always believed that linux needs all device drivers build into the kernel. Even user-mode-drivers need a tiny spec inside the kernel to properly work. So checking my phones /dev I could not find any trace of /dev/ttyACM0.
This either means I somehow installed the wrong kernel (maybe the one from Atom L) but I double and tripple checked it. Only thing left is, that Unihertz mixed up their Stock ROM files.
Or it could mean that this device is somehow "late" started either during boot or from extmodule but I couldn't find any evidence for that because I lack clues on how this could actually be achieved.
So, once more, I need someone to check their stock ROM if the device /dev/ttyACM0 is in fact present right after the reboot of the phone and a adb -d logacat > bootlog.txt from the phones boot sequence.
bootlog.txt
It would seem to me it isn't. I ran a few Linux device list commands in adb shell to see if I could find it, but nothing. It's possible I missed something though
Thanks.
Can you do me another favour and run a logcat on issue https://github.com/ADeadTrousers/android_device_Unihertz_Atom_XL/issues/2
Maybe some libraries are still missing...
The logcat from inside the phone may not show them because of missing(?) access rights.
Hey. I don't have the AtomXL, but I have an Armor 3WT and just finished getting the AtomXL version of Intercom working on that (with some lingering issues). Did you need some more assistance with this?
At the very least, please make sure to get the following files from /system/bin:
auto_update
dfu-util
extcmdtest
extmodule
get everything in /system/data/mfu/
And get /system/lib/libwebrtc*.so
and /system/lib64/libwebrtc*.so
We can figure out what else is necessary after that.
thanks @clewisit
I got everything except "/system/data/mfu/" (see https://github.com/ADeadTrousers/android_device_Unihertz_Atom_XL/blob/master/proprietary-files.txt)
Strange that I missed out this folder because in a feeble attempt I tried to copy eveythng that is absent in Lineage.
Currently intercom is stuck in a "init"-loop: After init is finished I get an error mentioning that it's not able to switch channels and starts all over. Because it also shuts down adb/usb I'm stuck to use logcat-reader-apps which are pain in the a.. to find anything usefull.
As soon as I get back home I'll test your suggestion.
It helps to give you the right path. /system/data/mcu/*.
Those are the actual firmware files for the radio. I believe I had a similar issue when I experimented with using the Atom XL MCU files on my phone, so I think we are on the right track.
So, after some throwbacks I was able to get the latest update (2020-11-04) for the Atom XL up and running.
Using the stock ROM intercom was working fine. It even prompted an firmware update, because there was a newer file in /system/data/mcu/.
Switching back to Lineage and I still get the "init"-loop with the error message that switching channels failed.
With 24ad9ff I recreated the last bit from stock ROM (symlinks to libraries) but it still doesn't work.
What does the logcat say?
logcat_01-18-2021_19-18-02.txt
Interesting points are at:
01-18 19:17:02.522 - an exception occurred during an event handling
01-18 19:17:03.316 - an exception occurred during an event handling
01-18 19:17:07.234 - an exception occurred during an event handling <-- looks like the final timeout from "switching channels failed"
Looking for the specific actions "agui.intercom.intent.action.*" I found a mentioning in "/system/etc/sysconfig/a-framework-sysconfig.xml" but I already copied that one. Nothing else showed up in the stock ROM files.
01-18 19:17:04.209 - the version of the firmware could be read so no problem with the "simple" communication between the processes.
01-18 19:17:04.203 - a permission denied on an audio device.
There are plenty of that kind but it's a totally different PID and as far as I can see it it's because the USB is not accessible while Intercom/ExtModule are running (AudioALSAPlaybackHandlerUsb & modules.usbaudio.audio_hal).
@clewisit Do you see anything else out of the ordinary? Any ideas on how to fix (if possible) those "missing" events?
Make sure the Intercom app is signed with your platform keys. That's how I finally got past the audio permission denials.
I'm not sure what would cause switching channels to fail at this point. I would try going back to the stock ROM, make sure intercom works and that it has updated the MCU/DMR firmware for the radio. Then, make sure your /system/data folder in lineage matches the stock ROM.
@ clewisit
Make sure the Intercom app is signed with your platform keys. That's how I finally got past the audio permission denials.
Do you mean by doing this https://wiki.lineageos.org/signing_builds.html
or do you mean something else?
I'm already signing my build but as far as I can remember from the build logs intercom.apk (and various others) won't get signed because the already are.
I'm not sure what would cause switching channels to fail at this point. I would try going back to the stock ROM, make sure intercom works and that it has updated the MCU/DMR firmware for the radio. Then, make sure your /system/data folder in lineage matches the stock ROM.
I already did that.
Since the app is a system app and expects to be run as the system user, the app needs to have the same signature as your build. Follow the instructions here:
https://stackoverflow.com/questions/37586255/signing-my-android-application-as-system-app
I tried several approaches to get the file signed AND correctly packed into the ROM files.
Sometimes the build process "reversed" my changes and other times the app was "missing" in the launcher.
Nevertheless after various throwbacks I was able to get it all work BUT nothing changed.
The app still can't "switch channels"
Sorry, not sure how much more help I can be, since I don't have this phone. Honestly, I'm really surprised that I had gotten this working on my phone. If I can get a hold of one of these, I will give it another shot.
You won't believe it, but I found the missing pieces! 44606b2
As a last resort I told myself: Just screw it and compare the files from Atom L and XL. Essentially they should be the same except of Intercom/Extmodule. And that's how I found theese pesky little build.props in the product partition:
ro.agold.intercom.ptt=yes
ro.agold.extmodule.dmr09=yes
ro.agold.extmodule.32k=yes
ro.agold.extmodule.hal=yes
ro.agui.single.mic=yes
ro.agui.smartkey_ptt=com.agold.intercom
Thanks for your help @clewisit even if it was just to goad me to finally do something about it. 😉
Awesome, great job!