claude0001

I get best results when using a Raspberry Pi3 for flashing the Pro1. I had lots of trouble using my normal PCs as well, even though some of them are old pure-USB-2.0 systems. The RPi has a 100% success record up to now. The cable then does not seem to matter much: I have successfully used, both, the official one and some random spare I had lying around. If you have a Raspberry at hand anyway (), just give it a try. The needed Android tools are just an "apt install adb fastboot" away. Edit: Note that the fact that my RPi is version 3 may be important. The Pi3 is the latest versi

In principle, yes. Note, however, that some hardware components are likely to never be supported by open-source drivers within the realistic lifetime of the Pro1. For orientation: The Nokia N900, a relatively popular hacker's phone from 2009 (!), still has only 80-90% of its hardware supported by the mainline Kernel (personal estimate). And that's despite the fact that it originally shipped with an OS that was quite "open" compared to today's Android ...

Well, not quite (as we discussed above). With Lineage you get the Android framework fixes from the AOSP security bulletins, but no patches to the Linux kernel or the binary driver blobs, as these are supposed to be implemented and distributed by the SoC manufacturer. That's what LineageOS calls the "vendor security patch level". As you confirmed yourself, that one is stuck at 04/2020 in LineageOS, too. It must be, as the binary bits are taken directly from Stock.

OK, thanks. I was unsure because, according to this thread, Stock received further updates at least until August last year ... So I get none of these actually included any fixes to the vendor bits. We'll probably have to accept that, I guess ... 😞 Sorry if I am asking obvious things. I was never on Stock, either, so I'm a little disconnected from its development.

Could anyone running the latest Stock look up what its "vendor security patch level" is? I am wondering why my self-built LineageOS (with Android patches from May 2021) indicates a vendor security patch level of "5 April 2020", although I extracted the vendor blobs from a much more recent (Lineage) release. Of course, if even Stock was stuck at that date, this would explain things ... thanks in advance!

Can't wait for Maemo Leste to take over the World. 😉

That must have been the key to success. 🙂 Congrats and thanks for posting these detailed instructions.

So, just one last update on that slightly off-topic discussion from few weeks ago: Following @Sean McCreary's suggestions, I was indeed able to build an up-to-date (unofficial) LOS 16.0. It is really not that difficult - my very first build went through smoothly and relatively quickly (~ 12 h overall), even though the ressources I had assigned to my virtual building machine were not even remotely close to the recommended values (i3-U, 3 cores, 6 GB RAM, 300 GB hdd). I'm now on Android patchlevel 05-05-2021, which does feel better, indeed. Thanks to @Sean McCreary's hint about ke

As the discussion was about shared data storage I can only imagine that a file browser was meant. Running a web browser as root would make no sense to me either.

I honestly cannot give a qualified answer, but I will try. Hopefully someone with more knowledge of Android will correct me and I will learn in the process: On Android, every app runs under a separate UID. This is to ensure any specific app cannot access files written by any other app unless that other app explicitly grants system-wide access. In a world where you expect every program on your device to spy on your data, this is supposed to enhance security. Effectively, this alone makes something like a file browser impossible: on Android, these have access only to files that belong to t

Android uses a very complex scheme of virtual mount points that, in combination with SELinux, restrict access to partitions beyond what one would expect from rights management on the filesystem level. I honestly do not understand them but I have run into those security systems multiple times in the context of running my GNU/Linux chroot aside of LineageOS. I can well imagine that also in the case under discussion here, rooting is the only way for Android Apps to access file systems touched by both OS's.

I feel like I do not care enough about LineageOS to do that work. I'll keep camping on my rooted LOS 16 for the foreseeable future anyway. Should I ever need to reinstall my system, I'll probably try to switch to SFOS (or UT if that has matured by then), as, honestly, I'm getting a bit tired of Android ... Sorry.

Sorry, I won't. As I wrote several times in this thread, I believe that having AGPS disabled is actually a sane default. Some might choose LineageOS specifically for privacy reasons, so I think it is better to have AGPS as an opt-in feature, even if that means one needs to root-edit the system config. Of course, best would be having the option user-configurable in the phone settings, but I do not know if that is (easily) possible. That said, @marmistrz intended to submit a patch (to LOS 18.1, I think). Do not know if it happened.

I am pretty sure many Lineage ports have AGPS disabled. As I wrote above, that default setting makes sense, considering that some users might choose LineageOS specifically for privacy reasons. Of course, the option to opt-in to AGPS from the GUI without requiring root access to the system config would be great. However, I suspect that, if it was all that easy to implement, that feature would be available already.

From what I read I thought this should be possible, but in lack of experience I wasn't sure. Many thanks for clarifiying this, as well as the problem of the signing keys when overwriting an official image by a self-built one. If I had a spare Pro1 as testing device, I would probably try to bake my own LOS 16 immediately. Unfortunately, I have only the one I use as my daily phone, and there is a realistic chance I will f**k things up at the first few attempts. So I still hesitate ...

That is a very good point, indeed. With PCs, "compatibilty" (with the IBM XT/AT) was seen as an advantage. With phones, we obviously must have taken a wrong turn somewhere ... The good news is that a World of incompatible devices could prevent SkyNet from spreading all too easily. 😉

That is why we eventually need mainline Linux support. And truly open-source phone operating systems. 🙂 I am typing this post using a fully-updated Linux OS running on a 12-year old PC (Thinkpad T400). If the hardware endures, nothing will prevent me from installing the most recent Debian distribution on it for ages to come. Remember: the most recent Linux kernel can run happily on an i386 with 32 MB of RAM ... That is where we want to go with phones, too! I am of course half-joking here: You are completely right that money its made (in obscene amounts) from planned obsolescence. The

Most threats can be avoided by installing only trusted (if possible open-source) software on the device. This includes an up-to-date web browser. No one is forced to use the default browser shipping with the OS. Of course, having AOSP security fixes would be nice, and we would readily apply them if we could have them without the functional regressions related to upgrading to a higher Android version.

I do not understand this point. Actually, the Pro1-X SoC still has a long support life ahead. After all, that was the reason for the switch. With its longer EoL, the 662 Pro1-X may also eventually have better software support: I doubt that newer Android versions will ever appear for the original Pro1. Ubuntu development is probably focusing on the Pro1-X right now. In the long run, the 662 may also have better chances regarding mainline Linux support than the de-facto obsolete 835-Pro1 ... Finally, the redesign of the mainboard may be a chance for FxTec to fix a few quirks of the ori

I thought I was pretty focused on setting up my phone the way I wanted. But I can only bow to such determination in the quest. 😄 Sorry it did not work out for you. But thanks a lot for sharing your experience with twrp with those who will follow you. I'll keep using my third-party QR scanning App on Lineage 16 because ... I am a coward. Respect. (I'm not joking!)

OK, look guys, my post was a reaction to @daniel.schaaaf, who I think is fundamentally right in his criticism of some aspects of today's open-source software culture. I tried to provide some examples how us so-called "power users" are simply more affected by major OS upgrades, and are hence left in the rain if Lineage versions are abandoned at every second stop. True. But neither can we change FxTec ways of public communication, IGG policies, or EOLs of QualComm product lines (to name but a few). Did that stop anyone from whining and complaining here? Now it is my turn. 😉 Self-bu

That is not true. As I wrote, I had LOS 16 from the point it became official and applied every update until support was dropped. None of the weekly OTA's broke anything related to the chroot set-up. AOSP security fixes do not change system behaviour on that level. Major upgrades, on the other hand, do. That's why they are called major, need to be well prepared, and, therefore, should not be necessary very often. Yes, you can still build LineageOS 16 and 17.1 yourself for the Pro1, which should merge-in the upstream fixes automatically. Retrospectively, I should have learned how to

Why not? No OTA update of LineageOS 16 (and I did apply all of them) ever broke that set-up. Why should it? After all, what I do there is not black magic. I make use of system interfaces that are, explicitly or implicitly, defined to behave in a certain way. As long as the Kernel, Android features, or root management did not change, I could be fairly certain no upstream security fix would break anything. I had simply expected LOS 16 to continue to receive security patches as long as upstream Android 9 does. That it didn't is disappointing and, yes, unprofessional. As you confirm

I could not agree more. What you describe is the reason I am staying on LOS 16. I have plenty of hacks in place, where I cannot predict whether they would still work on LOS 18.1 (or 17.1, for what matters). I use several autostart scripts in /data/local/userinit.d/ for setting up stuff on boot automatically. Those scripts are officially unsupported already in LOS 16, but can be made to work using some third-party apps. Will those still work with LOS 18.1? Obviously, all of those autorun scripts require root access. Will those early-executed shell scripts work with (third-party) Mag

So I get the setting improved things on your phone too? I now somehow regret not to have stressed the follwing from the beginning: Fully enabling AGPS (which I believe these settings do) enhances the functionality of GPS at the cost of privacy! There are valid arguments for having AGPS disabled by default in LineageOS and leaving it to the individual user to opt-in. See e.g. https://forum.xda-developers.com/t/keep-a-gps-supl-disabled-upon-rom-install.3612024/ However, I am not in charge. Go ahead with submitting a patch if you feel you must. 🙂