TL;DR

Dieses Problem tritt auf, wenn eine App versucht, eine vorhandene Berechtigung erneut zu deklarieren, mit der Fehlermeldung INSTALL_FAILED_DUPLICATE_PERMISSION. Betroffen waren vor allem Apps, die auf Adobe AIR (Paketpräfix mit com.air) basieren. Die Hauptursache ist die unterschiedliche Codeimplementierung in Lollipop 5.0 bei der Überprüfung der Signatur eines Zertifikats, das zum Signieren einer App verwendet wird. Für die Lösung springen Sie einfach zum Teil "Lösung".

Update : Google hat dieses Problem in Lollipop 5.0.1 behoben.

Technische Details

Auszüge aus dem Android L Developer Preview Issue Tracker , die von einem Eintrag im AOSP Issue Tracker verlinkt sind ,

Beitrag #4 :

logcat sagt mir, dass es einen Konflikt mit der Neudeklaration von Berechtigungen während der Installation gibt (in meinem Fall versucht Amazon, getui.permission.GetuiService, das bereits Camera 360 gehört, neu zu deklarieren).

LogCat von Beitrag Nr. 12 :

10-25 08:06:37.805   749   824 W PackageManager: Package com.tencent.mm attempting to redeclare permission com.google.android.c2dm.permission.SEND already owned by com.google.android.gsf
10-25 08:06:37.926  4812  4812 D Finsky  : [1] PackageInstallerImpl.cancelSession: Canceling session 121130466 for com.tencent.mm
10-25 08:06:37.926  4812  4812 E Finsky  : [1] PackageInstallerImpl.handleCommitCallback: Error -505 while installing com.tencent.mm: INSTALL_FAILED_DUPLICATE_PERMISSION: Package com.tencent.mm attempting to redeclare permission com.google.android.c2dm.permission.SEND already owned by com.google.android.gsf
10-25 08:06:37.926  4812  4812 W Finsky  : [1] 4.installFailed: Install failure of com.tencent.mm: -505 null
10-25 08:06:37.933   749   749 D ZenLog  : intercepted: 0|com.android.vending|-973170826|null|10017,!priority
10-25 08:06:37.933   749   749 V NotificationService: pkg=com.android.vending canInterrupt=false intercept=true
10-25 08:06:37.964  4812  4812 D Finsky  : [1] InstallerTask.cancelCleanup: Cancel running installation of com.tencent.mm

Auszüge aus dem AOSP Issue Tracker ,

Beitrag Nr. 4

In API19 verpackt das neue X509CertImpl(encCert) das Zertifikat (das bereits geparst und für die SHA1-Berechnung bereit ist), während in API 21 das Zertifikat als Bytestrom weitergeleitet, erneut geparst und von einer Zertifikatsfabrik verarbeitet wird. Welche Fabrik das ist, hängt vom Kontext ab. Im Falle der L-Geräte, auf denen ich getestet habe, erstellt die Fabrik ein OpenSSLX509-Zertifikat. Leider gibt es etwas in unserem Zertifikat, mit dem openssl Probleme hat, und der Fingerabdruck ändert sich während der Verarbeitung von openssl. Ich kann das auch mit dem openssl-Tool reproduzieren, wenn ich unser Zertifikat in ein anderes Format (zB PEM) konvertiere.

Wenn der SHA1 direkt auf 'encCert.getEncoded()' berechnet würde, wäre er in beiden Fällen korrekt.

Lösung

Update : Am 04.12.2014 hat Google dieses Problem in Lollipop 5.0.1 behoben. Für diejenigen, die keine Problemumgehung bei dem Versuch unternommen haben, die App neu zu installieren, können Sie das Lollipop 5.0.1-Image flashen, wenn es bereit ist/auf das OTA wartet.

Beitrag #20, #21

Sieht so aus, als ob dies in 5.0.1 behoben wurde:

https://android.googlesource.com/platform/libcore/+/6632d8c9d8d1a3ac338d541676148677641bafe3

https://android.googlesource.com/platform/frameworks/base/+/32a22c44b8351c1cccd3a1f9c47a33469d9378e0

Status: Freigegeben

Committer-Anmerkung

Stellen Sie Apps mit fehlerhaften Zertifikaten wieder her.

In Lollipop gab es ein Zeitfenster, in dem wir Zertifikate beibehalten haben, nachdem sie einen Dekodierungs-/Kodierungszyklus durchlaufen hatten. Die gut geschriebene OpenSSL-Bibliothek war beim Decodieren liberal (was das Analysieren leicht fehlerhafter Zertifikate ermöglichte), aber dann beim Codieren streng, wodurch wir unterschiedliche Bytes für praktisch dasselbe Zertifikat erhielten.

Eine verwandte libcore-Änderung (0c990ab4a90b8a5492a67b2b728ac9a4a1ccfa1b) gibt jetzt die ursprünglichen Bytes wörtlich zurück und korrigiert sowohl Installationen vor Lollipop als auch Installationen nach dieser Änderung.

Diese Änderung stellt alle Apps wieder her, die während des oben beschriebenen Zeitfensters installiert wurden, indem eine einmalige Überprüfung durchgeführt wird, um festzustellen, ob die Zertifikate tatsächlich gleich sind.

^{Weitere Lösungsvorschläge finden Sie in der älteren Version .}