| rinigus | @b100dian and mal : I cracked SMS receiving issue!!! in essence, had to start communicating with ril via vendor.qti.hardware.radio.qcrilhook@1.0::IQtiOemHook and send "ATEL ready" message | 08:09 |
|---|---|---|
| rinigus | now SMS receiving works without volte - I am sure volte will not be major issue either after rewriting ims plugin for aidl | 08:09 |
| rinigus | will cleanup my code for separate service and then push it out. | 08:10 |
| rinigus | probably should be separate ofono plugin and I suspect it will be needed for some other init/runtime functionality on qcom modems | 08:11 |
| T42 | <b100dian> Oh, what an excellent news! Great job rinigus!! | 08:30 |
| T42 | <b100dian> So this may mean I can drop my provider volte disablement even on tucana and sake, even in the absence of ims plugin | 08:38 |
| rinigus | @b100dian: right now it is to ensure that SMS will trigger events on arrival. I am testing it without volte as it worked without volte on LOS. as for tucana and sake, I guess you are "still" on hidl ims. but, I wouldn't be surpised if it magically would improve all newer qcom modems | 08:55 |
| T42 | <b100dian> Yes, I am on hidl on those two | 09:14 |
| T42 | <b100dian> btw, rinigus: how did you find that AT command, it is not present in any open source parts on github :P - did you decompile some .so? | 09:14 |
| rinigus | @b100dian: its not AT command at all. its separate HIDL call that is used by android java services. its a good question and I will reply to it after code cleanup :) | 09:15 |
| T42 | <b100dian> Oh, ok, it sounded as an AT comand ;) I did see its Qti Telephony call. Will wait for the meaty details ;) | 09:19 |
| Mister_Magister | Man sad thing happened. They turned off 3G now my decade old g2 can only use 2G :( And when they turn off 2G I won't have working phone :( | 10:38 |
| mal | rinigus: hmm, very strange | 11:52 |
| rinigus | mal: not really. quite exciting even :) . just adjusting code to get better logs and then will push code to tmp repo | 11:53 |
| mal | rinigus: how did you find that ATEL ready message? | 11:54 |
| rinigus | by reading/grepping/ all kinds of decompiled APKs. I'll write it up in an hour or so. | 11:55 |
| rinigus | mal and @b100dian: code is here - https://github.com/rinigus/fake-qcrilmsgtunnel | 12:14 |
| rinigus | I will start writing up how was it figured out. when ready, will paste in IRC readable form here | 12:15 |
| rinigus | I am going to paste below few messages on how I ended up working with vendor.qti.hardware.radio.qcrilhook . for easier reading, please wait for message END before your replies | 12:39 |
| rinigus | As I knew that SMS arrival works on LOS with and without volte, it was clear that something was amiss in SFOS. in particular, jtrace64 -f --thread qcrilNrd did not indicate even any binder transaction when I tried to get SMS. | 12:39 |
| rinigus | So, I went back to LOS and recorded logcat on boot with and without volte. when getting SMS, receiving calls, or making calls. in addition, when making these operations, I jtraced qcrilNrd. As a result, I have a data for the case when all is working fine | 12:39 |
| rinigus | When comparing SFOS and LOS, we are missing on SFOS lots of Java based services. so, my guess was that some of the missing services initialized qcril. qcril, in addition to android.radio has also strange vendor.qti.hardware.radio.qcrilhook@1.0::IQtiOemHook/oemhook0 and 1, one per sim. | 12:39 |
| rinigus | when grepping for vendor.qti.hardware.radio.qcrilhook LOS binaries, system_ext/priv-app/qcrilmsgtunnel/qcrilmsgtunnel.apk vendor/lib64/libqcrilNr.so and vendor/lib64/vendor.qti.hardware.radio.qcrilhook@1.0.so have it | 12:40 |
| rinigus | from this, we can see that some APK does have it. just jadx'ing only that APK didn't help. spent some time reading it as it did connect to HIDL service, but when it was used and how wasn't clear. | 12:40 |
| rinigus | in reality, looks like it is mainly communication channel that takes messages from other services running inside phone service/app by qcom and channels them to qcril if needed. and also provides reverse communication. that's my understanding of it, not 100% sure. | 12:40 |
| rinigus | I wrote small service that just connected to vendor.qti.hardware.radio.qcrilhook@1.0::IQtiOemHook/oemhook0 and made callbacks to its indication and reply. while indications were floating, not much changed compared to earlier. on sending SMS, it was quiet | 12:40 |
| rinigus | so, as just qcrilmsgtunnel.apk was insufficient, I went to list of extracted prorietary files in LOS. it contained a list of APKs that were pulled from device. so, I extracted a bunch of them, probably not all needed. | 12:40 |
| rinigus | next, I wrote a script to process my LOS logcat and try to guess where the message initiated from in the java sources. if logcat message did not contain qcril or did not had a hit to my extracted Java services, I dropped it. as I worked on the simpler case - no volte - ims was mostly dropped from messages as well. | 12:40 |
| rinigus | suddenly, I had instead of thousand lines something like 400-500 looking at me. this super useful script (not perfect) is at https://github.com/sailfishos-sony-nagara/main | 12:40 |
| rinigus | the lines like "08-01 19:37:07.348 3007 3967 D PowerUpOptimization: Sending ATEL Ready to RIL for slot: 0 --> QtiTelephony/sources/com/qti/phone/powerupoptimization/PowerUpOptimization.java:377 [7]" were in particularly curous. | 12:40 |
| rinigus | then I zipped all extracted java codes, my processed logcat, my processing script and uploaded it to chatgpt. after discussing around this with it, correcting, guiding it, and reading the code, I got my message that was sent to qcril. this is rather convoluted, as PowerUpOptimization makes the call that first arrives to the tunnel and then is in some form sent to qcril. | 12:40 |
| rinigus | bit trying and error made the call that resulted in happy qcril. | 12:40 |
| rinigus | END | 12:40 |
| rinigus | mal and @b100dian : how ^ | 12:41 |
| rinigus | I'll go afk for an hour or so. will be happy to discuss later on how to make ofono plugin or how to package this all for a working system | 12:43 |
| mal | rinigus: was that atel message only thing sent in los to the oemhook? | 12:43 |
| rinigus | mal: probably not as I couldn't get immediate jtrace. | 12:44 |
| rinigus | even that message was not in my traces. just in logcats | 12:44 |
| rinigus | I suspect that there are more messages | 12:44 |
| rinigus | but maybe not needed. note that this service is available in tama too. just we didn't need it at that time | 12:45 |
| mal | need to check if any of my devices has something like that | 12:53 |
| T42 | <b100dian> rinigus: thanks for the blog post! Hopefully other devices will benefit from this. | 13:26 |
| T42 | <b100dian> And of course, hats off for the tenacity | 13:27 |
| T42 | <b100dian> Now let me see if I can test today :) | 13:27 |
| mal | I do wonder what that ATEL means :) | 13:27 |
| T42 | <b100dian> some chip codename? | 13:30 |
| Mister_Magister | "A telephone" | 13:46 |
| rinigus | mal: ATEL - maybe android telephone stack? | 14:00 |
| rinigus | but nothing specific pops up on search | 14:01 |
| mal | yeah, that is one possibility | 14:01 |
| mal | quite likely actually | 14:02 |
| rinigus | there is a lots of "android.telephony..." props in PowerUpOptimization java | 14:02 |
| Mister_Magister | rinigus gets the prize! | 14:02 |
| rinigus | now, how can I wrap it into ofono plugin? | 14:02 |
| rinigus | any howto on the subject? | 14:02 |
| rinigus | Mister_Magister: A telephone is pretty close. :) | 14:03 |
| Mister_Magister | pretty close doesn't get you the win :P | 14:03 |
| rinigus | seems like I can take qcom ims plugin and use that as a howto for new plugins | 15:00 |
| T42 | <b100dian> omg I just got an sms ;) | 15:03 |
| T42 | <b100dian> what's wrong with packaging this as a service, as you already started? Just so that it is only ran when ofono is run (e.g. not in airplane mode etc.)? | 15:04 |
| mal | interesting that the whole oemhook thing is marked deprecated in android interface repo | 15:18 |
| mal | and afaik that is not even a thing in aidl anymore | 15:19 |
| mal | hmm, but that vendor.qti.hardware.radio.qcrilhook@1.0::IQtiOemHook in completely separate from the actual oemhook stuff radio interfaces | 15:21 |
| rinigus | @b100dian: obviously its easier to package as a service. at least for now (reading ofono binder extension plugin for IMS is already quite "interesting") | 15:22 |
| rinigus | will try to see what will happen with flight mode | 15:22 |
| rinigus | worked nicely, no problem | 15:24 |
| rinigus | mal: where did you see that deprecation? | 15:25 |
| rinigus | ok, if it is separate then deprecation maybe does not extend | 15:25 |
| rinigus | note that in java codes there is a check on whether HIDL or AIDL service is contacted | 15:26 |
| mal | https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/main/radio/deprecated/1.0 | 15:27 |
| mal | but that is the official oemhook, not the internal qcom one you use | 15:27 |
| rinigus | indeed | 15:28 |
| mal | I assume you don't see the official interface in binder-list | 15:32 |
| rinigus | mal: I see only on hwbinder: vendor.qti.hardware.radio.qcrilhook@1.0::IQtiOemHook/oemhook0 vendor.qti.hardware.radio.qcrilhook@1.0::IQtiOemHook/oemhook1 | 15:35 |
| rinigus | nothing on /dev/binder | 15:35 |
| rinigus | @b100dian: I'll try to make a service out of it. it will just need to read config and some extras as it has to process it all per each slot | 15:40 |
| mal | probably would be doable with binder plugin extension | 15:42 |
| mal | that ims plugin is quite complex compared to what is needed in this case | 15:49 |
| rinigus | it is. but maybe can use it as a base ... | 15:56 |
| rinigus | ... by removing most of it | 15:56 |
| mal | rinigus: maybe check unit_ext_plugin? | 15:58 |
| mal | to see the most trivial example of ext plugin | 15:58 |
| rinigus | mal: checking :) | 15:58 |
| rinigus | thanks! | 15:58 |
| rinigus | yeah, something in between is needed | 16:00 |
| rinigus | I'll try to compose something - will ask if I get into trouble. | 16:02 |
| rinigus | mal: looks like BinderExtPlugin can be only one :( | 17:25 |
| rinigus | so, either IMS or qcrilhook | 17:25 |
| rinigus | will make separate service first and later we can look into ofono plugins | 17:41 |
| T42 | <adampigg> rinigus: seems like you are getting your head very much around volte implementations? | 17:42 |
| rinigus | @adampigg: volte was not the saver here. will get back to volte as soon as this backdoor qcom init is sorted | 17:44 |
| rinigus | with volte I have to adapt yet sms sending/receiving to aidl. calls are already ok to my understanding | 17:45 |
| rinigus | so, maybe will manage to port sfos to nagara in ... a year, I guess. that's including los porting :) | 17:45 |
| mal | rinigus: hmm | 17:58 |
| T42 | <ot_kurva> Guys, did anyone tried to port SailfishOS on Pixel phones with Tensor chip? | 18:39 |
| T42 | <Mister_Magister> not yet I don't think | 18:39 |
| T42 | <b100dian> rinigus: that's because you're actually finding things that unblock others too. But yeah, los was... an unexpected journey | 19:17 |
| rinigus | @b100dian: that's what we all do here by swapping roles. just more difficult device than I expected. | 19:29 |
| rinigus | @b100dian: https://build.sailfishos.org/package/show/nemo:devel:hw:sony:nagara/fake-qcrilmsgtunnel but timing is off. starts too early - will look into it tomorrow | 19:51 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!