[ROM][11.0][UNOFFICIAL] LineageOS 18.1 for Unihertz Atom L and XL [Alpha] [2024-02-18]

[SepticFuddy]

Flashing from the bootloader would rule out twrp as a source of errors.

Let me guess: The animated lineage logo shows up but never stops?
I use opengapps and I had the very same problem. It took me quite some time to figure this out. I don't know if it is related to A11 or anything else but Velvet (googlequicksearchbox) needs two new permissions which are not in the standard release of gapps.
https://github.com/ADeadTrousers/an...0001-Add-missing-permissions-for-Velvet.patch
As the last update of opengapps was 2 month ago they should already have noticed and fixed that by now but the whole project seems a little bit dorment lately.
I don't know the current state on microG for that matter.
If you tried to flash without wiping data and you previously (in LOS 17.1) had debugging activated you would be able to do a logcat to see if you are affected by this. It should even be possible to use adb to modify the permissons during the boot phase.

EDIT: Maybe there is a fix for that from microG then you'd need to update microG alongside LOS.

Actually it never makes it to the LOS screen, just goes from the bootloader security warning to off, back to the bootloader security warning. Have to SPFlash it to kill the loop because it won't even stay off. microG doesn't get flashed in, only Magisk. Riru/EdXposed/microG are all installed from within the OS. Magisk/Riru/EdXposed are needed for sig spoofing to work, since I'm not installing LOS bundled with microG

EDIT: Now back on 17.1 I'm back to having the mobile network issues on T-mobile I was having before... it worked fine when I switched back to them a couple months ago up until resetting the phone. I just don't understand...

 

[a-dead-trousers]

Sorry it took me a while to respond. I just needed a little bit distance to all the tedious rom related work.

Actually it never makes it to the LOS screen, just goes from the bootloader security warning to off, back to the bootloader security warning. Have to SPFlash it to kill the loop because it won't even stay off. microG doesn't get flashed in, only Magisk. Riru/EdXposed/microG are all installed from within the OS. Magisk/Riru/EdXposed are needed for sig spoofing to work, since I'm not installing LOS bundled with microG

Thinking about this I believe it must be related to selinux because most of the time (except in recovery) when I had this issue it was due to a faulty policy. So I suppose TWRP is working which means we might be at luck here.

1) Connect your phone to your PC
2) Try to boot into LOS once
3) When the phone reboots (should be a slight flicker on the LED) press "volume up" to boot into the recovery
4) Use your PC to capture the kernel log with "adb shell cat /proc/last_kmsg > last_kmsg.txt"
5) Search the "last_kmsg.txt" for errors or panics regarding selinux, seandroid or policy loading problems.

Maybe there is some policy interference which doesn't happen on Atom XL devices (which I'm testing on) even if one uses an Atom L rom.

EDIT: Now back on 17.1 I'm back to having the mobile network issues on T-mobile I was having before... it worked fine when I switched back to them a couple months ago up until resetting the phone. I just don't understand...

The only thing I changed on 17.1 that might be connected to this is the apn list and how it is combined.
In my opinion it was faulty prior to my change cause I treated the overwrites differently (Vendor List > Google LIst >Lineage List instead of Lineage List > Google List > Vendor List). And I also did some cleanup on how the tripple apn/mcc/mnc is treated during the process. LOS/Android keeps the settings from the apn list in userdata until you switch your carrier/sim.
When did you change to T-mobile? Just to get a timeframe for searching in my changelogs.

 

[dijama]

That sounds great thank you - I'm upgrading from a lineage'd jelly 2 and was really looking forward to having the same experience here (with security updates woo!). appreciate all your work.

Unfortunately I have the same issues with the A11 build - i 'upgrade' to the stock 11, then run everything, get to the TWRP screen about 'unmodified system partition' and i have no touchscreen input so can't proceed. kinda sucks if the newer models(?) of this phone cant be freed

 

[a-dead-trousers]

Unfortunately I have the same issues with the A11 build - i 'upgrade' to the stock 11, then run everything, get to the TWRP screen about 'unmodified system partition' and i have no touchscreen input so can't proceed. kinda sucks if the newer models(?) of this phone cant be freed

Can you please try to get me the kernel symbols from your device?
https://github.com/ADeadTrousers/tw...H.md#get-the-symbols-for-analyzing-the-kernel
Maybe the kernels are much more different than I thought and I need to modify a different part of it.

 

[SepticFuddy]

The only thing I changed on 17.1 that might be connected to this is the apn list and how it is combined.
In my opinion it was faulty prior to my change cause I treated the overwrites differently (Vendor List > Google LIst >Lineage List instead of Lineage List > Google List > Vendor List). And I also did some cleanup on how the tripple apn/mcc/mnc is treated during the process. LOS/Android keeps the settings from the apn list in userdata until you switch your carrier/sim.
When did you change to T-mobile? Just to get a timeframe for searching in my changelogs.

May 6 was the initiation of the switch. Can't guarantee I was on the latest at the time, but I will try loading that build to see if it works. Stock A11 works

Sorry it took me a while to respond. I just needed a little bit distance to all the tedious rom related work.

Thinking about this I believe it must be related to selinux because most of the time (except in recovery) when I had this issue it was due to a faulty policy. So I suppose TWRP is working which means we might be at luck here.

1) Connect your phone to your PC
2) Try to boot into LOS once
3) When the phone reboots (should be a slight flicker on the LED) press "volume up" to boot into the recovery
4) Use your PC to capture the kernel log with "adb shell cat /proc/last_kmsg > last_kmsg.txt"
5) Search the "last_kmsg.txt" for errors or panics regarding selinux, seandroid or policy loading problems.

Maybe there is some policy interference which doesn't happen on Atom XL devices (which I'm testing on) even if one uses an Atom L rom.

BTW it is ERROR: 1 when trying to install, instead of the previous ERROR: 7 in older builds.

Searching for those phrases turned up nothing. But I'm on the XL not the L, remember? Here is last_kmsg.txt anyway

EDIT: I was also having a seriously annoying, frequent system UI hangup in 17.1. Magisk was also acting weird, for example not prompting to grant root access when it should. SeedVault would instantly fail to backup. Might have been a fluke, don't know

 

[a-dead-trousers]

May 6 was the initiation of the switch. Can't guarantee I was on the latest at the time, but I will try loading that build to see if it works. Stock A11 works

So it might be related to my change as it was in the April build. Do you have the apn/mcc/mnc settings from your vendor so I can check if the entry is in one of the files I used for the combination (and is missing from the result)? Alternatively which entry is selected in Stock A11?

BTW it is ERROR: 1 when trying to install, instead of the previous ERROR: 7 in older builds.

There should be more than just ERROR 1. Anyway I thought you couldn't boot. ERROR 1 is during installation.

Searching for those phrases turned up nothing. But I'm on the XL not the L, remember? Here is last_kmsg.txt anyway

This doesn't look like it's from my latest rom as it states "permissive=1". Both system and recovery run on "enforcing" now. (Which causes other problems but let's not get into details here)
Also if it is, the output of "avc:denied" means the rules are loading just fine. So once more I'm at a loss here.

 

[SepticFuddy]

So it might be related to my change as it was in the April build. Do you have the apn/mcc/mnc settings from your vendor so I can check if the entry is in one of the files I used for the combination (and is missing from the result)? Alternatively which entry is selected in Stock A11?

T-Mobile BYOD settings

There should be more than just ERROR 1. Anyway I thought you couldn't boot. ERROR 1 is during installation.

Yes, ERROR 1 is when I try to install LOS from stock A11, before flashing to "Super ()".

This doesn't look like it's from my latest rom as it states "permissive=1". Both system and recovery run on "enforcing" now. (Which causes other problems but let's not get into details here)
Also if it is, the output of "avc:denied" means the rules are loading just fine. So once more I'm at a loss here.

It's definitely "lineage-18.1-20220715-UNOFFICIAL-Atom_XL_TEE-signed.zip", with the A11 super and recovery

 

[a-dead-trousers]

T-Mobile BYOD settings

Will look into this.

Yes, ERROR 1 is when I try to install LOS from stock A11, before flashing to "Super ()".

Aren't there any more lines in the log than just ERROR 1?

It's definitely "lineage-18.1-20220715-UNOFFICIAL-Atom_XL_TEE-signed.zip", with the A11 super and recovery

No, that's not what I meant. The last_kmsg.txt seems to be from a previous boot with an other rom.

 

[a-dead-trousers]

Tried reflashing to A10 and going to 20220327, and it won't fully boot into LOS for some reason.

For me that mostly happens when "userdata" isn't cleaned from a previous failed attempt.

Trying to reflash and install an older version, then upgrade, but I can't seem to get SPflash to actually work all the sudden... gets stuck at "Download DA 100%" and switching to UFS

Uff... hopefully this is just a hickup.

 

[SepticFuddy]

For me that mostly happens when "userdata" isn't cleaned from a previous failed attempt.

Apparently I wasn't waiting long enough for LOS setup to kick in. Don't remember that being an issue before but whatever

Uff... hopefully this is just a hickup.

Yeah I'm not sure what's going on. Eventually got it to flash, but I was having particular trouble flashing 20210508 and not 20201104... until eventually it worked. I'm afraid to update drivers though, in case it breaks completely and I have trouble downgrading.

Will look into this.

T-Mobile seems to be working correctly on 20220327 FYI

Aren't there any more lines in the log than just ERROR 1?

IIRC it was just the regular "failed to install" message after that. If you really think it will help, I can try again. Wrestling with SPFlash has been a ***** though

No, that's not what I meant. The last_kmsg.txt seems to be from a previous boot with an other rom.

That's... weird. I definitely ran the command after trying to boot after installing LOS 18.1 from A11 stock

 

[dijama]

Can you please try to get me the kernel symbols from your device?
https://github.com/ADeadTrousers/tw...H.md#get-the-symbols-for-analyzing-the-kernel
Maybe the kernels are much more different than I thought and I need to modify a different part of it.

well, im not rooted :\
it's okay, i bought a oneplus 5 and ill be tossing the atom in the box with all the other misfits lol

 

[a-dead-trousers]

well, im not rooted :\
it's okay, i bought a oneplus 5 and ill be tossing the atom in the box with all the other misfits lol

So you're not using it anymore?
Would you be so kind to help out others by utilizing this valueable source of information?

 

[a-dead-trousers]

T-Mobile BYOD settings

According to the apn list from the stock rom this should be it

  <apn carrier="T-Mobile US LTE"
       mcc="310"
       mnc="260"
       apn="fast.t-mobile.com"
       type="default,mms,supl,rcs,xcap"
       mmsc="http://mms.msg.eng.t-mobile.com/mms/wapenc"
       protocol="IPV6"
       network_type_bitmask="1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|19|20"
  />

It is also in my list as it overrides the LOS default which was:

<apn carrier="T-Mobile US LTE" mcc="310" mnc="260" apn="fast.t-mobile.com" mmsc="http://mms.msg.eng.t-mobile.com/mms/wapenc" type="default,supl,mms" protocol="IPV6" roaming_protocol="IPV4V6" mtu="1440" />

There is also another one taken from the google list:

  <apn carrier="T-Mobile GPRS"
      carrier_id = "1"
      mcc="310"
      mnc="260"
      apn="fast.t-mobile.com"
      type="default,supl,ia"
      protocol="IPV6"
      roaming_protocol="IP"
      mtu="1440"
  />

But I don't think this would work.

Can you please check which one got selected in stock and/or check if the first one is selectable in LOS?

 

[SepticFuddy]

According to the apn list from the stock rom this should be it

  <apn carrier="T-Mobile US LTE"
       mcc="310"
       mnc="260"
       apn="fast.t-mobile.com"
       type="default,mms,supl,rcs,xcap"
       mmsc="http://mms.msg.eng.t-mobile.com/mms/wapenc"
       protocol="IPV6"
       network_type_bitmask="1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|19|20"
  />

It is also in my list as it overrides the LOS default which was:

<apn carrier="T-Mobile US LTE" mcc="310" mnc="260" apn="fast.t-mobile.com" mmsc="http://mms.msg.eng.t-mobile.com/mms/wapenc" type="default,supl,mms" protocol="IPV6" roaming_protocol="IPV4V6" mtu="1440" />

There is also another one taken from the google list:

  <apn carrier="T-Mobile GPRS"
      carrier_id = "1"
      mcc="310"
      mnc="260"
      apn="fast.t-mobile.com"
      type="default,supl,ia"
      protocol="IPV6"
      roaming_protocol="IP"
      mtu="1440"
  />

But I don't think this would work.

Can you please check which one got selected in stock and/or check if the first one is selectable in LOS?

The LOS default (second one) is what is being used in 20220327, which is working. At least, that's what it looks like from inside the OS. I can't see the "MTU" value or "network type bitmask" on the access point edit screen, but "rcs" and "xcap" are missing from the "type" list, and otherwise the first two are the same.

I have no idea what the "T-Mobile GPRS" entry is for. It's always been there, never been selected, and the T-Mobile techs have never cared about it in diagnostics. "T-Mobile US LTE" is the only one of several "T-Mobile" entries they show any interest in.

 

[a-dead-trousers]

The LOS default (second one) is what is being used in 20220327, which is working. At least, that's what it looks like from inside the OS. I can't see the "MTU" value or "network type bitmask" on the access point edit screen, but "rcs" and "xcap" are missing from the "type" list, and otherwise the first two are the same.

I have no idea what the "T-Mobile GPRS" entry is for. It's always been there, never been selected, and the T-Mobile techs have never cared about it in diagnostics. "T-Mobile US LTE" is the only one of several "T-Mobile" entries they show any interest in.

Like the last time: Please test.
https://github.com/ADeadTrousers/an...03-UNOFFICIAL-Atom_XL_TEE-signed-apn_test.zip

 

[SepticFuddy]

Like the last time: Please test.
https://github.com/ADeadTrousers/an...03-UNOFFICIAL-Atom_XL_TEE-signed-apn_test.zip

One problem: how do I test if installing LOS 18 still bootloops?

 

[a-dead-trousers]

Oh, now I understand. LOS 17.1 has the issue with the "wrong" apn and LOS 18.1 isn't booting.
Sorry, but for 17.1 I cannot do a "fixing" build cause that entitles switching my build environment back and forth. This roughly takes half a day as I don't have that much free disk space to host more than three environments (LOS test, LOS release and TWRP). Also every time I did this in the past during the transition from 17.1 to 18.1 something wasn't working quite right which took me another half a day to figure out.
Your only options would be to switch to a release prior to my change (what you basically did already) or do your own build. For that I'll prepare a fix in my 17.1 branches.

For the 18.1 bootlooping I also cannot help you.
My best guess is, that there is something interfering with selinux. During my tests I pretty much "jumped" from one phone configuration to another (XL EEA <-> XL TEE <-> L TEE <-> L EEA) and never had any problems doing so.

All I did was:
1) Making sure to have flashed the stock rom with splfash (recovery from TWRP, no super and vbmeta)
2) Booting into TWRP
( 3) Booting into Booloader ) <-- Only if it isn't working from within TWRP
4) Flashing the prepared super.img
( 5) Booting into TWRP ) <-- Only if it isn't working from within TWRP
6) Install LOS-zip
7) Wipe data with "Format" Option
8) Reboot into system

 

[a-dead-trousers]

One more option for 17.1:
Prepare everything for creating a super.img but before combining it modify the "apn_conf_xml" in product.img. Hopefully this won't break the signatur and is bootable afterwards.

 

[a-dead-trousers]

@SepticFuddy
I just released the August update and during that I figured out what was amiss:
I forgot to "push" my changes from my test repo to my release repo. Therefore I successfully tested it but didn't release it in the same configuration (wrong fingerprint).

To make 100% sure I tried it with 2022-07-15 from my release page (bootlooping) and 2022-08-22 (successfully booting)
Also the "fix" for "T-Mobil US LTE" is included.

But be cautious though:
- Bluetooth seems to have a problem with the audio channel. I just found this out while trying to connect to my car radio. So I'm in the middle of figuring out the cause.
- Intercom isn't working once again since the switch to 18.1 (no sound even when using headphones)

 

[SepticFuddy]

@SepticFuddy
I just released the August update and during that I figured out what was amiss:
I forgot to "push" my changes from my test repo to my release repo. Therefore I successfully tested it but didn't release it in the same configuration (wrong fingerprint).

To make 100% sure I tried it with 2022-07-15 from my release page (bootlooping) and 2022-08-22 (successfully booting)
Also the "fix" for "T-Mobil US LTE" is included.

But be cautious though:
- Bluetooth seems to have a problem with the audio channel. I just found this out while trying to connect to my car radio. So I'm in the middle of figuring out the cause.
- Intercom isn't working once again since the switch to 18.1 (no sound even when using headphones)

Good to know. I think I'll wait on account of the BT/Intercom stuff