Co je špatně na Androidu?

Já bych spíš viděl problém v komunikaci a moc tomu nerozumím, proč tomu tak je. Když na telefon moc nesahám a zbytečně si s ním nehraji, tak mi vydrží tak tři dny. Denní úbytek energie v baterii je tak 25-30%. Emaily kontroluji co jednu hodinu.

Když si v poštovním klientu (K9) nastavím, že chci poštu dostávat online a zaškrtnu v nastavení push notifikace, tak mi výdrž baterie dramaticky poklesne. Totéž dělají programy typu ICQ, Skype, alternativní Jabber klienti, ... Podle zkušeností si každý sebere o takových 20-40% energie z baterie denně nevíc. Na to, nechat jich běžet víc zároveň, jsem nesebral odvahu.

Přitom to nedělá nic jiného, než třeba Gmail nebo Hangouts a ty jsou těžce v pohodě. Jedinou světlou výjimkou, na kterou jsem zatím, z aplikací třetích stran, je WhatsApp, který dělá v podstatě totéž, co ty kecátka výše a na baterce ho nepoznám. Proč někde to jde a někde nejde, když možnosti mají stejné? Tomu nějak nerozumím.

Toto je spravna rec. O tomto som hovoril odkedy existuje android. Efektivita programovania v tychto casoch je na bode mrazu. Uz to nie je to co bolo volakedy. Viem si predstavit, ze by mobilny telefon vydrzal minimalne 2x tolko co teraz a aplikacie by bezali sviznejsie na stavajucom hardware ak by sa zmenil system vyvoja aplikacii.

[2] Bohuzial, toto sa deje nielen na androide. Aj na desktope sa programuje klikanim. Aplikacia ma zbytocne vela bordelu v podobe nejakeho frameworku, z ktoreho sa vyuzije mozno par primitivnych funkcii.
Dnes je moderne heslo: preco optimalizovat, ved mame uz aj v mobile x-jadrove procesory a kopec ramky. a potom to aj tak dopada.

[1] protože Gmail a Hangouts používají (velmi pravděpodobně) Googlí systém pro dopravu push notifikací - Google Cloud Messaging for Android, který dovolí aplikaci i celému telefonu spát a nechat se probudit, když se něco děje. Jenže na to je potřeba aby server té služby i aplikace spolupracovaly a server předával notifikace přes GCM. Jak to funguje low level technicky se mi nepodařilo zjistit, že telefon může spát a přesto zprávu dostane, i když z mé zkušenosti to někdy pár minut může trvat.

Pokud mám obecný IMAP klient a připojuji se k obecnému IMAP serveru, tento server logicky GCM nepodporuje, takže musím držet otevřené spojení přímo na ten IMAP server a aby nedošlo k timeoutu musí být zařízení stále aktivní a posílat keepalive po síti a nemůže upadnout do úsporného deep sleep režimu. Pokud chci takto udržovat něco co funguje na UDP protokolu, třeba SIP klient pro příchozí hovory, tak jde do háje baterka ještě daleko rychleji.

Já měl v androidu při vypnutém displeji zapnutou přes 10 hod GPS a aplikaci pro sledování polohy a baterie za tu dobu poklesla z 95% na 34%. Je to hodně nebo málo? A jak je to vůbec všeobecně s androidem v pohotovostním režimu?

Ryba smrdí od hlavy - nie je problémom práve linuxové jadro? Problém s výdržou batérie tam bol vždy.

[6] Kdysi jsem si na jednom notebooku docela dost hrál s PowerTOPem a spotřebu se mi povedlo dramaticky snížit už jen výběrem aplikací, které mi tam běžely. Když se počítač "nudí", tak se procesor přepne do nějakého "dřímajícího" režimu, ve kterém žere o dost míň, než normálně. To že je graf vytížení procesoru na nule, ještě neznamená, že počítač "dřímá". Když jsem vyeliminoval aplikace, které notebook příliš často probouzely z "dřímajícího" modu, tak se mi povedlo snížit spotřebu v idle z 18 na 12W a občas to šlo i na 10W., takže cca o třetinu.

[4] U toho IMAPu to docela chápu. Myslel jsem si, i když zároveň se mi to moc nelíbilo, že ten pošťák si to to spojení nějakým způsobem otevře přes Google. Googli server by byl připojený na IMAP server a když by se něco dělo, tak by telefonu dal vědět tím jejich PUSHem.

Vyloženě bych na to čekal nějaké API, přes které to bude fungovat, když ten WhatsApp dokáže být na příjmu trvale s minimálním dopadem na spotřebu. Něco jako "Google, já jsem serverová část aplikace X. Vzkaž uživateli Y, ať se aplikace X připojí na server. Něco tu pro ni mám". I když stejně nechápu, jak to tomu Googlu může fungovat. Nějakým způsobem využívá notifikace v síti mobilních operátorů? Kdyby šlo o běžné TCP/IP, tak nevidím důvod, proč by měl fungovat úsporněji, něž aplikace třetích stran.

Co si autor představuje pod "předěláním vývojového prostředí" a "opravdu efektivními knihovnami pro tvorbu uživatelského rozhraní a grafiky"? Bylo by to možné trochu rozvést?

[8] jak jsem psal o tom JDownloaderu... asi v tom smyslu, aby běžným programátorům nešlo vytvořit takovou zhůvěřilost, aby běžné uživatelské rozhraní mohlo žrát 50% výkonu 2GHz procesoru, když se tam evidentně neděje nic výpočetně náročného, co by mohlo spotřebovat takový výkon

To je cely takovej nesmysl, ze ani nevim kde zacit. Tak radsi nic.

Ha ha, pekne zavery, ale naivni predstava o reseni. Android je, jak vsichni asi vime, reseni, kde se muselo hodne spechat, jinak by hrozila dominance iOS. Tak proc ted ten narek? Android se postupne jiste podari optimalizovat, ale zatim se nezvlada ani update na posledni produkcni verzi. Obchody jsou plne zarizeni s Androidem 4.1, jejichz update nebude vubec mozny, nebo dost tezky. Takze prominte, ale Vas narek nad neoptimalnimi knihovnami mi pripada, jako jeden z poslednich problemu platformy.

Osobne si myslím že celé to nariekanie ohľadne toho že voľakedy sa programovalo lepšie je hlúposť. Mali sme 100x menšiu ram a 100x pomalší počítač a fungovalo to. No áno..... Ale tie programy toho aj 100x menej vedeli. Mali sme znakové terminály 80x25 a nie FullHD rozlíšenie s vykresľovaním tisícok 3D objektov 30x za sekundu... Dátové toky boli 10000x menšie... Multitasking? Ako vyzerala priemerna www stranka pred 10-15 rokmi? Bezpečnosť bola kde?
Počet dobrých programátorov sa určite niekoľkonásobne zvýšil. Ale komplexnosť problematiky sa zväčšila rádovo.
Pamätám si ako sme programovali v asembleri. Optimalizovali sme kód lepšie ako prekladače C. Ale dnes? Procesory a prekladače spravili tak obrovský vývoj, že pri optimalizovaní na viacjadrových procesoroch, hyperthreadingu, CUDA, pri komplexnosti OS ktoré používame nemáme šancu im konkurovať a lepšie optimalizovať.
Takže za trest si zober 10-15 ročný mobil a používaj ho mesiac dva. Uvidíme ako sa vyvinie tvoj názor na android.

Dalvik je mrtev, at zije ART (http://en.wikipedia.org/wiki/Dalvik_(software)#Android.27s_ART_virtual_machine).

[13] tak to je tedy hovězí nápad... chápete vůbec, že ART ten problém nevyřeší? a proč to nevyřeší?

[13] to si delate srandu, ze android je proti prumernemu server adminovi 15 let pozadu, ze s tim prisli teprve v 4.4

Cely blog je ladeny prilis negativisticky. Navyse podla mna nespravny (problem je IMHO inde).

Ked sa Android len rozbiehal (niekedy okolo verzie 2.1) tak sa spotreba baterky dost riesila, bolo vela odporucani ako "spravne" robit aplikaciu, upozornovalo sa na najvacsich zrutov baterky (mobilna komunikacia, displej, beziace procesy), ako robit synchronizaciu... Islo to az do takych detailov, ze sa porovnavala spotreba WiFi/2G/3G alebo ze modre pixely na displeji zeru vyrazne viac nez cervene (aj preto mal Android v zaciatkoch v menu cierne pozadie a biele pismo - zralo to menej, nez cierne na bielom).
Dnes to uz nikoho nezaujima: Obrovske padlovite telefony, vyssie rozlisenie displeja, LTE... a do toho sa pozadie zmenilo na biele, lebo to je viac "marketingove"... a kedze teflony musia byt tenke, tak vacsiu kapacitu baterky nie je kam napchat. Aha - a takmer som zabudol na mobilne reklamy. Napriklad ze ludia analyzou zistili, ze vacsinu vykonu Angry Birds spotrebuju prave na tu reklamu. Zasa vec, ktora nie je technicky problem, ale niekto to naschval (strategicky) chce mat takto...

Snahy o nutenie programatorov (len naozaj efektivne kniznice pre tvorbu uzivatelskeho prostredia a grafiky WTF?) by nikdy nefungovali. Nech si kazdy programuje ako chce. Kludne aj neefektivne. To vyriesi trh. Kto chce, vie vytvorit energeticky uspornu aplikaciu uz dnes. (A IMHO su systemove kniznice Androidu dost optimalizovane - to sa samozrejme neda povedat o roznych "add-on" knizniciach sluziacich na cielenie reklamy a spehovanie uzivatela.)

A trh dnes zjavne hovori, ze to moze byt aj neefektivne: Ludia si (vacsinou) instaluju kadejake chobotiny, zerie im to baterku a nadavaju na to, ale pouzivaju to dalej. A potom si zas kupia novsi krajsi lepsi vacsi telefon, kde si nainstaluju zasa tie iste chobotiny...
A tu je jadro vsetkych "problemov" s Androidom: vacsinovy uzivatel. Zozerie hocijaky sajrajt, tak sa vobec necudujem, ze sa najde plno subjektov, ktory mu ten sajrajt (hardverovy i softverovy) radi predaju.

Ak bude vacsina uzivatelov vyzadovat vacsiu vydrz baterie, tak ju dostane. Aj bez toho, aby niekto rozvrtal cely Android. Zatial to ale podla vsetkeho nie je priorita.

[7] brk, ano to by bylo pomocí GCM možné, ale znamenalo by to, že by autor toho klienta musel provozovat server, který by se napojoval na schránky přes IMAP a posílal přes GCM notifikace na svého klienta a provoz takového serveru něco stojí, takže to u programu jako K-9 Mail nezle čekat.

Ano, to API na to je, je to ten Google Cloud Messaging http://developer.android.com/google/gcm/index.html podívej se na to, mají to celkem hezky udělané. že to na použití ani není nijak složité, dělá to přesně to co popisuješ. WhatsApp je služba, které nemusí spolupracovat s legacy protokoly a servery a má vše ve vlastní režii, takže velmi pravděpodobně GCM používá.

Přes GSM to skoro jistě nejde, to by museli mít napojení na všechny GSM operátory co na světě jsou a nefungovalo by to na wifi, tipuju, že se telefon periodicky probouzí a nějakým úsporným způsobem zjišťuje, zda má nějaké zprávy, pokud ano zavolá tu aplikaci a zprávu jí předá a ta se zachová podle potřeby a povahy té aplikace. Pointa je v tom, že zařízení může pospávat, protože ta zpráva na něj počká, kdežto TCP spojení někam na IMAP/XMPP server se rozpadne a pak se data nepřenesou dokud se znovu naváže. A TCP a následně SSL handshake přeci jen nějaká data a výkon CPU spotřebuje, navíc by to dělala každá aplikace přijímající push zprávy, takže obsluha GCM oproti několika aplikacím, které se pravidelně se probouzejí a přihlašují na IMAP apod. může být docela rozdíl.

Líbí se mi že první pojmenujete problém a pak začnete řešit jiný.

A ty ledničky jsou taky strašný žrouti, 20% jídla se v nich zkazí ;)

Ad „Máte otevřené okno, stahujete soubor, pravidelně se překresluje rychlost stahování, graf vytížení datové linky... a jéje, ono nám to vytěžuje 2GHz procesor na 50%... no kde to jsme?“

Stejně blbě to můžeš naprogramovat v čistém céčku, knihovna neknihovna.

http://www.se-radio.net/2008/03/episode-89-joe-armstrong-on-erlang/

http://media.libsyn.com/media/seradio/seradio-episode89-JoeArmstrongOnErlang.mp3

- doporučuji k poslechu.

Concurrent language, 99,99999% spolehlivost, no shared state, immutable state, pattern matching, asynchronní zasilání zpráv, funkcionální jazyk,
distribuovaná databáze.

Pro vícejádrové procesory potřebujeme actor-based concurrency. Potřebujeme i kvalitní dobře navržené knihovny. Obojí žádný dnešní jazyk nesplňuje, i když některé jazyky mají k těmto cílům blíž než jiné.

Nejsem si jist, jestli tomu skutečně tak je, ale připadá mi, že takový IM+ taktéž běží přes GCM, jelikož po určité době zmizí z paměti a napíše, že přešel do push režinu, aby šetřil baterii. Otázkou je, nakolik je GCM bezpečný, když defacto vaše sezení je předáno na servery Googlu.

[19] Jenze jsou nastroje, ktere takove bastleni vylozene podporujou, a pak jsou jine, kde by ti takovej bastl dal vic prace, nez to napsat aspon +- normalne.

Ale ono v dobe, kdy "hello world" se v M$ visual C++ ... prelozi na 5MB velkou binarku ... neni co divit. Celej DOS nezabiral ani desetinu ...

Ostatne, v dobach minulych mela gameska par kB ... a dala se hrat cele mesice. Dneska neni zadna vyjimka 30+GB ... a dohrano mate za odpoledne.

22 :
A kolik z těch 30GB je kód? Pár MB. Zbytek jsou data. A ty se zmenšit moc nedají, pokud nemá utrpět kvalita. Mimochodem v současné době u AAA her ta data produkuje výrazně víc lidí, než ten kód.

Opravdu má cenu řešit jednotky MB přeloženého kódu když máme disky v TB a paměť v GB? Většina toho exáče bude stejně "studená" a dopad na výkon bude +- prd. Je kopec důležitějších věcí jako třeba struktura dat a jejich cachování než nějaký MB v paměti navíc.

[21] Ty údaje předáváš shape services (provozovatel IM+), ne Googlu - musíš jim dát logovací údaje do používaných IM služeb, v push režimu je pak na služby připojen server IM+ a v případě události přes GCM notifikuje mobil. Jak citlivá informace jde pak přes GCM pak záleží na IM+, klidně může být šifrovaná nebo to může být pouze informace typu "vstávej, máš zprávu". Dnes takhle funguje spousta IM klientů pro Android, možná i většina, protože aby přímo aplikace v telefonu udržovala trvalé TCP spojení na IM server spotřebovává moc zdrojů.

To všetko je len dôsledok doby v ktorej žijeme.
Uponáhľanej doby.
Ak chcú autori Androidu aby sa čo najrýchlejšie rozšíril musia spraviť všetko smerom k vývojárom aplikácií. Všetko jednoducho keďže nie všetci do toho vidia (a chcú vidieť) tak komplexne. No a vývojár aplikácie ma väčšinou bohužiaľ na prvom mieste konečný efekt a rýchlosť naprogramovania ako efektivitu.

A tento problém sa netýka len Androidu.

Nevim, jestli to ma co spolecneho s vydrzi baterie, ale od tech dob, co jsem si nainstaloval Cyanogenmod, tak mi telefon vydrzi o dost dyl. Asi to bude tim, ze mi na pozadi nebezi bonzacke aplikace ;-)

Doporucuju kazdemu vyzkouset - je to docela pekna zalezitost.

Tak popravde hlavni problem v androidu vidim v tom, ze ve srovnani s konkurenci nema tak vyborne SDK a emulator. Dalsi nevyhodou je ze je zameren az na prilis velke mnozstvi HW a existuje az v moc variacich. Popravde existuji telefony s androidem, ktere jsme byl schopen pouzivat intuitivne a v pohode a existuje verze a variace androidu u kterych jsem nebyl schopen napsat ani sms.

Napriklad v nejnovejsim CM11 uz nejsem schopen ani pridat novy kontak v pripade ze mi vola nezname cislo.

Efektivní vývojové prostředí pro Android už existuje pár měsíců. QT od verze 5 běží na androidu.

Je nativní, tudíž nežere moc paměti (nemá reference, garbare collector), procesoru a tedy baterie. Navíc má hardwarou podporu vykreslevání běžných komponent, čímž přenáší výkon z CPU na grafiku a snižuje spotřebu elektriky. Aplikace v něm napsané fičí jak blázen.

K te vydrzi, Jezisek najezil LG G2. Poprve samozrejme vybita do druheho dne;) Ale kvuli vanocum mi tu ted jen lezi a hlasi prichozi maily, k tomu par telefonatu od pribuznych. Po 190 hodinach baterka na 35%.

[26] tam to bohuzel kolisa verzi od verze, ted uz jen ze sportu to provozuju na stare dobre Galaxy 1 a nektere verze vysajou baterku za noc, jine vydrzi i tri dny...

Hezká úvaha. Jak si ale člověk vysvětlí výdrž telefonů jiných značek? Ať už je to iPhone s iOS nebo třeba Nokia Lumia 1020 s Windows Phone...

Efektivita programování = efektivita údržby a rozvoje, nikoliv jen nároky na zdroje. To první je důležitější.

Má zkušenost je ta, že se program nějak zpytlíkuje a spustí. Když běží příliš špatně nebo pomalu, tak se upraví tak, aby běžel lépe a rychleji. Fóra jsou plná dotazů typu "slow java.array.sort". Takhle se iteruje do doby, než to běží alespoň trochu přijatelně, pak se to označí za hotové. Fungovalo to tak vždycky.

Z principu je pak logické, že starší programy fungovaly s menšími nároky - ten HW byl slabší, proto se holt iterovalo a zlepšovalo více. Takže podle mého názoru se přístup za posledních 24 let nezměnil.

Jinak co se to týká prohřešků knihoven, tak těch mnoho není. Častěji je to o tom, že si lidé neumí představit nároky na výkon. Kopírují pole, řadí dlouhé seznamy, vyhledávají v seznamech fulltextově, nejlépe s použitím konverze textu. Musím ale přiznat, že do své implementace LZW jsem vyhledávací strom také implementoval až poté, co mě přestalo na komprimaci 50KB souboru čekat dvě minuty.

To není jediná příčina krátké výdrže. Druhá je nenažranost 3G a toho, že ho u nás mají operátoři špatně implementované (neustále se hledá síť a je hrozně slabé). Po jeho vypnutí se výdž klidně prodlouží o polovinu až na dvojnásobek.

Není to jen jedna věc:
1. Existují knihovny na kde co. Je snadné je použít bez toho, aby se zkoumala výpočetní náročnost dané metody nebo funkce. Ta se obvykle v dokumentaci neuvádí a není zavedená norma pro její vyjádření.
2. Objektové programování při nevhodném použití vede často až k nesmyslnému řetězu odvozování tříd a dereferencí.
3. Nedostatečná podpora prostředí pro runtime analýzu běhu programu.
4. Někteří programátoři aplikací neumí psát optimální kód, protože se to ani ve škole neučili. Nebo jen kvůli rychlosti kódování nechtěji použít složitější algoritmus.

[3] mno to heslo ale nerazi programatori, ale manazeri. proste si spocitali, ze nakoupit HW je levnejsi, nez platit programatorum za lepsi praci / optimalizaci. Protoze velke firmy maji armady matlalu/klikalu ...

a ani se nedivim. pokud zakaznikovi reknes, ze jsou dve reseni. a) zaplati 100h prace b) koupi za 40k dalsi stroj/silnejsi procaky/vic pameti je volba jasna ...

[35] No ale ekonomicky je to takto lepší, protože to vyjde levněji. Bohužel limita dokonalého programu je nekonečno.

[34] Složitější algoritmy mají být implementovány frameworky, které dělají specialisti na frameworky a nebo na nižší úrovni VM. Představte si, kdyby si každý ve své aplikaci implementoval pole, třídění, databázi, jak to bylo běžné ještě v 80. letech.

[37] To je v pořádku, ale uživatelé frameworku často nemají přestavu, jak je která volaná metoda nebo funkce náročná na zpracování. Zažil jsem, že klidně zavolají 1000x v cyklu metodu obsahující vzdálené volání a pak se diví, že je to pomalé.

[33] Přesně tohle jsem taky dlouho říkal a 3G zapínal, jen když jsem ho reálně potřeboval. Teď mám to 3G zapnuté trvale a na baterce to v podstatě nepoznám. To jsou spíše extrémní případy, kdy v konkrétní lokalitě obojí pokrytí stojí za prd a telefon furt přeskakuje ze sítě do sítě.

Možná by pomohlo to, co kdysi udělala Mozilla: začala vyhledávat rozšíření, co žerou systémové prostředky a vytvořila "černou listinu", zatlačila na autory...

[38] Ale vinu za to nese autor frameworku, že na to neupozornil, že to nehlídá, že to neoptimalizuje nějakou cachí, nebo bufferem, či právě nějakým složitějším algoritmem. Od toho by právě ten framework měl být, že se právě o to stará.

No nevím jak spolehlivý je ten logger spotřeby energie v Androidu, ale v něm aplikace prakticky nefugurují. Nejvíc mi žere vždy displej, součástí systému a WiFi, 3G a podobné srandy. aplikace hrají naprosto mizivou roli. Jen Google+ a hry si dovolí sežrat víc jak 3%.

Tak ono toto, alebo skor tento pristup sa deje v SW premysle odkedy sa z neho stal obrovsky business a zacali sa do toho liat velke peniaze a zvlast od masivneho nastupu internetovych "aplikacii a sluzieb". Totiz PR lahsie preda novu verziu Office kde sa vypichne par novych funkcii ako predat klientovy novy framework alebo nejaku sluzbu co bezi na pozadi. Jednak ten klient musi byt dostatocne technicky zdatny aby to posudil a ocenil a potom, vzhladom na medzirocny narast vykonu hw, mierne zlepsenia uz nikoho nezaujimaju. Takze marketing,PR, financaci proste tlacia na zrychlenie vyvoju, znizenie vyvojoveho cyklu a viac iteracii a co z toho vyplyva ? na programovanie v nejakom low level jazyku alebo hranie sa s optimalizaciou proste neni cas (pokial to nie je priamo zdrojom zisku), takze sa lepi v roznych skriptovacich jazykoch, pouzije sa kopec nezmyselnych a prerastenych kniznic a frameworkov len aby bol produk na cas hotovy. Ostatne ako tu aj bolo spomenute, z Androidu to smrdi na sto honov ze islo o cas aby IOS uz moc neprerastol a Apple neziskal totalny monopol.

Me se telefon rozbil, uvazuji ktery novy koupit a Android jsem vyradil. Z duvodu ze hodne lidi pise ze jim aplikace tuhnou nebo padaji. Ted kdyz ctu jeste tohle, jen me to vic utvrzuje Android nekupovat.

Clock: to že jsou nějaké aplikace nekvalitní neznamená, že je nekvalitní celý Android. Já třeba padající aplikace nepoužívám, ale proti gustu... Androida můžu obecně doporučit, ale asi ne na mobilu za 1200 Kč - nejlépe dvoujádro a minimum 500 MB RAM.

@44: Clocku když si koupíš telefon za 8-10-12 tisíc tak ti nic padat nebude. A nebo iPhone za 14-16.
Porovnávat OS Android na telefonu za 2 tis a za 10tis nelze. U obou je OS stejný, ale HW za 2 tisíce opravdu nebude tak plynulý jako 4jádro s 1GB RAM za 8-10 tisíc.

Ale věř těm co tvrdí, že to padá, není plynulé když ti nenapíší jaký mají HW střep.

Já mám HTC Evo 3D a nic mi nepadá, vše je plynulé a neměnil bych.

V článku se mluví o knihovnách. Ale ty programy dělají vývojáři. Ty knihovny se dají použít dobře a špatně. Nebo jde použít jiné. Špatně jdou použít obvykle s menším úsilím a proto se to tak dělá. A vesměs málo aplikací je optimalizováno na minimální spotřebu. Ono to chce totiž hodně času hrát si s detaily, a místo prostého pollování čekat na správnou událost. Jenže tohle mohou hodnotit jednoduše uživatelé. Kdyby aplikaci nepoužívali, byl by to jasný příklad pro vývojáře, že mají něco špatně. Ovšem uživatelé to velmi často jsou ochotní tolerovat za pár vychytávek navíc. Tohle nemá s platformou nic společného. Android je v tom naprosto nevině. Udělat aplikaci, aby nějak fungovala bez efektivního přístupu je prostě rychlejší a levnější. Dost často to není velký problém. Dokud to tak zůstane, takové aplikace budou. Bez ohledu na platformu, knihovnu, nebo programovací jazyk. Jestli kvůli tomuto zavrhujete Android, přeju hodně štěstí. Budete ho potřebovat. :-)