Az a baj,hogy sok esetben elvárjuk a frissitést,miközben az elöző verzioból sem hoznak ki sokat a gyártók,egy Cm 7.2 valamiben többet tud mint egy stock 4.2 droid,a cm fejlesztéseket is ellehetne rejteni a stock romokban.

Azt meg még inkább, hogy a rengeteg SoC nagyjából 3 féle belsőt takar. A Cortex A5-ös mafokat mindegy mibe csomagolod bele, attól még azok Cortex A5-ös magok maradnak... Van nagyjából 4 SoC gyártó jelenleg a globális piacon, ebből 3-at natív kódúton támogat az Android. A dolgok nem itt buknak meg...

Na igen, elég égés a gyártóknak, hogy az opensource közösség jobbat csinál...

@Keeperv85 : Na de rengeteg féle hardver variációjáról beszélünk, azért az már macerásabb... Amikor bizonyos SoC-ok cuccai bizonyos hardverekkel bugzanak... :S

Ennyi erővel az asztali Linux és egyéb rendszerek sem optimalizálhatóak más és más gépekre. Lásd mégis jól elvannak. Gyártói kifogás a hanyagságukra az esetek többsége. Eleve ne válogassa be azokat a hardverelemeket, amikről tudja már a proto modellek után, hogy problémás ahhoz a SoC-hoz rendelni őket....

Azért egy Referencia / Developer-nek szánt készüléken eléggé fos, hogy nem tudod kivenni az akkut, ezer meg egy oka lehet miért kell áramtalanítani a szerkezetet. Aki nem ért hozzá annyira annak ott a Google Play Edition kiadás, de basszus, hogy azok jobbak legyenek mint a Nexus és ráadásul a frissítést meg a gyártótól kapják. Ez az egész Android identitás zavarral küzd ilyen téren.

Oh tényleg... azért egy magát fejlesztőnek tartó embernek -hogy téged idézzelek- eléggé fos érv, hogy nem tudja újraindítani az akku kiszedése nélkül a készüléket. Hint: ítélet ideje beépített lehetőség a bekapcs. gomb hosszú megnyomására történő reset...

Nem mellesleg az összes Apple termék unibody, akkor kitől is ered az identitászavar?

Amúgy hogy is kerültél ide, mert ez itt nem szifonos fórum, és ha ennyire utálod az androidot, akkor minek jöttél ide ízetlenkedni?

na ezért mondtam már sokszor XDA kezébe adnám az egész OS fejlesztést,miután kiadta a Google a legfrissebb Android verziót.

Csak addig mondod, még nem tudod az XDA-n mennyi magát géniusznak tartó nyomorék van. Közben egy 3 soros scriptet sem tud lefuttatni némelyik. Nagyon belterjes lett az is az utóbbi időkben...

Továbbá hadd jegyezzem meg, hogy még a CM esetében sincs szó OS fejlesztésről. Egy meglévő alap újra átgondolása csupán. A külső kernel programozók pl. még csak a közelébe sem kerülnek a komolyabb fejlesztéseknek. Nem véletlen, hogy a fő repo-ban nincs egyetlen CM lltal megkezdett artifact sem mergelve... Sőt! A CM kód szorosan az AOSP mellé épül és nem helyette. Nem lehet belejavítani pl. egy főágban lévő elgépelt szövegbe, mert a szerverek közötti szinkron integritása megsérülne a folyamat alatt, így azzal, amit a Google csinál az AOSP-ben szembe kell nézni a CM fejlesztésekben is. Ha az előbbi hiányos vagy rossz, akkor a CM vagy lemarad és vár a javításra, vagy szépen beforog a hiba ideát is, ha tudnak róla, ha nem...

Speciális esetekben nem segít a hotkey. Ubuntu phone esetén csak úgy lehetett bootolásra bírni, ha levetted az akku érintkezőket. Na ezért lenne jó kivehető aksi egy Developer Referencia telefonnak.

Nem is én kevertem ide az Apple cuccait, még a végén Apple fanboy leszek egy Androidos fórumba lol. Lumia user vagyok. Itt azzal van baj, hogy az Apple termékei és a Google termékei nagyon nem egy célcsoport, és aki androidos telefont vesz az rohadtul nem akarja csavarhúzóval szétszedni a telefont egy egy kernelbootloop esetén.

(#92) vtomi2

Úgy hogy elolvastam a cikket, és korábban egész tisztességesen kitapasztaltam a romfőzést, a scriptezést és néhány hozzászólással ezelőtt leírtam ezeknek a programoknak a veszélyeit.

(#94) Keeperv85
"Csak addig mondod, még nem tudod az XDA-n mennyi magát géniusznak tartó nyomorék van. Közben egy 3 soros scriptet sem tud lefuttatni némelyik. Nagyon belterjes lett az is az utóbbi időkben...

Továbbá hadd jegyezzem meg, hogy még a CM esetében sincs szó OS fejlesztésről. Egy meglévő alap újra átgondolása csupán. A külső kernel programozók pl. még csak a közelébe sem kerülnek a komolyabb fejlesztéseknek. Nem véletlen, hogy a fő repo-ban nincs egyetlen CM lltal megkezdett artifact sem mergelve... Sőt! A CM kód szorosan az AOSP mellé épül és nem helyette. Nem lehet belejavítani pl. egy főágban lévő elgépelt szövegbe, mert a szerverek közötti szinkron integritása megsérülne a folyamat alatt, így azzal, amit a Google csinál az AOSP-ben szembe kell nézni a CM fejlesztésekben is. Ha az előbbi hiányos vagy rossz, akkor a CM vagy lemarad és vár a javításra, vagy szépen beforog a hiba ideát is, ha tudnak róla, ha nem...
"

Na igen emiatt is van az az elvakult a Nexus über alles hozzáállás mindenütt, mikor az egész csak addig tart a nagy csoda ameddig támogatja a chipset gyártó a hardvert, még a Google atyaúristen se szarik rájuk 18 hónap után, még biztonsági frissítésekkel sem (!), akkor milyen a többi droidos cucc... Az egész egy tákolmány, mert 18 hónap közben általában 1-2 szer önkéntes béta teszterek a userek majd amikor vége a támogatásnak akkor meg CM nightly teszterekké válnak. Az XDA-val való példálózás pedig egyszerűen nonszensz egy androidos low cost telefon vagy egy full kínai mobillal, mert gyakorlatilag nem létezik hozzá közösségi támogatás.

Na igen...csak tudod az egész ott kezdődik hogy ők adott esetben az alapot oldják meg jobban,persze van hogy hibáznak.
Jó példa erre a mostani telefonom...amikor megvettem olyan lomha volt hogy az már fájt(pedig 2 magos cpu,512mb ram)
Az egymagos LG gt540-em sokkal gyorsabb volt CM rommal mint ez Stock rommal,ja igen csak ott egyedi kernel és egyedi fejlesztések voltak.

A cikkben leírt dolgok sok CM romban már alapból benne vannak,sőt pl a Nexus 5 egyes romjaibam.
Milyen furcsa pl hogy a Project svelte nevű fejlesztést,amit a Google kitalált a 4.4-ben....egy CM 7-ben már sok esetben alapból benne van,ami ugye 2.3 ra épült.

"Na igen...csak tudod az egész ott kezdődik hogy ők adott esetben az alapot oldják meg jobban,persze van hogy hibáznak."

Nem nagyon nyúlnak az alapokba, nem tehetik. Amibe bele tudnak nyúlni, abban már meglévő optimalizálásokat lehet eszközölni egy másik készülékre esetleg. Jó példa erre pl. a Bravia Engine, bár ez optikai tuning, nem sebesség.

"Milyen furcsa pl hogy a Project svelte nevű fejlesztést,amit a Google kitalált a 4.4-ben....egy CM 7-ben már sok esetben alapból benne van,ami ugye 2.3 ra épült."

Milyen furcsa az, hogy egyetlen olyan CM fejlesztés sincs viszont, amit ők találtak volna ki. A téma motort a T-Mobile írta, a DSP-t a Sony és így tovább. A Project Butter alap Google kódút, az ART engine dettó. A Trebuchet launcher 80%-a AOSP kód... Az csak egy dolog, hogy a CM csapat olyan eszközökre is elhozza, ahol másként soha sem lenne kész. (Vagy éppen valamelyik külső kontributor, ha nincs CM fejlesztés az eszközre még vagy már...).

KSM,ZRAM,Hardveres gyorsitás már CM6-tól,meg egy csomó minden.....mondom vannak fejlesztéseik amik náluk már évek óta benne vannak.

sőt náluk már CM6-ban müködöt az SD kártyára app helyezés,de pl CM6-ban már bekapcsolhattad a JIT gyorsitót,bizonyos Scriptel.....és ugye ezek mind még a 2.X-es időkből való.

Akkor várom az ART runtime-ot Android 4.1 ig visszamenően.A Google által kiadva.

[ Szerkesztve ]

Én már annak is örülnék, ha a 4.4-ben vagy a CM11-ben normálisan működne... Pillanatnyilag szerintem érdemesebb bevárni az 5.0-át...

Ezek jó része Linux specifikus nem pedig Android! A JIT 2.2 alap kelléke volt és alapértelmezetten be is volt kapcsolva az 512 MB-os telókon. (Nexus One) App To SD már 2.1 ben is volt csak egy kis init.d szerkesztés kellett hozzá.

A CM nem talált fel semmit, csak elvégezte a userek helyett a piszkos munkát, összeollózta a cuccokat úgy, hogy a rendszer jellege AOSP maradjon. Nekem nagyon tetszik a filozófia, de ők sem tudnak csodát tenni, elég megnézni hány hivatalos stable build van kint és mennyi unofficial port. Egyből nem rózsás a helyzet. Nightlyzás nem ér!

[ Szerkesztve ]

Na igen,csak ha nincs cm fejlesztés,akkor ők hogy jönnek rá pl arra hogy mit kell beirni a build.prop-ba,mert vannak dolgok amit ha a stock romba irunk be is működik.Vagy vannak titkos fejlesztések,amit a google nem rak bele a stock romba?

"Vagy vannak titkos fejlesztések,amit a google nem rak bele a stock romba?"

Egész pontosan vannak olyan artifactek, amik soha sem mergelődnek az AOSP kódútba. Vagy azért, mert a review alatt megbuktatják őket, vagy azért, mert szimplán vissza lesznek fogva és a következő verzióig elhagyott státuszba kerülnek. Mondok egy nagyon jó és hétköznapi példát erre. Az CM7 egyik újdonsága volt, hogy a 2.3.5-ben megjelentek az állapotsori kapcsolók. Az AOSP-be nem kerültek bele. Jött a Honeycomb és láss csodát... megjöttek a kapcsolók! Aztán ugyan ezt követte a tablet UI... szintén a CM7-be integrálva. ...és lásd: az is előkerült... Már csak egy dolgot nem tudom miért nem csinálnak meg: a T-Mobile-féle téma motort... ítélet ideje készen van, ott van a CM romokban és nem és nem és újra nem...

De ilyen pl a Boot Audio kikapcsolása,de pl olyan apróságok hogy a csengőhang a fülhallgatón vagy a hangszoron szólaljon meg a fülhallgató csatlakoztatva van,vagy pl többféle akkumlátor,óra,térerő kijelző piktogram az állapotsoron........de pl vannak appok amik maguktól eltudnak fordulni CM-romban ha eldöntjük a telefont,igen csak ezekhez root jogosultság kell,és akkor alapból úgy kellene árulni a telefonokat,de pl a szokásos 3 gombot is szabadon lehetett variálni.

Egy jobb CM Rom után a Stock Droid egy funkció szegény valami................pl az én telefonomon sem voltak állapotsori kapcsolók,nekem kelett megoldani power toogles-el,külön vicc a gyári videó lejátszó...csak akkor fordul el habekapcsolom az elforgatást renderszinten,MX player,Quickpick alapból tudja...........és ne mondják hogy nehéz lenne megoldani.

No igen. Ez a forgatósdi engem is bosszant. Egyes telókon a gyári launcher nem tudja forgatni a főképernyőt. Azt sem értem, hogy miért nem kötelező az alkalmazásoknál mindkét nézet. Pl. Port.hu. Az alkalmazás tud fekvő lenni, de a betöltőkép nem. Szerencsétlen droid meg forgatja ide-oda (akkor is, ha fix fekvő nézetet állítok be a telón). Ilyen volt az új Dolphin böngésző megosztás menüje is. Emiatt nagyon lassan nyílt meg. Mentségére legyen, hogy ezt még a bétában tapasztaltam. A véglegest még nem próbáltam. Jó lenne, ha a fektetett nézetet a Google kötelezővé tenné, mert a hiánya nem csak idő és erőforráspazarló, de inkompatibilitási problémákat is okozhat. Pl. miniPC -n érdekes a szitu. Ott a rendszer rá van kényszerítve a landscape nézetre. Ezért csomó alkalmazás csak manuálisan telepíthető. Elég viccesen néz ki az álló nézetű port.hu logó fekvőre torzítva. Vagy a speedtest, aminek egyáltalán nincs fekvő nézete.

[ Szerkesztve ]

Aki kicsit jártas a Droid fejlesztésben...kérdeznék valamit!
A Kernel Tuner szerint a VSYNC off álapotban van a telefonomon....viszont ha jól tudom a Project Butter a VSYNC-re épül,vagy ez nem az?
Elvileg a GPU támogatja,vagy ezt is kikapcsolhatják a gyártók?
Lehet hogy Sok telefonban nem is müködik a Project Butter?
Vagy van olyan kernel ahol ezt kilehet kapcsolni?

[ Szerkesztve ]

Ugyan már, minden dokumentálva van valahol, főleg hogy az egész Android Open Source Project alatt készül. Szerinted úgy jöttek rá ezekre a dolgokra hogy random beírtak valami marhaságot angolul egy konfigurációs fájlba? Szépen le van minden dokumentálva, és szépen lehet követni a mindennapos fejlesztést például a CM-nél is.Csak a bookmarkjaimból csemegezéve: [link]

Nem vagyok developer, de a PB több apró részletből áll össze. Ilyen például a Google-által fejlesztett Interactive CPU ütemező, ami a digitalizáló jelére megugrasztja a CPU órajelét és még érintés előtt. Ehhez jön hozzá a 60fps + vsync, vannak alkalmazáson belüli optimalizációk, mint például a billentyűzet és a tárcsázó is jobban és gyorsabban reagál az érintésre. Elvileg kontextus érzékeny a memória kezelése, és próbálja megtippelni hogy mire fogsz kattintatni egy adott művelet után és betölti a memóriába, hogy gyorsabban nyílhassanak meg, nem tudom hogy ebből mennyi került át a felhasználói alkalmazásokhoz.

A Project Svelte ezt gondolta tovább

Csökkentették az egész rendszer memória felhasználását, majd lehetővé tették az alkalmazásoknak hogy figyeljék a memória használatot és ha akarnak automatikusan kerüljenek egy kevésbé memória igényes állapotba helyet adva az éppen aktuális folyamatnak. Sajnos ehhez az kell hogy az alkalmazások is ezeket az irányelveket figyelemmel kísérve íródjanak, tehát a régi appok ugyan olyan rőforrászabálóak mint eddig.

A jövőben az ART hivatott leváltani a JIT okozta lassulásokat, mivel a telepítés pillanatában már fordulnak az alkalmazások a nagyobb hardverek és gyorsabb háttértárak miatt így gyorsabban töltődnek be egyszerre a memóriába.

[ Szerkesztve ]

Ez egy kicsit összetett kérdés. A V-Sync hiányában is megy a Project Butter, ilyenkor fake v-sync fut, vagy éppen az sem. Nem mindegy az sem, hogy (korlátozódjunk a Qualcomm megoldásaira, abból van a legtöbb) ION kódúton fut a kernel, vagy még a PMEM-re épül. Vagy éppen ezek sajátos keveréke, mert éppen valamelyik mérnökség egy elborult pillanatában keresztezte őket...

A Probléma azzal van inkább hogy iszonyatos különbség van a jól és a rosszul megírt appok közt,sok esetben hiába van erős hardver a telefonodban,ha nem mindenhol tudsz gyors kódfuttatást végrehajtani.
Számtalan olyan alkalmazással találkoztam ami ugyanazon müveletet akár 10x lasabban csinálta meg,de pl funkcióban meg sokkal többet tud.
Olyan sincs hogy hogy teleszemeteled a telefonod,persze ha kifogsz egy rosszul megírt alkalmazást akkor azt fogod érezni hogy sz*r a Droid....Nyilván a Google sajátjaiért a Cég felel.

Ide még vissza kell néznem...

Üdv!

Egy kis segítségre lenne szükségem.... nem találtam kimondottan témába vágó topikot, úgyhogy gondoltam talán itt valaki tud segíteni. Adott egy androidos tv, a pontos tipus kdl-55w808c Rootolásban kellene segítség. Sajnos nem nagyon találok semmit hozzá, a "gyors" programok mint a kingroot,stb nem tudják megoldani. Jelenleg android 7.0 van rajta, nemrég frissült...