Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

153 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. If you really want an un-Googled version of stock, I can build that since I do have access to the sources. But personally, I highly recommend Lineage instead. It has some nice features that stock does not. You should file an issue for calls on my github. You can file the lock pattern issue with Lineage, as I dont have anything to do with that. Lineage recovery should be able to flash the su package. If not, please let me know. I could build su into the ROM, but that would upset others. FxTec has been very engaged and helpful with development. I appreciate that a great deal. On the technical side, the smaller OEMs (up to the size of, say, OnePlus) stick very close to the QCOM reference design so they are easier to deal with than devices from the big OEMs like Samsung etc. As for sources, I have access to most of the OEM BSP. But even the OEM gets several hundred closed source prebuilt binaries.
  2. Thank you so much for the consideration. I won't take donations for this project myself but please do donate to Lineage, the EFF, or your favorite open source project.
  3. So I have spent most of the day today trying to get TWRP to decrypt FBE. It has been quite an adventure, as my only prior experience with TWRP decrypt has been FDE on Android 7.0 which is quite simple to support. FBE on Android 9.0 requires a lot of infrastructure that I had not known about. I'm not done yet. Hope to have it working in the next couple of days. I'm also preparing an EDL package for user consumption. This will allow anyone to un-brick their device and restore the stock factory image no matter how badly they damage the software. But don't go erasing your entire device flash for fun... (1) damaging the xbl partition requires dissasembling the device to enter EDL and (2) damaging the fsc partition will kill your IMEI and possibly some other critical radio settings.
  4. Yes, official Lineage builds are signed with official Lineage keys. I never bother to generate and sign my builds with private keys.
  5. 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. I always do this at the setup screen, as I definitely do not want Google recording everything it hears. I know from experience with a previous device that when you disable always-on listening it actually does get disabled.
  6. 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
  7. 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...?
  8. 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 can certainly investigate. When setup is done, does the physical keyboard work as expected? Oh, and I have also noticed the physical keyboard does not seem to react to special modifier keys (the yellow diagonal arrows). So certain characters may not be possible to input. I think the forward slash on the P key is one of them. I'll need to figure that out soon. My top priority right now is getting the figerprint reader to stop forgetting data on reboot. Keyboard may be next if no other major issues appear.
  9. 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!
  10. Got FBE working. Should have a new build tomorrow morning (about 12 to 14 hours from now).
  11. 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.
  12. The Pro1 WiFi mac should be persistent and (fairly) unique, so long as you don't nuke that file. But it's definitely bogus.
  13. 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 entirely.
  14. 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 their own unique and different way of reading the wlan MAC addrs. Nobody actually uses /persist/wlan_mac.bin because that would be too simple and logical. 😄 For example, OnePlus uses an NVRAM item. ZTE used /persist/wifimac.dat on the axon7. And so on. While theoretically possible, it won't happen. Qcom has too much invested to do this themselves. And keep in mind that Google ships phones with Qcom chips and would surely detect something like this, even if nobody else did. Not to feed the tinfoil hat crowd, but it would be much more covert to place spyware in the modem side of things which is entirely closed source. Either in the modem code proper or the user space blobs that drive it. There are several hundreds of megabytes of closed source user space blobs in modern platforms which have direct access to things like the modem, trustzone, etc. That is a nice thought. Unfortunately, it is not true once the kernel leaves kernel.org. Qcom breaks their own kernel-user ABI with nearly every release. But that isn't really relevant to upgrading the kernel version. You pull in the relevant qcom and oem bits on top of the new kernel version so that whatever ABI existed in the OEM kernel also exists in the new kernel. The problem is making the qcom bits build and run with the new kernel version. EDIT: I may have misread what you meant. Yes, the core kernel ABI does stay the same so that the basic syscalls will still work with the new kernel version. So in that sense you are correct. The real fun comes in taking the closed-source userspace binaries and making them run on a newer Android version, which is something that Lineage does regularly with older devices. Google has, on many occasions, broken their ABIs for things like libstdc++ and other common utility libraries. The Lineage folks then need to figure out how to make the closed source binaries work again, or steal updated binaries from devices that have been updated to the new Android version. Yes, Qcom releases kernel sources. GPLv2, of course, not GPLv3. The pro1 uses this tree: https://source.codeaurora.org/quic/la/kernel/msm-4.4/ idealte made remarkably few changes compared to other OEMs that I've seen. Just the stuff required for the device to run, really.
  15. 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 use unencrypted storage. But I have not developed apps in quite some time, so I don't know the exact details off the top of my head.
  • Create New...

Important Information