- Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Különösen rendezett beltér hozható össze a Cooler Master új házában
- A középkorra és a pokolra is gondolt az új AMD Software
- Új gyártástechnológiai útitervvel állt elő a TSMC
Hirdetés
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
Aktív témák
-
anglergab
addikt
Sziasztok!
Lenne néhány általános kérdésem a Defy-jal kapcsolatban:
1. A hangszóróhiba mennyire érinti a jelenleg szolgáltatónál kapható Defy-okat?
2. A jelenleg kapható készülékek kamerája rávehető-e trükközéssel 720p-s videófelvételre?
3. Ismert bug/hiba a jelenleg kapható készülékek hardverével kapcsolatban?
4. Úgy értesültem, hogy jelenleg a legjobb rom a CM. Ez igaz? Mennyire bugmentes?
5. Hallottam, hogy a Defy-ok bootloadere zárolt; ez azt jelenti, hogy a jelenlegi készülékeknél sem cserélhető a kernel?
6. Milyen SoC/"CPU" van a jelenlegi Defy-okban? TI OMAP3 3610, 6320, vagy 3630-as?
7. CM alatt a proci 1.2 GHz-re húzható?
8. Működik az USB OTG (host) mód? A Droid/(Milestone) esetébe bootolásnál aktiválható ez a mód, a CPU-juk architektúrája eléggé analóg (hasonló, majd' ugyanaz), ezért gondolom a Defy-nál is működik. Valaki kipróbálta (nem pendrive-ra gondolok, ahhoz úgyis extra trükközés kell ; ha már USB-s billentyűzet működne, már örülnék)?Érdeklődőbbeknek: A hw biztosan támogatja az otg-t, kérdés, hogy a kernel tartalmazza-e a szükséges configot és modulokat. A kernel configon nehéz változtatni, ha tényleg zárolt a bootloader; viszont kernelmodulok (*.ko fájlok) boot után beilleszthetők (insmod) a kernelbe.
Ha csak néhány kérdésemre tudsz/tudtok válaszolni, légy szíves, azt is írd/írjátok ide meg!
A válaszokat előre is köszönöm!
PS: köszönöm az első hozzászólás szerkesztőinek, hogy két cikkemet is belinkeltétek.
[ Szerkesztve ]
-
anglergab
addikt
válasz #71562240 #9864 üzenetére
Én sokat foglalkoztam USB host móddal. Blade-nél sikerült is aktiválnom.
Szerintem lehetséges, hogy megoldható a Defy-jal is. A hardver biztosan képes rá, nézd meg a TI oldalán az OMAP3-as platform specifikációját (3610, 3620, 3630 stb. mind képes rá).
A Droid/Milestone 65 nm-es SoC-ának a 45 nm-es verziója van a Defy-ban. Amit a 65 nm-es tud, a modernebb is tudja kisebb fogyasztás mellett. (A TI egyébként egy dokumentumban ismerteti a 65 és 45 nm-es verziók képességeit, és nem látok eltérést, mindkettőnél szerepel az OTG mód). A Droid/Milestone-nál az aktiváláshoz boot közben össze kellett kötni az OTG pin-t a GND-dal, kis ideig (ezért nem vállalok természetesen semmiféle felelősséget; meg viszonylag nehéz is kivitelezni, ugyanis a legtöbb micro USB-s kábelben nem megy OTG vezeték -- értsd: nem vezetik ki a csatlakozóból). Ezután USB host módba bootolt a készülék. Újraindítás után újra USB kliens lett.
Tehát úgy tűnik, hogy a Droid/Milestone kernelconfigjában engedélyezett az USB OTG (értsd: a .config fájlban kernelfordításnál az USB_OTG=y volt, vagy valami hasonló opció volt yes-re állítva). Nos, ha a Defy kernele nem cserélhető, és "n" szerepelt a kernelconfigjában fordítás előtt, akkor tényleg nem tudunk USB host aktivált kernelt beállítani. Reméljük, hogy nem ez a helyzet. -
anglergab
addikt
válasz #71562240 #9871 üzenetére
OK, dolgozom a probléma megoldásán.
Örülnék neki, ha további USB host szakértő kollégák is megkeresnének, együtt gyorsabban kideríthetnénk a megoldást.##############################
USB host mód / OTG szakértők / kísérletezők jelentkezzetek nálam!
##############################[ Szerkesztve ]
-
anglergab
addikt
válasz #99499520 #9893 üzenetére
Ha már a kernelnél tartunk, erről mi a véleményed: (#9889) anglergab?
[ Szerkesztve ]
-
anglergab
addikt
Amit linkeltél, az az egyik kernel (és recovery?) binárisa, tehát gépi kód, amit a Defy CPU-ja végrehajt (általában néhány MB). Nekem kernel forráskód (tehát szöveges programkód; általában több száz MB) kell majd, remélhetőleg a CM kernelé elérhető.
@chab7: a CM kernele milyen eredetű? A gyárin alapul, vagy teljesen egyedi? Egyébként a CM-es kernel forráskódja letölthető? USB host-hoz lehet, hogy szükséges lesz módosítani.
[ Szerkesztve ]
-
anglergab
addikt
Tehát van hivatalos CM nightly build Defy-ra. Itt nem szokott fluktuálni a minőség/megbízhatóság? ZTE Blade CM nighty-knél gyakori volt, hogy kijavítottak bugokat aztán pluszba újabbakat bele is raktak. Szóval nem igazán lehetett számítani a nightly-k bugmentességére.
[ Szerkesztve ]
-
anglergab
addikt
Üdv!
Sikerült a CPU húzás a recoveryből. Az 1350 MHz / Vsel 72 (=0.72 V?) mellett úgy tűnik, hogy stabilan működik (köszönjük, Mira72). Felemeltük még a középső frekvenciát 600 MHz-ről 800 MHz-re, 44-es Vsel mellett. Ilyen beállítás esetén Quadrantban a max. 2787 volt (viszonylag nagy fluktuációkkal, néhány 100 pontos szórás volt azért) (megjegyzem, ha a CM Settingsében a min. frekvenciát is az 1350 MHz-es max.-ra állítottuk, akkor elértünk 2868 pontot is). Ezután növeltük 1400-1450 MHz-re az órajelet, ezután minden nagyon belassult, akadozott. Ekkor gondoltuk, hogy ez a relatíve alacsony Vsel miatt van, így azt is emeltük 2-es egységekben néhányszor. Nos, ennek nem lett eredménye, maradt az akadozás 1400 MHz-től felfelé, az 1400 MHz-et is beleértve. Visszatértünk az 1350 MHz/72 Vsel-hez, és újra stabilnak és gyorsnak tűnik.Egyébként mit jelent pontosan ez a három clock/vsel értékpár? A min. és a max. világos, de a közteset mikor használja? Továbbá az ondemand governor beállítás az optimális, ugye? Még valami: amit a recoveryben beállítok, az miért nem kerül alkalmazásra reboot után (értsd: külön be kellett állítani a CM Settingsében is a megfelelő rádiógombra). További furcsaság, hogy a CM Settingsében 2 órajelkategória van, a recoveryben pedig 3. Miért?
[ Szerkesztve ]
-
anglergab
addikt
Találtam infót a Vsel vs. V témához: (#2710) ronaldo Tehát lineáris az összefüggés, nemnulla offszettel.
Fontos megjegyezni, hogy a Droid/Milestone SoC-a 65 nm-es, ellenben a Defy-é 45 nm-es gyártástechnológiával készült (konkrétan az első 45 nm-es SoC, amit handheld eszközbe szántak!). A 45 nm-esnek alacsonyabb a fogyasztása, így ugyanolyan órajelek mellett alacsonyabb feszültségértéken működik.[ Szerkesztve ]
-
anglergab
addikt
USB Host: ZTE Blade-nél nyilvános volt a kernel forráskódja, így a kernel config fájlja is. Tehát bárki módosíthatta a forrást és újrafordíthatta a kernelt. A kernel config fájlában lehet aktiválni kernelbe fordítandó featureket, így az USB host mód hardver szintű aktiválását is. A hardveres támogatás adott volt (mint ahogyan a Defy-nál is, lásd a TI oldalán a platformunk specifikációját), így a config módosításával és célszerűen driverek, scriptek kernelbe fordításával adott volt az usb host, de nem az otg lehetősége a Blade-nél. A tényleges aktiváláshoz már "csak" kernel modulok kellettek (ezek *.ko fájlok, kernelverzió-specifikusak, ezáltal részben Android platformverzió-specifikusak is), amelyek betölthetők voltak boot után (insmod ....ko). Így a memóriába betöltött kernelhez hozzáadhatók újabb "driverek".
Visszatérve a Defy-hoz a tanulságok:
1. Hardveres támogatás adott, ez tény.
2. Kernel configjában aktivált-e a mód -> kérdéses; ha nem aktivált, nem szükségszerűen következik, hogy soha nem aktiválható, még ha zárt is a bootloader.
3. Kernel modulok az USB host módhoz (Loadable Kernel Modules) elérhetők-e? Ezek kvázi driverek pl. HID-es egérhez, usb-mass-storage osztályú eszközhöz, stb. Akár a HDMI (DVI) kimenet is megvalósítható az USB-n keresztül. Ha nem elérhetők, elkészíthetők-e? Pl. Nexus One-hoz, ZTE Blade-hez léteznek ilyen *.ko, esetleg *.so fájlok.
4. USB-OTG (On the Go) hardveresen elérhető? A Droid/Milestone esetében igen: ezáltal bootolásnál a micro USB B csatlakozó OTG pinjének rövid idejű földelésével aktiválható a host mód. MIvel szinte ugyanaz a SoC/CPU van a Defy-ban is (csak más csíkszélességgel), várható, hogy működjön a Defy-nál is az OTG hardveresen. Kérdés, ha támogatja, hogy ekkor a kernel részéről milyen támogatás szükséges (ha egyáltalán szükséges), és ez implementálva van-e. Reményre adhat okot a Droid/Milestone natív USB-OTG támogatása (úgy tudom, out-of-box működik ott, rom csere nélkül). Nyilván a legjobb az lenne, ha a Defy-nál is működik a stock kernellel az USB-OTG, mert ez már feltételezi az USB host mód támogatását, legalább billentyűzet esetén (lásd a Megjegyzéseket).Megjegyzés #1: az USB OTG többet nyújt a "sima" USB host módnál. Az OTG révén dinamikusan váltani lehet az eszköz kliens és host módjai között -- azért újraindításra szükség van. Az "sima" (tehát OTG nélküli) USB host mód aktivált/enabled kernel kizárólag hostként képes működni: tehát ha kliensként csatlakoztatni szeretnénk az eszközt egy hosthoz (pl. fájlmásolás USB-n PC-re), akkor másik kernelt kell feltenni/betölteni a memóriába (nyilván ekkor biztosan szükséges újraindítás).
Megjegyzés #2: az USB host és/vagy OTG tesztelését USB-s billentyűzettel célszerű végezni, mivel ezt igen sok esetben a Linux kernel natívan támogatja, míg egérhez külön HID driver kell.
Megjegyzés #3: erősen ajánlott -- még egy billentyűzetnél is -- az extra árambetáplálás (töltés) USB host mód közben. Ez Y-alakú kábellel valósítható meg a legegyszerűbben.
Megjegyzés #4: tudomásom szerint a GPL licensz értelmében jogunkban állna elkérni a gyári/stock Motorola kernel forráskódját. Tudomásom szerint az nem elérhető, vagy tévedek?
[ Szerkesztve ]
-
anglergab
addikt
Valószínűleg a wpa_supplicant.conf-hoz nem tud hozzáférni egy process. Ellenőrizd a wpa_supplicant.conf fájl jogosultságait vagy recoveryben próbáld a Fix Permissions-t.
(#10096) Mozzarella: viszonylag nagy lehet a Quadrant pontok szórása, főleg az órajel emelésével. Egy készülék esetén is, hát még több készülék között. Magasabb órajeleken hamar megmutatkoznak a pici minőségi eltérések az egyes szilíciumlapkák között. A kezdeti hőmérséklet hatásáról nem is beszélve. Szóval a Quadrant pontszám függhet attól magasabb órajeleken, hogy mennyi ideje volt bekapcsolva a telefon, illetve a teszt előtt mennyire számításigényes műveleteket futtattál.
[ Szerkesztve ]
-
anglergab
addikt
válasz RootRulez #10133 üzenetére
Szóval innen a legfrissebb nightly-t érdemes letölteni? Ez a leghivatalosabb CM forrás, vagy xda-n kell keresgélni?
(#10135) domerator Ha töltőn van és be van kapcsolva, akkor definíció szerint nem lehet sleep módban. Akkor van sleep módban, ha ki van kapcsolva a kijelző ÉS nem ébred fel hardveres érintőgombra. PC-n monitorozod a CPU használatot? Ha igen, akkor sem lehet igazi sleep módban, mivel töltődik. Egyébként van olyan permission a progiknál, hogy megakadályozhatja a készülék sleep módba kerülését: látszólag ilyenkor is sötét a kijelző, de felébred hardveres érintőgombra.
[ Szerkesztve ]
-
anglergab
addikt
válasz domerator #10135 üzenetére
Lásd a #10138-as hsz-t. Szóval az igaz sleep mód a PC-k S3 állapotához (suspend-to-ram) hasonló. Elég nehéz ilyenkor monitorozni realtime a cpu loadot, ugyanis ha az lehetővé válna, akkor már nem sleepben lenne a telefon. Egyébként egyes programok és device-ok (GSM modem, ébresztőóra) igazi sleepből kihozhatják/felébreszthetik a telefont, ha megfelelő trigger (bejövő hívás, időzítés, stb.) bekövetkezik.
[ Szerkesztve ]
-
anglergab
addikt
válasz volvoguy #10157 üzenetére
Ha a wpa_supplicant.conf jogosultságai elállítódnak, akkor Error-t ír a wifi státusznak a Settingsben. Ilyenkor vagy töröljük a konfigfájlt, vagy helyreállítjuk a jogosultságait, vagy lefuttatunk egy scriptet a recoveryből, ami minden fájlra (a systemen) helyettünk ezt végrehajtja (Advanced>Fix Permissions).
(#10161) kammerer számomra a kapacitív gombok is hardveresnek számítanak
(#10145) domerator köszi a screenshotot. Igazi sleepben volt a Defy-od, ez kétségtelen az elmondottak alapján. A néhány %-os CPU load idle módban akár a monitorozásnak is betudható. Nagyobb felbontás esetén kellene a CPU load idősort vizsgálni és periodicitást keresni (akár Fourier-transzformálni ). Lehetséges, hogy feltűnne a system monitor appod pollozási frekvenciája; még az is elképzelhető, hogy néhány másodpercre felébresztgeti rendszeresen a monitor app a mobilt (ez esetben érdemes nagyobb pollozási időintervallum mellett megismételni a mérést). Ugye a mérési módszer befolyásolja a mérendő mennyiséget/a mérés eredményét -- ez a hatás (általában; jó esetben) elhanyagolható, de ha ilyen %-os felbontáson vizsgáljuk a CPU loadot, akkor már nem biztos. Most látom, hogy a CPU load grafikon skálázása logaritmikus.
[ Szerkesztve ]
-
anglergab
addikt
A CM7-ben a Vsel-t nem SetVsel-lel, hanem a recovery-ből módosítottuk (ami ugye része a CM-nek).
A LiPol akksik nem szeretik, ha csontra le vannak merítve (és azt sem, ha max.-ra fel vannak töltve, tartósan). Legjobban a 80% körüli töltöttséget kedvelik. Mindenesetre a akku % kijelzés finomhangolására jó a teljes lemerítés/feltöltés ciklus, azonban az akksi bizonyára nem kedveli.
(#10172) topa11: Megpróbálhatod törölni a Market adatait, és újrapróbálni.
[ Szerkesztve ]
-
anglergab
addikt
Kikapcsolva természetesen gyorsabban töltődik.
Kalibrációhoz: talán egyenletesebben töltődik, ha ki van kapcsolva, mivel a töltőáram nem fluktuál, mint ahogyan bekapcsolt állapotban előfordulhat. Így talán kikapcsolt állapotban érdemesebb kalibrálni.(#10179) kammerer Nyilván betöltve kell lennie kernelnek (legyen az recovery, vagy a normál rendszer) a hardveres érintőgombok működéséhez. Kivétel a hardveres gombok közül a hangerőszabályzás, mivel az kernel betöltése előtt (firmware szinten) is működik.
[ Szerkesztve ]
-
anglergab
addikt
Az akkumulátorfogyasztása a legfrissebb CM nightly-knak milyen a gyári Motorola Android 2.2-eshez képest? Illetve a legfrissebb nightly-kban mennyi error/warning látszódik DDMS-ben (adb logcat-on)? A sok error/warning az optimalizálás hiányára utal, Blade-nél sok volt.
Továbbá mennyi RAM-ot eszik a CM a gyári 2.2-höz képest?[ Szerkesztve ]
-
anglergab
addikt
válasz szabof1 #10343 üzenetére
Üdv!
Mennyire frissek a leírásodban linkelt programok (RSDLite, SOC, 2ndInit)?
Ezekből a legfrissebb változatot hol lehet letölteni?
Egyébként a leírásodban linkelt 2.2-es romok hivatalos gyári (stock) rom-ok? Tehát nincsenek megpiszkálva?
Köszi a részletes leírásokat!(#10354) chab7 ZTE Blade-nél Linux használatával is fel lehetett tenni custom recovery image-et, nem volt szükség Windowsra, driverekre. A Defy-nál miért nem található konzolos (adb-s) recovery telepítéshez leírás?
[ Szerkesztve ]
-
anglergab
addikt
chab7, szabof1 mi a véleményetek erről? -> #10353
[ Szerkesztve ]
-
anglergab
addikt
Köszi a linket! Az adb-t be tudom állítani Linux alatt, de pl. hogyan rootolsz, telepítesz custom recovery-t / bootmenüt / 2ndInit-et / sbf firmware fájlokat Linux alatt?
Custom recovery image (img fájl) minden bizonnyal telepíthető flash_image progival. De a bootmenü / 2ndInit telepítésének mi az elméleti háttere? Meg ugye az sbf flasheléhez is windowsos program kell.
[ Szerkesztve ]
-
anglergab
addikt
Nem az én készülékem, aminek a screenshotját látjátok (egy kollégámé ).
Egyelőre annyit tudok, hogy 1370 MHz-en érte el, a további részleteket mihelyst megtudom, beleírom a táblázatba. A rendszer: CM RC 1.5 (biztosan nem nightly, régebbi, az xda-ról lett letöltve még), ha jól emlékszem.[ Szerkesztve ]
-
anglergab
addikt
válasz mira72 #10463 üzenetére
Milyen clock/vsel értékek mellett sikerült elérni az újabb rekordot?
Egyébként a telepített appok száma aligha befolyásolja a teljesítményt, sokkal inkább az éppen memóriába betöltött adat mennyisége. Ez magyarázhatja részben, hogy második-harmadik futtatásra jobb az eredmény: az első futtatás után a memóriában maradnak benchmark rutinok (shared library-k), nem kell azokat újból a NAND-ból beolvasni a RAM-ba (ami nagyon időigényes relatíve).
A feszültségről: tegnap linkeltem egy cikket, abban írnak a VSel vs. Volt összefüggésről. -
anglergab
addikt
válasz Tökmindegy #10501 üzenetére
Milyen a CM (nightly-k) akkufogyasztása a gyári 2.2.2 CEE rom-hoz képest?
-
anglergab
addikt
Valaki használja itt az sbf_flash-t? (linuxos SBF flashelő/kicsomagoló progi)
Az sbf_flash outputjában a következő olvasható nálam (kicsomagoltam egy sbf-et (-x kapcsoló), telefon nincs csatlakoztatva):===JRDNEM_U3_3.4.2_179002_DEBLUR_SIGN_SIGNED_UCAJRDNEMARAB1B80AA03A.0R_PDS03C_USAJRDNFRYORTCEE_P016_A016_HWp3_Service1FF.sbf ===
Index[1]: Unexpected chip 32
Index[2]: Unexpected chip 32
Index[3]: Unexpected chip 32
Index[4]: Unexpected chip 32
Index[5]: Unexpected chip 32
Index[6]: Unexpected chip 32
Index[7]: Unexpected chip 32
Index[8]: Unexpected chip 32
Index[9]: Unexpected chip 32
Index[10]: Unexpected chip 32
Index[11]: Unexpected chip 32
Index[12]: Unexpected chip 32
Index[13]: Unexpected chip 32
...Ez mit jelent? Egyáltalán hiba? Ismétlem: nem telefonra írta, hanem a gyári sbf firmware CG-kre kicsomagolásakor.
[ Szerkesztve ]
-
anglergab
addikt
Köszi. Azért megnéznéd, hogy a terminálra mit ír ki Neked erre (kicsomagolás)?:
./sbf_flash -x <sbf fájl>
A bootloader témához: a bootloader zártságából következik, hogy eddig custom rom pl. CM esetén is gyári 2.2.2-es bootloadert (és így -- mivel része -- kernelt) kellett használni?
[ Szerkesztve ]
-
anglergab
addikt
A Defy+ rom, amit használsz, milyen kernelt (bootloadert) tartalmaz/használ? 2.2.2-eset vagy valami 2.3-asat? Ha az utóbbi, lehet downgradelni 2.2.2-es kernelre?
(Ha nem tudod, az uname -a parancs megmondja a pontos kernelverziót, és abból már következik, hogy 2.2.2-es vagy 2.3-as rendszer natív kernele.)
[ Szerkesztve ]
-
anglergab
addikt
CMStats -> Második a Defy (umts_jordan) a CM telepítések számát illetően! Furcsa, hogy még nincs stable verzió Defy-ra. Bár közismert tény, hogy egy CM nightly Defy-ra stabilabb / sokkal bugmentesebb, mint egy CM stable Blade-re.
[ Szerkesztve ]
-
anglergab
addikt
(#10594) csabi94: zárt bootloader esetén a kernel nem módosítható, csak max. másik gyárira (ami aláírt): nem tölthetünk be valódi custom (tehát nem gyári fordítású) kernelt. Pedig sok hasznos feature bevezetéséhez, valódi, mély változtatásokhoz szükség lenne a kernel újrafordítására. Röviden: a készülékben rejlő valódi potenciál kiaknázásához (custom rom-ok révén) szükséges a kernel cseréje.
(#10596) kano próbáltad kalibrálni az akkut és/vagy wipe-olni a batterystats fájlt (ha mindkettőt próbáltad/próbálod, akkor lényeges lehet a sorrend)?
Egyébként érdemes várni néhány napot, hogy a friss rendszer "megtanulja" az akkukapacitást helyesen becsülni (a jó statisztikához meg sok mintavétel/(töltési) ciklus kell). Szóval valószínűleg nem a CM fogyaszt sokat (nagyon sokan használják, ha ilyen bug lenne, azt valószínűleg hamar kijavítanák), hanem kezdetben hibásan jelezte vissza az akku töltöttségét a rendszer.(#10647) pok.tom Miből gondolod, hogy már régóta piros lencséseket árulnak? Ez a T-re vagy a boltokra igaz, vagy esetleg mindkettőre?
Valaki rendelt mostanában T webshopból Defy-t? Piros vagy zöld lencséset kapott?
-
-
anglergab
addikt
válasz Lacopapi #10795 üzenetére
Bizonyos esetben (zöld lencsénél?) a Defy+-ra való átállás magában foglal fixed sbf firmware telefonba írását is. Ha vissza akarunk térni nightly-ra (vagy 2.2.2 gyárira), akkor nem az lenne a logikus, hogy a gyári sbf-ből származó megfelelő firmware részt visszategyük? Mivel ilyen firmware részeket nehéz előállítani, célravezető lenne a komplett gyári (stock) sbf flashelése, nem?
[ Szerkesztve ]
-
anglergab
addikt
Egyébként ugyanígy kell megnézni Linux esetén is (adb logcat vagy lolcat ; de ha scriptelni akarunk, akkor csak annyi az eltérés, hogy Windows esetén batch fájl, Linux esetén bash script kell , meg persze a megfelelő binárisok).
Igaz, a leírásban windowsos környezet szerepel, mivel a többség azt használja.
Bár tény, hogy kevés olyan művelet van egy androidos okostelefon esetén, amelyhez külön PC kellene (pl. a firmware flashelése ilyen; bár ha működne az USB host -- nincs kizárva --, akkor akár másik Defy-ról is lehetne sbf-et írni )(#10803) kano A Defy+ rom kedvező fogyasztása a gyári, illetve CM7 rom-okhoz képest mutatja, hogy fogyasztás szempontjából igen sokat számít a kernel (ugye az utóbbi kettő romban ugyanaz a kernel).
[ Szerkesztve ]
-
anglergab
addikt