[R&D] VOLTE for non-stock roms for XT1254 on Verizon
- Thread starter koftheworld
- Start date
I also logged into to Verizon to check on VoLTE status and it said my device(s) were already enabled.
Thanks @NepoRood! I should be able to test in an hour or so. I'll report back.
Unrelated, has anyone thought about methodically disabling things (or maybe deleting files) on the Stock ROM and testing VoLTE after each change until it breaks? I was attempting this before (and discovered that disabling the My Verizon App didn't do anything) but couldn't get any of the more system-level processes to actually stop... even trying to kill them from adb. I'll be glad to take this testing on if it sounds like a good idea, AND if someone can tell me how to kill the stuff lol.
KA won't function (or collect logs) without root, so it's necessary for that purpose.
I installed VoLTE_5 and got the same results as my previous test, with the exceptions that the VoLTE flag was enabled by default this time and all files that I added myself last time were there by default.
I also discovered that toggling airplane mode is enough to make VoLTE work again after it stops working. You don't have to reboot the phone. However, it only works once per toggle.
A note to everyone testing: just so we're all doing the same experiment, please try using Chrome as your test when you're testing VoLTE. The default search bar on the launcher doesn't seem to work in any circumstances for me, so it would just make diagnosing easier if we just all use the same app for testing. You can use other apps too if you want, just remember to do at least one test with Chrome.
And one last thing: if you're going to test, post logs or it didn't happen.
I also discovered that toggling airplane mode is enough to make VoLTE work again after it stops working. You don't have to reboot the phone. However, it only works once per toggle.
A note to everyone testing: just so we're all doing the same experiment, please try using Chrome as your test when you're testing VoLTE. The default search bar on the launcher doesn't seem to work in any circumstances for me, so it would just make diagnosing easier if we just all use the same app for testing. You can use other apps too if you want, just remember to do at least one test with Chrome.
And one last thing: if you're going to test, post logs or it didn't happen.
Last edited:
I'm not sure how useful that would be at this point. VoLTE is working, so all the working parts are there. We just need to figure out which app/system process/whatever is getting pissed off after that first instance of it working and tell it to chill out. The only way I can see to do that is to comb through the logs. I've done a little bit of that, but I haven't found anything that's stood out to me yet.
Okay, one other question... has anyone tested incoming calls? I've yet to successfully receive an incoming call on VoLTE.
Confirmed. During an incoming call, VoLTE doesn't work. It also breaks VoLTE for all subsequent calls until you reboot or toggle airplane mode.
Update: Attempted an incoming call (didn't even ring) & added logs
Tested this build and instead of repeating exactly what @TheSt33v did, I tried:
-Making a call (VolTE worked)
-Made another call (VoLTE failed)
-Pulled the SIM card out & put it back in
-Made another test call (VoLTE worked again)
I'm hoping this will give some more illuminating logs. My apologies, but I had to fiddle with some things so the logs aren't completely clean.
Last edited:
But you can grant it permission with Privacy Guard, right? Anyway, I use SysLog mostly, because you can clean the buffer before doing a test
EDIT:
SysLog requires root too, lol, :silly:
(In my defense, I hadn't been awake very long)
Last edited:
@bhb27 will need to see if anything I gleaned is helpful here but it appears the first call in that log ended at 21:37:13. In the dmesg at that time (~890 sec after boot start) we have this:
May be something unable to update volte back to available after that initial call. @translucentfocus do you have SELinux running in enforcing mode or permissive? I think these are related to SELinux, but if it is in permissive mode the system just logs these without actually stopping the operation so it should not affect volte if it is permissive. If it is enforcing this may be related. However it appears based on the logs here it is in permissive mode, but I figured you can confirm for us.
There are also some interesting looking ims logs in the logcat output starting at around 21:38:25 which seems like when sim was pulled and reinserted to regain volte, though I am not sure what to make of them.
Code:
[ 889.048675,1] type=1400 audit(1491878307.150:72): avc: denied { read } for uid=1000 pid=3831 comm="imsdatadaemon" scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=netlink_socket permissive=1
[ 889.048960,1] type=1400 audit(1491878307.150:73): avc: denied { create } for uid=1000 pid=3830 comm="imsdatadaemon" scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=netlink_route_socket permissive=1
[ 889.052837,1] type=1400 audit(1491878307.150:74): avc: denied { bind } for uid=1000 pid=3830 comm="imsdatadaemon" scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=netlink_route_socket permissive=1
[ 889.052952,1] type=1400 audit(1491878307.150:75): avc: denied { write } for uid=1000 pid=3830 comm="imsdatadaemon" scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=netlink_route_socket permissive=1
[ 889.053056,1] type=1400 audit(1491878307.150:76): avc: denied { nlmsg_read } for uid=1000 pid=3830 comm="imsdatadaemon" scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=netlink_route_socket permissive=1
[ 889.053159,1] type=1400 audit(1491878307.150:77): avc: denied { read } for uid=1000 pid=3830 comm="imsdatadaemon" scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=netlink_route_socket permissive=1
[ 889.773945,3] init: avc: granted { set } for property=net.lte.ims.volte.provisioned pid=2370 uid=1001 gid=1001 scontext=u:r:radio:s0 tcontext=u:object_r:net_radio_prop:s0 tclass=property_service
[ 889.774448,3] init: avc: granted { set } for property=net.lte.ims.wfc.provisioned pid=2370 uid=1001 gid=1001 scontext=u:r:radio:s0 tcontext=u:object_r:net_radio_prop:s0 tclass=property_service
[ 889.774853,3] init: avc: granted { set } for property=net.lte.ims.vt.provisioned pid=2370 uid=1001 gid=1001 scontext=u:r:radio:s0 tcontext=u:object_r:net_radio_prop:s0 tclass=property_service
[ 889.974075,3] init: avc: granted { set } for property=net.lte.ims.volte.provisioned pid=2370 uid=1001 gid=1001 scontext=u:r:radio:s0 tcontext=u:object_r:net_radio_prop:s0 tclass=property_service
[ 890.036972,3] init: avc: granted { set } for property=net.lte.ims.wfc.provisioned pid=2370 uid=1001 gid=1001 scontext=u:r:radio:s0 tcontext=u:object_r:net_radio_prop:s0 tclass=property_service
[ 890.060126,3] init: avc: granted { set } for property=net.lte.ims.vt.provisioned pid=2370 uid=1001 gid=1001 scontext=u:r:radio:s0 tcontext=u:object_r:net_radio_prop:s0 tclass=property_serviceThere are also some interesting looking ims logs in the logcat output starting at around 21:38:25 which seems like when sim was pulled and reinserted to regain volte, though I am not sure what to make of them.
SE Linux is in Permissive Mode. (Went to About Phone to confirm) @bhb27 disabled it so that we could test more easily as I recall, but I couldn't find the post in a quick search of the thread.Competentpsycho;71812765 [user=5747496 said:
I will take a long look at the log, that behavior seems to be trigger by some system action hope they log what they are doing so we can make a workaround to get at least 100% out volte call..
there is no selinux rules for ims/volte related yet, to test you must have it at permissive, in the log permissive=1 means it is in permissive, if was a 0 enforcing, getenforce adb command will tell you...
this log error looked interesting to me:
04-10 22:08:57.953 1550 1747 E Diag_Lib: [IMS_ERROR]| 3544 | 1747 |ims-rtp-daemon ims_rtp_qmi_handler_thread_func waiting on select thread>
I'm going to explore your gh to look into both of those.
none volte files goes here
https://github.com/bhb27/proprietary_vendor_motorola/blob/N_Volte2/quark/quark-vendor.mk
volte only goes here
https://github.com/bhb27/proprietary_vendor_motorola/blob/N_Volte2/quark/quark-vendor-ims-blobs.mk
no need to duplicated (add to quark-vendor-ims-blobs.mk and also to quark-vendor.mk) or add any bin to Android.mk
Last edited:
VoLTE_6
Turns out, after rechecking, I still missed a couple of packages
New build, Here
If this one doesn't work properly, maybe we'll need so find something "outside" of what we have...
Turns out, after rechecking, I still missed a couple of packages
New build, Here
If this one doesn't work properly, maybe we'll need so find something "outside" of what we have...
thank you for the explanation. i was confused based upon what you wrote about signed packages.
are you building directly from @bhb27 's tree, or are you building from your own?Turns out, after rechecking, I still missed a couple of packages
New build, Here
If this one doesn't work properly, maybe we'll need so find something "outside" of what we have...
Trees from bhb, I just added to package list (he already had them there, they just weren't included)
EDIT:
Just to show the difference, here's the links.
roodbuild/quark-vendor-ims-blobs.mk
and
bhb27/quark-vendor-ims-blobs.mk
All other files are exactly the same :good:
Last edited:
great! i was curious what was the difference between your trees. did you submit a pull request to bhb, or are you holding off until we determine effectiveness?
quick question - i saw you listed RcsServiceM \ . shouldn't that only be RcsService \ ?
Last edited:
New posts
-
-
-
i can install twrp.img adb & windroid
- Latest: Walter Bishop
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone