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