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

I am really curious to know what the problem was, if it's not too much work to explain 😇 If you're referring to not having LED notifications (except charging), I can confirm. Notification vibration I have though. @Polaris: Just to make sure, you haven't accidentially disabled vibrating notifications? Not only the global setting, but maybe just for the apps you use? Sometimes things can get weird and the default notification channel settings may not be what you'd expect (I know that I had chat notifications for a certain app completely hidden by default, for some reason). Many h

So, now that the topic of keyboard mapping has come up here already, I want to add a bit of (what I hope is) constructive criticism. But first off I want to clarify that I am and will stay grateful for @tdms (and mccrearys) work on this port, without which my Pro¹ be not much more than an expensive toy. And, those who do all the unpaid community work (i.e. @tdm) have the right to decide how this project goes, until we start writing patches ourselves we should only offer suggestions. So, here we go: If I understand @Craigs suggestion right, he would have the semantics of the "slanted

It's not an intentional option... I don't really know how the SailfishOS porting process is supposed to work, but I have a Jolla and compared some of the things we found out in the chat with the Jolla; and to me it looks like you mostly take the userland from the Jolla, add changes and put that onto the new phone. Now, I don't know how familiar you are with desktop Linux (I have no idea if your interest is mainly Android or Linux in general), but if you are familiar: SailfishOS is very much like a desktop Linux distribution, amongst other things it is using systemd, udev and udisks2. Now

Ok, so the restore-tool sends the idealte-signed (or is it qualcomm-signed?) firehose programmer to the phone, and then communicates with said programmer over USB to send it the stuff it has to flash (or receive whatever it reads), am I getting this right? So in theory, if one were to take the signed firehose from your tool it could be used with the Linaro tool or something similar? And I take it that you don't have the firehose source (and if you had you couldn't sign the resulting binary), but what with the code from cyngn? I suppose you are not at liberty to release the source of

Yass! Oh, that sounds very interesting! How much is your tool dependent on the NDA stuff F(x)tec gave you? Do you think it is possible to develop something like it as open source, and add reading capabilities to it? I mean, that sounds like a prime way to fully, completely, back up your device :D But apart from that, if you can read flash with EDL, doesn't that kind of defeat locked bootloaders? As in, now I can dump the data from the phone before I tamper with it to get the decryption key? Or is that completely mitigated by a part of the encryption key being stored in a secu

It looks like QDL mode is EDL mode -- at least when I put my device into EDL mode it is listed as "QDL mode" in `lsusb`. As it seems the only tool we have for EDL flashing is the one from this thread, you can't really cherry-pick partitions to flash. However, the tool offers the "Base only" option. I have not tried that, but according to tdm's page here, "base only" will keep most of the "high-level" partitions intact, so it might leave SailfishOS mostly untouched. What you can't do in any case is checking which partitions are "corrupt", as far as I know neither EDL nor fastboot allo

I am afraid that this is exactly what you did 😞 Just yesterday I talked about this with the others in the Chat (not using SailfishOS myself, that's why I didnt find out sooner). It seems that Sailfishs logic what to hide in the UI, as well as their automount logic, is to some extent hardcoded to the hardware of the Jolla (or maybe the Xperia phones too). So all these unformatted partitions are indeed internal partitions of the Pro1... You may have deleted the bootloader, the modem firmware, or similar stuff... At this point, all you can do is to EDL flash, I am afraid 😞

@EskeRahn: I know, that is why, if they have programmed the changes themselves, they may have the rights to open it :)

@Waxberry: Did you (fxtec) program the stock launcher? If so, could you open-source it? That might allow users to improve it or install it on LineageOS and such.

Why is that stored in persist in the first place? Has it something to do with the FDE of stock? Though you'd always unlock before using Fingerprint anyway?