| 29 Oct 2024 |
 samueldr | probably something like that if it exists | 00:56:01 |
 oak 🏳️🌈♥️ | If you look at the Fingerprint HIDL link I posted, it quite nicely shows what all are the compontents related to that | 00:56:03 |
| oak 🏳️🌈♥️ | fingerprintd is standard component provided by AOSP, but the FP vendor library is provided, well, by the vendor | 00:57:30 |
 atemu12 | Thanks a bunch for the pointers so far though! I'll have a look at all of them tomorrow and try to figure out what and how my fingerprint reader broke. | 00:57:50 |
| samueldr | Atemu: and that activity launcher app filters activities in packages too, so e.g. finger will find the fingerprint-related ones under settings | 00:57:56 |
| oak 🏳️🌈♥️ | I hope the issue is not inside the closed source binaries | 01:00:02 |
| atemu12 | In reply to @samueldr:matrix.org
Atemu: and that activity launcher app filters activities in packages too, so e.g. finger will find the fingerprint-related ones under settings Yeah it didn't like that ^^' | 01:00:15 |
| oak 🏳️🌈♥️ | I wonder if the FP vendor library sources are available | 01:00:27 |
| samueldr | oh, yeah, launching random activities might not work when they require params | 01:00:31 |
| atemu12 | It's also not like the settings are at fault, this is almost certainly just the settings reacting to biometrics not working at a lower layer | 01:00:46 |
| samueldr | yes, was about to say; it wasn't meant to imply that the settings page are to be looked at, but an example that it will filter "deeper" than package names | 01:01:23 |
| atemu12 | In reply to @oak:universumi.fi
I hope the issue is not inside the closed source binaries Given that it also affects stock ROM... | 01:01:32 |
| samueldr | it sure smells fishy | 01:01:54 |
| oak 🏳️🌈♥️ | It might be that the problematic code runs inside TEE | 01:02:03 |
| atemu12 | Ohoh | 01:02:13 |
| atemu12 | That could also be a state that I'd wipe by wiping userdata, huh | 01:02:32 |
| atemu12 | Because android would presumably re-init TEE state when it's got a clean slate | 01:02:54 |
| oak 🏳️🌈♥️ | Yeah it probably resets the Keystore / Keymaster at least | 01:04:12 |
| oak 🏳️🌈♥️ | Fairphone has Qualcomm chip so they are probably running QSEE | 01:04:32 |
| samueldr | that fairphone? (I forget which model is the latest) | 01:05:01 |
| samueldr | (I thought it was fairphone 5? and here remember FP4, but might be wrong?) | 01:05:21 |
| atemu12 | All of them run QC chips AFAIK | 01:05:30 |
| oak 🏳️🌈♥️ | * Fairphone 4 has Qualcomm chip so they are probably running QSEE | 01:05:22 |
| atemu12 | * All of them have QC chips AFAIK | 01:05:39 |
| samueldr | definitely not, initial ones were mediatek based | 01:05:51 |
| atemu12 | Oh indeed | 01:06:15 |
| samueldr | * definitely not, initial ones were mediatek based | 01:06:20 |
| atemu12 | The first one is MediaTek | 01:06:40 |
| samueldr | right, the last four were qualcomm | 01:06:47 |
| oak 🏳️🌈♥️ | I think Qualcomm announced recently they will lock the secure side of their SoCs so it's only going to be running TEE OS signed by Qualcomm keys in the future. Even for companies that make phones with those chips | 01:07:41 |
