EskeRahn

Not new at all... Also there on stock Android 9.

(lineage-18.1-20210906-nightly-pro1-signed.zip on August 5 security patch installed smoothly using adb sideload and Open_Gapps-arm64-11-pico-20210712) ...But the reintroduced Accessibility / keyboard bug is not (yet) fixed, see above.

They do look suspicious, indeed.

PPS looking inside the fastboot_all.bat inside the .7z file, Someone with more understanding of these things might be able to pinpoint the specific file that does the trick: fastboot flash boot_a boot.img fastboot flash boot_b boot.img fastboot flash dtbo_a dtbo.img fastboot flash dtbo_b dtbo.img rem fastboot flash system_a system.img rem fastboot flash system_b system.img rem fastboot flash vendor_a vendor.img rem fastboot flash vendor_b vendor.img fastboot flash vbmeta_a vbmeta.img fastboot flash vbmeta_b vbmeta.img fastboot flash userdata.img fastboot flash abl_a abl.elf fastboot flash

The clipping seems like a firmware/software issue, so most likely not much point in sending it in. Is it related to the two sources? Someone are talking in the background and the music is playing. Could it be some attempted noise reduction that are teasing? It sounds a bit like when e.g. Skyping with someone in a meeting room, and the equipment struggles with recording what is noise and what is signal.

PS on how to flash the stock android see this thread

I doubt that factory resetting will do the trick, that 'merely' erase user data. I think it is in the flashing process it also sends something to the display, but I'm not sure. I would rather suggest flashing the latest version, without wiping the user data/

For those on the same version of stock, I do not think a factory reset would be needed after a re-flash. But I could be wrong, it is more of a hunch, as far as my understanding of this whole flashing circus works. So should I do it on a stock device, I would flash without the wipe first - I mean worst case is a re-flash WITH a wipe... So only time is lost. That said, if people have some extra packages sideloaded, they should most likely be applied again.

Are you sure? I believe that it is the flashing of the stock that ALSO flashes something to the display. So even if on stock I think we might have to re-flash it to get the screen working correctly - but as it is the same image, there should be no need of a factory reset, so not that bad. I have not tried to do it though, so be sure to make suitable backup in case a wipe is needed to get things working after the flash.

Interesting. I must admit I'm a bit confused here, as this would mean that Gapps and Magisk go to different slots. Could you check at next load whether it (in small print) says a or b at the three sideloads?

I'm pretty sure that a reboot to recovery is needed between the first two. At the least that was the case for Lineage 16 - have not tried without since.

That was my point yes 🙂

Let me make an example. Assume we use the left YA key combined with the letters 'P' and 'L' to in the kernel 'emulate' two missing physical keys. But YA combined with 'T' might not be mapped in the kernel, so in this case rather than just sending the 'T', it could be sent as a modifier+'T', for remapping furhter down the pipeline,

It would be nice if the kernel remapping could be so flexible that it only took a modifier key if it was used with on of the defined remappable keys. This way more combinations would be available for the users, with the modifier used with other keys.

I would be surprised if the handling of the physical keys and touch are not substantially different, so do not think we can deduce from differences between the two.

Yes it is stated somewhere that IF you want to use gapps, then it MUST be installed before first OS-boot after a flash, and must be reinstalled after each OS flash.

That sounds like something eats up the processing power, so it is unable to process the keystrokes in real time. But obviously what ever does the processing should have had sufficient priority for this not to happen normally. Anything you are aware of running in the background that might be what is disturbing. E.g. some complex sound decoding, playing high-resolution sound? I would try to install something like GSam or the like, to find out what is using the resources. (GSam registers the battery pull over time, but any substantial CPU activity should also leave a mark in the power cons

Silly me, i did not read the log provided closely enough> .... healthd : battery l=75 v=3983 t=30.0 .... So that should hardly cause anything to shut down

Swapped: A=Keyboard, B=Case - at the least that is the naming used in the FactoryKit....

Most likely a scancode for historical reasons is a byte, somewhere in the 'pipeline', so the map to 464 must happen later.

The Hall_a is the keyboard open/close detector, the Hall_b is the one in the display (case detection) They are called a and b in the 'factorykit'-test (The one just above OTG almost at the bottom) See this

Look at it another way. Why should a bank care if they did not see a reduction in their risk of loosing money somehow?

(lineage-18.1-20210830-nightly-pro1-signed.zip on August 5 security patch installed smoothly using adb sideload and Open_Gapps-arm64-11-pico-20210712) ...But the reintroduced Accessibility / keyboard bug is not (yet) fixed, see above.

Have not tried it (I might find some time for it later) but I really think you should consider @Slion's idea of changing the initial qwertY/qwertZ switch to some radiiobuttons (or a drop down), collecting the settings in named sets. There could be one (say "custom") with all the options unfolding. But it will be terrible difficult for most user to understand the consequences of all the switches. It gets a bit like AICP: very customizable, but also very hard to set up for the normal user. But if we are into switches, the alt or fn debate could be handled by letting that be yet another switch

Well part of it is that could well be that in many countries the banks hold the responsibility for fraudulent activities on your account, unless they can prove that you have shown gross irresponsibilty, e.g. Sharing your pasword. And as security on phone banks apps are often down to simple four digits pins, and phones are stolen more than laptops, it all adds up to higher risk for the banks, so at the least they want to reduce the risk of any troyan horse or the like accessing your bank app. And this is easier on rooted devices. But of course they could offer an option of you taking all