Android Entwicklung – Der Google Playstore & LVL-Lizenzierung

Im Gegensatz zu iOS muss man sich um den Schutz der App vor unerwünschten Kopien komplett selbst kümmern. Bei iOS besteht der Schutz vor allem darin, dass man Apps nur aus dem iTunes Store installieren kann. Dieser Mechanismus ist nicht perfekt und kann mit dem Jailbreak des Gerätes ausgehebelt werden – aber er ist einfach. Auf Android wird es für Entwickler wesentlich komplizierter, einen grundlegenden Schutz zu realisieren.

Dort können auf jedem Telefon ohne Aufwand beliebige APK-Files installiert werden. Das erweitert den möglichen Kreis der „App-Cracker“ sogar auf Leute, die nicht mal merken, dass eine App kostenpflichtig wäre, wenn Sie von jemanden per Mail geschickt wurde.

Wenn man kostenpflichtige Apps auf Android verkaufen will, sollte man also für eine Lizenzüberprüfung oder einen vergleichbaren Mechanismus auswählen und diesen umsetzen. Wir haben entschieden, die App über den Google Playstore zu verteilen und die dort verfügbare LVL-Schnittstelle zu verwenden. Damit prüft man, ob der Benutzer eine lizensierte Kopie der Anwendung verwendet. Damit dies etwas bringt muss man die Anwendung zusätzlich mit einem Obfuscator schützen, damit diese Lizenzprüfung nicht einfach wieder ausgebaut werden kann.

Während der Entwicklung kann man den Lizenzserver von Google anweisen bestimmte Antworten (lizensiert, nicht lizensiert, usw.) zurück zu liefern. Leider kann man die Gültigkeit dieser Antworten nicht konfigurieren und auch nicht einsehen, warum welche Anfragen mit welcher Antwort beantwortet wurden. Verwendet man beispielsweise auf dem Gerät eine andere Version als in der im Play-Store hochgeladenen Version, liefert der Play Store immer zurück, dass die Anwendung lizensiert ist. Greift man dann beim Debuggen zu oft auf den Play Store zu, um diesen Problemen auf den Grund zugehen, kann es schon mal passieren dass der Lizenzserver den entsprechenden Account sperrt (für einen durch Google nicht näher spezifizierten Zeitraum von 2h bis 3 Wochen), ohne dass man darüber informiert wird.
Außerdem scheint die Play Store Anwendung ab und an nicht richtig zu funktionieren (Workaround: Gerät neu starten oder Lizensierungsdaten zurücksetzen). Dies führt zu extrem undurchsichtigem Verhalten des Lizenzservers, das zu vielen Stunden frustrierendem Debugging führt. Am ersten Tag waren wir nach 18h Arbeit im wesentlichen genauso weit wie am Morgen. Mehr Infos dazu gibt es übrigens auch hier.

Ein weiteres Detail war für uns zwar kein Problem, für größere Teams mag das aber dennoch unangenehm sein: die Lizenzantwort kann man nur global für **alle** Anwendungen eines Accounts einstellen.

Der Playstore ist nicht nur beim Entwickeln etwas unberechenbar, sondern auch später für die Käufer. Wir hatten einige Supportanfragen dazu – auf manchen Handys beendeten sich neu gekaufte Anwendungen wegen einer fehlenden Lizenz. Diesen Fehler scheint ein Neustart des Geräts zu beheben, was das Vertrauen in den Store nicht gerade stärkt. Etwas Vergleichbares ist in vier Jahren iOS übrigens nie passiert.

Aber auch die zweite Herausforderung, die Anwendung gegen dekompilieren zu schützen, ist verhältnismäßig aufwendig. Google setzt hier auf das OpenSource Tool Proguard, zu dem es im Internet immerhin eine Menge Dokumentation gibt. Leider braucht man die auch, da die initiale Konfiguration extrem kompliziert ist. Viele Fehler treten erst zur Laufzeit in Kombination mit den verschiedenen Android Versionen, Action Bar Sherlock und Roboguice auf. Tipp am Rande: Maven kann übrigens unter OS X keine Release Versionen mit Proguard bauen. Man muss hier manuell nachhelfen.

Zurück zu Teil 1: Das Tooling
Weiter zu Teil 3: Finanzielles und Fazit