tdm

Found the issue with the fingerprint reader. The hardware and Android keep separate lists of registered fingerprints. When you wipe data, Android list is cleared but the hardware list is not. Eventually the hardware has all 5 slots filled and won't accept any more. So the new data only exists in memory and fails to write to persistent storage. I'll investigate more to see how this is supposed to work, and I should have a fix soon. In the meantime you can delete the fingerprint files under /persist to fix it.

Nope, not yet. That will come soon.

test3 is up on my server. I haven't fixed FM radio or the fingerprint reboot issue yet, but I'm tossing this out because it's been way too long since any updates.

I have not tested this, but it is plausible.

That should not be possible. Perhaps the boot loader lock is disabled or ignored.

That will be up to you to decide. If you are hesitant, wait for a few days after I release test3 tomorrow and see what others say. But I believe it will be mostly on par with stock except for the FM radio.

I don't see why not, but I'm curious why you want userdebug?

Sorry I don't actually know what's going on with Verizon or VoLTE. I use AT&T and old fashioned GSM voice. But after things are stable in a few days, I can start investigating VoLTE.

That screen is the adups updater. The OEM tossed the adups files into the build as binary blobs (not source code), so I doubt they have access to fix it. Personally I'm less annoyed by the spelling and grammar than the fact that you cannot get out of setup without agreeing.

Yes this has everything from the stock build. It is user/release same as stock, not userdebug. That may work, feel free to give it a shot and report back. See my factory restore thread. Start with the device off, hold both volume buttons, press power for about 3 seconds. The device should be in EDL mode.

I think I'm now back where the original test2 build was: - Cell radio works same as before (still can't make voice calls). - Notification light works. I still need to review and cleanup the code though. - Front camera works (I was missing some camera libs). Additionally: - I've added the keyboard layout file to the vendor partition and that seems to work. I'll try to fix the FM radio and the fingerprint issue today. Both of those may be more involved. In any case, I'll have a test3 tomorrow at the latest.

I worked with @EvilDragon today and we were able to revive the device. The xbl_a partition was corrupted. This should have been written with the factory tool, so I need to investigate why it did not get written properly.

Hmm, there should be one. I'll take a look after Lineage is stable.

On-device audio and nfc now work. I'm out of time for the day, so I'll try to get this wrapped up tomorrow. Remaining "big" items blocking test3: - test/fix cell radio (should be working or require minor tweaks). - fix front camera (it's not recognized, probably a missing file). - fix notification light. - fix FM radio. - figure out why the fingerprint sensor loses its data at reboot (at least for me). - add keyboard layout file.

Okay it looks like Bluetooth, WiFi, GPS, and Fingerprint work. Still need to test/fix cell radio, on-device audio, and NFC. Note the WiFi signal strength indicator is still broken. That's going to be toward the end of the to-do list.

Progress! After waaaaaaaay too long, I've finally fixed the wlan subsystem restart. Turns out the open source power HAL isn't working properly. The vendor power HAL works. So I'll use the vendor one for now and continue on with all the other stuff.

WiFi is starting now but it's crashing the device. I've been trying to figure that out. Shouldn't be long.

I haven't really investigated keyboard things yet. I've been busy getting the vendor image working in order to fix a2dp. But I know that idealte put the keyboard config files in system instead of vendor, which is why its broken. I'll put them in my lineage vendor once it's working. As for other locales, I haven't tried at all yet.

I've not seen a thorough discussion on the subject, even on internal lineage slack. With several hundred people making up lineage, there are undoubtedly people who want it and people that don't. The major reason it's been dropped is that the security changes in Q make it even more difficult to support. Since it's not really a core feature it will get done last. And if it turns out to be really difficult or intrusive, it may just get dropped. At least until someone with the motivation and ability comes along.

Indeed, sad but true. It's currently not working in 17. I'm hoping they will figure that out. And if they don't, me or someone else likely will.

Good catch thanks. Obviously I started with a lineage tree that had built other devices which pulled in these dependencies previously. I'll make a note to fix that.

Yes this is true. The actual encryption key is not accessible. There are valid(ish) reasons for this. If that is not acceptable to you, feel free to change your fstab and run unencrypted. I won't do it and I won't support it. IMO the benefits far outweigh the lack of knowing the actual key. If the hardware fails to the point that you cannot decrypt using the Android scheme, how do you expect to extract unencrypted data? And don't say backups, because backups can be made in both cases (TWRP will happily decrypt and backup).

The device tree and kernel tree will be imported into Lineage github for official support. Any changes needed for this particular device in the other Lineage code will need submitted and approved by the Lineage team. I don't have any of these changes yet, and may or may not eventually need them. The device becomes official when I tell the Lineage team that it's ready and request that they import the code. I also need to add a Lineage wiki page and etc. The device will continue to receive builds add long as at least one person is maintaining it. (There are at least 3 peo

By its nature, it hijacks basic system functions and hides/overrides things. That's bad in my book. Same as xposed. After 7 years of working with Android ROM development, I've seen the trouble these types of things can cause. And since they usually work fine, the device maintainer (me) gets blamed when they break in odd ways. Lineage (and previously CyanogenMod) bug forums are littered with crashes caused by these things. So the first thing the alert developer does is look for evidence of these tools and reject the bug report if found. So basically, they cause much pain

Lineage has an su addon package. AOKP (which I love and always use) has su builtin. But most of the time, I keep su disabled and use "adb root" from my PC if I need to tinker with things.