claude0001

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. 🙂

I think some things regarding AGPS are left blank on purpose in LineageOS, as using such services potentially reveals your location to the server operators, which may be seen as a privacy issue. Even disregarding this, from what I read on the internet, the optimum settings depend on what region of the world you are in. So maybe there is no one-size-fits-all config anyway. I found this config on some German Android user-forum and did not really check if it is truly optimal. The new settings certainly helped (a lot) in my case, but you may find even better ones for Poland by experiment

In LineageOS 16 I could vastly improve the locking speed by the following edits in /system/vendor/etc/gps.conf: [...] XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin [...] XTRA_VERSION_CHECK=1 [...] NTP_SERVER=europe.pool.ntp.org [...] INTERMEDIATE_POS=1 [..] SUPL_HOST=supl.vodafone.com SUPL_PORT=7275 [...] I am also in Europe (Germany) and at times could not get a fix at all (even after waiting for hours) with the default settings of LineageOS 16. Since I made that edit, GPS fixes a

Yes, I believe you. Let's not go over this again. 🙂 GCam is not compatible with a Google-free LineageOS, and certainly even less with SailfishOS and UbuntuTouch. It is simply not an option for many people, plus, it does not support the shutter button which was supposed to be one of the outstanding features of the Pro1. The camera should make good pictures reliably, irrespective of the backend software used. But, sadly, it doesn't.

Well, honestly, the crappiness ... ahem ... loveable peculiarities of the Pro1's camera got me back to carrying my DSLR along more often, too ... 🤔

I agree that the Pro1 is bulky compared to other modern phones. But to be fair one must also say that the big size helps in all kinds of business use-cases (which are a main selling point of the phone): When coding, emailing or word processing, the huge screen allows to display a lot of content at acceptable font sizes, which certainly increases productivity. Also, as @lawliett already mentioned, running desktop Linux apps in a chroot is much more pleasant with a big display. As much as I loved my N900, I certainly do not miss its tiny screen. 🙂

I did not think that was the problem here. If LineageOS 16 and 17.1 still had the Pro1 as build target in their config, the build system would continue to spit out new builds every week. In that process, upstream patches like AOSP security fixes (which are not device-specific) would be included automatically and not require any manual intervention by a device maintainer. At least this is how I understood things work. Someone with more knowledge about the LineageOS build process may correct me. I thought the problem here was simply to save resources on the build farm by allowing

Let me try to rephrase that in a more optimistic way: They are very enthusiastic about porting the latest-and-greatest release to the Pro1. 🙂 The real problem is that, as soon as a new release (here 18.1) is declared "official", the previous one (17.1) stops receiving upstream patches. De-facto, releases are dropped from support at the very moment they have matured ... Effectively, users have only this choice: Either stay on an older, stable, and nicely de-bugged LOS port that does however no longer receive upstream AOSP fixes. Or change horses every few months b

If you just want to run a few Linux programs, something like Termux and AnLinux is definitely the easiest way to start. I have never used those Apps, though, so I cannot help with specific questions about them. For advanced stuff, like the above, a "hand-made" chroot (with root access to Android/Lineage) will probably always be superior to (non-root) in-App solutions. Setting up your own Linux chroot on Android is actually not that hard provided you have some experience with Linux. The real problem is that the required information is scattered all over the internet. Also, some things

As I wrote above, 17.1 no longer has the Pro1 as build target, so there will be no more (official) updates for it. See https://www.lineageoslog.com/17.1/pro1 ... and that is exactly why the older, stable versions should keep building, at least on monthly basis so they keep receiving the upstream security fixes in AOSP. Every upgrade that changes APIs or other major parts of an OS is potentially disruptive for the already-installed base. That is why professional distributions keep their "stable" branches alive as long as upstream fixes can be picked-up with reasonable effort.

Looking at your picture, I notice that the lower right corner is actually sharp: that wall socket seems to be quite nicely in focus. The rest of the picture obviously isn't -- even though there are many objects at roughly the same distance from the lens than the wall socket. Also the upper half of the shelf exhibits some very strange ("wavy") perspective distortion. This looks like an optical problem. Like a misalignment between lens and sensor or so. Sadly, I do not think this can be corrected for in software. @Jacob_S posted similarly distorted pictures earlier in this thread. Mayb