2013-08-21

Berechtigungen erben

Nutzer von Android-Apps sind leider oft leichtfertig, wenn es um das Abnicken von Berechtigungen geht. Umso mehr freut es mich, wenn Anwender nachfragen.

Ein Nutzer meiner App TKBirthdayReminder wollte wissen, warum ich lesend und schreibend auf das Anrufprotokoll zugreife. Ich war erstaunt. Mir war nämlich nicht bewusst, dies zu tun. Ein Blick in das Manifest offenbarte:

READ_CONTACTS, WRITE_CONTACTS, CALL_PHONE, RECEIVE_BOOT_COMPLETED, WAKE_LOCK, GET_ACCOUNTS und READ_SYNC_SETTINGS

Also kein Hinweis auf das Anrufprotokoll.

Nach etwas nicht allzu zielführender Recherche habe ich dann die Google-Doku konsultiert. Unter http://developer.android.com/reference/android/Manifest.permission.html#READ_CALL_LOG und http://developer.android.com/reference/android/Manifest.permission.html#WRITE_CALL_LOG steht sinngemäß: Wenn man die Berechtigungen "Kontakte lesen" und "Kontakte schreiben" anfordert (das muss TKBirthdayReminder tun, um Geburtsdaten lesen und schreiben zu können), “erbt” die App in älteren Systemversionen automatisch auch den lesenden bzw. schreibenden Zugriff auf die Anrufhistorie.

Googles Rat für alle, die die Rechte nicht benötigen: targetSdkVersion auf 16 oder höher setzen

2 comments:

  1. Nur, um die Rechte loszuwerden, einfach mal targetSdkVersion verändern? Das ist ja die Hammer-Methode ;) Aber wenn wir gerade schon beim Thema sind: Es wäre interessant, nach welchen Kriterien du targetSdkVersion setzt. Auf die höchste Version, die du in Hardware hast?

    ReplyDelete
  2. > Nur, um die Rechte loszuwerden, einfach mal targetSdkVersion verändern?
    > Das ist ja die Hammer-Methode ;)

    Wie geschrieben: offizieller Rat von Google. :-)

    Man muss sich sehr genau überlegen, ob man das möchte. Zum Beispiel hat Google mal das Verhalten von RECEIVE_BOOT_COMPLETED geändert, so dass die Action nur noch dann gesendet wird, wenn mindestens einmal vorher eine Activity angezeigt wurde. Das ist nicht schlimm, aber man muss es eben wissen. Solche Änderungen "lauern" an vielen Stellen. In Konsequenz bedeutet dies: testen, testen, testen...

    > Es wäre interessant, nach welchen Kriterien du targetSdkVersion setzt.
    > Auf die höchste Version, die du in Hardware hast?

    So konservativ wie möglich. Bei TKBirthdayReminder stehen minSdkVersion und targetSdkVersion auf 7, bei TKWeek 8 bzw. 15.

    Eine höhere targetSdkVersion macht das Entwickeln etwas leichter, weil man direkt auf neue Klassen, Methoden, etc. Zugriff hat. Auf der anderen Seite muss man darauf achten, dass "neuer" Code auf alten Systemen nicht ausgeführt wird. Also wieder testen, testen, testen...

    ReplyDelete