android.view.InflateException (Fehler beim Aufblasen der Klasse) nur bei der Produktion

Question

Meine App verwendet eine Drittanbieter-CustomView, die ich nicht ordnungsgemäß zum Projekt hinzugefügt habe. Was ich getan habe, habe ich heruntergeladen die Dateien des Projekts als * .java und fügen Sie sie manuell zum Projekt unter Paket com.blabla.utils.CustomView (so habe ich es definiert in den *. XML-Dateien, die diese Klasse verwendet) . Als ich die App auf mehreren Geräten (mit USB-Kabel, und Senden einer signierten APK an den Tester) Debugging/Testen, schien alles in Ordnung zu sein. Aber wenn ich die App Produktion hochgeladen, ich Ausnahme

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.*.*}: android.view.InflateException: Binary XML file line #55: Error inflating class com.*.*.CustomView

Jetzt plötzlich bekam, wurde mir klar, was mein Problem war, habe ich das Projekt ordnungsgemäß nicht hinzufügen, ich brauchte die Bibliothek als ein hinzufügen existierendes Projekt in meinen Arbeitsbereich und sie verknüpfen dieses Projekt mit meinem Hauptprojekt. Und ich habe die com.blabla.utils.CustomView zu com.theoriginaldeveloper.package in * .xml-Dateien geändert. es hat das Problem gelöst, ein neues APK hochgeladen.

Aber meine Frage ist, warum ich diese Nachricht nicht bekommen habe, während ich die App debugging? Wie kann ich sicher sein, solche Ausnahmen bei der Produktion zu vermeiden? Was fehlt mir hier?

(Hinweis: Ich habe die APK mit demselben Keystore signiert, den ich beim Testen und Verwenden von Eclipse verwendet habe).

Danke.

Answer 1

Wahrscheinlich wurde Ihr Release-Build durchlaufen und Obfuscator, die die Klassennamen verstümmelt, während die Debug-Builds nicht verschleiert wurden.

Android-Apps verwenden häufig ProGuard als Obfuscator/Optimizer.

Warum es mit den ursprünglichen Klassennamen funktioniert, liegt daran, dass das Bibliotheksprojekt eine Proguard-Konfigurationsdatei enthält, die Regeln enthält, um die bestimmten Klassen nicht zu verschleiern, da sie dynamisch aus XML-Layouts referenzierbar sein müssen. Wenn Sie den Paketnamen änderten, stimmte die Obfuscator-Regel nicht mit dem neuen Paketnamen überein.

Insbesondere sucht proguard-project.txt im Projektverzeichnis und dort Regeln wie

-keep public class foo.somepackage.SomeClassName 

und stellen Sie sicher, dass die Regeln aktualisiert werden, wenn Sie Paket oder Klassennamen ändern.