[INDEX][OPO] Lista Custom ROM e Kernel | Guida alla scelta

[riccardi]

se guardi la prima pagina di ogni threads su xda puoi trovare descrizione, info utili installazione etc.

in ogni caso anche su xda c'è il tasto cerca; se scrivi droigKang ROM oppure CRDroid le trovi easy

qui su Androidiani abbiamo da poco aperto il thread sulla DroidKang...
https://www.androidiani.com/forum/mo...peek-cm11.html
vi aspettiamo numerosi

[Bokonon]

qui su Androidiani abbiamo da poco aperto il thread sulla DroidKang...
https://www.androidiani.com/forum/mo...peek-cm11.html
vi aspettiamo numerosi

Avete letto che m3dd0g ha rotto dichiarato di aver rotto lo schermo del One? Dubito che il prossimo fix della CM glielo riparerà
E poi ci sono i retroscena [ROM][KK4.4.4][PIE][CM11s] ★★★ DroidKang v6.1 ★★★ [HOVER][PEEK][01/09][CM11] - Post #1242 - XDA Forums

[Bokonon]

A proposito, se in assenza di aggiornamenti volete restare con una crDRoid (la Droidkang è comunque basata su di essa) rimetto il link al thread dello sviluppatore su Google+ (non esiste un thread su XDA) e vi comunico che è una delle ROM che ha aggiornato sia Kernel che OS per essere compatibile con i nuovi fix del touch.
https://plus.google.com/communities/...4-3dc466c1b60d

[alesoft73]

Domanda su AK Kernel.
Per cambiare le impostazioni uso Synapse, qualcuno ha capito come salvarle e farle caricare ad ogni avvio ???
Ho un problema con il suono e Rom Paranoid. Dopo un tempo random il suono si disattiva.
Con Synapse, su consiglio del creatore di AK devo settare delle impostazioni che ad ogni boot svaniscono.

Ringrazio TUTTI!

[Bokonon]

Domanda su AK Kernel.
Per cambiare le impostazioni uso Synapse, qualcuno ha capito come salvarle e farle caricare ad ogni avvio ???
Ho un problema con il suono e Rom Paranoid. Dopo un tempo random il suono si disattiva.
Con Synapse, su consiglio del creatore di AK devo settare delle impostazioni che ad ogni boot svaniscono.

Ringrazio TUTTI!

Attenzione: synapse si perde le impostazioni in continuazione. Leggi il thread dedicato su XDA.
Fossi in te disinstallerei synapse e UKM e sperimenterei con Trickster...ha qualche opzione in meno ma è molto piiù affidabile.

[spigolon97]

scusate , vorrei provare la color os ,ma quella che ho trovato e da flashare come rom principale , e non lo zip da flashare in recovery ( io volevo quello cosi la metto in multirom ) si trova lo zip flashabile ?

[alesoft73]

Attenzione: synapse si perde le impostazioni in continuazione. Leggi il thread dedicato su XDA.
Fossi in te disinstallerei synapse e UKM e sperimenterei con Trickster...ha qualche opzione in meno ma è molto piiù affidabile.

Ottimo! grazie ma trickersmod non ha la parte sound.... che mi interessa.
Usero' FauxSound vedo se risolvo (grazie come sempre

[mitic]

Ma io non vedo miglioramenti nel reparto audio non cambia nulla settando l audio sia da synapse che da faux sound ... Non capisco come mai... e chiedevo anche voi come voltaggio di carica cosa utilizzate ?

[Bokonon]

In questo thread, proverò a fornire un quadro generale per comprendere come funziona la community e come funzionano le custom ROM.
Alla fine, vi renderete conto che nulla è da scartare a priori: ma, una volta compresi i pro e i contro, farete scelte più sensate e in linea con le vostre esigenze.

Capitolo 1: Gli sviluppatori/developers

Google rilascia il codice di Android (=AOSP) perchè a sua volta utilizza il codice di linux (nei termini GPL). A sua volta, chiunque utilizzi il codice di Android nei suoi lavori è obbligato a rilasciare open source il codice che ha scritto.

Un'azienda oppure un Team di utenti decidono che la AOSP non è la ROM ideale e completa che vorrebbero. Rivedono il codice sorgente, aggiungono features e magari scrivono pure uno o più app originali da allegare al pacchetto. L'azienda rilascierà il codice open source di ciò che ha modificato...mentre il codice originale delle app se lo terrà in casa (non ha alcun obbligo di pubblicarlo dato che non è basato su altro codice rilasciato sotto GPL). Il Team di utenti invece rilascia tutto sotto GPL in open source perchè il suo scopo è contribuire alla community e non il lucro.
In genere un Team parte da uno o più utenti che sanno programmare: molto spesso è anche il loro mestiere nella vita reale. Iniziano a macinare codice e poi trovano altre persone che condividono la loro visione su come dovrebbe essere Android..e così nasce un team (che in genere aggrega a strascico themers, testers, builders e altro).
Su XDA ci sono alcuni team storici che hanno inziato prendendo la AOSP di Google e l'hanno lentamente trasformata riscrivendo interi blocchi di codice e aggiungendo feature. Su XDA ci sono alcune delle più famose custom ROM --> Custom ROM Central - XDA Forums
Il Team Cyanogenmod è nato così prima che che decidessero di formare una società.

Riassumendo ogni Team sviluppa Android a partire dalla AOSP. Nel corso degli anni, ogni team ha pensato e realizzato diverse idee innovative e ha lasciato la sua impronta. I Team, a livello centrale, decidono la direzione da prendere e le feature da introdurre: poi sviluppano e testano e infine rilasciano.
Pertanto, ogni team sviluppa una ROM generica e successivamente la adatta a tutti gli smartphone che intendono supportare. In pratica, l'intero Team sviluppa la ROM generale poi ad uno o più membri vengono assegnati uno o più smartphone da seguire. Il loro compito è adeguare la ROM alle specifiche dello smartphone e aggiornare le build integrando gli aggiornamenti della ROM principale (che include sia il codice del Team, sia i nuovi commit di Google). Inoltre inseriscono anche i nuovi commit specifici del kernel sviluppato per lo specifico smartphone.
Nonostante sia un hobby, sono organizzati quasi a livello professionale. Infine è chiaro che ci sono le punte di diamante in ogni team. Per citarne un paio, la Paranoid Android ha Franco e SferaDev, Slimkat ha Kufikugel e Jubakuba.

Il prossimo capitolo è dedicato ai Builders, mentre il terzo capitolo sarà dedicato a cosa accade nella realtà nella community OPO, quindi ci saranno esempi in cui saranno applicati i concetti esposti nei primi due capitoli.

[Bokonon]

Capitolo 2: I Builders (come li definisco io )

Ci sono 10 siti di ricette. Nove siti sono gestiti da chef e offrono le loro ricette originali. Il decimo non è uno chef e magari non sa nemmeno cucinare ma pubblica le ricette prese da tutti gli altri siti. Questo è in soldoni il concetto che stiamo per affrontare.

Tu che leggi, si proprio tu, potresti benissimo scaricare il SDK di Android e i compilatori: potresti benissimo andare su GitHub e scaricare in blocco il codice della tua ROM preferita per l'OPO e infine compilarlo. Otterresti esattamente l'ultima build della tua ROM preferita.
Bello vero? E non serve nemmeno sapere cosa siano Java e il C++. Magari non è esattamente così rose e fiori la prima volta... e occorre comunque imparare prima come usare un compilatore, impostare GIT per reperire il codice completo (le parti della ROM che sono state sviluppate dal Team vengono pescate in altri account...per esempio quello della CM) e infine impostare la toolchain.

A questo punto però ci hai preso gusto e ti chiedi Visto che la mia ROM non ha una feature che è presente in un'altra ROM, magari potrei provare a infilarcela dentro io. Per esempio vorresti avere il PEEK della Paranoid Android dentro la Slimkat: quindi prendi il codice della PEEK e lo integri nella ROM. Questa operazione è già decisamente più sofisticata e richiede una serie di conoscenze aggiuntive che possono essere sviluppate leggendo le guide o guardando come hanno proceduto altri utenti per ottenere il medesimo risultato. Dopo molti smadonnamenti, sono certo che verresti a capo di tutti gli errori in fase di compilazione e otterresti la tua Slimkat con il PEEK.
Magari poi apri pure un thread su XDA in cui ringrazi il Team SlimROM e il Team PA e metti a disposizione del pubblico la tua Slimkat col PEEK.
Ogni volta che il Team SlimROM aggiornerà la sua build e ogni volta che il Team PA aggiornerà il codice del PEEK (se mai ce ne fosse bisogno), compili il tutto e rilasci un aggiornamento.
E se qualche utente ti chiede un'altra feature? Cerchi il codice ci lavori un po' su come hai già fatto e la implementi.
E se ti chiedessero di fissare un bug? Allora rispondi la verità, ovvero che il bug è della ROM principale e che ci stanno lavorando su. Una volta fissato rilascierai la nuova build. Oppure...fai finta di niente e scrivi Vedrò cosa posso fare e prendi tempo...tanto l'utente medio non la più pallida idea di quale sia il tuo grado di competenza e non legge nemmeno la prima pagina (=OP). Quanti di loro capiscono che sei l'ultima ruota del carro e che dipendi in tutto e per tutto dal lavoro altrui? Pochissimi, te lo posso assicurare. Il 99,9% non legge nemmeno i changelog. Se appena escono due righe di codice nuovo da incorporare, ricompili tutto e rilasci una nuova build, non solo penseranno che sei una sorta di divinità ma leggerai anche mesaggi del tipo Wow, adesso va molto più veloce e il bug che avevo rilevato è scomparso. Ti farai 4 risate ma non andrai a contraddire i tuoi clienti replicando Guarda che ho aggiornato due righe di codice in tutto e non riguardavano nemmeno lontanamente ciò di cui parli.

Nel frattempo, ci avrai preso proprio gusto e comincerai ad accumulare esperienza e conoscenze che ti permetteranno di fare passi avanti. Dopo aver infilato dentro pezzi di codice dalle ROM più disparate e dai developers più disparati...magari inizi a valutare l'idea di aggiornare il kernel. In fondo anche il Team principale aggiorna una parte del kernel prendendo il codice per adattarlo all'OPO dalla CM e (eventualmente) dal CAF: praticamente tutto il software che riguarda l'hardware dello specifico dispositivo non viene mai toccata nemmeno dal Team principale. Solo l'azienda che ha creato l'hardware (o al massimo gli ingegneri informatici che hanno ricevuto tutta la documentazione e le tools per scrivere i drivers) possono scrivere o modificare quel codice.
Magari, visto che il Team principale rilascia le build ogni settimana, potresti fornire un servizio aggiornando più rapidamente di loro solo quella parte del kernel ed eventualmente le librerie della ROM (per compatibilità) e infine rilasciare la tua bella ROM a cadenza giornaliera. Immagina quanta gente ti seguirà e scaricherà la tua ROM pur di non attendere anche solo 24 ore in più. Ed ecco che vai su Gerrit per leggere i commenti sui nuovi commit della CM e decidere quali integrare. Anzi a, questo punto, perchè non infilare dentro il kernel anche delle nuove feature? Ad esempio un nuovo governor e il supporto F2FS (sempre sviluppati da terzi).
Probabilmente a questo punto inizi a renderti conto che non solo non è così facile ma che richiede una marea di tempo e che cominciano a saltar fuori incompatibilità e bug a iosa. Forse una buona via di mezzo potrebbe essere quella di mantenere la system che hai sviluppato e integrato con altre feature e sostituire solo lo stock kernel della ROM con un custom kernel sviluppato e aggiornato da qualcuno che ha deciso di occuparsi solo e unicamente di questo.

Insomma, le possibilità sono tante e le scelte di un builder e la qualità delle sue ROM dipendono fondamentalmente dalla sua esperienza, dalle sue capacità e dal tempo che è disposto a dedicare. Se sei un programmatore che (per ragioni di tempo o scelta personale) invece di partecipare attivamente dentro un Team volessi solo sviluppare una ROM personalizzata, di sicuro sapresti gestirti infinitamente meglio di chi ha solo un'infarinatura generale di informatica: con tutta probabilità, saresti pure in grado di tracciare e risolvere piccoli bug e incompatibilità. La qualità delle tue build sarebbe sicuramente superiore alla media.

Riassumendo, i minestroni (o compilations, come le chiama Franco) sono nel 99,9% dei puri derivati. Le capacità di un builder possono variare molto...e questo ci porta al terzo capitolo.