tdm

Because it's likely going to require real time communication in order to not stretch into weeks, and I doubt there is anything at the end user level to learn from this. I'm offering to do this for two reasons: I'm genuinely curious what is wrong with this device, and I don't feel it's right to make other people pay for your mistakes.

I don't recall anyone mentioning when or whether stock will be upgraded to Q. Has anyone official chimed in on this? Lineage is getting close to releasing Q (which will be 17.1). By the time that happens, I should have Lineage running well and updating should hopefully be pretty easy.

I avoid magisk like the plague but my first guess is bind-mounting the fstab file with a copy that removes the encryption parameters from the userdata partition.

It is relatively well known that all you do is remove /data/system/locksettings.* to remove the lock screen. This can be done very easily in TWRP with the file browser. But if your data is unencrypted, why bother? Just suck the data out directly. Yes, Android will force encryption on first boot. How it does that depends on FDE or FBE. With FDE (stock), it will encrypt in-place and then reboot. With FBE (Lineage), it will just encrypt files as per usual. Now, if you have files that are unencrypted under FBE, I don't know exactly how that would be handled. It may just continu

Nope there are no problems with encryption disabled. It just leaves your data open to anyone with access to your device. I always used to run unencrypted because entering a pin to unlock the device was a pain. But with the advent of fingerprint readers, this is mostly mitigated. Just so you know, if your data is not encrypted, it is trivial to boot into recovery and remove the screen lock. I haven't actually used an external sdcard in some time. But generally speaking, my sensitive data isn't there anyway. The stuff that's sensitive is usernames and passwords to va

Alright, so I got gnss fixed. I just did a fresh build and wipe and .... it boots. Unfortunately there are some broken things that need to be fixed before I can do another release (namely wifi and cell radio). But now that I've gotten it to boot, it should be all downhill from here. So I'll work on those and hopefully will have a working build within a few days. After that the bugs should fall quickly and official support won't be far off.

You ... don't have encrypted data. 🙂 You may not care about it now, but if your device is lost or stolen it's nice to know that your data is (relatively) secure. I'm sure that if someone with a lot of resources was after you, they could hack into your data. But for most of us, encrypted data is "secure enough".

My understanding is that microG requires a framework hack to work. I did not add that. Additionally, modifying /system to add the microG files will break verity so that would also need to be disabled. There may be more issues but those are the ones that come immediately to mind.

@EvilDragon nice to see you're actually here on the forums. That is a huge stroke of luck! I'll be happy to work with you on getting the device back to a working state, but we should probably take this to another place. Feel free to reach out to me in email tdm.code at gmail dot com. In answer to some of your other questions, no, the tool does not do a read-back-verify. But it's always been reliable for me. If the flash process takes several minutes and succeeds, it is surely working as intended. So the problem is most likely (1) something that is not fl

Yup, absolutely. As soon as I can get a vendor image built and working. I've just now gotten Lineage to boot with a custom built vendor image plus one remaining hack (copying the gnss blobs from stock). I'll try to clean that up and get it going today. And hey what do you know... with the custom vendor image, a2dp actually works. 😄 😄 😄

Apparently no other device builds FMRadio nowdays. I have a local patch to make it build, but I'm holding off on submitting until I can get it to actually work. As for the doze apk, I don't know. The current trees are heavily copy/pasted from dumpling (1+5t) so they should work. I'll be cleaning things up soon (again, after things actually work).

Don't disable encryption. I'll get a TWRP that does decryption soon after I get Lineage in a usable state. But really you should have no need to decrypt data anyway.

Thank you but I don't think that will help. The APN should only affect data. I think there is something else going on with my voice service.

I imagine that it will probably be within a week or two. I'm quite disappointed that I cannot get voice service (yet?) but that should not stop official support if the issue is my device.

Got to tier2 support with my carrier and they verified that voice should work. They focused on the "mobile network / preferred network type" setting to try fixing it. But we couldn't get it working. I'll keep trying. I don't suppose anyone here uses AT&T USA with the Pro1 and wants to share their network type setting?

Thanks but been there, done that, didn't work. I'll probably be calling them today.

It's Pure Talk USA, an AT&T MVNO.

So just a quick update regarding Secure Boot. I had considered posting a new thread about this but I'm not sure it's warranted. So I'll just drop this here... I spoke with FxTec and they confirmed that they disabled Secure Boot intentionally. The rationale was that it makes the device more developer friendly, especially for non-Android OS's. I'm not sure I agree with this conclusion, but that is/was the decision. The one thing that disabling Secure Boot allows is building a custom abl (boot loader). I have yet to see anything that requires a custom abl. But it does leave the

So I've spent the better part of a day trying to figure out what's wrong with voice calls. I can't see anything wrong. I've got reports from several people that voice calls work fine on Lineage. The one person that reported an issue on github says that it doesn't work on either stock or Lineage, so that's not a Lineage specific issue. My experience is that I can get SMS and data, but no voice calls, both on Lineage and on stock. I have to assume this has something to do with my carrier and the IMEI, because there really isn't anything else that I can see that would

Reproduced here, thanks for the report.

So I've been thinking about this custom key that AVB allows, and I've also read a bit of the source for abl where it's implemented. I've come to the conclusion that AVB is worthless at best and dangerously misleading at worst on devices that have Secure Boot (*) disabled, and the Pro1 is such a device by design. Let me explain... The security that AVB intends to provide is to ensure that you are running code that has been signed, either by your OEM or by your custom ROM vendor that does AVB signing (Copperhead, Graphene, etc.) Note that it does not ensure the integrity of your d

In this case, I would take "firmware" to mean everything closed source. Particularly the abl partition and the vendor bits for hardware support which occasionally have security issues. The official Lineage policy for device maintainers is to assert on the latest firmware version from the OEM (eg. fail to install if it is out of date). Some maintainers are better than others at following through on this. Here's an example of how this is supposed to work. I have been using OnePlus devices for the last year or so. Every time they release a new firmware, the maintainer

That's entirely up to how often I get bsp updates. IdeaLTE gives updates to FxTec on request and they are passed along. So I can't just grab the latest code on demand. Yes you can upgrade without data loss. Generally you should always be able to update the same ROM without loss. You only need to wipe when switching ROMs.

Well, this looks promising... tommy@neuron:~$ echo x > foo tommy@neuron:~$ fastboot flash avb_custom_key foo target reported max download size of 536870912 bytes sending 'avb_custom_key' (0 KB)... OKAY [ 0.009s] writing 'avb_custom_key'... OKAY [ 0.003s] finished. total time: 0.011s tommy@neuron:~$ fastboot erase avb_custom_key erasing 'avb_custom_key'... OKAY [ 0.003s] finished. total time: 0.003s tommy@neuron:~$

Well, what do you know ... the qcom bootloader in the bsp does reference avb_custom_key. I'll have to dig more to see if it's actually enabled and usable. Thanks!