You should have no dramas flashing Lineage22 over the top of Lineage23, so long as you wipe the data partition. I would be all but certain Sailfish won’t work if you try to go ahead with Lineage23.
Just make sure you end up in slot a with Lineage22 before flashing SFOS per the instructions. And I would very much encourage booting into Lineage22 once to confirm its working.
Thanks, exactly what I suspected. Just wanted to get it somewhat confirmed.
Looks like there is a chance indeed! Very encouraging to read last night’s meeting logs.
It seems like the general consensus is that there is not much work in making the official AAS “just work” on the community port - I wonder why in my admittedly brief testing that was not the case, I was certainly under the impression that the LOS22 base made things a bit harder.
Anyway, great to hear that Jolla is still on board. Not sure what the next steps are, I suppose I shall wait with baited breath like everyone else!
Thank you so much for your work.
I was able to successfully flash your image onto my Xperia 10 V today.
Everything works as @juz described. 
Marvelous news. I wonder how long until they’ll start offering it, though. X10V being my daily-driver, I’m quite reluctant to switch from the official port until AAS is available on the community port as well
Glad it’s working well, @bardoftruth!
As I have not yet got around to generating a new flashable image since the initial release, be sure to zypper ref && zypper dup and reboot to install the latest updates (ie. usb-moded, battery charge control, etc.).
Great work @Sharks !
My X10V was sitting in a drawer for a year and a half, and now it is running your port.
Let’s hope Jolla listens and at least could provide AAS support for these ports.
Did you read the meeting notes? AAS support was confirmed to come: Community meeting on August 20, 2026
It has been a few weeks now, and the phone has been fantastic with the new port. Things are fast, stable and everything (expected) is working well.
A recent update partially fixed the battery ageing protection for me, but only partially. Is it working for any other users?
Here is a summary of what is happening for me:
Battery ageing protection set to 90%.
Phone charges normally up to the limit:
13:01:26 batt_soc:88 batt_current:334778
13:01:31 batt_soc:88 batt_current:1726075
13:02:17 batt_soc:89 batt_current:1700745
13:03:13 batt_soc:90 batt_current:1488953
MCE enables charging protection:
13:03:16 pm7250b_charger: smblib_somc_smart_set_suspend: voted for smart charging (1).
13:03:16 mcemodules/charging.c: mch_policy_set_charging_state(): mch_charging_state: allowed -> disabled
Charging stops correctly at 90%:
13:03:19 batt_soc:90 batt_current:0
13:10:59 batt_soc:90 batt_current:0
13:20:58 batt_soc:90 batt_current:0
13:30:01 batt_soc:90 batt_current:0
~31 minutes later charging resumes by itself.
No corresponding
mch_charging_state: disabled -> allowed
or
smblib_somc_smart_set_suspend: voted for smart charging (0)
appears in the log.
Charging begins again:
13:34:07 batt_soc:90 batt_current:483398 usb_current:1836395
13:34:12 batt_soc:90 batt_current:485229 usb_current:1844505
13:34:17 batt_soc:90 batt_current:485840 usb_current:1840285
13:34:22 batt_soc:90 batt_current:486755 usb_current:1889270
A few seconds later current increases significantly:
13:34:38 batt_soc:90 batt_current:1681214
13:34:43 batt_soc:90 batt_current:1645508
13:34:58 batt_soc:90 batt_current:1549988
Battery then charges beyond the configured limit:
13:35:13 batt_soc:91 batt_current:1488953
13:37:21 batt_soc:92 batt_current:1261597
13:39:29 batt_soc:93 batt_current:1123658
13:40:31 batt_soc:94 batt_current:1072083
Expected:
- Charging remains suspended at 90%.
Observed:
- MCE successfully disables charging at 90%.
- Battery current remains 0 for ~31 minutes.
- Charging resumes without any visible MCE state change.
- Battery continues charging past 90%.
I have tried 2 different chargers, and different cables. For some reason after ~30minutes, the phone restarts charging.
I am not sure what else to check or to monitor. If anyone has any ideas that would be great. I will try and look a little more in the next few days.
Thanks!
Interesting stuff, thanks for the detailed report.
You note that there is no state change reported by mce. Is the contents of /sys/class/battchg_ext/smart_charging_interruption being changed as expected?
I wonder if there’s any other file that could be used instead for charge control, eg.
/sys/class/battchg_ext/usb_input_suspend/sys/class/qcom-battery/charging_enabled/sys/module/qpnp_adaptive_charge/parameters/charging_enabledFeel free to fiddle with /etc/mce/70-battery-xqdc72.ini and see if you can get it working more reliably with some different file if you can find one. For some reason I have an inkling that the fp5/Nagara file might be present but not sure why.
Unfortunately as you and I have discussed before this is one of the few areas where Murray and Zambezi are substantially different, so I’m flying blind a bit here given I don’t own a Zambezi device to test on.
Thanks so much for the good tips. I’ll study logs more tonight hopefully. They are good ideas to check out, so thanks for taking the time to share them. Seems very strange that it all works well, then always something must overide, and charging continues. Weird it seems to consistently take 30 minutes.
I feel the nagara file cannot be present, as batterybuddy (with nagara changes included) reported missing control and didn’t work.
Ah, I had not considered that. Apologies.
For some reason I thought the /sys/class/qcom-battery/ directory existed on Zambezi but I could be misremembering.
You have a good memory! It does exist. The problem we ran into is it doesn’t contain charging_enabled! It only contains:
[defaultuser@Sailfish10V ~]$ ls /sys/class/qcom-battery/
fcc_stepping_in_progress parallel_pct restrict_chg restrict_cur version
A little info from me regarding the charging mode threshold limitation:
The journal shows that the kernel or driver is running a watchdog that changes the status in the file /sys/class/battchg_ext/smart_charging_interruption from 1 to 0 after almost exactly half an hour.
Aug 27 12:00:54 Xperia10V kernel: [charge_info_status]usb_present:1 / usb_online:1 / usb_voltage:5029408 / usb_current:125865 / chg_type:5 batt_present:1 / batt_status:1 / batt_temp:316 / batt_current:0 / batt_voltage:4258268 / batt_soc:88 chg->typec_mode = 6
Aug 27 12:00:54 Xperia10V kernel: [charge_info_other] connector_temp = 0 thermal_status =5 water_det = 0 system_temp_level = 0 otg_current = 1000000 fv = 4480000
Aug 27 12:00:55 Xperia10V kernel: [drm:sde_connector_check_status_work:2557] [sde error]Check err_flag status 0
Aug 27 12:00:56 Xperia10V kernel: (virq:irq_count)- 4:1056049 14:692727 206:646492 20:329363 6:179007 172:88999 297:55562 1:45660 21:29081 173:26951
Aug 27 12:00:56 Xperia10V kernel: (cpu:irq_count)- 0:2242607 1:272214 2:163726 3:174138 4:66603 5:72747 6:99247 7:209287
Aug 27 12:00:56 Xperia10V kernel: (ipi:irq_count)- 0:5856012 1:957276 2:0 3:0 4:8026 5:1128313 6:0
Aug 27 12:00:56 Xperia10V kernel: pm7250b_charger: smblib_set_icl_current: set ICL to 1000000uA
Aug 27 12:00:56 Xperia10V kernel: ALG: cap_learning_update: [SOMC CL][OFF] charge_status:1 bsoc_cp:8474
Aug 27 12:00:56 Xperia10V healthd: battery l=88 v=4258 t=31.6 h=2 st=2 c=0 fc=5095000 cc=0 chg=a
Aug 27 12:00:59 Xperia10V kernel: [FTS_TS]get_flow_cnt:reg0x91,val:c7,last:c7
Aug 27 12:00:59 Xperia10V kernel: pm7250b_charger: smblib_somc_smart_charge_wdog_work: Smart Charge Watchdog timer has expired.
Aug 27 12:00:59 Xperia10V kernel: pm7250b_charger: smblib_set_icl_current: set ICL to 1000000uA
Aug 27 12:00:59 Xperia10V kernel: ALG: cap_learning_update: [SOMC CL][OFF] charge_status:1 bsoc_cp:8474
Aug 27 12:00:59 Xperia10V kernel: [charge_info_status]usb_present:1 / usb_online:1 / usb_voltage:5004496 / usb_current:141110 / chg_type:5 batt_present:1 / batt_status:1 / batt_temp:316 / batt_current:0 / batt_voltage:4258268 / batt_soc:88 chg->typec_mode = 6
Setting /sys/class/qcom-battery/restrict_chg to 1 (echo 1 > /sys/class/qcom-battery/restrict_chg
) unfortunately doesn’t prevent the phone from charging.
@bardoftruth Thanks for checking this out too. Good to get some info. I just finished running another test, and found the same as you regarding the watchdog after 31 minutes. Not sure what to do about that - I wonder if the watchdog can be suspended, or overridden somehow, but I don’t know about these things.
Perhaps the ticket is to try elsewhere as you suggested. You are right about restrict_chg, but if you also change restrict_cur I think charging stops.
If I do both:
echo 1 > /sys/class/qcom-battery/restrict_chg and
echo 0 > /sys/class/qcom-battery/restrict_cur the charging is stopped completely.
Perhaps I should try sticking that in the/etc/mce/70-battery-xqdc72.ini, though not sure how to put two things in there.
Maybe after 30mins the charge drops to 89% and phone starts charging again until 90%?
Good guess, but I charged my 10V to 88%, then activated the charge limit at 80%
The value in the file /sys/class/battchg_ext/smart_charging_interruption was set from 0 to 1, and it stopped charging.
After 30 minutes, the value automatically reset itself (as seen in the journal log) from 1 back to 0, and the 10V started charging again.
Thanks for the thought @avhakola .
I have monitored this relatively closely a few times.
In brief:
phone charges until threshold is reached
mce activates smart_charging_interruption, this successfully puts charging into a holding pattern where current in is equal to consumption.
the phone successfully hovers at the threshold percentage.
after ~30 minutes, a sony kernel watchdog interferes and overrides mce’s actions.
the phone resumes charging until full.
It is the watchdog overriding mce that restarts charging, not something on the sailfish side, nor the battery dropping below the threshold.
To avoid unnecessary further digging by others, I just thought I should make a quick note:
So it’s possible sharks and mal have located a better (the correct?) file to be using. Possibly /sys/class/power_supply/battery/input_current_limit is the way to go. I’ll see how it goes tonight and report back.
Edit: Unfortunately the same behavior as earlier, after ~30 minutes charging resumed.
You’re dead right there, 30 minutes on the dot.
I think at this stage the options are to either edit the kernel source to get rid of / extend that timer indefinitely, or else write a hack so that mce can edit both /sys/class/qcom-battery/restrict_chg and /sys/class/qcom-battery/restrict_cur at once. I’m leaning toward the second option as I’m not sure I’m brave enough to modify the kernel sources if I don’t have to. Messing about in userspace is safer!