Gigadoc2

Don't be too sure about that, for me it is the other way around and I need to use the USB3 port and cable ;)

Off-topic for this thread, but could you post a bit about your setup in the cases thread? I'd be interested in that setup :)

You need to sideload for major LineageOS upgrades: https://wiki.lineageos.org/devices/pro1/upgrade

While I don't think Magisk is inherently bad, I like to remind myself that it and Xposed are primarily tools to customize an OS which you can't customize otherwise, i.e. to customize the stock ROM of a phone. Since we have the liberty to build and install our own ROMS with the Pro1, I try to avoid anything that modifies the system partition post-flash, instead trying to built everything needed into the ROM from the start. That said, I am also kind of missing the superuser functionality (too many apps refusing to be backed up with adb backup, even the open source ones), and Magisk provides

I don't think the official LineageOS would ever merge such a change, as the restrictions (you mention it yourself) are put in place there for a reason: Apart from no permissions on FAT32 or exFAT, saving onto a FAT-formatted SD is also unencrypted, while saving to the internal storage by default is encrypted. Someone could make a downstream fork of LineageOS for the pro1, but I doubt that @tdm (or anyone else) could get such a change upstream. You could make direct SD access a manually grantable permission, but LineageOS will most likely not accept that either, see the eternal debate abou

FWIW, I have no Gapps at all, and as mentioned before experience similar problems. Much more seldom, but it happens.

What is MtG or OG? I am afraid I don't quite follow you^^

Just for the record, I am experiencing some of the described hiccups as well, but not so frequently that it makes it unbearable. It seems to correlate with system load in some way. Unfortunately I cannot tell if stock has the same problem or not, I am too afraid of flashing it without having a full backup for now.

To be more precise, I need pretty much exactly 300GB (50 of that is optional ccache). The pull request incorporated a forked version of MicroG itself, to make it work on Android 10, which is no longer necessary. In principle all that is needed now is to set up the build process for LOS 17.1 itself, and to use a new Signature spoofing patch (though just line numbers need to be changed, AFAIK). The problem is, someone needs to merge the pull request^^ For reference, what I use is this: sudo podman run --rm -ti \ -e "USER_NAME=Revreso Buildbot" \ -e "USER_MA

I have, but I've built the images myself (as I didn't want to wait for the official status), so maybe my builds are slightly different? Anyway, I've installed it just like the test builds, fastboot flashing the boot.img, booting into the recovery and from there flashing the zip. It could be that the LOS4MicroG builds have no boot.img for you to flash, as they are automatically generated and the maintainer is missing. The entire project seems to be left on autopilot and for example the 17.1 devices are not building at all. Considering that the Pro1 might get on 17.1 soon as well, you

In the above I think you forget a very important commercial aspect: Many (most?) apps are sold as 'free' by being infested with ads, and for some by stealing data. That model would not work if people had complete control and could easily remove/block the ads. E.g. by blocking or restricting network access. In that sentence you quote the app developers are the "content providers", so I don't think I forgot them in that part of the post? This is precisely why they have that veto right in the Android security model, so that they can retain control over their content, be it the App i

I'd like to add a bit unto the things @daniel.schaaaf and @tdm already said, with regards to how Google interprets "security". There is a paper by Google employees where they explain the Android security model, it might even be an official Google position (though I am not 100% sure of that): https://arxiv.org/pdf/1904.05572.pdf#section.3 That paper is quite interesting, they include a detailed threat model (which finally explained to me why Google considers a locked bootloader as a critical security feature for regular end-users) and it is not even that old, it refers to Android 9.0.

Just keep in mind that this app only works because SELinux is not enforcing. Normally apps wouldn't be allowed to do that (side note: why are the discretionary permissions even allowing this?). So when the build goes official, that app won't work anymore.

You are right, I wanted to make that the point of my reply (but somehow forgot to include it): So far I've only seen anecdotal evidence for either claim, and no reliable statistics (and I am not sure how one would get these). So I wouldn't discount it on the basis of stability claims some people made at some time, but rather because it does not fit either SD cards or Android in general (how would you even use its features?). Well, it depends on what you are benchmarking, certain operations will be faster on any COW filesystem (copying, as an easy example), but then random writing will

To defend one of my favourite filesystems: I have my daily driver notebook running on btrfs since 2014, fully stable. And the features that the COW nature of it offers are vastly underestimated: You may think about subvolumes and snapshotting them, but did you know that with reflinking you can have snapshot semantics on a per-file level, without any need to create subvolumes? You don't need to think in advance where you want to set the boundary for a snapshot, you just reflink copy the files that you want to "snapshot". Have a huge build tree with icky or non-existent version control where you