2017-08-10 2 views
4

In einer Apk verwende ich eine AAR-Bibliothek, die eine native Bibliothek enthält. Beim Versuch, die MD5-Prüfsumme der .so-Datei zur Laufzeit zu berechnen, bemerkte ich, dass sie sich von der .so-Datei innerhalb der aar unterschied. Die Größe der Datei ändert sich auch: Die Datei in der APK wiegt etwa 20 Bytes weniger. Weiß jemand, warum der Apk-Erzeugungsprozess diese Art von Dateien verändert? Kann ich irgendetwas tun, um die Datei intakt zu halten?APK-Generierung ändert die Größe der .SO-Datei

Es passiert nur für die arm64-Version.

+0

ist die native Bibliothek als vorkompilierte Binärdatei enthalten oder wird sie vom NDK kompiliert und erstellt? – rupps

+0

Von Gomobile kompiliert und erstellt und dann in die endgültige .aar-Bibliothek kopiert. – achojoao

Antwort

0

In meinem App/Build-Ordner habe ich gesehen, dass die .so-Datei auch in intermediates/transforms/mergeJniLibs und intermediates/transforms/stripDebugSymbol gefunden wurde. Die md5sum der .so-Datei in mergeJniLibs stimmte mit der Summe der ursprünglichen .so-Datei überein. Die md5sum der .so-Datei in stripDebugSymbol war die, die anders war. Weitere Untersuchungen hat mich dazu gebracht, dies zu dem Android-Abschnitt des Moduls build.gradle hinzuzufügen (siehe auch: PackagingOptions doNotStrip documentation ):

android { 
    . 
    . 
    packagingOptions { 
     doNotStrip "**/*.so" 
    } 
    . 
} 

Nach einem Gradle sync, sauber und neu zu erstellen, die MD5-Summe der .so in app/build/outputs/apk/debug stimmt mit der ursprünglichen md5sum überein.

+0

Während dieser Link die Frage beantworten kann, ist es besser, die wesentlichen Teile der Antwort hier aufzunehmen und den Link als Referenz zur Verfügung zu stellen. Nur-Link-Antworten können ungültig werden, wenn sich die verknüpfte Seite ändert. - [Aus Bewertung] (/ review/low-quality-posts/19049901) – EJoshuaS

+0

Aktualisiert, um den Antworttext anstelle eines Links zu einer anderen Frage hinzuzufügen. –

Verwandte Themen