tdm

Yes, official Lineage builds are signed with official Lineage keys. I never bother to generate and sign my builds with private keys.

If you can get me a logcat, I can take a look. But no promises, I obviously do not share your bank... 😄 Yes I noticed this last night. Maybe I was pressing it wrong before? 😛 Cellular functionality will be interesting to see. My device has a zero MEID, so I cannot connect until I change it. I'm not sure where assistant is located. It may be in the Google app. But I'm not even sure where that is, as I never cared to delete it entirely and the gapps zip does not contain any files that look like independent packages for assistant. You can disable always-on listening.

Now that we have a working Lineage install, I think we need an issue tracker. I think the easiest thing to do is to use github since it has a built-in issue tracker for projects. https://github.com/tdm/android_device_fxtec_pro1/issues

Okay I guess I'll have to investigate that. Yes, the WiFi signal strength indicator is broken. Seems to work fine here, both in the browser and in the youtube app...?

I believe stock has some changes to the orientation settings to allow landscape in more places. But I am not quite sure exactly where or how yet, as I haven't gotten that far. As you noticed, the virtual keyboard does not pop up by default. On stock it does. I believe this is a preference setting in the device tree. You can manually activate it just as you noted, by pressing the keyboard icon in the navbar and telling it to always show the virtual keyboard. I have not tried any non-English layouts and, to be honest, I would not know how they should behave. But I ca

Okay test2 build is up at the page linked in the OP. Please note the instructions have changed. I have switched to MindTheGapps. This is a gapps package maintained by a Lineage developer and it plays nicely with A/B. Enjoy!

Got FBE working. Should have a new build tomorrow morning (about 12 to 14 hours from now).

Got some help with vbmeta so that should be solved for now. I still want to build and install the vendor partition for lineage but that's no longer top priority. Last thing before test2 is switching to FBE, if I can manage that tomorrow.

The Pro1 WiFi mac should be persistent and (fairly) unique, so long as you don't nuke that file. But it's definitely bogus.

A bit of news on MAC addrs. The OEM writes /persist/wlan_mac.bin on boot using the binary /vendor/bin/macplugin. They checked this binary into their device tree without any source, so I don't know the exact algorithm. i'm in the process of reverse engineering it. It seems to generate 02:aa:xx:xx:xx:xx where "xx" is random. The kernel driver picks this up and strips the private bit so you get 00:aa:xx:xx:xx:xx. So there you go -- each device gets a unique, random, bogus MAC address. 😄 I'll investigate BT at some point soon. I would not be surprised if that got skipped entir

The MAC addrs are read from different places depending on the wlan chipset (the wlan chip is not part of the soc proper). The qcom wlan chip which is in the pro1 by default reads its MAC addrs from /persist/wlan_mac.bin. You should have a copy of that file and it should match the MAC addr that you see in your system settings. But the BSP spits out a default wlan_mac.bin with bogus addrs by default. The OEM is responsible for changing this file at factory programming time. Nobody bothered to do this on the pro1. It is a similar story for BT. Also of note, nearly every OEM has

Yes, as I just noted, Qualcomm chooses the base kernel for its BSP on each platform. There are no closed source drivers in the kernel (but literally many hundreds of closed source user space binaries!) The reason that updating kernel versions is so difficult is simply the extensive source code changes done by Qualcomm. I tried updating kernel versions for a device about 6 years ago. It did not go well. I have not tried since. EDIT: And as for your concern about app developers and secure storage, my understanding is that encrypted storage is default and you must take action to

Because there are none. All Qualcomm devices use the kernel that Qualcomm provides in their BSP for the device. In this case, Qualcomm provides kernel 4.4.x for msm8998 on Android 9. I haven't looked at the BSP for Android 10 yet, but I suspect it is probably 4.9.x. It is possible for third parties like Lineage to update to a newer kernel version. However, given the extensive changes to the kernel sources by Qualcomm, this is a rather huge task and is very rarely done.

I'm not familiar with all the pros and cons. But I do know that you get partial functionality with FBE at boot, and the boot process is not interrupted half way through with a PIN entry screen. Given what I know about the development of the device, it's probably FDE because that is the BSP default and nobody took note and told the OEM to switch. But that's just my guess.

Oh, the one issue with switching to FBE is TWRP. If stock uses FDE and custom ROMs use FBE, there may be a need to hack something up to support both. And speaking of TWRP, if a good version doesn't appear by the time I've got a reasonably stable lineage build, I'll do that also. Which kind of sounds strange, as I'm the lineage recovery maintainer... 😛

Quick update: I found the issue with vbmeta. Unfortunately, it looks like fixing it will take another day or two. I'm going to go ahead and (try to) switch lineage to FBE for the next build so that we can ditch FDE without looking back. I also started work on plumbing in make shift mac addrs for WiFi and BT. Neither fxtec nor the OEM seem to have valid OUI blocks assigned so I'm going to steal an unassigned block. Finally, I am in the process of building a full factory package. Once that is complete, we can have a discussion about custom partitio

There are three stages in the boot process that may enter EDL. The first is in the primary boot loader (PBL), which is in true ROM. It checks a specific pad on the mother board is shorted. This requires disassembling your device to activate. The second is in the secondary boot loader (SBL), which is in UFS (eg. flashable). It checks the USB data pin is shorted. This is what an EDL cable (or copper wire trick) triggers. The third is in the "aboot" or modern equivalent, aka the "boot loader" to Android, which is of course in UFS. It checks for both volume keys

That is entirely my fault, sorry. 😞 I changed the product name to match the OEM software last week, and apparently I copied the boot image out prior to making that change. I will get a new test build out soon. Today is rather busy, so probably tomorrow.

I have never seen that before. But there is no need to wait for 10 minutes. The actual flashing process should take less than 5 seconds for the boot image. You can try different USB ports on your computer. Sometimes some ports do not work for unknown reasons. It looks like you are running Linux, so try flashing as root to ensure there are no permission issues. If nothing works, you can contact me privately and we can try to figure it out.

Well it depends what you mean. The protocols are qcom proprietary. I have the specs because I worked on this stuff at cyngn. The factory package for the Pro1 has been shared to developers by FxTec. As for EDL cables, they should not be needed unless something goes very wrong. The Pro1 boot loader enters EDL if you hold both volume keys when you power it on. And in a pinch you can McGuyver it with a small strand of copper wire and a steady hand.

It's called EDL, also sometimes called "deep flash". This is a protocol baked into the device boot ROM (real ROM -- read only memory). The factory uses this to flash the device from scratch. I have access to it.

Seamless updates are pretty much the one and only reason for A/B to exist. There is a tradeoff with data though -- you lose about 4gb of data storage. That's not insignificant. As for the find7, people tried to provide hacked up partitioning solutions. There were bound to be bricked devices. I used a find7 and loved it back in 2014, but unfortunately I never got the time to do a proper partition flash tool. I have all the tools that I need to completely rebuild and reflash the Pro1 just like the factory does. It's literally impossible to fully brick when you have these

I am surprised the A/B issue with gapps issue has gone on for so long. The Pro1 is my second A/B device (the first being 1+6t) and I'm getting rather irritated with the situation. Hopefully someone can do something to fix this soon. For my part, I think I'm going to start doing my personal builds with bundled gapps. Another thought is to just re-pave the Pro1 without A/B support. And switch from FDE to FBE while I'm at it. This would solve several issues: * No more A/B compatibility headaches. * Gain an extra ~4gb or so for data. * Allow system boot without s

It works for me. Is anyone else having issues? files.nwwn.com should have address 144.91.102.195. I switched servers in the last few days but DNS should have been updated some time ago. EDIT: reproduced the issue, investigating. EDIT: the issue seems to be IPv6. EDIT: fixed, new IPv6 address should propagate within an hour.

I am pleased to announce test builds for LineageOS 16.0. Please note this thread is for test builds. These builds are not necessarily stable or suitable for daily use. You can find the build(s) and detailed installation instructions here: Lineage on FxTec Pro1 Test Builds Please report any issues here and I will do my best to fix them. Thanks!