Replicant

If /system/lib/libsamsung-ril.so is restored after booting the phone with the modem disabled, is it feasible to restart whatever process normally links to that .so file, in order to initialize the modem without rebooting the entire phone?

Jeremy Rand wrote:

If /system/lib/libsamsung-ril.so is restored after booting the phone with the modem disabled, is it feasible to restart whatever process normally links to that .so file, in order to initialize the modem without rebooting the entire phone?

It's worth a shot. RILD is the process to start and it should initialize the modem, but I'm not sure if the SIM card is then properly registered with Android if it wasn't at boot.

Wolfgang Wiedmeyer wrote:

Jeremy Rand wrote:

If /system/lib/libsamsung-ril.so is restored after booting the phone with the modem disabled, is it feasible to restart whatever process normally links to that .so file, in order to initialize the modem without rebooting the entire phone?

It's worth a shot. RILD is the process to start and it should initialize the modem, but I'm not sure if the SIM card is then properly registered with Android if it wasn't at boot.

Good news! I didn't even have to restart RILD myself. About 5-10 seconds after I restored /system/lib/libsamsung-ril.so to its original location, Replicant discovered the mobile network, including the SIM. I infer that RILD periodically checks for /system/lib/libsamsung-ril.so if it fails to find it on initial boot.

This is on the Galaxy S3 i9300 with Replicant 6.0 0001.

My understanding is that Jeremy's scripts are considered to be a good-enough-for-now solution.
Should I go on with my original intention, then?

1. implement a standalone graphical app, wrapping Jeremy's scripts, quite like with RepWifi
2. include the option to disable RIL directly inside RepWifi
3. patch the System Settings app, adding a checkbox that executes the scripts under the hood when checked/unchecked.

Or.. Should we wait for a deeper understanding of modem (in)operation before going on?
Should this be the case, I think that what reported on #1820 is the way to go.. I'll post what I know on that page.

Please let me know what you consider to be the best choice!

Cheers,

Fil

Fil Bergamo wrote:

My understanding is that Jeremy's scripts are considered to be a good-enough-for-now solution.
Should I go on with my original intention, then?

In terms of usability and device-independence, there is still room for improvement ;)

If you think it's worth doing, I can come up with one of these options:

1. implement a standalone graphical app, wrapping Jeremy's scripts, quite like with RepWifi
2. include the option to disable RIL directly inside RepWifi

Not sure if that's worth it. I think it's better to integrate it into the settings app.

1. patch the System Settings app, adding a checkbox that executes the scripts under the hood when checked/unchecked.

If you already do the whole work of adding the settings there, it should be based on a proper solution that is as device independent as possible. The scripts certainly aren't and what goes into the settings app should not be specific for a certain hardware interface implementation. Then it's a lot easier to account for devices that don't have a modem or that don't use Samsung-RIL. Otherwise, it becomes a pile of hacks over time.

Using the approach with the RIL daemon I described, it's also not entirely sure that it will work for all sorts of possible hardware that can be supported by Replicant. There is also the case that a dedicated daemon is used to boot the modem and the vendor RIL does the rest. The approach would not help in this case. I currently have it this way for QMI-RIL. But I'm planning to change that and also let the RIL control the modem boot.

Or.. Should we wait for a deeper understanding of modem (in)operation before going on?
Should this be the case, I think that what reported on #1820 is the way to go.. I'll post what I know on that page.

Testing it with such a cell would certainly help a lot to ensure that it works as intended. Now, there is not really a way to test it.

I really want to work on this to provide the front-end for disabling the modem.
But I will need some strong solutions in the back-end to work with.

Has anybody looked into this in details?
What would be a general way of unloading the modem firmware that works for every supported device?
Do every device work the same, in that a firmware binary resides in a certain filesystem location?
Is moving that binary away an equivalent workaround for all devices?

I can really work on the settings app efficiently if anybody is able to answer those questions.

wouldnt a approach like postmarket os, to give this feauture during installation a easier solution for this? Or the idea is to be switchable at all times?