Kapcsoljuk ki a wifit, bluetooth-t, 3G adatforgalmat, ha nem használjuk ezeket, csökkentsük a fényerőt...
Ezek a szokásos alap megoldások. Tekintsük át a kicsit trükkösebb, kevésbé közismert megoldásokat, és nézzünk ezek mögé! Ismerjük meg, pontosan milyen folyamatok vezethetnek az akksink gyors merüléséhez!

Fényerő: az automatikus fényerőt (ami a környezet világosságához igazítja a kijelző LED háttérvilágítását) célszerű lehet letiltani, ugyanis ez a kényelmi funkció jelentősen terheli a CPU-t, főleg, ha gyakori a mintavételezés (a szenzor kiolvasása, azaz pollozása). Arról nem is beszélve, hogy a szenzorok is áramot fogyasztanak.

Modern integrált fényérzékelő szenzor. Működése közben áramot fogyaszt, a kiolvasása extra energiát igényel!

Kijelző színek: a TN filmes panelok a telefonokban LED-es megvilágításúak, a megjelenített színtől első közelítésben nem függ a fogyasztásuk. Ám, ha egy kicsit részletesebben megvizsgáljuk a problémát, akkor kiderül, hogy éppen a sötét pixelek fogyasztanak több energiát (mint a világos pixelek). Ugyanis a pixelek alapértelmezett állapota a minden háttérfény átengedése (azaz a teljesen világos szubpixel, RGB-nél ugye a fehér), a sötétítéshez folyamatosan áramot kell fenntartani (a tranzisztorok adják le ezt az energiát hő formájában). Megjegyzem, hogy nagyon kicsi az eltérés a fehér és a fekete pixelek tranzisztorainak (amúgy is nagyon kicsi) áramfelvétele között. Ám a TN film nagyon sok tranzisztort tartalmaz (~1 millió).

[70w]: WayteQ xTAB-70w specifikus információ

Akkumulátor, töltés

-- [70w] USB-ről is tölthető a tab, annak ellenére, hogy a szofter kisütést ír
-- [70w] érdemes üresjáratban tölteni a hálózatról a tabot, ezzel az akksi élettartama kevésbé csökken; lehetőleg kerüljük az aktív használat közbeni töltést, ez nagyon intenzív melegedéshez vezethet
-- ne várjuk meg, míg a tab teljesen lemerül, ugyanis a Li Pol akksik nem szeretnek teljesen lemerülni (valójában nem is merülnek le teljesen, már előbb kikapcsolnak, azonban már ekkor is nagyon alacsony a töltöttségük)
-- tároláshoz az optimális töltöttség a ~ 80%
-- nem érdemes túltölteni sem, ezt sem szereti az akksi -- viszont erre van hatékony beépített védelem; ellenben a túlmerülés ellen a tab kevésbé hatékonyan tud védekezni
-- nem kell formázni az akksit, akármikor tölthetjük, memóriaeffektus nem lép fel
-- az akksi "formázása" többet árt, mint használ
-- [70w] a gyors töltéshez 2 A leadására képes táp szükséges
-- [70w] érdemes csökkenteni a tab kijelzőjének fényerejét (automatikusan erre nem kerül sor), és letiltani a kijelző képének automatikus forgatását, ezáltal extra akksiidőhöz juthatunk
-- [70w] a tab lítium (pontosabban Li Fe) akksival rendelkezik, a gyári kapacitása 3200 mAh, a névleges feszültsége 3.7 V, a tárolható max. energia 11.84 Wh
-- az akksit nem kell kalibrálni, azonban az automatikus szoftveres kalibráció érdekében érdemes teljesen feltölteni rom csere/frissítés előtt; a batterystats.bin kalibrációs fájl törlésével nem lehet extra akksiidőhöz jutni

FONTOS! Az előzményeket lásd a Ghoo Power akksiról írt cikkemben!

Kiindulási feltételek: adott egy stabilizált 5 V-os (DC) feszültségforrás, esetünkben a Ghoo Power akksi, amit a Bike2USB-vel töltök biciklin.
Adott egy 3 V (DC) 3 LED-es hátsó villogó. Adott egy 4.5 V (DC) 7 LED-es első lámpa.
A feladat adott: 5 V-ból kellene 3 V-ot és 4.5 V-ot előállítani, minél jobb hatásfokkal.

Az implementációm:

- hátsó lámpa (5 V -> 3 V, 2xAA elem): erre a célra egy szimpla ellenállás mint feszültségosztó és áramkorlátozó nem megfelelő. Túl sok lenne a veszteség, lekorlátozná az áramot és még a kívánt feszültségszint sem lenne biztosítható általa mindig. Tovább bonyolítja a helyzetet a LED-ek nemlineáris feszültség-áram karakterisztikája, semmilyen feszültségingadozás itt nem tolerálható. Egy megbízhatóbb, profibb alkatrészre esett a választásom: egy feszültségregulátorra (ilyeneket használnak a tápegységekben és az alaplapokon is). Az LM317-eset választottam. Szükség van 2 kondenzátorra és 2 ellenállásra. Az előbbiek nem kötelezők, a zajszűrésben van szerepük. Az utóbbiak (az ellenállások) viszont szükségesek. Kiszámolható, hogy melyik kivezetéshez mekkora ellenállásra van szükség a kívánt feszültségkonverzióhoz (lásd az adatlapot).
Pl.: R_1 = 240 Ohm + R_2 = 330 Ohm -> ~ 3 V. A hátsó lámpa tokjában az elemek helyére rögzíthető az LM317-es az ellenállásokkal, esetleges kondenzátorokkal és vezetékekkel együtt. Az LM317-es konverzióval 5 V-nál mérve a 3 LED-es villogó ~ 70 mA-t fogyaszt, a teljesítmény 350 mW. Nagyjából ennyi a 3 nagy fényerejű LED teljesítménye is (ideális esetben), tehát ~ elhanyagolható a regulátor terhelése (kb. 40 mW alatt lehet).
Ez nagyon elterjedt megoldás, pl. a Raspberry Pi miniszámítógépben is ugyanígy állítják elő az input 5 V-ból az alacsonyabb feszültségeket (pl. 3.3 V-ot). A regulátor elég széles feszültségtartományban dolgozhat, azonban magasabb terheléseknél hűtés szükséges (az integrált nagyteljesítményű FET-ek miatt). A regulátorban van áramgenerátor és stabilizátor IC is, sokszor még túláramvédelem is.
Elég profi IC. Egyébként az output feszültséget megadó képlet:

Előfeltételek:

HW:
0. Samsung Nexus S
1. Y-alakú kábel a tápellátáshoz (a Nexus S nem ad ki feszültséget, de nem is "lebeghetnek" host módban a kivezetései!) A Nexus S töltődni fog host módban. Uplink feszültséget biztosító powered hub esetén nem szükséges Y-kábel.
2. USB OTG-kábel (micro USB). Nem szükséges, hogy OTG legyen (tehát az ID pin "lebeghet" a kábelben).
3. USB-áramforrás, low-power eszközökhöz is! (pl. PC, akksi) high-power eszközökhöz extra (vagy nagyobb "teljesítményű") USB-áramforrás!
4. Az USB periféria (billentyűzet, egér, pendrive, külső HDD, hub, stb.) Egy eszköz esetében nem szükséges hub!

SW:
1. Matr1x kernel 21=< (CFS)
2. CM9 nightly (Android 4.0.4)
3. USB Hoszt Vezérlő app (sztupy)

How-to:

0. Csatlakoztatod az Y-kábelhez az USB-áramforrást és az USB perifériát. Ha ez hub, csatlakoztasd hozzá a további USB eszköz(öke)t. Ha powered a hub, csatlakoztasd az áramforrását. Ha a powered hub uplink (a mobil fele) biztosít feszültséget, akkor powered hubnál nincs szükség USB áramforrásra. Meggyőződsz, hogy tényleg kap feszültséget az (összes) USB periféria.
Ha csatlakoztattál nagy áramigényű eszközöket, azok megfelelő működéséhez további áramforrásokra van szükség (pl. HDD, CD/DVD meghajtó, stb.)
1. Bekapcsolod a mobilt (ha már be volt, kikapcsolod és újra bekapcsolod, nem pedig újraindítod).
2. Megvárod, míg a Superuser app működésbe lép.
3. Elindítod az USB Hoszt Vezérlő appot (vársz).
4. Beállítod: működési mód: (ha nem OTG kábelt használsz) Auto-hoszt mód, (ha OTG kábelt használsz) OTG (és vársz), Hoszt mód eszközkezelője: S3C HS (USB2) kezelő, majd Töltő kikapcsolása (és vársz)
5. Infó fülre lépsz, majd csatlakoztatod az Y-kábelt az OTG-kábelen keresztül.
6. USB fül: billentyűzetnél lehet, meg kell nyomni a Frissítés gombot (vársz), majd az USB Keyboard-ra, és USB eszköz újraindítása (Android billentyűzet rejtve lesz). Egérnél: alapból látszik, ezt csak újraindítani kell (kurzor meg fog jelenni). Pendrive, HDD: alapból látszódnia kell: a megfelelő partíciónál eszköz csatolása (a leválasztás nekem nem működött). A pendrive-ot nem kellett újraindítani a használatához.
7. Ha már nem kell az USB-eszköz, kihúzod az OTG-kábelt.
8. Újracsatlakoztatás: goto: #3 (az USB Hoszt Vezérlő appot NE zárd be!)

Nagyon sokan kérdezték tőlem, hogyan sikerült a ZTE Blade androidos készüléknél az USB host módot engedélyeznem, ezért közzéteszem ezt a személyes bejegyzést.

FONTOS! Ezen bejegyzés (NEM pedig cikk) elsősorban hozzáértőknek ajánlott!
FONTOS! Az USB host mód egy erősen kísérleti mod! Ha aktiválva van, nem csatlakoztatható a mobil PC-hez!
FONTOS! Ha az USB host mód aktiválva van, akkor nem lehet elérni a mobilt ADB-n és az SD kártya sem elérhető PC-ről!
FONTOS! Bármilyen módosítás előtt készítsünk rendszerünkről teljes backupot!
FONTOS! A működésért, esetleges károkért (pl. téglásodás) NEM vállalok semmiféle felelősséget, csak saját felelősségre!
FONTOS! A témához NEM nyújtok semmiféle támogatást!

Kettő (!) USB billentyűzet és egy USB egér egyszerre (!) csatlakozik egy Blade-hez

FIGYELEM! A firmware cseréje (TPT alkalmazása) igen veszélyes/kockázatos művelet!
FIGYELEM! Ezen bejegyzés (NEM pedig cikk) elsősorban hozzáértőknek ajánlott!
FIGYELEM! Ezen bejegyzés NEM tartalmaz instrukciókat a frissítésre vonatkozóan; csupán elméleti összefoglaló.

Mi az a TPT?

A Total Phone Transfer rövidítése. Alkalmazásával újraírható/frissíthető a ZTE Blade firmware-je (~BIOS) és előre elkészített lemezképekben tárolt teljes operációs rendszer(kép) automatizáltan (hibaellenőrzés nélkül) beírható a NAND memóriába (ROM). Komoly hátránya, hogy visszafordíthatatlanul elronthatja a készüléket, ha nem megfelelően, vagy előismeretek nélkül alkalmazzák. Ezen bejegyzés elsősorban a hozzáértőknek ajánlott!

RAM vs. "ROM"

A ZTE Blade 512 MiB RAM-mal rendelkezik (közvetlen hozzáférésű memória programkódnak és adatoknak), ebből az alkalmazások számára elérhető ~ 416 MiB. A készülék 4 Gbit ~= 512 MB-nyi belső memóriát (internal storage; a továbbiakban "ROM", a becenevével ellentétben írható-olvasható-, NAND-memória, háttértár, "lemez", mtd) tartalmaz (analóg a PC-k merevlemezével, a háttértár funkcióját tölti be); ebből ~ 467 MiB elérhető közvetlenül a rendszer számára (1 MB = 10^6 B, míg 1 MiB = 1024^2 B = 2^20 B). A leggyorsabb tárolóeszköz természetesen a RAM, elérési sebességben utána következik a ROM (~ HDD); a sor legvégén kullog az SD memóriakártya (~ flash tárolóeszköz, pendrive). Érthető, hogy érdemes alkalmazásainkat a belső memóriában (és nem az SD-n) tárolni, a gyors hozzáférés érdekében. Az érdeklődő olvasónak megjegyzem, hogy fizikailag egy házban (csomagban) került elhelyezésre a RAM és a ROM, lásd az első képet.
Megjegyezzük, hogy a szakzsargonban a ROM szót többféle jelentésben is használhatjuk, a kontextusától függően: jelentheti a belső memóriát (ami az elnevezéssel ellentétben (újra)írható-olvasható, bár nem korlátlan alkalommal), és jelentheti a telepítendő zip fájlt is.

Ezen cikk a ZTE Blade-n futó Android 2.1 (Éclair), 2.2 (Froyo) operációs rendszerekhez készült, ugyanakkor számos ismertetésre kerülő parancs/eljárás alkalmazható másik androidos okostelefonon, sőt asztali gépen futó Linux (pl. Ubuntu, Debian) terminálban is!

Az Android Linux alapú operációs rendszer: tehát Linux kernel (rendszermag) töltődik be indításkor a memóriába.

Megjegyzés: a szürke színű szövegek elsősorban haladó felhasználóknak ajánlottak, illetve a téma iránt különösen érdeklődő olvasónak; aki kezdő/most ismerkedik az Androiddal kihagyhatja most a szürke részeket, és esetleg később elolvashatja azokat.

Megjegyzés: a boot.img lemezképfájl tartalmazza a bootloader nevű partíción a normál rendszerindításkor inicializált kernelt (ugyanis pl. a clockwork recovery is tartalmaz egy egyszerűsített kernelt; a kernel mérete Android esetén néhány MB).
Megjegyzés: Aki már felrakta a Clockwork recoveryt a ZTE Blade-re, a recovery indításakor láthatott egy fekete képernyőn megjelenő A N D R O I D ... szöveget (fejjel lefelé); a recovery kernele ekkor töltődik be.
További érdekességek:
- normál boot (elérése: Power gomb nyomvatartása a splash kép megjelenéséig): legelőször a splash partíción található bitképet látjuk, ezután/közben a bootloader partícióról betöltődik a kernel és a firmware egy része, ezután felcsatolódnak a system, userdata, cache stb. partíciók csak olvashatóan, és elindul a grafikus felület.
- recovery boot (elérése: Power gomb + hangerő MÍNUSZ gomb nyomvatartása a splash kép eltűnéséig): szintén a splash tartalmát látjuk, majd a recovery partícióról betöltődik egy speciális, "csökkentett tudású" kernel, majd betöltődik a recovery menüje is (ha felraktuk a clockwork-öt, egyébként 3 betűt látunk, és semmi különöset nem tudunk csinálni).
- bootloader mód (elérése: Power gomb + hangerő PLUSZ gomb nyomvatartása ~ 10 másodpercig): ekkor a splash után látszólag megáll a rendszer, ugyanis nem töltődik be a kernel. Ekkor PC-ről ADB-n keresztül olyan diagnosztikai beavatkozásokat hajthatunk végre, amelyeket futó (betöltött) rendszer alatt csak root jogkörrel tudnánk végrehajtani. Ebben az üzemmódban a telefon keres a fájlrendszerben a /mnt/sdcard/image helyen mbn fájlokat: ezekkel alacsony szintű műveletek automatizálhatók (pl. partícióátméretezés, partíciók tartalmának flashelése, boot, recovery csere stb.) Az eljárás neve: Total Phone Transfer (TPT), a ZTE Blade fórumán csodazip-nek hívják a zipet, amely tartalmazza az image mappát, ami tartalma az előbb említett helyre írható, ha low-level módosításokat szeretnénk végrehajtani (módosított verziói: csudazip, csudazip2).
Figyelem! A low-level (TPT) beavatkozások különös körültekintést, figyelmet kívánnak: ugyanis elképzelhető (ha a felhasználó nem követi PONTOSAN a leírásokat), hogy a készülék a végfelhasználó számára visszafordíthatatlanul károsodik, helyreállítása csak szakszervízben lehetséges!
TPT beavatkozás előtt a szkriptek (image.rar) md5 hashainek kiszámítása, összevetése a fájlokat publikáló által közzétett ellenőrzőösszeggel kritikus fontosságú!