Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "R.Wieser" Newsgroups: comp.mobile.android Subject: Re: Android keyboard: your choice. Date: Mon, 24 Jun 2024 20:32:10 +0200 Organization: A noiseless patient Spider Lines: 52 Message-ID: References: <20240617114559.a2970ac2923facc44a2ec355@gmail.com> Injection-Date: Mon, 24 Jun 2024 20:32:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="d1df2db1434430c13aa56a53eec16b7f"; logging-data="1129266"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19BrM6xuSJ+7YF+fQigwq9W+Xnm+rnZ/kpVwo1unyHidQ==" Cancel-Lock: sha1:mNledY9sa1uBsO1S7Jf4cFnxiZo= X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-Priority: 3 X-RFC2646: Format=Flowed; Response X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Bytes: 3368 Andy, >> Is it possible those are BIND_INPUT_METHOD and BIND_TEXT_SERVICE ? > > Yes those are not listed by f-droid > >> those are not under "uses-permission", but under "service" -> >> "permission" > > Thanks, wasn't aware of the distinction, but it's still "a permission" I wasn't aware either. This subthread ("they differ") brought them to my attention. So thank you. > run at startup (why not use the proper name android.permission > RECEIVE_BOOT_COMPLETED? Most smartphone users have little-to-no technical background. They would be stumped to translate the latter to the former - which they have a better chance to understand. >> Is it possible those are BIND_INPUT_METHOD and BIND_TEXT_SERVICE ? > > Yes those are not listed by f-droid > >> those are not under "uses-permission", but under "service" -> >> "permission" > > Thanks, wasn't aware of the distinction, but it's still "a permission" Yep, it is. I can imagine quite a bit of funky stuff you could do when you can inject keystokes into the phone. > Also there's no mention of android.permission.READ_CONTACTS Although the apk in question doesn't seem to have any way to send the data anywhere, forgetting to mention such a privacy related permission is not good. Luckily the phone itself will still ask for it. > Regarding the DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION, I found this [snip] I also did search for an explanation to that permission, and remember having found the same webpage. But alas, even after reading it I have no idea how an app protecting itself from malfunctioning (not to say malicious) other apps needs a permission. I'm rather likely missing something there, but I don't know what. :-( Regards, Rudy Wieser