La concorrenza: iOS

Quando si sviluppa un’applicazione per iOS controllare i dati della propria app su filesystem è tutt’altro che un problema, perché è possibile ispezionare i dati di ogni applicazione installata (in test) su ciascun simulatore, semplicemente con il Finder.
Il percorso di questi file è cambiato tra la versione 7 e la 8 di iOS, e ora i file si trovano su ~/Library/Developer/CoreSimulator/Devices/_DEVICE_UDID_/data/Container/Data/Application/_APPLICATION_ID_/....
Purtroppo gli id dei dispositivi e delle applicazioni sono delle sequenze di numeri e lettere tutt’altro che parlanti, ma basta capire come con Xcode è possibile ispezionare questi codici, o meglio ancora che è sufficiente stampare sul log della propria applicazione i percorsi interi e poi andarseli a guardare, e i dati delle nostre applicazioni mobile non avranno più segreti.

Il robottino verde è più timido

Quando si passa ad Android le cose si fanno più complicate. Per cominciare i dati possono essere salvati nella directory privata data/data/appid o in aree per così dire “pubbliche” ma sempre in cartelle con lo stesso nome dell’appid, che possono trovarsi nella root o in /Android/. E’ importante scegliere bene dove salvare i dati, perché quelli più “strategici” dovrebbero essere protetti il più possibile, mentre altri più di pubblico dominio sarebbe meglio lasciarli accessibili anche da applicazioni terze, per offrire maggiori funzionalità.
Detto che il similatore classico di Android è indegno di essere paragonato a quello di iOS, con l’arrivo di Genymotion anche gli sviluppatori Android si sono ritrovati con una valida alternativa ai dispositivi fisici, ma in questo caso l’accesso ai dati è più problematico rispetto a iOS.

Accesso fisico ai file da un dispositivo o da Genymotion

A differenza dei dispositivi Apple quando si parla di Android i file manager non sono utopia ma vengono installati di default o è possibile comunque scaricarsene di buoni senza spendere un centesimo.

Su Genymotion sarebbe possibile installare i Google play services per poi scaricarsi qualunque app presente sul market, ma se abbiamo bisogno solo di un file manager qualunque ce n’è già uno preinstallato.

Fin qui tutto semplice, e per prendere i file senza tanti giri strani è sufficiente condividerli, ad esempio con Dropbox. Ma come fare per andare a sficcanasare tra i file privati e/o a copiarsi tutti i file dell’app?

ADB, ovvero il ponte

ADB è un tool presente nell’sdk di Android con cui è possibile fare tante cose carine, tra cui copia di file, backup, esecuzione di query sui db sqlite delle varie app e chi più ne ha più ne metta.
L’eseguibile dell’Android Debug Bridge si chiama “adb” e lo si può trovare nella platform-tools interna alla directory di installazione dell’sdk Android.
L’sdk di Android può essere ovunque perché dipende da chi o cosa l’ha installato, ma in genere sta in:
/Users/username/Library/Android/sdk/ (Mac)
C:\Users\username\AppData\Local\Android\sdk (Windows)
perché questi sono i percorsi di default quando si installa Android Studio.

Alcuni comandi e limitazioni varie

Con l’adb si può:

• visualizzare la lista dei dispositivi/simulatori disponibili: ./adb devices
• collegarsi alla shell di un dispositivo/simulatore per eseguire operazioni su file system: ./adb -s device shell
• una volta che si è dentro la shell si possono visualizzare le app installate: ls data/data

… e tante altre cose. Ma la cosa che ha me è servita di più è la creazione di un backup dell’app, perché purtroppo succede che la documentazione dell’sdk che stiamo utilizzando sia fallace e ci induca a utilizzare percorsi sbagliati per salvare e caricare i nostri database… e lo scaricarmi in locale una copia dell’applicazione è stato illuminante in questo senso.
Purtroppo se il dispositivo a cui ci colleghiamo è ancora “integro” (non ci siamo collegati con l’utente root) alcune operazioni ci saranno proibite per mancanza di permessi. Peccato.

Backup dei dati di un’applicazione

Stabilito che in uno dei dispositivi collegati e accesi (telefono o simulatore) c’è un’app con appid uguale a it.blabla.boh, per farne il backup è sufficiente eseguire il comando:
./adb backup -noapk it.blabla.boh
Appena eseguito sul dispositivo/simulatore viene richiesta una conferma con eventuale inserimento di password.

Il risultato è la creazione di un file backup.ab dentro la cartella platform-tools. Questo file è abbastanza rognoso, ma per decomprimerlo senza grandi patemi esiste un programmino chiamato Android Backup Extractor (abe) che può essere scaricato da qui e il cui progetto si può trovare su GitHub.

La decompressione del file .ab in un .tar (a sua volta decomprimibile normalmente) è cosa (in teoria) semplice:
java -jar abe.jar unpack backup.ab backup.tar [password]

A volte funziona tutto, a volte l’abe va in errore non si sa il perché. Potrebbe dipendere dalla versione di Android installata sul dispositivo/simulatore, a me con la 4.3 è andata liscia, ma quando ci ho riprovato su un altro computer non ce l’ho fatta… Il file .ab comunque può essere decompresso anche in altri modi, se così non ce la fate buona ricerca.