How I wish I had bought a 5IV/1IV instead of that damn 10V. 
As always⊠thank you @rinigus for your hard work.
2 Likes
Seems to work, thanks!
1 Like
Itâs not something you couldnât remedy 
I bought the 10 V, too, but then I realized that I do not have to be stuck with it, so I bought the 1 IV. The next step is to sell the 10 V and regain some part of the 1 IV costâŠ.
And @vlagged just as much!
Of course! I just wasnât aware, since I just look in to this thread now and then. 
As I kept having problems with the recharging limit which at some point just broke and I couldnât make it work again, for my own use I modified BatteryBuddy 4.3.2-1 (which seems to be the latest release version) to work with the 1 & 5 IV. It is 100% functional now, including the upper and lower limits, current limit, notifications, etc. If someone wants either the modified source code (project ready to build in the SDK) or the rpm package, please let me know.
Or if someone would prefer to modify it oneself, hereâs the information so that you donât have to rediscover it:
- the charging control file on Nagara is
/sys/class/qcom-battery/charging_enabled(writing 1 to that file enables charging, 0 stops it) - to make current limitation work, one needs to control two files: write max current (in microamps) to
/sys/class/qcom-battery/restrict_currand write 1 to/sys/class/qcom-battery/restrict_chgto enable the limit (it gets reverted to 0 on every reboot, so in order for the current limit to work it has to be rewritten with 1 each time) /sys/class/power_supply/usb/onlineinforms whether usb charger is connected (0 or 1)- all the remaining files are already supported by BatteryBuddy as they remain the same as on some other devices, so thereâs no need to modify anything to make those functions work, e.g.
/sys/class/power_supply/battery/capacity(holds current charge level in %),/sys/class/power_supply/battery/temp(temperature),/sys/class/power_supply/battery/current_now(reports the charging current in uA),/sys/class/power_supply/battery/status(current status, e.g. charging, discharging, full, empty, etc.),/sys/power_supply/battery/health, and so on. - In addition to adding the 1/5 IV specific control files to
application/src/battery.cppandservice/src/battery.cpp, one also needs to remember to include them inset-write-permissions.shandrestore-write-permissions.shscripts so that write permissions are correctly set on boot (e.g.chmod 666 /sys/class/qcom-battery/charging_enabled 2>/dev/null), otherwise the control files wonât be writable for BatteryBuddy. I also used that script to write 1 to the file enabling to limit the charging current (echo 1 > /sys/class/qcom-battery/restrict_chg) so that it is re-enabled on each boot. Well, and thatâs itâŠ.
I will contact @direc85 and ask him if he would like to officially include those Xperia 1 & 5 Mk IV specific control files in Battery Buddy, but for now we can easily make it work ourselves, as indicated above. Iâve been testing it for a couple of days now and it works 100% OK.
5 Likes
Update: 5.0.0.77 testing images are available for both 1 IV and 5 IV devices as well as for updating from command line.
The changes enable the 2nd radio / SIM also on 1 IV, but also safeguard for when you donât have an eSIM registered so you donât see the loading indicator instead of access to home screen at boot.
Thereâs a also the droidmedia update that makes the video playback work locally, and selection of Developer/MTP/Charge only when plugging in.
If youâre already on 5.0.0.77 you should just zypper ref && zypper up, otherwise the incantation is
devel-su
ssu re 5.0.0.77
version --dup
restart
4 Likes
thanks for your great job!
are 5.1.0.7-images to be expected soon?
I finally got my XQ-CQ54 last week (after having received an unlockable SOG09 which I had to send back, the dealer was unable to provide me with the info which model he has in his stocks beforehand) and kept my fingers crossed after reading about the release in last weeksâ meeting log.
Altough I digged deep in this post (and others) I want to avoid see-saw flasing to stock FW / LOS / SFOS and looking for the needle in a haystack as @wetab73 had to do to get eSIM running.
Iâd like to use both eSIM and SIM if possible (with 2 different providers).
anything else I have to take into account before launch newflasher with the latest versions (LOS lineage-21.0-20260404)?
looking forward to have SFOS finally back as a daily driver,
happy sailing!
Update went smooth, everything works perfectly fine, including MTP and Developer mode cable connection! Fantastic job, thank you so much!
2 Likes
@wetab73 @Siltaar havenât you been able to check on LOS if video recording volume is very low there, too?
I checked with native ROM yesterday for video recording (was OK) and will be able to test in LOS in the coming days.
1 Like
Fyi USA users, after forcing ATTs hand a bit the 5IV global does now correctly register to the ATT network and MVNO (such as PureMobile). Calls, data and MMS working. Previously they had the device erroneously blocked for not being certified (it is certified even if reps or documentation claim otherwise). Weâre also able to register on on Google Fi successfully, albeit there are MMS issues.
3 Likes
Sorry, I had no opportunity to go back to LOS recently. But Iâd say that you can rather easily test it yourself by backing up the entire SFOS system to a tar.gz archive and then unpacking it. I tested it yesterday because when the .77 update was made available, I decided that I would like to revert to the original unmodified vendor.img because it turned out that it doesnât take any modifications in it for the AAS mobile data to work. But in the past whenever I was reflashing vendor.img I was always ending up (for some mysterious reasons) with a non-bootable SFOS, so I thought Iâd try to just tar.gz the entire /data/.stowaways/sailfishos content and if I end up with a non-bootable system then Iâd try to format sda94 and just unpack that archive just like we extract SFOS rootfs filesystem from an archive on fresh install on the 1/5 IV.
Long story short, a system archived using tar --numeric-owner -czvf backup.tar.gz /data/.stowaways/sailfishos/ and then restored using tar --numeric-owner -xzvf archive.tar.gz -C /data/.stowaways/sailfishos/ restores a fully working OS with the only exception being that fingerprints need to be added anew. So with a system backed up this way, you can safely go to LOS to do some tests and then go back to your untouched SFOS within just minutesâŠ
3 Likes
After the last update, when I overload my phone, the second sim card turns off. You have to turn it on all the time.
I did try to protect against it, but maybe insufficiently. the script that keeps an eye on your 2nd sim is at droid-config-sony-nagara/sparse/usr/libexec/nagara/ofono-esim-bootfix.sh at main · sailfishos-sony-nagara/droid-config-sony-nagara · GitHub
on your device it is at /usr/libexec/nagara/ofono-esim-bootfix.sh
look into the script and check properties like ro.product.device (/system/bin/getprop) are set correctly.
please open an issue at Issues · sailfishos-sony-nagara/main · GitHub and describe with parameters that are tested by that script.
1 Like
Hmm..
It might just be that the openrepos lpac is not replaced by chum lpac..
Try zypper in lpac-2.3.0+git1-1.1.1.bso or if needed
zypper in --oldpackage lpac-2.3.0+git1-1.1.1.bso
Actually now I think we should ship the chum lpac @rinigus what do you think? (if this the issue),
2 Likes
That could be correct assumption
I think having lpac at chum is correct location and there is no need to have multiple versions around. But maybe we should advice to have chum version of lpac installed
The file /usr/libexec/nagara/ofono-esim-bootfix.sh is identical to the script droid-config-sony-nagara/sparse/usr/libexec/nagara/ofono-esim-bootfix.sh at main · sailfishos-sony-nagara/droid-config-sony-nagara · GitHub
This solved the problem of turning off the second sim card after a reboot.
3 Likes
Great
This is the second time I have rigged my environment before releasing it, and I canât capture the actual update problems :(.
1 Like
I tested video recording from LOS on phone B and it seemed recording a correct audio level.
I tested video recording from SFOS on phone A and it was not loud enough.
Both phones are X 5 IV.
2 Likes