Come ci sono riuscito? In realtà non è nulla di fantascientifico, è quello che si fa da sempre con i sistemi Unix. Semplicemente quando si ha poco spazio si monta una directory su di un'altra partizione più capiente. Nel nostro caso diciamo ad Android che la directory delle applicazioni utente e di tutte le dalvik cache non si trovano nella memoria interna, ma bensì nella 2a partizione della Sd card.
Poi come viene fatto tecnicamente… è tutto in queste linee di codice generico:
codice:
# Applicazioni
mount <2a partizione della SD card> /sd-ext
mount /data/app /sd-ext
# Dalvik cache
mkdir /sd-ext/dalvik-cache
mount /data/dalvik-cache /sd-ext/dalvik-cache
Tutto il resto dello script è per i controlli, compatibilità con Link2SD, check e fix della 2a partizione ecc. Più semplice di così non si può spiegare.
Esiste una seconda soluzione, forse più comoda, ma che implica avere SEMPRE la scheda SD collegata: mettere tutta la memoria interna nella 2a partizione della SD card. Ha bisogno dell'accesso al file di sistema init.rc che viene caricato in RAM disk al boot, in quanto fa parte del boot.img (erroneamente chiamato "il kernel". Il kernel è la prima parte del boot.img. La seconda è per l'appunto la RAM disk). Quindi bisogna scompattare il boot.img, modificare init.rc, ricompattare, fare il flash del boot.img modificato. In pratica fa il seguente:
codice:
mount <2a partizione della SD card> /data || mount <"memoria interna"> /data
|| sta per OR: Se il primo mount non va a buon fine esegui il secondo (quello standard).
Se togli la scheda ti ritrovi con i dati vecchi, se ci sono. Puoi addirittura ritrovarti col wizard di configurazione. Con S2SD o Link2SD questo non può succedere.
Come vedi non è nulla di eccezionale. Solo che Google ha fatto di tutto per impedire certe procedure, o perlomeno non renderle semplici. Non c'è alcuna ragione tecnica per la quale quei file non potessero stare nella memoria flash. Anzi. Inoltre, visto che vengono caricati in RAM, è pure uno spreco vergognoso di questa preziosa risorsa.