ROM Custom CyanogenMod 10 Jelly Bean per Mediacom 711i

[pippo60gd]

Tranne per me che uso skype tutti i giorni o quasi Ad ogni modo hai fatto davvero un ottimo lavoro pippo. Meno male che ci sei tu altrimenti avremmo un tablet appena usabile e destinato a breve alla soffitta

Adesso la telecamera funziona! Non hai scuse.

Questa è stata fatta con il programma camera fx:

[merlinolillo]

Adesso la telecamera funziona! Non hai scuse.

Questa è stata fatta con il programma camera fx:

Sei un grande!!!! Appena la pubblichi la installo immediatamente e ti do le mie impressioni. Nutro sempre una grande ammirazione nei tuoi confronti per quello che stai facendo per noi che abbiamo questo tablet

[pippo60gd]

Sei un grande!!!! Appena la pubblichi la installo immediatamente e ti do le mie impressioni. Nutro sempre una grande ammirazione nei tuoi confronti per quello che stai facendo per noi che abbiamo questo tablet

Skype (la versione modificata) funziona. L'ho provato e va discretamente.

[pippo60gd]

Ricapitolando:
telecamera ok;
youtube e flashplayer ok (le ultime versione da google play);
audio ok;
hdmi ko;
sdcard da sistemare;

[pippo60gd]

Ricapitolando:
telecamera ok;
youtube e flashplayer ok (le ultime versione da google play);
audio ok;
hdmi ko;
sdcard da sistemare;

Allora, la questione sdcard.
Google, dopo le ennesime critiche alla sicurezza di android, sembra che abbia stretto le redini. Ha modificato il demone vold in modo che non sia possibile accedere alle partizioni vfat. Il problema infatti è proprio la vfat e la sua implementazione sui permessi.
Le soluzioni possono essere:
1) montare la sdcard scavalcando vold;
2) formattare la sdcard con ext2/3/4; (da verificare)
3) non saprei.
Si accettano suggerimenti.

[pippo60gd]

C'è qualche persona di buona volonta che conosce l'inglese che possa tradurre questo documento?
https://android.googlesource.com/pla...orage/index.md

[Taddi]

Ma col traduttore di google non si capisce nulla ?

[merlinolillo]

C'è qualche persona di buona volonta che conosce l'inglese che possa tradurre questo documento?
https://android.googlesource.com/pla...orage/index.md

Sono un insegnante di inglese alle scuole medie Ci provo io

[pippo60gd]

Ma col traduttore di google non si capisce nulla ?

qualcosa si capisce.

[merlinolillo]

# Informazioni tecniche della memoria esterna


Android supporta dispositivi di memorizzazione esterna, che è costituita da un
file system case-insensitive e senza permessi. La memoria esterna può essere
costituita da un supporto fisico (ad esempio una scheda SD), o da un emulatore supportato
dalla memoria interna. I dispositivi possono contenere più livelli di memoria esterna,
ma attualmente solo il livello principale è manipolabile dagli
sviluppatori tramite API.

# # Configurazione specifica del dispositivo

L'archiviazione esterna è gestita da una combinazione di `` servizio vold init e
`` sistema di servizio MountService.

Il montaggio di volumi di memoria esterna fisica è gestita da `` vold, che
esegue operazioni di gestione temporanea per preparare il dispositivo prima di esporlo alle applicazioni.
Il file specifico della configurazione del dispositivo `vold.fstab` definisce mappature da dispositivi sysfs
ai punti di montaggio del filesystem, e ogni riga segue questo formato:

dev_mount <label> <mount_point> <partition> <sysfs_path> [flags]

* `` Etichetta: Etichetta per il volume.
* `Mount_point`: percorso file system in cui il volume deve essere montato.
* `Partizione`: Partition number (1 based), oppure 'auto' per la prima partizione utilizzabile.
* `` Sysfs_path: Uno o più percorsi sysfs ai dispositivi in ​​grado di fornire questo mount point.
Separati da spazi, e ognuno deve iniziare con `/`.
* `Flag`: virgola opzionale lista separata di flag, non devono contenere `/`.
I valori possibili sono non rimovibile `` e `` criptabile.

Le interazioni della memoria esterna al di sopra del livello di framework sono gestite
attraverso `MountService`. Il file di configurazione per il dispositivo `storage_list.xml`,
in genere fornito attraverso una sovrapposizione `frameworks / base` , definisce gli
attributi e i vincoli dei dispositivi di memoria. L'elemento `<StorageList>`
contiene uno o più elementi `<Memoria>` ; uno dei quali deve essere contrassegnato
come primario. Gli attributi `` <Memoria> includono:

* `` mountPoint: percorso del filesystem di questo montaggio.
* `StorageDescription`: risorsa di tipo stringa che descrive questo montaggio.
* `Primary`: true se questo montaggio è il primario della memoria esterna.
* `Removable`: true se questo supporto ha un supporto rimovibile, ad esempio una scheda SD.
* `` Emulated: true se questo supporto viene emulato ed è sostenuto dalla memoria interna,
eventualmente utilizzando un demone FUSE.
* `Mtp-reserve`: numero di MB di storage che l'MTP dovrebbe mantenere libero.
Viene utilizzato solo quando il montaggio è contrassegnato come emulato.
* `AllowMassStorage`: true se questo montaggio può essere condiviso via di memoria di archiviazione di massa USB.
* `MaxFileSize`: dimensione massima del file in MB.

I dispositivi possono fornire una memoria esterna emulando un filesystem case-insensitive,
senza permessi supportato dalla memoria interna. Una possibile
implementazione viene fornita dal demone FUSE in `system / core / sdcard`, che può
essere aggiunta come servizio `init.rc` specifico del dispositivo:

demone Sdcard # virtuale in esecuzione come media_rw (1023)
Servizio sdcard / system / bin / sdcard <source_path> <dest_path> 1023 1023
class late_start

Dove `source_path` è la memoria interna del supporto e `dest_path` è il
punto di arrivo del montaggio.

Quando si configura uno script `init.rc` specifico del dispositivo, la variabile di ambiente
`` EXTERNAL_STORAGE deve essere definita come il percorso verso la memoria esterna primaria.
Il percorso di `/ sdcard` deve anche risolvere nella stessa posizione, possibilmente
attraverso un symlink. Se un dispositivo regola la posizione di memorizzazione esterna tra
aggiornamenti della piattaforma, il symlink dovrebbe essere creato in modo che i vecchi percorsi continuino a

funzionare.

A titolo di esempio, ecco la configurazione di archiviazione per Xoom, che utilizza un FUSE
daemon per fornire la memorizzazione esterna primaria, e comprende una scheda SD fisica come
memoria esterna secondaria:

* [Vold.fstab] (https://android.googlesource.com/dev...ter/vold.fstab)
*

L'accesso alla memoria esterna è protetto da varie autorizzazioni Android.
A partire da Android 1.0, l'accesso in scrittura è protetto con la autorizzazione
`WRITE_EXTERNAL_STORAGE`, realizzata con la `sdcard_rw` GID.
A partire da Android 4.1, l'accesso in lettura è protetto con la nuova
autorizzazione `READ_EXTERNAL_STORAGE` , realizzata con la `sdcard_r` GID. Ad
attuare il permesso di lettura, è stata creata un nuova directory top-level `/` storage
in modo tale che i processi devono essere in possesso del `sdcard_r` GID per passare in esso.

Dal momento che la memoria esterna non offre alcun supporto alle autorizzazioni dei filesystem
tradizionali POSIX, il codice di sistema non dovrebbe memorizzare i dati sensibili sulla memoria esterna.
In particolare, i file di configurazione e di log dovrebbero essere conservati solo nella memoria interna
dove possono essere efficacemente protetti.

# # Memoria esterna Multi-utente

A partire da Android 4.2, i dispositivi sono in ​​grado di supportare più utenti, e la memoria esterna
deve soddisfare i seguenti vincoli:

* Ogni utente deve avere la propria memoria esterna primaria isolata, e non deve
accedere alla memoria primaria esterna di altri utenti.
* Il percorso `/ sdcard` deve risolvere alla corretta memoria esterna primaria specifica dell'utente
in base a com'è il processo in uso dall'utente stesso.
* L'archiviazione di grandi file OBB nella directory `Android / obb` deve essere condivisa
tra più utenti come ottimizzazione.
* La memoria esterna secondaria non deve essere scrivibile dalle applicazioni.

L'implementazione della piattaforma predefinita di questa funzione sfrutta gli spazi dei nomi del kernel Linux
per creare tabelle di montaggio isolato per ogni processo di biforcazione Zygote, e
quindi utilizza supporti bind per offrire la corretta memoria esterna primaria
specifica dell'utente in quello spazio di nome privato.

All'avvio, il sistema monta un solo demone FUSE emulato esterno di memorizzazione in
`EMULATED_STORAGE_SOURCE`, che è nascosto da applicazioni. Dopo le biforcazioni Zygote,
lega montaggi alla sottodirectory specifica dell'utente da sotto il FUSE
demone all' `EMULATED_STORAGE_TARGET` in modo che i percorsi di memorizzazione esterni risolvano
correttamente per l'applicazione. Affinchè un app manchi di punti di montaggio accessibili per altre
archiviazione di utenti, essi possono accedere solo alla memoria dell'utente per il quale erano stati avviati.

Questa implementazione utilizza anche la funzionalità di condivisione della sottostruttura del kernel
per propagare eventi di montaggio dal namespace della root predefinita in spazi dei nomi delle app, che assicura
che le caratteristiche come i contenitori ASEC e il montaggio OBB continuino a funzionare correttamente.
Lo fa montando i rootfs come condivisi, e poi rimontandoli come slave
dopo che ogni namespace Zygote è stato creato.


L'ho riaggiustata completamente in maniera sbrigativa. Ad ogni modo spero che stavolta si capisca bene