2016-05-12 23 views
6

NOVITÀ: la cosa principale che sto cercando è una correzione per i numeri di riga sbagliati. Ciò rende quasi impossibile individuare i vari arresti anomali.Studio Android: numeri di riga proguard errati, non completamente offuscanti

Ad un certo punto del passato, la mia offuscazione del proguard ha smesso di funzionare correttamente, o almeno così sembra. Nel seguente snip del file di registro, si noti che i miei identificatori BasicList e ImageClick vengono visualizzati nel file. Tuttavia, è chiaro che Proguard è in esecuzione poiché non sono presenti obfucscations.

In secondo luogo, per la riga BasicList, mostra un numero di riga di 6218. Il mio file sorgente non ha dove vicino a quelle molte linee. Per essere chiari, non è neanche una postura di personaggi.

E/InputEventReceiver(3814): Exception dispatching input event. 
E/MessageQueue-JNI(3814): Exception in MessageQueue callback: handleReceiveCallback 
E/MessageQueue-JNI(3814): java.lang.NullPointerException 
E/MessageQueue-JNI(3814): at com.perinote.perinote2.BasicList.a(SourceFile:6218) 
E/MessageQueue-JNI(3814): at com.perinote.perinote2.ae.onClick(SourceFile:266) 
E/MessageQueue-JNI(3814): at android.view.View.performClick(View.java:4240) 
E/MessageQueue-JNI(3814): at com.perinote.widgets.ImageClick.onTouchEvent(SourceFile:1156) 
E/MessageQueue-JNI(3814): at android.view.View.dispatchTouchEvent(View.java:7384) 
E/MessageQueue-JNI(3814): at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2209) 

mio Proguard-project.txt ha le seguenti

-renamesourcefileattribute SourceFile 
-keepattributes SourceFile,LineNumberTable 

-assumenosideeffects class android.util.Log { ... stuff ... } 

Tutte le idee?

risposta

0

L'opzione -renamesourcefileattribute SourceFile indica a Proguard di nascondere i nomi file originali e di visualizzarli come "SourceFile". Perciò i lenzuoli saranno cambiati.

Al fine di ripercorrere la traccia dello stack originale è necessario mappare le fonti offuscato per le fonti orginal aggiungendo la seguente opzione al proguard-project.txt:

-printmapping mapping.txt 

Hai due opzioni per decodificare la pila offuscato traccia:

metodo GUI

  1. aperto {android-sdk}/strumenti/Proguard/bin/Pro guardgui.bat
  2. Selezionare l'opzione “ritornare” sulla colonna di sinistra
  3. Aggiungi il tuo file di mapping e offuscato traccia dello stack
  4. Fare clic su “Ripercorrere!”
  5. metodo

CLI

  1. Metti la traccia dello stack offuscata in un file di testo (ad esempio: stacktrace.txt)
  2. Copia il mapping.txt e stacktrace.txt in/tools/proguard/bin
  3. Su Windows, eseguire il seguente comando nella stessa directory dei file: retrace.bat -verbose mapping.txt stacktrace.txt> out .txt
  4. out.txt avrà lo stack trace de-offuscato

è possibile trovare una spiegazione più dettagliata here

Speranza che aiuta. Saluti.

+0

Siamo spiacenti, questo non aiuta. Il problema fondamentale è che i numeri di riga sono sbagliati. Tutta la mappatura funziona con i simboli ma non fa nulla con i numeri di riga. –

0

Una volta ho avuto un problema molto simile, con la eccezione di ingresso dispacciamento Evento, e per risolverlo, sono andato aggiungendo Proguard ogni cartella con il codice, utilizzando questa linea:

-keep class !com.MyPackage.folderActivity { *; } 

Nel caso in cui che l'offuscamento fallito dopo aggiungere una cartella, è possibile aggiungere classe per classe della stessa cartella utilizzando qualcosa di molto simile:

-keep class !com.MyPackage.folderActivity.ActivityOne { *; } 

all'inizio si tratta di un processo molto lento, ma poi E'facile da mantenere.

Beh, spero che questo sia utile.

+0

La mia comprensione di "keep" è che istruisce proguard a non rimuovere il codice dall'app, cosa che farà se rileva che il codice non è utilizzato. Non sono sicuro di cosa ciò avrebbe a che fare con i numeri di riga. Tuttavia, la prossima volta che trovo l'output del registro con numeri di riga errati, proverò questo. Se funziona, sarò felice di assegnarti il ​​giusto credito di risposta! –

+0

hai ragione, ma il "!" il segnale è uno dei caratteri jolly di proguard che funziona come un negatore, quindi, in questo caso, dice a proguard di fare l'azione opposta, offuscando solo quella cartella o attività. Questo può essere utile per te, per trovare quale classe ha troppe dipendenze che causano l'errore con linee di numeri elevati. Su questo link puoi controllare altri caratteri jolly: https://stuff.mit.edu/afs/sipb/project/android/sdk/android-sdk-linux/tools/proguard/docs/index.html#manual/usage.html – ZLNK

+0

Cosa intendi per "classe ha troppe dipendenze"? –