• ROM, invisible from Android user interface. It is really mounted as read/only filesystem under /sytem. It can be flashed from Recovery menu or remounted read/write using root privileges.
• Internal Storage (Archivio interno in italiano). Mounted as read/write under /data, is where your apps are stored. This storage is not accessible from your computer when connected via USB cable.
• Phone Storage (Memoria telefono in italiano), it is where user media (pics, music etc) are stored. When you connect your phone to your computer, this storage is accessible and you can copy files between them.
• SD Card (if any)

Links:

• What is Difference between Internal, Phone and External Storage? Android Storage Explained.
• RAM-a-lama don't be a ding ding about Android storage

L'ADB (Android Debug Bridge) consente operazioni di base, quali la copia di file tra PC e terminale e soprattutto l'accesso shell sul terminale stesso. Per attivarla su Android si deve anzitutto abilitare le Opzioni sviluppatore, cioè un menu solitamente nascosto di Impostazioni. ecco la procedura che funziona sia su Android 4.4 KitKat che su Android 5.x Lollipop:

• Impostazioni ⇒ Info sul telefono ⇒ Numero build (fare tap 7 volte)
• Impostazioni ⇒ Opzioni sviluppatore ⇒ Debug Android (attivare)

In inglese:

• Settings ⇒ About phone ⇒ Build number (tap 7 times)
• Settings ⇒ Developer Options ⇒ USB debugging (enable)

Con versioni di Android più vecchie provare qualcosa del genere:

• Impostazioni ⇒ Applicazioni ⇒ Sviluppo ⇒ Debug USB
• Settings ⇒ Applications ⇒ Development ⇒ USB Debugging
• Settings ⇒ Developer Options ⇒ USB Debugging

Quando si collega un PC al dispositivo Android e dal PC si esegue il comando adb shell, sul device appare la richiesta Allow USB debugging?. Solo dopo aver risposto affermativamente viene eseguita la shell su Android. L'autorizzazione del dispositivo non è permanente, ma scade dopo un certo periodo di tempo, per evitare tale scadenza è necessario modificare le impostazioi da

• Settings ⇒ System ⇒ Developer options ⇒ Disable adb authorization timeout

Con il passare del tempo Google obbliga l'installazione di nuovi programmi non richiesti. Oltre ad occupare memoria flash (il cosiddetto archivio interno) spesso attivano anche servizi che occupano memoria RAM e rallentano tutto l'apparecchio. I programmi spesso sono classificati come applicativi di sistema e non possono essere disinstallati.

Per fortuna con il telefono sbloccato (ottenuti cioè i permessi di root) è possibile rimuovere anche queste componenti. Ovviamente si deve stare attenti a cosa si disinstalla, è possibile bloccare definitivamente alcune funzionalità essenziali del telefono. Per disinstallare questi applicativi ho usato App Master(Uninstall Master) (software non libero).

Il risultato è stato molto soddisfacente: un telefonino (Nexus S del 2011, con Android 4.1.2) che sembrava arrivato alla fine dei suoi giorni perché rallentato e non responsivo, è tornato praticamente come nuovo. E non ho rinunciato ad alcuna funzionalità!

Segue l'elenco dei programmi che ho tolto.

• Archiviazione contenuti protetti con DRM
• Email (EmailGoogle.apk)
• Google Play Magazines
• Google Play Services ripristinato perché richiesto da Maps e Calendar
• Google Talk
• Google Play Books
• Google Play Edicola
• Google Play Movies
• Google Play Music
• Google+
• Hangouts
• Movie Studio
• MusicFX
• TalkBack

Maps e Calendar ogni tanto si lamentano se si toglie Google Play Services (compare un avviso nella barra dei messaggi), ma il funzionamento di entrambi non sembra compromesso.

Ovviamente sul mio telefonino non uso contenuti protetti da DRM, non ci guardo i film, né acquisto libri e riviste tramite i servizi Google.

Con Audacity si prepara una traccia stereo, a 44100 kHz, 16 bit PCM. Se necessario aggiustare il campionamento (da Tracks, Resample) e il formato (menu a discesa della traccia, Set Sample Format).

In generale le suonerie hanno un'ampiezza che non va oltre +/- 0.5, eventualmente aggiustare con Effect, Amplify.

Dal menu File, Export salvare in formato ogg. Il nome del file conviene averlo alla Unix way: tutto minuscolo con gli underscore invece degli spazi. Eventualmente specificare il Track Title con maiuscole, spazi, ecc.

Nella SDCard creare le directory /sdcard/media/audio/{alarms|notifications|ringtones} che contengono rispettivamente gli allarmi (es. sveglia), i suoni per le notifiche (es. arrivo SMS) e le suonerie (es. telefonata in arrivo). Le suonerie di sistema sono invece in /system/media/audio/.

La scansione dei nuovi file avviene al riavvio del telefono. Per impostare i suoni accedere a Impostazioni, Audio.

Pare che vengano scansionate anche le directory Alarms, Notifications e Ringtones contenute nella radice della sdcard interna (/storage/sdcard0) e quella esterna (percorso che dipende dal S.O. del telefono).

In generale il filesystem /system è montato read-only e quindi neanche all'utente root è permesso effettuare modifiche. Se si deve intervenire sui file è possibile rimontare provvisoriamente con i permessi di read/write. Da riga di comando adb shell:

su -mm
mount -o remount,rw /system
mount -o remount,ro /system

L'opzione -mm passata a su consente di manipolare l'intero spazio dei montaggi (can manipulate the master mount namespace). Senza questa opzione l'utente root non ha accesso ai filesystem esterni vfat (memoria telefono e SD card).

Un buon programma per l'emulazione terminale è Terminal Emulator for Android di Jack Palevich. È possibile personalizzare il profilo modificando il file /system/etc/mkshrc.

Le password delle reti WiFi, sebbene memorizzate nel telefono e pure comunicate a Google, non sono visibili dall'interfaccia utente del telefono. Il file in effetti viene memorizzato in /data/misc/wifi/wpa_suppliciant.conf, con un file manager ed accesso root è possibile copiarlo, ecc.

La posizione del file cambia a seconda della variante di Android, è documentato che in alcune versioni Android Oreo si trova in /data/wifi/bcm_supp.conf oppure /data/misc/wifi/wpa.conf. Altrimenti potrebbe essere memorizzato in formato XML, ad esempio su un Android One Oreo 8.1.0 esiste il file /data/misc/wifi/WifiConfigStore.xml.

Su uno smartphone Oukitel WP12 con Android 11 il file si trova in /data/misc/apexdata/com.android.wifi/WifiConfigStore.xml.

Gran parte dello spazio utilizzabile dall'utente (per foto, download, ecc.) va sotto il nome di Phone Storage (Memoria telefono in italiano) e - se disponibile - SD Card (Scheda SD in italiano). Entrambe le memorie vengono chiamate memoria esterna, nonostante che in generale la memoria del telefono è saldata dentro e non rimuovibile. Va intesa esterna in quanto esportata verso il PC collegato al cavetto USB.

Quando si connette il telefono al PC tramite cavetto USB e si attiva l'archivio USB, al PC vengono esposti degli usb-storage con filesystem vfat, che è possibile montare. Ad esempio un telefono con Phone Storage di 4 Gb e scheda SD aggiuntiva da 32 Gb espone i seguenti device:

sd 5:0:0:0: [sdc] Attached SCSI removable disk
sd 5:0:0:1: [sdd] Attached SCSI removable disk
sd 5:0:0:1: [sdd] 61407232 512-byte logical blocks: (31.4 GB/29.2 GiB)
  sdd: sdd1
 sd 5:0:0:0: [sdc] 8116224 512-byte logical blocks: (4.15 GB/3.87 GiB)
  sdc:

Come si vede la scheda SD è partizionata, mentre la memoria del telefono no.

In generale sul telefono le partizioni sono montate dal sistema operativo Android in /storage/sdcard0 e /storage/sdcard1. Un link simbolico /sdcard → /storage/sdcard0 è di fatto lo storage predefinito.

A partire da Android 4.4 KitKat questi storage non sono trattati nella stessa maniera: la memoria del telefono è considerata lo storage esterno primario, mentre la SD card è considerata lo storage esterno secondario, da questo illuminante post su OsmAnd si legge:

• A partire da Android 4.4 KitKat lo storage esterno primario e secondario non sono gestiti allo stesso modo.
• A partire da KitKat i permessi READ_EXTERNAL_STORAGE/WRITE_EXTERNAL_STORAGE non riguardano lo storage esterno secondario (SD card). Anche se una applicazione ha questi permessi, non può accedere allo storage esterno secondario, ma può scrivere sul primario.
• L'unico modo per scrivere nello storage esterno secondario è utilizzare la propria cartella, ad esempio quella restituita dalla funzione getExternalFilesDirs().

In genere un'applicazione può scrivere solo in una directory della SD card, che deve avere esattamente il nome /storage/sdcard1/Android/data/<package_name>/, dove package_name è il nome dell'app che si deduce dal nome del file .apk contenuto in /data/app/ (ad esempio com.whatsapp per il file com.whatsapp-1.apk).

Pare che in Android 5.0 la gestione della SD card sia migliorata, vedere l'articolo evidenziato sotto.

Se il device è rooted, è possibile impostare gli stessi permessi di lettura/scrittura per la memoria esterna primaria e secondaria eseguendo una tantum l'applicazione SDFix. Il programma modifica il file /system/etc/permissions/platform.xml, in modo tale che alle applicazioni con permesso WRITE_EXTERNAL_STORAGE sia aggiunto il gruppo media_rw. Attenzione che il progamma sciupa l'indentatura del file e gli spazi, quindi chi ha un minimo di pratica con la riga di comando può editare direttamente il file (dopo aver rimontato il filesystem in read/write):

<permission name="android.permission.WRITE_EXTERNAL_STORAGE" >
    <group gid="sdcard_r" />
    <group gid="sdcard_rw" />
    <group gid="media_rw" />
</permission>

Riferimenti web:

• External Blues: Google Has Brought Big Changes To SD Cards In KitKat, And Even Samsung Is Implementing Them
• Android 5.0 Makes SD Cards Great Again, Extends API To Allow Full Directory Access, Automatic MediaStore, And Improves Security
• Download or update on external SD-card not possible anymore since Android update to 4.4.2

Le vecchie versioni di Android (< 4.4) esponevano il contenuto del filesystem (non tutto, solo lo storage utente) tramite il protocollo USB Mass Storage. Questo protocollo è supportato nativamente da quasi tutti i sistemi operativi, GNU/Linux compreso, e non richiede l'installazione di particolare software. Tuttavia c'è il problema che l'accesso concorrente al filesystem diventa pericoloso, per cui in genere le app Android vengono bloccate mentre si effettua l'accesso da PC. Vedere in proposito l'articolo Android USB Connections Explained: MTP, PTP, and USB Mass Storage.

Per ovviare al problema sui nuovi Android viene usato il protocollo MTP (Media Transfer Protocol), che con GNU/Linux richiede in generale l'installazione del software relativo. Si tratta di una implementazione in user space, tramite FUSE, quindi non sono necessari i permessi di root per accedere allo storage.

Il pacchetto Debian necessario è jmtpfs (backport per Wheezy e Jessie) oppure mtpfs per la vecchia Squeeze.

Per montare il primo dispositivo che risulta collegato (attenzione: bisogna eventualmente sbloccare lo scehermo del telefonino):

mkdir media/android
jmtpfs media/android/
ls -F media/android/
Card/  Phone/

Per lo smontaggio si usa fusermount -u.

Oltre a questa implementazione FUSE esiste anche il pacchetto mtp-tools che contiene diversi esempi di programmi user-space. Sono considerati solo esempi perché ancora poco maturi per un uso quotidiano. Dovrebbero servire ad accedere ai vari contenuti dei dispositivi MTP (player multimediali, dispositivi Android, …).

Per la gestione da riga di comando dei pacchetti apk esiste il tool pm. Con le applicazioni di sistema (system app) potrebbero esserci delle complicazioni, forse legate al filesystem montato read-only o forse dovute ai permessi utente. Vedere pià avanti un problema (risolto) con il comando pm uninstall.

Esiste un tool per scompattare/ricompattare i pacchetti: android-apktool Apktool.

1. Scaricare l'archivio jar
2. Verificare di avere java -version 1.7
3. Creare un batch apktool che esegua java -jar apktool_2.0.0rc2.jar $@

Per estrarre il contenuto di un archivio:

apktool d Superuser.apk 
I: Using Apktool 2.0.0-RC2 on Superuser.apk
I: Loading resource table...
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /home/niccolo/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
Cleaning up unclosed ZipFile for archive /home/niccolo/apktool/framework/1.apk
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...

Icone e immagini sono contenute nelle directory res/drawable-*. La nazionalizzazione delle stringhe è contenuta nel file res/values/strings.xml. Ecco ad esempio compe appare il nome di un programma tradotto in Cinese:

<string name="app_name">安卓清理大师</string>

Per la gestione dei pacchetti da riga di comando esiste pm, vedere le guide:

• Android Debug Bridge
• What useful Android Shell commands do you know?

Ad esempio:

pm install /storage/sdcard0/Download/Termux-com.termux-0.42-42.apk

Alcuni errori riscontrati durante l'installazione:

Per rimuovere una app si usa il comando:

pm uninstall com.android.service

L'esempio si riferisce ad una system app presente in /system/priv-app/, classificata come harmful da Google Play Protect e come spyware da alcuni siti. Pare che sia installata da alcuni produttori di telefonini. Il comando di disinstallazione fallisce con questo errore:

Failure [DELETE_FAILED_INTERNAL_ERROR]

L'errore accade nonostante che venga eseguito da root, anche rimontando il filesystem /system in modalità read-write ed avendo disattivato e terminato l'app dal menu Impostazioni ⇒ App del telefono. È stato necessario utilizzare questa variante del comando:

pm uninstall -k --user 0 com.android.service

In realtà questo non disistnalla la app, ma la rende non disponibile per l'utente 0 (root), quindi se ne dovrebbe impedire completamente l'esecuzione. Per completare l'operazione pare indispensabile rimonatare il filesystem read-write e cancellare la directory /system/priv-app/com.android.service-9002_0711/.

Alcune app affiancano al file .apk, un archivio .odex. Si tratta di un archivio che contiene parte del codice della app (pseudo-codice che viene compilato dalla macchina virtuale Dalvik) già compilato Ahead-of-time (AOT) e pronto per l'esecuzione. In questo modo la app non occupa spazio nella cache di Dalvik e la sua prima esecuzione è più rapida. Per contro la modifica di una applicazione risulta più complessa, poiché il codice è suddiviso in archivi diversi.

Provato con Android 6.0.

Le normali applicazioni utente vengono installate nella directory /data/app/, mentre le applicazioni di sistema si trovano in /system/app/ oppure in /system/priv-app/. I programmi come App Backup & Restore fanno il backup anche delle app di sistema, ma se vengono usate per farne il restore in genere le installano come app utente.

Con una shell di root è possibile promuovere una app utente ad app di sistema, facendo attenzione alle convenzioni dei nomi dei file. Ad esempio il file /data/app/com.mediatek.omacp-1/base.apk deve essere rinominato e spostato in /system/app/Omacp/Omacp.apk,

mount -o remount,rw /system
mkdir /system/app/Omacp
chmod 755 /system/app/Omacp
cp -p /data/app/com.mediatek.omacp-1/base.apk /system/app/Omacp/Omacp.apk
chmod 644 /system/app/Omacp/Omacp.apk
reboot

NOTA: La directory lib/ pare che non sia necessario copiarla, mentre è indispensabile rimettere l'eventuale file oat/arm/<appName>.odex eventualmente presente.

L'app ha un nome breve Omacp e uno esteso com.mediatek.omacp-1, dove si ottengono queste informazioni?

Android Studio è l'ambiente di sviluppo ufficiale Android. Al suo interno sono contenute le varie componenti che un tempo si potevano scaricare e installare sepraratamente, come l'SDK e i Platform Tools.

ATTENZIONE! Pare che Google abbia deciso di rendere nuovamente disponibili i Platform-tools come download separato (pochi megabyte invece dei centinaia dell'SDK). Controllare la pagina SDK Platform Tools Release Notes per il download.

Dopo aver scaricato l'archivio (es. android-studio-ide-145.3330264-linux.zip) lo si scompatta e per l'installazione si esegue bin/studio.sh. Durante l'installazione viene identificata l'architettura e scaricato il software relativo, viene creata una directory $HOME/Android/Sdk/ e la directory con le impostazioni personali $HOME/.AndroidStudio2.2. Il contenuto originale dell'archivio può essere spostato nella stessa cartella $HOME/Android/ al termine dell'installazione.

Per avviare l'ambiente si esegue $HOME/Android/bin/studio.sh.

L'ADB (Android Debug Bridge) viene installato in $HOME/Android/Sdk/platform-tools/, in generale bisogna prima avviare la parte server con i privilegi di root e quindi si possono eseguire i vari comandi anche come utente non privilegiato.

Ecco ad esempio come ottenere una shell interattiva su un terminale Android collegato tramite USB, sul telefono si deve aver attivato l'opzione Debug USB:

su -c "$HOME/Android/Sdk/platform-tools/adb start-server"
# Esegue una shell interattiva sul terminale collegato via USB:
$HOME/Android/Sdk/platform-tools/adb shell

Col telefono collegato via USB e l'opzione USB debug attiva, dal PC si lancia il comando adb di SDK (richiede permessi di root sul PC):

./platform-tools/adb backup -f nexus-s_2014-10-23.ab -apk -obb -shared -all -system

Nel backup vengono compresi:

• Backup apk packages and expansions (obb), stored into the archive path /apps/<package>/a/<filename>.apk.
• Backup shared SD card contents
• Backup all installed applications, including system ones

sul telefono compare una richiesta di conferma ed una eventuale password. Per effettuare il backup di 6 Gb ci sono volute quasi due ore.

Come si fa il restore, eventualmente selettivo?

Da questo utilissimo post How do you extract an apps data from a full backup made through adb backup, si apprende che un backup Android è un archivio tar compresso con l'alogritmo deflate, inoltre - se è stata impostata una password - il tutto è cifrato con AES. L'header della compressione deflate non è standard. Sembra che ci siano funzioni non documentate oppure bug nel modo in cui viene creato l'archivio, se si usa l'opzione -system la compressione potrebbe non essere attiva e il file tar potrebbe contenere byte extra, vedere questo post.

Ci sono varie soluzioni per esplorare il contenuto dell'archvio, programmi per Windows, oppure le AdbBackupRoutines scritte in Perl. Gli script dipendono da alcune librerie (ma quelle relative alla crittografia possono essere commentate dal codice, se non si usano backup compressi): libterm-readkey-perl, libcrypt-cbc-perl, libcrypt-pbkdf2-perl (solo in Debian Jessie). Con questo comando si trasforma un backup Android in un file tar:

backupdecrypt.pl nexus-s_2014-10-23.ab nexus-s_2014-10-23.tar

La modalita fastboot in genere non esiste sui telefonini Samsung, operazioni come il flash di nuove immagini si possono fare mettendo il telefono nella modalità Odin e usando il software Heimdall.

Con questo comando impartito dal PC si riavvia il telefono nel programma bootloader (fastboot menu). Sul PC servono i Platform Tools dell'SDK Android e sul telefono si deve aver impostato l'opzione USB debug:

adb reboot bootloader

Quanto il telefono è in modalità fastboot, il comando adb dal PC non serve, bisogna utilizzare piuttosto il comando fastboot anch'esso fornito con l'SDK Android (richiede i permessi di root sul PC):

./platform-tools/fastboot devices
38353D90950E00EC        fastboot

Queste sono alcune delle operazioni che si possono fare in modalità fastboot (eseguire sul PC il comando fastboot senza argomenti per avere un aiuto):

• update: reflash device from update.zip
• flashall: flash boot + recovery + system
• flash: scrivere un file su una partizione della flash memory.
• oem unlock: sblocco del bootloader (ATTENZIONE! Esegue un reset di fabbrica e cancella tutti i dati!). Con questa operazione sarà possibile installare (flashare) un'immagine non firmata, ad esempio una Recovery ClockworkMod più potente della stock.

Per entrare nel menu Recovery di solito si preme una combinazione speciale di tasti durante l'accensione del telefono (es. volume + insieme a power). In alternativa si utilizza il seguente comando da adb:

adb reboot recovery

Queste alcune azioni che è possibile fare dalla System Recovery:

• Installare un aggiornamento del sistema operativo (richiede un file firmato digitalmente).
• Cancellare i dati e fare un factory reset.
• Fare il backup o restore dei dati utente.

In generale il System Recovery Menu fornito di fabbrica non consente alcne operazioni più potenti e pericolose, ad esempio l'installazione direttamente da un file .zip presente sulla SD card, ignorando le firme digitali. Questo è il motivo per cui esistono delle recovery personalizzate come la ClockworkMod, spiegata bene in questo articolo.

In generale con un terminale che ha il boot loader sbloccabile (es. un terminale Google della famiglia Nexus), la procedura è la seguente:

1. Dal modo fastboot, sblocco del boot loader (cancella tutti i dati ed esegue un factory reset!).
2. Dal modo fastboot, installazione di una Recovery personalizzata non firmata digitalmente (es. ClockworkMod).
3. Dalla recovery personalizzata, installazione di uno .zip non firmato digitalmente, in genere si installa il programma su che fornisce i privilegi di root. Per la gestione di tali permessi si utilizza in genere una app come SuperSU oppure Superuser.

Con un terminale non sbloccabile la procedura varia a seconda del modello, in generale segue questi passi:

1. Trovare un modo per ottenere i privilegi di root. In alcuni casi ci si basa su delle vulnerabilità del sistema operativo originale e quindi è sufficiente installare una app apposita (es. Framaroot o Towelroot). In altri casi è necessario un programma installato su PC che invia qualche comando specifico tramite cavo USB (il telefono deve avere il modo USB debug attivo). Un programma molto diffuso per questa attività è VRoot. Al termine di questa operazione si ha l'eseguibile su installato e una app di gestione come SuperSU oppure Superuser.
2. Installazione di una app per la gesione delle ROM, ad esempio ROM Manager direttamente dal Google Play. Questo programma ha bisogno dei permessi di root.
3. Si utilizza il ROM Manager per installare una Recovery personalizzata o intere ROM alternative (l'intero sistema operativo) sul telefono.

Sembra diffusa la prassi di utilizzare la directory /data/local/ in modo equivalente alla /usr/local/ di una distribuzione GNU/Linux, cioè quella directory in cui il sysadmin installa binari, script, ecc. validi per tutto il sistema.

Vedere ad esempio l'installazione degli Android ports.

Questo è il tipico schema di partizioni usato da un dispositivo Android. Vedi l'articolo originale qui: Android Partitions Explained: boot, system, recovery, data, cache & misc.

This is the partition that enables the phone to boot, as the name suggests. It includes the kernel and the ramdisk. Without this partition, the device will simply not be able to boot. Wiping this partition from recovery should only be done if absolutely required and once done, the device must NOT be rebooted before installing a new one, which can be done by installing a ROM that includes a /boot partition.

This partition basically contains the entire operating system, other than the kernel and the ramdisk. This includes the Android user interface as well as all the system applications that come pre-installed on the device. Wiping this partition will remove Android from the device without rendering it unbootable, and you will still be able to put the phone into recovery or bootloader mode to install a new ROM.

The recovery partition can be considered as an alternative boot partition that lets you boot the device into a recovery console for performing advanced recovery and maintenance operations on it.

Also called userdata, the data partition contains the user’s data – this is where your contacts, messages, settings and apps that you have installed go. Wiping this partition essentially performs a factory reset on your device, restoring it to the way it was when you first booted it, or the way it was after the last official or custom ROM installation. When you perform a wipe data/factory reset from recovery, it is this partition that you are wiping.

This is the partition where Android stores frequently accessed data and app components. Wiping the cache doesn’t effect your personal data but simply gets rid of the existing data there, which gets automatically rebuilt as you continue using the device.

This partition contains miscellaneous system settings in form of on/off switches. These settings may include CID (Carrier or Region ID), USB configuration and certain hardware settings etc. This is an important partition and if it is corrupt or missing, several of the device’s features will will not function normally.

This is not a partition on the internal memory of the device but rather the SD card. In terms of usage, this is your storage space to use as you see fit, to store your media, documents, ROMs etc. on it. Wiping it is perfectly safe as long as you backup all the data you require from it, to your computer first. Though several user-installed apps save their data and settings on the SD card and wiping this partition will make you lose all that data.

On devices with both an internal and an external SD card – devices like the Samsung Galaxy S and several tablets – the /sdcard partition is always used to refer to the internal SD card. For the external SD card – if present – an alternative partition is used, which differs from device to device. In case of Samsung Galaxy S series devices, it is /sdcard/sd while in many other devices, it is /sdcard2. Unlike /sdcard, no system or app data whatsoever is stored automatically on this external SD card and everything present on it has been added there by the user. You can safely wipe it after backing up any data from it that you need to save.

I got this problem on Android 4.4.2 (Kinkelon G9000, kernel 3.4.67, build G9000_20140815), using ping from terminal or adb shell:

ping www.google.com
This version of ping should NOT run with privileges. Aborting

It seems that the ping executable is installed with wrong permission. The fix needs root permission and remounting /system in read/write:

# ls -l /system/bin/ping                              
-rwxr-sr-x root     net_raw     26068 2014-08-15 06:17 ping
mount -o remount,rw /system
chmod 755 /system/bin/ping                            
mount -o remount,ro /system                           
# ls -l /system/bin/ping
-rwxr-xr-x root     net_raw     26068 2014-08-15 06:17 ping

I got this problem on Android 4.4.2 (Kinkelon G9000, kernel 3.4.67, build G9000_20140815), using OpenVPN for Android by Arne Schwabe. The app is free software, here it is the repository.

The problem is that all the traffic is routed to the VPN, routing options from the app are ignored. I opened issue #305.

The server configuration is TLS using certificates, multi-client. The server pushes some routes, for the server point-to-point address and for a local private network:

push "route 10.67.0.1"
push "route 192.168.3.0 255.255.255.0"

The client configuration does not have any route specification:

verb 4
client
dev tun
proto udp
remote vpnserver.rigacci.org 1194
nobind
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>

After the connection is established, this is the status for network packets outgoing from the Android device:

iptables -L -t mangle -n
...
Chain st_mangle_tun0_OUTPUT (2 references)
target     prot opt source               destination         
MARK       all  --  0.0.0.0/0            0.0.0.0/0            MARK and 0x0
MARK       all  --  0.0.0.0/0            10.67.0.1            MARK set 0x3c
MARK       all  --  0.0.0.0/0            192.168.3.0/24       MARK set 0x3c

ip rule show
0:      from all lookup local 
100:    from all fwmark 0x3c lookup 60 
32766:  from all lookup main 
32767:  from all lookup default 

ip route show table 60
default dev tun0  scope link

This means that packets that should be routed to the VPN are mangled with mark 0x3c, then routed via the routing table 60, and then forwarded to the tun0 device. This is OK!

The problem is that every packet goes through the VPN, this is because of two entries added into the main routing table:

ip route show table main
0.0.0.0/1 dev tun0  scope link 
...
128.0.0.0/1 dev tun0  scope link 

To fix the routing problem we have to run the following script (root required) on the Android device:

#!/system/bin/sh
/system/xbin/su -c '/system/bin/ip route del 0.0.0.0/1 dev tun0'
/system/xbin/su -c '/system/bin/ip route del 128.0.0.0/1 dev tun0'

Create the script into /data/local/bin/openvpn-route-fix, then add theese advanced custom options to the OpenVPN configuration:

script-security 2
up /data/local/bin/openvpn-route-fix

WARNING: in some cases - after removing the bogus VPN default routes - the VPN (private) source address is used for connections to the internet; this causes an invalid source addres routed to the internet. May be this is a problem only if you use the terminal to fix the default route and the same terminal e.g. to ping the internet.

Usually, when both WiFi and 3G data connection are enabled and availables, WiFi is preferred; no preferences are exposed by the Android user interface to change this behaviour.

Neverthless on a rooted device it is possibile to change the preferred data network, using the svc command from the terminal:

# svc data                                             
Control mobile data connectivity

usage: svc data [enable|disable]
         Turn mobile data on or off.

       svc data prefer
          Set mobile as the preferred data network

# svc wifi                                             
Control the Wi-Fi manager

usage: svc wifi [enable|disable]
         Turn Wi-Fi on or off.

       svc wifi prefer
          Set Wi-Fi as the preferred data network

Catturare la schermata del device Android da un PC collegato via adb:

adb shell screencap -p /sdcard/screen.png
adb pull /sdcard/screen.png
adb shell rm /sdcard/screen.png

In alcune versoni Android (es. Cyanogenmod 5.1.1) esiste l'opzione:

• Impostazoini ⇒ Opzioni sviluppatore ⇒ Accesso root: Solo ADB

se è attiva, l'accesso con adb shell da PC avviene direttamente come root, senza dover usare il comando su.

È possibile effettuare il backup di una cartella con il comando tar e creare l'archivio direttamente su PC con una formula del tipo:

adb exec-out "tar zcf - /sdcard/Documents 2> /dev/null" > Documents.tar.gz

L'opzione adb exec-out invece di adb shell garantisce che lo stdout prodotto dal comando viene passato inalterato al terminale (e quindi può essere rediretto su un file), altrimenti c'è il rischio che i caratteri newline vengano interpretati aggiungendo il carriage return o cose simili. Lo stderr va soppresso, altrimenti finirebbe nel file locale.

Per ripristinare sul device Android l'archivio presente sul PC:

cat Documents.tar.gz | adb shell "cd /sdcard/restore; tar zxf -"

Alcune app mettono a disposizione dei widget, cioè delle funzioni specializzate che possono trovare posto nella home screen del device, a fianco delle icone per avviare le app.

Risulta (almeno su un Android One 8.1.0 Oreo) che il widget non può funzionare se l'app viene installata nella SD Card, quella che viene chiamata anche memoria esterna per differenziarla dalla memoria interna che è la flash nativa del dispositivo. In pratica quando si fa un tap lungo sul desktop è possibile accedere all lista dei widget disponibili, nel caso in cui l'app sia installata nella memoria esterna, il widget non risulta più in elenco.

Dal menu Impostazioni ⇒ App e notifiche ⇒ Informazioni app ⇒ Spazio di archiviazione è possibile (per le app che lo supportano) scegliere in quale spazio di memoria far risiedere il programma, e quindi avere a disposizione o meno gli eventuali widget.

ATTENZIONE: Non funziona con tutti i terminali! Ad esempio non funziona con Samsung Galaxy S4 GT-I9515.

Dal tastierino di composizione telefonica digiare *#*#4636#*#*, si accede ad un menu di verifica per

• Informazioni telefono
• Informazioni batteria
• Statistiche di utilizzo
• WiFi Information

Ci sono un sacco di informazioni utili, come il codice IMEI, lo stato del roaming, statistiche traffico PPP, ecc.

• The most useful things you can do with adb and fastboot
• Android Partitions Explained: boot, system, recovery, data, cache & misc
• Boot Android from SdCard