tdm

Regarding root detection and the su-hide patch... The kernel su hide patch was intended for a specific purpose: someone claimed that Lineage su was insecure but refused to provide any details except that it could be exploited even when root access was disabled in settings. The su-hide patch was my response. It is impossible to exploit something that does not exist. 🙂 The patch was never intended to prevent apps from detecting the device has been rooted. That is a cat-and-mouse game and I don't play. If an app insists that it run on an un-rooted device or does anyt

The Lineage version is 16.0 and the device is arm64. So you want "addonsu-16.0-arm64-signed.zip".

No, I am talking about the Official(tm) LineageOS superuser add-on from here. I do not use or endorse any other su package, and I absolutely don't touch magisk at all.

Right, that is the strange part. So maybe the opposite. I don't know. It's all conjecture until I can get logs...

Yes, official Lineage behaves the exact same way for root access, etc.

I suspected something like this. AVB is probably unhappy because the Lineage security patch level is less than the stock patch level for the newest devices. Or something like that. I'll need to investigate.

The root access setting is dynamic. By default it only shows disabled and adb. When you install the su add-on, it adds the "apps and adb" option.

No, you still need to flash the add-on for su to work. The add-on contains the su binary. The kernel patch does not provide an su binary, it only hides the su binary when root access is disabled for apps.

The setting is "root access" in developer options. And note developer options is not visible by default, you need to enable it by tapping on the build number 7 times.

Thanks for the recovery log, but unfortunately that is not really helpful -- it only says that the Lineage install succeeded. I need a logcat of Lineage (trying to) boot in order to figure out what's going on. This will require some tweaks to enable logcat at startup. If you are comfortable hacking on your phone with adb, we can try to do that. Alternatively, perhaps you can tell me exactly which version of stock you were running and maybe I can reproduce that here.

No, it is not opt-in/opt-out. But it does not break anything either. It works like this: If root access is enabled for apps in settings, the patch does nothing -- su works normally. If root access is disabled for apps in settings, the su binary (/system/xbin/su) disappears. You cannot see it with "ls" or "stat", it cannot be run, etc. It simply does not exist. Note that root access for adb still works in both cases, as it does not use the su binary.

test15 is up. Changes: * Fix QWERTZ apostrophe (really!) * Back out noise rejection bits from DT2W patch * Add su-hide patch Please test. Particularly those that have had issues with the screen failing to turn on after sleep. I would like to know if this fixes the issue or not. If it does not, I'll need to play with the noise rejection stuff and see if I can fix the issue without the visual artifacts on my device.

It is possible to update firmware without going back to stock. It requires one person (me, most likely) to flash the stock update, copy the firmware partitions, and make a flashable zip. The only way to make a backup of userdata right now is to make a copy of your userdata image (eg. using "dd"). When a decrypting TWRP is available, that will be a much nicer way. But yes, you should also be able to use the A/B system to try different test builds. You are correct, TWRP for system-as-root devices should install by injection into the boot partition instead of a partitio

Yes. I actually wrote the kernel patch to do that, about ... 3 or 4 years ago. I'll apply that for next build. The patch works by watching for the su daemon process. When it is running, everything is normal. When it is not running, the kernel hides the existence of the su binary -- it cannot be detected with "ls" or "stat" etc. except by root. So you just disable root before running one of those (annoying and broken) apps.

Okay let's assume for now it only affects pre-production devices. I'll still look into it though because it is quite annoying. And yes, perhaps not the best description. But if you see it, you'll know...

Is anyone else seeing horizontal lines flickering across the screen with test14? I saw this with stock but haven't seen it with Lineage until today. So the DT2W kernel patch must be the cause.

test14 is up. Changes: * Fix QWERTZ apostrophe. * Disable double tap to wake. Also updated github repos.

Which version of stock did you have running prior to flashing Lineage? Does upgrading to test12 or test13 work, or are you stuck on test10?

Apparently the German corona-warn-app is only available from Play Store in Germany (known issue on github), so I installed it from apkmirror (here). It installs and starts fine on my device using test13 and Play Services 20.18.17. Is there a particular function in the app that fails?

Well, I'm afraid I don't know anything about the USB low level stuff. I only know the various protocols involved, which use bulk transfers. In your first capture, there are no bulk transfers at all. So everything that is happening is low level. In your second capture, I see the host sending a request (packet 157, "getvar:has-slot:boot_a"). The phone does not respond at all. I'm working with another user who is seeing a similar issue with EDL. Not sure if they are related, but it seems like it may be. My current theory is that the host is incompatible with the phone in some way. Can yo

That is very strange. I've never seen anything like that. Out of curiosity, I searched the bootloader source code for that string, and found ... nothing. 😕 If you send me a wireshark dump of the usb traffic, maybe I can find a clue?

I'll probably be the one to do that. I got close to a functional decrypt before covid hit, but haven't been able to work on it since. I'm focused on getting Lineage finished and official and TWRP should come after that.

I agree with most of what you said. Except perhaps the part about comparing app permissions to a desktop OS. Every desktop OS allows apps (we used to call them programs or executables, remember?) to do pretty much whatever they want whenever they want. Please note that there are two distinct meanings for "secure" / "security" in terms of a device. There is security from the corporate perspective, which includes things like DRM and evidence of tampering. And then there is security from the user perspective, which includes exploiting vulnerabilities, hacking, malware, etc. Whene

Oh, I didn't know you still had or used a Pro1. Good to see you are still here. 🙂 I should have the apostrophe on the L fixed for the next build. Sorry, I don't know what could be up with WhatsApp. Can you tell me what is the last build that worked?

Fair enough. And you are able to choose to verify your content via HTTPS, MD5, SHA1, or all three. 🙂 Of course if you were really worried about MITM attacks you would be right to be concerned that the attacker could alter the hashes on the lineage.html page also. In which case, I suppose those people would be asking for the hashes to be made available via a third party server (such as this forum). But nobody has asked for this so far. In fact, I doubt that more than a couple people even bother to check the hashes. Hmm, not sure what the timestamp issue co