| T42_ | <roundedrectangle> hey everyone, it's me again, now i am having an issue where it says `CANNOT LINK EXECUTABLE "/usr/libexec/droid-hybris/system/bin/minisfservice": library "libandroidicu.so" not found` in logcat (and also for `minimediaservice`), i did make a symlink at /odm/lib64/libandroidicu.so to /apex/com.android.runtime/lib64/libandroidicu.so in sparse but still, i have this error | 06:00 |
|---|---|---|
| rinigus | @roundedrectangle: link that you added doesn't make a difference in this case as you are linking in android hadk. for me, minisfservice is linking nicely on los21 sources. sounds like you miss some android sources there that should have pulled in libandroidicu.so compilation | 07:02 |
| rinigus | also that symlink sounds weird. we usually link in opposite direction and to libexec/droid... | 07:02 |
| rinigus | with compilation - could be some differences in android versions, but I would expect it to be pulled in automatically | 07:03 |
| T42_ | <roundedrectangle> rinigus: i read about the symlink here https://sailfishos.wiki/books/hadk/page/hadk-hot#bkmrk-common | 07:04 |
| rinigus | OK, I misread. yes, direction is correct. and sounds like you have service compiled. (too early to give feedback by me misreading the messages) | 07:06 |
| rinigus | then its way better. | 07:06 |
| T42_ | <roundedrectangle> i also had a similar issue but about /vendor/bin/hw/vendor.qti.hardware.cryptfshw@1.0-service-qti.qsee and vendor.qti.hardware.cryptfshw@1.0.so, there mounting /system/product to /product helped. i read that i could also modify ld.config.txt in hadk faq, but mounting is simpler. | 07:07 |
| rinigus | for nagara we use overlays as shown here for that lib: https://github.com/sailfishos-sony-nagara/droid-config-sony-nagara/tree/main/sparse/overlays/system/lib64 | 07:08 |
| T42_ | <roundedrectangle> maybe making a systemd mount unit instead of a symlink for that androidicu.so could help... | 07:08 |
| rinigus | in logcat you may get more messages regarding why it fails. these symlinks help when there are some permission errors (aka not allowed to link in this or that space) | 07:09 |
| rinigus | for overlays, we also have scripts in our sparse and systemd unit. advantage is that you can overlay pretty much anything on top of android filetree to either add or adjust files | 07:09 |
| rinigus | but it makes sense to experiment directly on device first and later start adjusting your configs when you get config working | 07:10 |
| T42_ | <elros34> you really have the same error or just misleading "library * not found"? | 09:34 |
| T42_ | <roundedrectangle> i'm sorry, i didn't understand what you meant. i have same "CANNOT LINK EXECUTABLE ..." error. here is my logcat if it helps https://justpaste.it/bwtwk | 10:50 |
| T42_ | <elros34> ok ignore. what about /dev/*binder* permissions? | 11:18 |
| T42_ | <roundedrectangle> I tried enabling memcg configs in kernel defconfigs (or something like that) and the build failed, I am trying to fix it right now. But anyway, this doesn’t have anything to do with the androidicu error, right? Or am I missing something? | 11:20 |
| T42_ | <roundedrectangle> Defconfig* | 11:21 |
| T42_ | <elros34> I don't think so. What kernel version do you have? | 11:22 |
| T42_ | <elros34> I would focus on binder errors now | 11:23 |
| T42_ | <roundedrectangle> 3.10.108. for now i don't have issues with fixing the binder errors, i was asking about the androidicu.so error, but thank you anyway. maybe fixing binder errors will fix that too. | 11:26 |
| T42_ | <elros34> quiet old. What do you mean you have no binder errors? Your log is flooded with binder errors, no point fixing some androidicu now | 11:30 |
| T42_ | <roundedrectangle> i do, i am saying i can fix them myself, i don't need help there for now | 11:30 |
| T42_ | <roundedrectangle> but thank you anyway, i will try fixing them first | 11:30 |
| T42_ | <roundedrectangle> nevermind, ignore | 11:31 |
| T42_ | <roundedrectangle> okay, so i tried to apply some more things in defconfig but the binder errors are still there, then i tried adding more things mer-kernel-checker was complaining about but then i got a lot of errors when compiling. i could fix them but i found that there is an unofficial lineageos 18.1 port for my device and those compilation issues are fixed in the kernel fork for that port so i'm just going to make a new port based on that because | 14:16 |
| T42_ | <roundedrectangle> additionally bluetooth is broken in official 17.1 build, and in that 18.1 port it isn't iirc (i used it some time ago) | 14:18 |
| T42_ | <elros34> what makes you think that changing defconfig will help with permission issue on /dev/binder. I was basically asking about ls -al /dev/*binder* | 14:46 |
| T42_ | <roundedrectangle> ah, okay. well i googled something from the logcat log and in irc logs i read that i should fix defconfig. | 14:51 |
| T42_ | <roundedrectangle> | 14:51 |
| T42_ | <roundedrectangle> but anyways, since bluetooth is broken switching to 18.1 base is still a good idea in any case. it's better to do it earlier in the porting process to waste less time | 14:51 |
| rinigus | @b100dian: first tests using android suspend system instead of autosuspend by linux kernel: https://github.com/sailfishos-sony-nagara/main/issues/55 | 15:59 |
| mal | rinigus: what does the service actually do? | 16:01 |
| T42_ | <TheVancedGamer> handles mem_sleep | 16:01 |
| T42_ | <TheVancedGamer> without autosleep in kernel | 16:01 |
| rinigus | mal: it handles Wakelocks and suspends the device via echo mem > /sys/power/state | 16:02 |
| mal | then instead of wrapping the android service it probably should be done in mce which already handles at least some wakelock stuff | 16:03 |
| rinigus | as several newer daemons on android use that for wakelock management, they miss out on SFOS ability to lock/unlock wakelocks | 16:03 |
| mal | hmm | 16:04 |
| rinigus | ... as these wakelocks are internal to android and don't get exposed to linux kernel anymore | 16:04 |
| mal | no idea why they decided to do that | 16:05 |
| rinigus | its actually quite good. if service dies, wakelock gets destroyed automatically. if I understand it correctly | 16:05 |
| rinigus | and already in tama, I had to hack linux kernel to prevent autosuspend getting into extremely tight loop trying to suspend and failing. same with nagara. | 16:07 |
| mal | what was failing in suspend attempts? | 16:08 |
| rinigus | mal: hard to say as attempts were in very few microseconds as far as I remember. so, whatever was done in drivers or some other reasons. | 16:11 |
| rinigus | corresponding commit: https://github.com/sony-nagara/android_kernel_sony_sm8450/commit/e8af2f1baa1f2b3b0856df908b2e17a0514c6fe6 | 16:11 |
| rinigus | but it is even not very important at this stage as we have a fix. main issue is that android services expect this mechanism and we miss it. whether it creates issues in SFOS is another question, but design of those services is already using it | 16:13 |
| rinigus | so, I will explore this android suspend service and patch to make it easier to use. then test to see if it works well. | 16:14 |
| T42_ | <b100dian> rinigus: apart from bluetooth which you wrote doesn't change much, I'd be curious if overall power comsumption is lower (say, in a few days) | 18:08 |
| rinigus | @b100dian: would be interesting. I am making patches now and it will be relatively simple to test it soon. probably will be ready tomorrow | 18:10 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!