yashsingh1/xdaforums huggingface dataset:
[Miscellaneous Android Development] a-dead-trousers:
As TWRP is working now please check the contents in the partition "persist" (Mount and then File Explorer).

There should be two folders t6 and t6_twrp. Delete the later and clear the first of it's contents. After that you should be able to use TWRP for TEE.

If that is not working or you still getting error 1001 you may put the cart before the horse.

android_device_Unihertz_Atom_LXL/docs/HOW-TO-FLASH-SUPER.md at master · ADeadTrousers/android_device_Unihertz_Atom_LXL

Common device tree for the Unihertz Atom L and XL - ADeadTrousers/android_device_Unihertz_Atom_LXL

github.com

With this guide you can build a complete TEE super.img to flash (either via fastboot or from within TWRP) as an alternative to installing a zip archive. In a nutshell you will be doing what the installation procedure inside TWRP is doing. Then you only need to flash boot.img and you are good to boot into system. After you have setup the system with that you should be able to get TWRP running.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
To make sure that I understand correctly, I simply need to get into TWRP, delete the referenced files, and then I should be able to use the TEE stock ROM + TEE TWRP + TEE Lineage? To ask another way, is removing those files under "persist" the solution to the issues I've had with using the TEE files?
[Miscellaneous Android Development] a-dead-trousers:
Maybe.

As far as I know the files under t6 are part of the encryption and (re-)created during the first time setup. Therefore this is the only reason I can think of that TWRP won't boot. If you are unsure you can copy the contents onto a sdcard for safekeeping.

After that you should reflash the latest TEE stock rom to make sure everything is in order. Uncheck vbmeta*, super and recovery so you don't need to redo the whole unlock/flash procedure. Alternatively you can select my recover.img and super.img in spflash to use instead of the stock files if you want to cut some more corners. TWRP (or better yet trustkernel) should have no reason to not let you boot into the recovery as it has no more information of the stock rom left.

If that's not working the only option left I can offer is the creation of a super.img according to the guide from my previous post. This I had to do several times during the beginning when I had trouble to get the recovery properly up and running. I messed up the system more times than I can think of and didn't have a backup at hand. Back then I only had one device which was also my daily driver so I had to get creative in getting it back to work.
[Miscellaneous Android Development] a-dead-trousers:
Okay, now I was able to reproduce the issue with my backup/test phone.

I've setup stock L TEE and was trying to boot into twrp which didn't work.

I'll look into it more deeply.

EDIT:

TEE recovery won't boot.

EEA recovery was able to boot properly AND decrypt data.

So my guess that it is related to the encryption is not the reason. I'll try to get this tackeld down.

EDIT2:

Got it.

Somehow I used the kernel of the XL TEE not only for the XL EEA but also for the L TEE. Also the L TEE kernel cannot be properly patched to get the touchscreen to work therefore I had to use the L EEA kernel which seems to do the trick just like the XL TEE does for the XL EEA.

@it_unihertz_when_i_pee Can you please test the release 20220130 on your device and see if it is working for you too. Thanks.

In the meantime I'll also test all my other recovery releases.

Sorry for the inconvenience.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
(this was a duplicate post)
[Miscellaneous Android Development] it_unihertz_when_i_pee:
Almost there it seems. Appreciate the effort all this time.

Starting from 202105 stock, and going through the usual procedure with the 20220130 recovery, I was able to reliably get into TWRP, which is great.

However, I've tried flashing the 20220122 TEE Lineage zip with both adb sideload and SD card, but neither one actually seems to boot. In both cases I just get a bootloop until I press volume up to get back to TWRP to try again.

With sideloading, when I swipe to enable sideloading, I get "failed to mount /system_root (permission denied). The sideload command from my PC completes, with no errors, at 47%. The phone reports "script succeeded, result was [1.000...]. When I click Reboot System, the phone reports "No OS installed!"

When installing the zip from an SD card, the whole process goes without any hint of a problem. Same "script succeeded" message, but no warning after clicking Reboot. However, the phone just stays at the splash screen until it gives up and tries again or I hold volume up to get back to TWRP.

I'm going to keep trying various wipes and tweaks to the process and will report any success.

Edit: whoops, double posted, must have misclicked. Can't delete the other one apparently?
[Miscellaneous Android Development] a-dead-trousers:
I seem to have neglected the L TEE pretty bad lately: Another kernel mixup.

Fixed it with release 20220131.

Once more sorry for the inconvenience.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
Great success! The process worked exactly as expected this time around. From stock to lineage in about 10 minutes flat.

Once again, I appreciate all your time and effort with these ROMs and troubleshooting.

Now I get to figure out how to get mobile data working with my local carrier.
[Miscellaneous Android Development] a-dead-trousers:
What's your carriers name?

Normally it should work out of the box as I integrated a rather extensive apn list directly from google.

Alternatively are you able to manually enter an APN (settings > network > mobile > extended)?
[Miscellaneous Android Development] it_unihertz_when_i_pee:
Appalachian Wireless.

To clarify the issue, phone calls and texts work fine as-is. Mobile data is the only issue. So the APN isn't too far off.

There is an "Appalachian" entry in the list. I was able to use the techniques from this stackexchange post to query the list from an adb shell, and I found the following entry:

# content query --uri content://telephony/carriers --where "name='Appalachian'"
Row: 0 _id=3270, name=Appalachian, numeric=310750, mcc=310, mnc=750, carrier_id=1813, apn=VZWINTERNET, user=, server=, password=, proxy=, port=, mmsproxy=, mmsport=80, mmsc=http://mms.ekn.com, authtype=-1, type=default,mms,dun,supl, current=NULL, protocol=IPV4V6, roaming_protocol=IPV4V6, carrier_enabled=1, bearer=0, bearer_bitmask=12288, network_type_bitmask=12288, mvno_type=, mvno_match_data=, sub_id=1, profile_id=0, modem_cognitive=0, max_conns=0, wait_time=0, max_conns_time=0, mtu=0, edited=0, user_visible=1, user_editable=1, owned_by=1, apn_set_id=0, skip_464xlat=-1

However, some of this information does not align with the suggested APN information found in search results, specifically the 'apn' value. Some sites say it should be 'internet', some say 'VZWINTERNET'... I will freely admit all search results I can find are dubious, and AW doesn't publish the APN details (as far as I can find). I took a couple of tries at using the "content insert" commands to create an APN from the adb shell, with the only difference being the 'apn' value, set to a few different values. I was still able to call/text, but no data. This further leads me to think that the existing carrier setting is correct except for the 'apn' value.

No. See attached screenshot for the only two APNs that show. The 3-dot menu only has "reset to default" as an option.

I found a zipped XML file that is supposed to represent "all APNs, as known to Google" but I was not able to flash it successfully with TWRP. This is probably the wrong approach anyway, but I thought I would mention it on the list of things I had tried.
[Miscellaneous Android Development] a-dead-trousers:
The 'apn' value is just the name that is shown in the apn list and has no bearing on the functionality.

What worries me is that Applechain is in fact in the list but doesn't get selected while XFinity and StraightTalk do for some reason.

So for my understanding that means some other parameters (mmc, mns, carrier_id, ... ) which the system uses to query the list are off. Therefore the wrong entries are selected. But I don't know how the selection works in detail and which information from the sim card / network dial-in are being used.

Can you check your "all APNs, as known to Google" file if the three apns in question (applechain, xfinity, straighttalk) are on that list and if there is a difference (besides the 'apn' value) to the one on the phone? The most significant information for the apn to work should be the 'mmsc' value. Maybe this will better help you to identify the three apns on the list even if they are named differently.

Maybe togehter we can figure out why applechain is overlain by the two others.

EDIT:

Do you have another android phone at hand where mobile data is working whith applechain and you can check the apn settings that show up in the apn list from adb?
[Miscellaneous Android Development] a-dead-trousers:
@it_unihertz_when_i_pee

I found this handy solution to get the apn list manually editable:

Can't Edit APN settings? - Community

Use the settings you found earlier in the adb query.
[Miscellaneous Android Development] a-dead-trousers:
I have to withdraw this statement. In fact the 'apn' value is the most important.

Also now I think I know how the query for the correct apn settings work. Resetting the apn list on my phone to default values gives me four possible apn settings to select from. By checking my apn-conf.xml I found all four entries and they share the same 'mcc'/'mnc' value.

I did the same with 'TRACFONE.VZWENTP' and 'COMCAST.RSLR.VZWENTP' and they too share the same 'mcc'/'mnc' value (311/480). Using these values I also found three more entries but they have a few more values like "carrier_id' and I think that's the reason they don't get selected.

'Appalachian' on the other hand has seven entries with 'mcc="310"', 'mnc="750"' and 'carrier_id="1813"'.

Out of curiosity I also checked the stock apn-conf.xml from unihertz. I couldn't find anything related to 'Appalachian' or 'carrier_id="1813"'. 'mnc="750"' seems to be entirely reserved for Vodaphone. 'mcc="310"' shows up quite often so I think it's a country or region code or whatever.

@it_unihertz_when_i_pee

Was mobile data working with the stock rom? What apn settings were used?

Maybe this way we can figure out what 'mcc', 'mnc' and/or 'carrier_id' is being used by 'Appalachian' and provide an entry in apn-conf.xml (either as patch or merge request into the repo I got it from)
[Miscellaneous Android Development] it_unihertz_when_i_pee:
No, this is the only phone I have that works with this carrier. The other devices I have available are T-mobile carrier-specific old units, and TMo just don't work way out here in the woods.

My wife's iPhone is on AT&T, or else I would try checking that.

After resetting the network settings, I was able to tap on the APNs to view them, but all the settings are greyed out and uneditable. Attached are screenshots showing the information displayed to me. Interestingly, both of the APNs shown to me are mcc 311, mnc 480, not 310 and 750 respectively

With no SIM installed, I am not able to get to the mobile data settings screen at all.

Yes, mobile data worked fine on the stock ROM. I can't say what settings were used, I honestly never looked at them because it Just Worked™

I could try calling them. You would be surprised how technical reps can be at these small companies.

There's no matching entry for either of the APNs my phone is showing. Searching (case-insensitively) "comcast", "xfinity", "vzwentp", "straight", "tracphone" all return no results.

Here's a SourceForge link to where I was able to get this apns-conf.xml file.

I wish it were a simple matter of just "flash this zip file to update your APNs" and be done with it.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
Forgot to add something. in the APNs conf file I got my hands on...

mcc 311 correlates to a bunch of other carriers, probably US Cellular resellers, if I had to make a guess.

mnc 480 correlates to some other carriers, Verizon among them. Maybe a hint there?

mcc 310 has a bunch of Verizon-adjacent carriers, Appalachian among them.

mnc 750 has a small handful of instances, Appalachian among them.
[Miscellaneous Android Development] a-dead-trousers:
That sounds somewhat familiar. Have you tried to use your phone in a more populated area? Maybe you are not logged into your home network and therefore get the "roaming" options.

What do you get with

getprop gsm.sim.operator.numeric
getprop gsm.operator.numeric

The first is your contractor and the second the carrier you are currently logged into.

Also you can check these numbers on https://www.mcc-mnc.com/ (Just found the site)

But can you "add" a new entry?

On the site it was mentioned that you need to activate WiFi to get to the apn settings.

Maybe they can tell you what settings you need. It's worth a shot.

I will check this out.

Trust me, I wish the same.
[Miscellaneous Android Development] a-dead-trousers:
Most website for 'appalachian wireless apn settings' I found mentioned mcc=310 / mnc=750.

This setting is also in my apn-conf.xml for 'Appalachian' and on the mcc/mnc website (part of East Kentucky Network and operating on Verizone)

But somehow you are logged in as mcc=311 / mnc=480 which is Verizone itself (or another of their co-contractors). Which suggests you are on roaming.
[Miscellaneous Android Development] a-dead-trousers:
It's a mirror of the sample apn-full-conf.xml that is supplied with LOS and is already integrated into my rom.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
No, the only option under the 3dot menu is to reset to default.

Alright, good to know. So your ROM and stock Lineage have the same APN configuration.

I'm having an e-mail exchange with their support that has already been productive.

They were able to confirm that the APN value itself should be VZWINTERNET

I'm inquiring about the MMSC / MSC / MCC values in my latest message, just sent.

This may be due to just poor coverage here in general.

I can say for certain that using the stock ROM, I can get and use 3G/4G if I put my phone on the window sill. Doing the same while the phone is running Lineage doesn't. So QED it is something in the ROM... not your work, but Lineage in general. That's my working theory.

Given the above APN confirmation, and the fact that you're already using the same APN file I found, it may be that I am roaming here, but it should work with roaming data enabled. Always has before.

We'll see what Appalachian Wireless has to say via email. I can always call them too, if this doesn't pan out.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
getprop gsm.sim.operator.numeric = 311480

getprop gsm.operator.numeric = 31000 when my phone is placed on the window sill, and 00000 when in a location with no signal.

According to the mcc-mnc lookup, 311480 is Verizon Wireless and 311000 is... nameless.
[Miscellaneous Android Development] a-dead-trousers:
@it_unihertz_when_i_pee

Please test this release on your device.

https://github.com/ADeadTrousers/android_device_Unihertz_Atom_L_TEE/releases/tag/20220203-test

It includes a few more apn rules for Verizon directly from google (test-apns-conf_verizon.xml).

If this doesn't work I'll integrate the diff of the stock apn-conf.xml file instead.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
I'll try this tomorrow night. We're in the path of some severe weather tonight and I'd rather not take a risk of being phoneless in an emergency.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
I tried it anyway because I felt lucky.

All that TWRP said was "Error installing the zip file".
[Miscellaneous Android Development] a-dead-trousers:
I just checked the file locally and remote. It is the correct one and I was able to install it on my test phone (which had the same configuration as yours cause I haven't reset it yet) without problems.

So it must be something on your side.

Maybe an error while downloading?

How'd you try to install it?

SHA256: fbb67f65bda3b0453334fec7f3f06b6396311f6cf3473b1867ff43c2834b5a01
[Miscellaneous Android Development] it_unihertz_when_i_pee:
Apparently my SD card ADAPTER is not to be trusted (!) and biffed the file transfer. Anyway, I used a proper tool (rsync), verified the checksum, and afterwards it flashed just fine. So, errors on my part.

Anyway, after going into the APN settings and resetting it to defaults, I get a lot more options to choose from (screenshots attached). None of them seem to allow data service though, even the ones that say VZWINTERNET.

For a few of the entries, the APN field is editable, but I didn't try changing any of those to something else.
[Miscellaneous Android Development] a-dead-trousers:
New test release including entries from stock apns-conf.xml:

https://github.com/ADeadTrousers/android_device_Unihertz_Atom_L_TEE/releases/tag/20220205-test
[Miscellaneous Android Development] it_unihertz_when_i_pee:
Still no luck on this. Quite puzzled. Maybe the APN business is a red herring? I can't think of what else it would be, though.

For the record I went into town this weekend where I had strong signal, and tried choosing one of the APNs explicitly, with no change.

If I hadn't already invested the time and effort to get the user space "set up" since getting Lineage installed, I'd have already stock flashed it and done more digging there. Might come down to that anyway.
[Miscellaneous Android Development] a-dead-trousers:
In the beginning I had to activate "Roaming" to be able to get LTE working. Before doing that I made sure that I manually selected my "home" network to NOT run into any "financial" problems. Maybe this would help.

So that doesn't help. Good to know.

The entry which most likely should work is "LTE - Verizon Internet".

You can always create a backup from within TWRP.

Maybe you can use another android device instead and check which settings it uses. Also check the two properties with a terminal app to make sure it uses 311/480 and nothing else. Then you could try to extract apns-conf.xml or if not possible send me the phone name and I try to get my hands on the rom to extract the apns-conf.xml myself.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
Got ambitious tonight and re-flashed the stock image.

getprop gsm.sim.operator.numeric gave 310756

getprop gsm.operator.numeric gave 31000

The phone connected to VZWINTERNET right away. The APN is photographed and attached. I included a picture of the data use to show that it was able to download some files with no problem.

Edit: the images posted out of order. Sorry.
[Miscellaneous Android Development] a-dead-trousers:
This is strange... why is the operator on the sim recognized completly different? This should be a value that's taken directly from the sim itself. It seems I need to do more research.
[Miscellaneous Android Development] a-dead-trousers:
It looks like there's no easy solution:

Carrier configuration | Android Open Source Project

source.android.com

This looks odly familiar to the things PeterCxy did with ims in his old build I based mine on.

I think ims seems not to be working at all in my builds therefore the correct settings cannot be supplied to the system.

Sadly even if I tried to implement something myself I don't have a contract to properly test VoLTE and everything connected with it.

Sorry.
[Miscellaneous Android Development] it_unihertz_when_i_pee:
Wonder if I'm out of luck with Lineage entirely on this carrier, regardless of phone. I'd considered getting something with mainstream Lineage support (a Pixel most likely) for compatibility reasons, but now I fear that would be a waste of money.

I don't fully understand what this documentation means, but it sounds as if it is a problem at the AOSP level. If this is the case, I might as well suck it up and just use the stock ROM on the phone I already own.
[Miscellaneous Android Development] a-dead-trousers:
The Pixel has good community support. Also the kernel is opensource which helps a lot. The Unihertz devices (along with all mediatek devices I guess) have more of an "enthusiastic" support. I do this entierly in my free time.

I think as Verizon is not such a small company that it will work on the Pixel.

It's about a change in the approach of serving the required settings of the telephony subsystem to the system(-apps). It started in Android 6 and seems to have gain broad acceptance around A8 or A9. The apns-conf.xml is prior to that and only serves as a fallback.

If I understand this correctly the sim card (of Verizon at least) seems to have signature to it that forces the system to use the new approach and the fallback to mcc/mnc seems to be not compatible.

The next logical approach for me would be to consume all my holiday leave, buy a plane ticket, travel to your (remote) area, get a Verizon contract and start debugging the device. Or find someone who is capable to do that. ;)
[Miscellaneous Android Development] it_unihertz_when_i_pee:
And I'm quite grateful. Thank you for all of your time and effort.

I think I'm going to look into other carriers. Lineage had mobile data on T-Mo previously, and given that I can physically see Verizon broadcasting here, that might be an option as well.
[Miscellaneous Android Development] SepticFuddy:
For the record, I'm in a very remote area as well (NW Montana), and Voice+SMS/MMS hasn't worked for me at all on my tower since September or so, and wasn't totally reliable before then. LTE works fine. Can't place any Wi-Fi calls because they require SOME sort of network connection to initiate. Same was true last time I checked for my rooted stock Atom though. When I go in to town (about 22mi away), everything works fine all over the valley (though I often have to disable/enable service first.) The T-Mobile store tells me this is a very unusual area regarding the tower situation, and I have gotten word from their engineers that they know my tower is having issues and they are "working on it" (which they've been saying for at least a year when I moved out here). It's hard for me to tell exactly if they've ditched support for our voice frequencies entirely as part of a 5G upgrade or if it actually is a malfunction on their part, because dealing with them has been excruciating. The two landlords I've had here don't seem to have any calling issues though. One is on AT&T I think and the other I don't know.

What has worked for me is using a FreedomPop VOIP SIM (haven't tried the newer "Premium" one) in the Atom since LTE signal is solid. Unfortunately, I couldn't get their app (which handles voice/SMS) to run on the XL with LOS and microG. It gets stuck during initializing trying to register for push notifications, and none of the protections I could think of to disable fixed that problem (maybe somebody has a tip on that?). So for now I just have a spare number on the Atom for non-Signal calling from home. (see later message)

Just figured I'd mention that in case you find any of it relevant.
[Miscellaneous Android Development] a-dead-trousers:
Aren't push notifications part of the google play store (environment)?

I think you need at least the micro gapps for that to work.
[Miscellaneous Android Development] SepticFuddy:
microG is supposed to be able to handle them, but maybe signing into a Google account is required? I've never quite understood exactly how they work, and none of the other apps I've used have ever had any notification problems, so maybe they're all just using local notifications? Not really sure how to find out

So I did a bit more digging and noticed I overlooked enabling Cloud Messaging in microG, which requires device registration but not signing into a Google account. The FreedomPop VOIP app seems to be working fine now, even if it's not as nice as ideal as being able to use the native apps (mainly because I can't use Signal for SMS this way but oh well)