claude0001
-
Content Count
607 -
Joined
-
Last visited
-
Days Won
76
Posts posted by claude0001
-
-
23 hours ago, suicidal_orange said:
are these the bits we are trying to get mainline support for so we don't have to rely on companies?
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 ...
-
2
-
-
17 hours ago, Hook said:
Just to let you know, switching to Lineage will move you to Android 11 with current updates.
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.
-
1
-
-
28 minutes ago, Hook said:
I don't have stock, but, yes, that is the last vendor security update and is that on the Lineage official weeklies as well.
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!
-
3 hours ago, Rud said:
Symbian, here I come! :)))
Can't wait for Maemo Leste to take over the World. 😉
-
1
-
1
-
-
51 minutes ago, DieBruine said:
I put a bottle of whisky on the screen
That must have been the key to success. 🙂
Congrats and thanks for posting these detailed instructions.
-
1
-
3
-
-
On 4/13/2021 at 12:35 PM, eldarion said:
Have you guys looked at an android security bulletin lately? https://source.android.com/security/bulletin
[...] I can't wrap my head around the "I'll stick with stock" or "I'll stick with LOS16" messages around here. That seems like insanity [...]
On 4/14/2021 at 2:57 AM, Sean McCreary said:[...] You can use the updated branches to build a (mostly) patched version of 16.0 or 17.1 for the Pro1 by following the instructions for building your own images [...]
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 key migration, I did not even need to wipe my data for flashing it on top of the last official LOS16, and everything still works as expected.
This experience largely reconciles me with Lineage. Though it *would* be nice if they allowed several official branches per device ... 🙂
-
6
-
2
-
-
16 hours ago, brunoais said:
Wait... File browser?
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.
-
1
-
-
21 hours ago, brunoais said:
I think you need to root at the android level. However, why root at the browser app?
In other words, why the need to run the browser app with root permissions?
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 the GID 1023 "media_rw". For all other files, the browser needs root privilege. On top of that, SELinux enforces further access restrictions which I did not try to understand.
My experience from sharing a partition between LineageOS and a GNU/Linux chroot is that root access is necessary on the Android side to write to that file system.
-
3
-
-
1 hour ago, brunoais said:
Ultimately, the only requirement would be that the uids and gids match in both installs.
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.
-
1
-
1
-
-
27 minutes ago, marmistrz said:
As I said, feel free to submit an issue to https://gitlab.com/LineageOS/issues/android and request a user-configurable option.
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.
-
1
-
-
1 hour ago, _DW_ said:
Maybe send a pull request to the lineage team with the fix?
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.
-
5 hours ago, marmistrz said:
Yeah, but I'm 99.9% sure that the same issue holds for 18.1. I submitted a patch with gps fixes in https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/308056
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.
-
1
-
-
17 hours ago, Sean McCreary said:
[...] You can use the updated branches to build a (mostly) patched version of 16.0 or 17.1 for the Pro1 by following the instructions [...]
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 ...
-
1
-
-
58 minutes ago, VaZso said:
However, PC has a high level of compatibility which does not really true if we look at specific ARM devices.
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. 😉
-
2
-
-
3 hours ago, VaZso said:
this industry is moving too fast, so 662 will also be obsolete in a few years
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. Therefore, ways of continued (perpetual?) use of existing hardware will never be realistically available to "normal" users. Not because it is technically impossible but because, in the industry, no one can want that. Those people have families to feed, too ... 😉
-
2
-
-
9 hours ago, eldarion said:
That seems like insanity
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.
-
4
-
-
6 hours ago, 86turbodsl said:
... and the support lifetime will be that much shorter ...
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 original phone (looking at you, Pro1 camera ...).
-
4
-
-
6 hours ago, order#10248 said:
Actually, my only motivation for this upgrade was the expectation to get the QR-Code scanning feature in default camera app. But unfortunately this is not included and a different/separate app has to be used for that. Too bad ...
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!)
-
2
-
-
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.
1 hour ago, Rob. S. said:Still, I'm afraid there's not much we can do to make Lineage change their policies
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-building would be a solution for me, indeed. The problem is that I would need to learn it now that the only device I have for testing my builds is in productive use. Vicious circle ... 😐
1 hour ago, EskeRahn said:That the tweaks you are using have nor been affected, does not prove anything, sorry.
Well, then let me tell you this: That stuff I do on my Pro1 is standard in other places of the Internet. Yes, it is known that you have to find your hacks with every new device and every new Android version. But it is also pretty much accepted that the tools and interfaces one uses to play these tricks do not change within one AOSP version. That is essentially as likely as an OTA breaking your Apps. And, even in the unlikely event of such a regression, it is usually a bug that can be fixed (relatively) easily from one side or the other. Please just believe me.
Major releases are of course different in that they are meant to introduce changes. That's why I would like to avoid those as long as I can. I thought official LOS would allow me this, but sadly it doesn't. Hence I'm whinig. Sorry for bothering everyone. 😄
Also, I think your comparison to Windows 10 rather supports my point: as of version 10, Windows is no longer stable (in the sense of feature-stability), but essentially a rolling release. That is why deal-breaking changes are now more likely to (seemingly) come out-of-nowhere than in the old days. This is pretty much what I would like LineageOS not to become ... 😉
-
3
-
-
1 hour ago, EskeRahn said:
So a heavily tweaked system is not suitable as a stable daily platform, unless you leave it without any updates
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.
1 hour ago, Hook said:There must be some way to get the security updates into older releases of Lineage.
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 do that before setting up everything relying on the official releases ...
-
2
-
-
1 hour ago, Rob. S. said:
I just wouldn't get my expectations up as to its working in a stable way for a longer period of time.
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, in every computer system, major upgrades are something that needs to be very well planned or tested before taken to production. That's why I (like many) want to go through that process only every few years. Not every few months.
Finally: All of these are honest questions about LOS 18.1. Where if not in this thread could I expect to get answers?
-
1
-
-
11 hours ago, daniel.schaaaf said:
Google makes Android safer and more secure with every new version. Unfortunately they also make Android more restrictive for power-users and they gradually "encourage" users to stay away from SD-cards.
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) Magisk the same way they work with the (native) AddonSU of LOS 16?
- I run a GNU/Linux (Devuan) in parallel to LineageOS in a chroot. As Devuan relies on the host OS for all kinds of stuff (network, powermanagement, ...) it uses Lineage's SSH-server (which I also start in via userinit.d on boot) to talk do it (e.g. query DNS servers, request wakelocks, ...). Does SSHD work in LOS 18.1 again the way it did on LOS 16, after there had been a few issues on 17.1?
-
I use two partitions on my SD-card: One for normal data storage, and one containing my Devuan Chroot FS. As the data partition is shared with the GNU/Linux system and needs to preserve UNIX access rights, something like FAT is no option as file system, so I went for ext4. No problem for Devuan. But Android Apps could not write to that file system for a long time: Android security stands in the way. After quite some research, I found that, in LOS 16, I can work around this by disabling SELinux and remounting one of the many cryptic Android mount-points of the SD partition with "mask=0":
#!/system/bin/sh # # Disable SELinux, it prevents write access to our EXT4-formatted SD-Card # partition. # /vendor/bin/setenforce 0 # # Re-mount data partition of external SD-card read-writable by all apps # mount -o remount,mask=0 /mnt/runtime/write/24a37a95-5429-4d2f-b98d-27fccea25e17Now, who can tell me if this will still work on LOS 18.1? No one here, I guess. Probably not even the devs themselves ... -
For my Devuan system partition, things are even more mysterious. At the beginning of my Chroot-init-script, I mount the Devuan partition like this:
# Mount the system partition containing Debian # It turns out this should be an ext3 fs (not ext4) for things to # work smoothly ... mount -o bind /mnt/media_rw/88f89540-879a-4309-9776-bf276aaac733 /data/DEBIAN # # Make it a real root directory mount -o remount,exec,dev,suid /data/DEBIAN [...]Nothing special, eh? Well (as noted in the script) it turns out Devuan starts successfully only if its SD partition is formatted as ext3. ext4 will not work. No idea why, nothing to find on the Internet. I can only guess that, again, Android's handling of the SD card gets in the way with ext4, while an ext3 FS (obviously supported by the kernel, but maybe considered "obsolete" at some higher level of Android) is somehow ignored, allowing the partition to be fully taken over by Devuan.
Yes, that is a bloody hack! I found it to work, but do not understand it even to the slightest degree. How can I predict it will still work with LOS 18.1? Not at all!
The list is not complete, but I think one can see my point: That people tell me they have been able to dirty-flash the living daylights out of their phones, and that their Android Apps were mostly happy afterwards, does not help me one bit. I spent a lot of time setting up a system on the edge of what LOS 16 can do, using features that may be partly undocumented and that seemingly very few others use (or no one else?). I am completely unsure if any of these solutions would still work if I switched to another major release.
The only way to know would be to try. But as the Pro1 is my only phone and I use it productively, I cannot realistically take that risk. At least not every few months when Lineage decide to abandon yet another major release.
To be productive with my Pro1, I have to rely on my OS to be stable. The Debian meaning of stability that is: Never change a running system. Patch it with security fixes, yes. But never change its behaviour, never break any interfaces!
Sorry for the outburst. Not even 10 months in the Android world and I already start to feel tired of fighting ... 🙂
-
2
-
1
-
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. 🙂
-
2
-
Cable type for fastboot
in General Discussion
Posted · Edited by 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 version with USB-2.0 ports only, the Pi4 has a USB3 bus which may again cause problems (did not try).