Podpis aplikace je jediná věc, podle které telefon pozná, že aktualizace přišla od téhož vývojáře jako původní instalace. Kdo ten podpis dokáže zfalšovat, dostane do cizího telefonu vlastní kód pod jménem známé aplikace. Proti tomu míří schéma podpisu APK v3.2, které přišlo s Androidem 17: balíček podepsaný podle něj nese dva podpisy místo jednoho.

Jeden klíč klasický, druhý mřížkový

V bloku v3.2 musí být přesně dva podepisující. Jeden použije klasický algoritmus, tedy RSA nebo ECDSA jako dosud, druhý postkvantový ML-DSA. Když jsou oba klasické nebo oba postkvantové, ověření selže. Stejně dopadne balíček, ve kterém se ti dva rozcházejí v rozsahu verzí systému, na které míří. Blok má v podpisové části APK vlastní identifikátor 0x70e1c89f, aby se poznalo, že jde o hybrid.

ML-DSA je zkratka pro podpisový algoritmus postavený na mřížkách, který americký normalizační úřad NIST vydal 13. srpna 2024 jako FIPS 204. Android z něj bere dvě varianty, ML-DSA-65 a ML-DSA-87.

Proč dva klíče, a ne rovnou jeden

Dokumentace Androidu to popisuje jako obranu do hloubky. Dokud nemá nový algoritmus odslouženo v provozu, drží se vedle něj ten prověřený: klasický podpis kryje případnou chybu v čerstvé implementaci mřížkové matematiky, postkvantový míří na stroj, který jednou klasický klíč spočítá. Až se ML-DSA ve velkém osvědčí, má být podle dokumentace možné přejít na jediný postkvantový klíč.

Sbírání zašifrovaných dat na později, kterým se odůvodňuje spěch u šifrování, tu roli nehraje. Padělaný podpis musí útočník vyrobit ve chvíli, kdy se aplikace instaluje, ne o deset let dřív. Dlouhou životnost má něco jiného, totiž řetěz důvěry uvnitř telefonu, a právě na něj se Google v oznámení odvolává, když mluví o odolnosti platformy na desítky let dopředu.

Starší Androidy ten blok přeskočí

Telefon s Androidem 16 a nižším o schématu v3.2 neví a ověří balíček podle staršího podpisu. APK proto musí dál nést i blok v3.0 nebo v3.1 podepsaný jediným klasickým klíčem; dokumentace mu říká K0 a označuje ho za záchrannou síť. U existující aplikace je to její dosavadní podpisový klíč, u nové se K0 vygeneruje vedle nového hybridního páru.

Aby se toho nedalo zneužít, zapisuje podpisový nástroj do staršího bloku dva atributy s hranicemi verzí systému, 0xbf940529 a 0x9f06b79c. Když se telefon do tohoto rozmezí trefí a hybridní blok v balíčku nenajde, instalaci odmítne. Bez toho by útočníkovi stačilo blok v3.2 z APK vystřihnout a systém by se spokojil s klasickým podpisem.

Klíče vyrobí Google Play

Vývojář, který používá Play App Signing, se o nic starat nemusí. Google Play během vydání Androidu 17 vygeneruje podpisové klíče ML-DSA novým aplikacím a těm existujícím, které se přihlásí, a to bez ohledu na to, na jakou úroveň API aplikace míří. Klíče drží v Cloud KMS. Později má jít dodat vlastní klasický i postkvantový klíč a nechat Play jen samotné hybridní povýšení. Google k tomu začne vývojáře vyzývat, aby si podpisové klíče obměňovali nejméně jednou za dva roky.

Podpisy aplikací jsou jen jedna z vrstev

Na ML-DSA přechází v Androidu 17 také ověřený start systému, tedy Android Verified Boot, a začal i převod vzdáleného dokládání stavu zařízení, kde se mění certifikační řetězy KeyMintu. Úložiště klíčů Android Keystore umí na podporovaných zařízeních vygenerovat ML-DSA-65 i ML-DSA-87 přímo v zabezpečeném hardwaru přes běžné rozhraní KeyPairGenerator, takže aplikace, která potřebuje kvantově odolný podpis, si k němu nemusí přibalovat vlastní kryptografii.

Mřížkové klíče jsou přitom výrazně větší než klíče eliptických křivek a v zabezpečeném prostředí telefonu je paměti málo. Google sám tuhle část označuje za velký kus inženýrské práce.

Termín zatím nikde nestojí

Majitel telefonu z toho neuvidí nic. Aplikace se instalují a aktualizují stejně jako dřív, jen ověření navíc projde druhým podpisem. Výrobci a ti, kdo si Android upravují, si implementaci můžou proklepat testem HybridSignatureVerificationTest.java ze sady CTS.

Co v žádném z obou oznámení není, je datum. Android 17 hybridní podpis ověřit umí, Google Play ho umí vyrobit, ale den, od kterého by aplikace bez postkvantového podpisu do Obchodu Play neprošla, nikde uvedený není.

Zdroje: popis schématu podpisu APK v3.2 v dokumentaci AOSP, zápis Security for the Quantum Era na blogu Google Security z 25. března 2026, oznámení Androidu 17 z června 2026 a shrnutí na Privacy Guides.

Apple v úterý 18. srpna 2026 zveřejnil novou verzi licenční smlouvy vývojářského programu a s ní i nové obchodní podmínky pro aplikace šířené v Evropské unii. Účinnosti nabývají 1. října 2026 a nejnápadnější změnou je zánik poplatku za instalaci: Core Technology Fee, tedy padesát centů za každou první roční instalaci nad milion, nahradí Core Technology Commission ve výši pěti procent z prodejů digitálního zboží v aplikacích šířených mimo App Store.

Rozdíl mezi tím dvojím je zásadní. Poplatek se platil za staženou aplikaci bez ohledu na to, jestli na ní kdo něco vydělal – kdo rozdával aplikaci zdarma a dostal se přes milion instalací, platil dál. Provize se počítá z tržby, takže aplikace bez prodejů neplatí nic.

Kolik si Apple bere po 1. říjnu

Podmínky se sjednocují: dosud si vývojář vybíral mezi původní smlouvou a dodatkem s alternativními podmínkami, nově platí pro všechny jedny. Sazby v App Storu vypadají takto:

• 26 % z prodeje přes Apple In-App Purchase, tedy platební systém Applu. Účastníci programů pro malé firmy, mini aplikace a videoslužby a předplatné po prvním roce platí 15 %.
• 20 % z prodeje přes cizí platební bránu uvnitř aplikace, u zvýhodněných programů 10 %.
• 15 % za odkaz ven, který uživatele pošle koupit obsah na web nebo do jiné aplikace; u zvýhodněných programů 10 %. Provize se týká jen prodejů uskutečněných do sedmi dnů od klepnutí na odkaz.
• 5 % z prodejů v aplikacích šířených přes cizí obchody nebo přímo z webu vývojáře – to je ta Core Technology Commission.

Z nákupů v aplikaci si Apple historicky bral 30, nebo 15 procent, připomíná CNBC. Evropská sazba 26 % je tedy nižší než světová, k ní se ale u aplikace, která posílá zákazníky na web, přičítá ještě provize za odkaz ven.

Jedna podmínka je nová a vývojáře váže: výběr platebních možností – Apple In-App Purchase, cizí brána v aplikaci, odkaz na web, nebo kombinace – musí vydržet dvanáct měsíců. Přeskakovat mezi modely podle toho, co zrovna vychází líp, tedy nepůjde.

Obchod s aplikacemi smí zkusit víc firem

Druhá změna se týká alternativních obchodů. Dosud musel jejich provozovatel doložit buď finanční zázemí, nebo dva roky ve vývojářském programu a aplikaci s milionem prvních ročních instalací v Unii za předchozí kalendářní rok, píše TechCrunch. Od října stačí splnit jednu položku ze seznamu, na kterém je mimo jiné hodnocení finanční stability od Dun & Bradstreet, veřejná obchodovatelnost akcií, investice od zavedeného investičního fondu, provedený audit, postavení státní instituce, školy nebo neziskovky, akreditiv na milion dolarů nebo milion prvních ročních instalací celosvětově.

Zároveň padá požadavek mít v Unii právnickou osobu. Malým provozovatelům Apple provizi odpouští: kdo za posledních dvanáct měsíců vydělal celosvětově méně než deset milionů eur a z ceny svého obchodu a předplatného k němu za celou dobu méně než milion eur, provizi z těchto částek neplatí.

Platba mimo App Store u dětí projde přes rodiče

Za povolení cizích plateb v App Storu si Apple vymínil pravidla pro nezletilé, na kterých se podle svého sdělení domluvil s Evropskou komisí. Aplikace v kategorii Kids musí nákup přes cizí bránu schovat za rodičovskou bránu a odkaz na nákup na webu nesmí nabídnout vůbec. U uživatelů mladších třinácti let platí totéž, u třináctiletých až sedmnáctiletých musí být za rodičovskou branou obojí – platba v aplikaci i odkaz ven. Tam, kde je v dané zemi hranice rodičovského souhlasu vyšší než třináct let, posouvá se s ní i tohle pravidlo.

Spor tím podle Applu končí

Nové podmínky jsou zatím poslední kolo sporu, který se táhne od zavedení nařízení o digitálních trzích. V dubnu 2025 dostal Apple od Evropské komise pokutu 500 milionů eur za to, že vývojářům bránil informovat zákazníky o levnějším nákupu mimo App Store; podmínky, které pak nabídl, kritici označili za formální poslušnost bez ochoty cokoli změnit. Letos v červenci Apple neuspěl u Tribunálu Evropské unie se žalobami proti tomu, že ho Komise označila za strážce brány.

Že je spor vyřešený, zatím říká Apple: ve svém oznámení mluví o úzké spolupráci s Evropskou komisí a podle CNBC uvedl, že návrh neshody s regulátorem odstraňuje. Vlastní vyjádření Komise v oznámení Applu ani v obou zprávách o změně nezaznělo. Podobným tlakem prochází i druhá strana trhu – Komise letos nařídila Googlu otevřít jedenáct funkcí Androidu cizím hlasovým asistentům.

Pro majitele iPhonu se 1. října nic neláme. Aplikace se dál instalují z App Storu, cizí obchody zůstávají menšinovou cestou a jestli se sazby promítnou do cen předplatného, ukáže se až po nějaké době. Zajímavější je, co se mění menším vývojářům: poplatek, který rostl se stahováním bez ohledu na tržby, mizí a s ním i důvod bát se vlastní popularity.

Zdroje: Apple Developer, Changes for apps in the European Union, Apple Developer News, TechCrunch, CNBC.

Apple 12. srpna 2026 oznámil vývojářům dvě změny ve věkovém hodnocení aplikací pro korejský App Store. První platí od téhož dne a je z nich větší: kdo má na svou hru nebo zábavní aplikaci oficiální rating od korejské komise GRAC, může jím přepsat hodnocení, které obchod sám spočítal z dotazníku. Stačí při odeslání další verze aplikace uvést číslo, pod kterým komise rozhodla.

V Koreji rozhoduje o hrách zákon, ne obchod

Věkovku v App Storu jinde na světě určuje dotazník, který vývojář vyplní v App Store Connect. Apple z odpovědí odvodí hodnocení a to se pak ukazuje na stránce aplikace. Korea to má postavené obráceně. Podle zákona o podpoře herního průmyslu musí hra před výrobou i před distribucí projít hodnocením a rozhodují o něm tři subjekty: komise GRAC se sídlem v Pusanu, agentura GCRB a takzvané IRCB, tedy obchody, které si směly hodnocení převzít samy.

Právě mezi ta IRCB patří App Store. GRAC je v tabulce jmenuje tři: Google Play, App Store a OneStore. O kus dál na téže stránce ale píše Google, Apple a Samsung, takže si výčtem protiřečí; App Store je v obou. Rozchází se i v tom, kdo oprávnění uděluje: v definici ministerstvo kultury, sportu a cestovního ruchu, a to nejvýš na tři roky, o odstavec níž sama komise. Neomezené oprávnění to v žádném případě není. Obchod si smí sám přidělit stupně Všichni, 12 a 15; kategorii 19, tedy nepřístupné mládeži, IRCB udělit nesmí a musí o ní rozhodnout komise.

Odtud plyne celý dnešní problém. Vývojář si u komise vyřídí rating, obchod mezitím z dotazníku spočítá jiný, a čtenář v korejském App Storu vidí číslo, které se s úředním rozhodnutím rozchází.

Číslo RCN se zadává u záznamu aplikace

Nové řešení je administrativní. V App Store Connect přibylo u položky Korejská republika tlačítko Add RCN; vývojář do něj zapíše číslo rozhodnutí (Rating Classification Number), vybere stupeň, který od komise dostal, a zaškrtnutím potvrdí, že jde o oficiální rating GRAC pro tuhle aplikaci. Vybírat jde ze čtyř korejských hodnot: Všichni, 12+, 15+ a 19+. Tím se dostane do korejského obchodu i stupeň, který by si Apple sám přidělit nemohl.

Než se aplikace odešle ke schválení, dá se číslo i vybraný stupeň libovolně měnit nebo obojí naráz smazat. Během posuzování už je vývojář jen vidí a po schválení aplikace se zamknou úplně. Apple k tomu popisuje i opačný směr: když komise vydá rating jiný, než jaký má aplikace v obchodě, ozve se vývojáři App Review a vyzve ho, ať číslo doplní a pošle novou verzi.

Od října se dva popisy obsahu posunou výš

Druhá ohlášená změna přijde v říjnu 2026 a týká se jen Koreje. Dva popisy obsahu, které dnes ještě spadají pod stupeň Všichni, se posunou na 12+: ojedinělé vulgarity a hrubý humor, a ojedinělá témata pro dospělé nebo s narážkami. Aplikace, která nemá v dotazníku nic jiného než jeden z těchhle dvou popisů, tak v Koreji ze stupně pro všechny vypadne. Kolika aplikací se to týká, Apple neuvádí.

Korejská věkovka se ukazuje vedle globální

Zvláštní korejské hodnocení nevzniklo teď. Apple ho v dokumentaci k věkovým hodnotám popisuje pro iOS 18, macOS 15, tvOS 18, watchOS 11 a visionOS 2 a novější, a to jako druhý údaj vedle globálního: dostane ho každá aplikace, která má Hry nebo Zábavu jako hlavní nebo vedlejší kategorii, a k tomu každá s častým nebo intenzivním napodobováním hazardu. Korejské hodnoty v ní staví vedle svých globálních stupňů 4+, 9+ a 12+ a u posledního z nich upozorňuje, že GRAC může u některých aplikací vydat KR-15 nebo KR-19.

U hazardu je RCN rovnou podmínkou. Aplikace a hry s častým nebo intenzivním napodobováním hazardu jsou podle téže stránky v korejském App Storu dostupné jen tehdy, když vývojář číslo od komise dodá. Bez něj se do obchodu nedostanou.

Konkurenční obchody na to mají společný dotazník

GRAC nesedí mimo mezinárodní systémy. Sdružení ESRB oznámilo 19. prosince 2017, že korejská komise podepsala dohodu s koalicí IARC, ve které je vedle ní ESRB pro Severní Ameriku, evropské PEGI, brazilský ClassInd, německá USK a australská klasifikační rada. Princip je jeden dotazník, ze kterého vypadnou hodnocení pro všechny zapojené oblasti najednou.

Mezi obchody, které tehdy podle ESRB systém IARC používaly, jsou Google Play, Microsoft Store, Nintendo eShop a Oculus Store; App Store mezi nimi není. Apple si drží vlastní dotazník a vlastní stupnici a korejskou hodnotu z ní odvozuje sám. Číslo RCN je pak jediné místo, kde se do toho výpočtu dostane rozhodnutí státní komise.

Změna tedy nezavádí novou povinnost, opravuje nesoulad. Dokud vývojář neměl kam úřední rating zapsat, musel žít s tím, že obchod ukazuje něco jiného než komise, a řešilo se to případ od případu přes App Review. Kolik jich bylo, Apple neuvádí.

Google představil 12. srpna 2026 na akci Made by Google nové Pixely a hodinky Pixel Watch 5. Ve stejný den vyšel na vývojářském blogu Androidu popis změny, která na pultech vidět není: bezdotyková gesta na zápěstí přestávají patřit jen systému.

Dvě gesta, dvě role

Nové rozhraní se jmenuje Modifier.oneHandedGesture a připojí se k libovolnému ovládacímu prvku aplikace psané v Compose. Rozlišuje jen dvě akce. Primární má patřit tomu nejdůležitějšímu, co jde v dané chvíli udělat, tedy vyfotit, spustit nebo zastavit stopky, přijmout hovor; hodinky Pixel ji spouštějí dvojitým stisknutím palce a ukazováku. Druhá akce zavírá, na Pixelech ji vyvolá otočení zápěstí a ve výchozím stavu dělá totéž co systémové zpět. Aplikace si ji smí předefinovat, třeba na ztlumení vyzvánění.

Rozhraní je zatím v beta verzi knihovny, konkrétně v androidx.wear.compose:compose-material3:1.7.0-beta01. Do vydaných aplikací se tedy hned nedostane. Jako první příklad Google uvádí Spotify, které chce dvojitým stisknutím prstů pozastavovat a spouštět přehrávání. Samotná gesta fungují na Pixel Watch 3 a novějších a framework firma nabízí i ostatním výrobcům hodinek s Wear OS.

Osm měsíců o gestech rozhodoval jen systém

Gesta na Pixelu nová nejsou. Google je zapnul aktualizací z 9. prosince 2025 a tehdy o nich psal jako o novince Pixel Watch 4: dvojité stisknutí prstů posouvalo oznámení, odkládalo budík, ovládalo stopky a časovač, pozastavovalo hudbu, vybíralo chytrou odpověď a přijímalo i ukončovalo hovory. Před nimi měly hodinky jediné gesto, zvednutí ruky pro Gemini. Srpnová vývojářská dokumentace už mluví o Pixel Watch 3 a novějších, zatímco prosincové oznámení jmenovalo jen čtvrtou generaci.

Všechny ty úkony ale měly společné jedno: seznam sestavil Google. Co gesto udělá, rozhodoval systém a aplikace do toho neměla jak vstoupit.

Situace, na které Google celou věc staví, jsou banální a právě proto srozumitelné: člověk venčí psa, nese nákup nebo má rukavice. Druhá ruka není volná, obrazovka na dotek nereaguje, přesto je potřeba přijmout hovor nebo zastavit hudbu. K tomu firma přidává obrazovkové nápovědy, které se objeví ve chvíli, kdy dvojité stisknutí prstů zrovna něco udělá – bez nich by uživatel gesto zkoušel naslepo.

Apple otevřel totéž o dva roky dřív

Apple Watch mají dvojici gest, která si s tou od Googlu odpovídá skoro přesně. Dvojité ťuknutí je rovněž stisknutí ukazováku a palce dvakrát za sebou, otočení zápěstí zahazuje oznámení, časovače a hovory. Podle stránky podpory obě fungují na Apple Watch Series 9 a novějších, na Apple Watch SE 3 a na Apple Watch Ultra 2 a novějších.

Vývojářům je Apple otevřel ve watchOS 11. Přehled změn watchOS to datuje do června 2024 a popisuje modifikátor handGestureShortcut(_:isEnabled:) s parametrem primaryAction: aplikace jím určí, který prvek na dvojité ťuknutí zareaguje, a funguje to na tlačítkách i přepínačích. Apple v té poznámce popisuje jen gesto primární akce, druhé z dvojice v ní nefiguruje. Google se k témuž kroku dostal o dva roky později, zato rovnou s oběma gesty.

Na zápěstí se gesta vracejí podruhé

Ovládat hodinky s Androidem pohybem ruky se dalo dřív než v obou dnešních verzích. V době, kdy se platforma jmenovala Android Wear, uměla mávnutí zápěstím ven a dovnitř pro listování v oznámeních a zatřesení, které vracelo na ciferník. Server 9to5Google, který to připomněl při prosincovém návratu gest, píše, že tehdejší mávnutí fungovalo i nad ciferníkem, takže se jím dal otevřít celý seznam oznámení; dnešní verze to neumí. Google podle téhož zdroje gesta odstranil ve Wear OS 3 a na vině byla nejspíš nespolehlivost a spotřeba.

Wear OS 7 mimochodem slibuje až o desetinu delší výdrž proti Wear OS 6. Je to číslo Googlu z téhož blogu, nezávislé měření k němu zatím není.

Jak moc se bezdotykové ovládání rozšíří, se pozná teprve podle toho, kolik vývojářů si rozhraní vezme. Dokud je v betě, aplikace v Obchodu Play na dvojité stisknutí prstů reagovat nebudou.

Zdroje

• Bring one-handed gestures to your Wear OS app, Android Developers Blog, 12. srpna 2026
• Enhance your app for the new Pixel lineup, Android Developers Blog, 12. srpna 2026
• New AI-powered gestures and Smart Reply updates for Pixel Watch, blog.google, 9. prosince 2025
• watchOS updates, Apple Developer Documentation
• Use buttons and gestures on your Apple Watch, podpora Applu
• Pixel Watch 4's new gestures are handy, but did Google do it better a decade ago?, 9to5Google, 14. prosince 2025

Na blogu pro vývojáře Androidu vyšel 20. července 2026 krátký zápis, kterému by se dala lehce minout pointa. Google v něm mění výchozí chování rozhraní Nearby Connections: to už si samo nezapne Wi-Fi ani Bluetooth. Změna platí od konce roku 2026 a týká se stejně aplikací od Googlu jako aplikací od kohokoli jiného.

Co se mění

Dosud mohlo rozhraní Nearby Connections přepnout Wi-Fi a Bluetooth do zapnutého stavu samo, bez toho, aby uživatel cokoli potvrdil. Aplikace zavolala rozhraní, to si zjistilo, že rádio je vypnuté, a zapnulo ho. Napříště to neudělá.

Google k tomu píše, co po vývojářích chce: aplikace se má napřed přesvědčit, že potřebné rádio je zapnuté, a když není, má na to uživatele upozornit a nechat zapnutí na něm. Termín je „koncem roku 2026“ a s ním doporučení projít si své postupy spojování už teď. Přesnější datum v oznámení není.

K čemu to rozhraní je

Nearby Connections je součást služeb Google Play a slouží k tomu, aby si dvě zařízení v dosahu vyměnila data napřímo, bez internetu a bez serveru uprostřed. Spojení je podle dokumentace šifrované a pod kapotou používá kombinaci Bluetoothu, Bluetooth Low Energy a Wi-Fi podle toho, co se zrovna hodí; dosah dokumentace uvádí zhruba 100 metrů.

Příklady použití, které Google sám jmenuje, jsou vesměs věci, u kterých čekat na síť nedává smysl: sdílená tabule pro lidi v jedné místnosti, hra pro víc hráčů na jednom místě, telefon jako ovladač ke hře běžící na televizoru s Androidem a přenos fotek nebo videa mezi dvěma přístroji bez připojení.

Vývojář si k tomu vybírá jednu ze tří topologií. Cluster spojí M zařízení s N zařízeními do beztvaré skupiny, hodí se na hry a platí se za něj nižší přenosovou rychlostí. Star má jeden střed a N paprsků a je rychlejší. Point-to-point spojí právě dvě zařízení a dá nejvyšší možnou průchodnost, ale víc než jedno spojení naráz neumí.

Android zavíral rádia po částech řadu let

Samotné oznámení je na tři odstavce, ale zapadá do řady, která začala mnohem dřív. Obyčejná aplikace už rádia zapínat dávno nesmí:

• Metoda WifiManager.setWifiEnabled() je zavržená od úrovně API 29, tedy od Androidu 10. Dokumentace k ní říká rovnou, že aplikacím cílícím na tuhle a vyšší verzi vždycky selže a vrátí false.
• Metody BluetoothAdapter.enable() a disable() jsou zavržené od úrovně API 33, tedy od Androidu 13, a chovají se stejně. Výjimku mají jen správce zařízení, správce profilu a systémové aplikace.

Stopu po tom postupném utahování je vidět i v návodu k Nearby Connections. Oprávnění, která si aplikace zapisuje do manifestu, mají u sebe horní hranici verze systému: CHANGE_WIFI_STATE platí nejvýš do API 31, BLUETOOTH a BLUETOOTH_ADMIN do API 30, přístup k přibližné poloze do API 28. Každé číslo je jedno vydání Androidu, ve kterém se něco zavřelo a nahradilo něčím užším.

Nearby Connections v té řadě zůstávalo výjimkou. Běží ve službách Google Play, tedy ne jako běžná aplikace, a mohlo dělat to, co volání ze samotné aplikace už roky nedokáže.

Co s tím vývojář udělá

U Bluetoothu je řešení připravené: ACTION_REQUEST_ENABLE otevře systémovou obrazovku, na které si zapnutí odsouhlasí uživatel sám. Aplikace se tedy zeptá, jestli je rádio zapnuté, a když není, vyvolá tuhle výzvu. U Wi-Fi zbývá uživatele upozornit a poslat ho do nastavení.

Pro toho, kdo telefon jen používá, to znamená jednu obrazovku navíc před sdílením souboru nebo před hrou pro dva. Podle nás je to výměna, která stojí za to: aplikace, která umí sáhnout na rádio bez ptaní, umí i vysílat a poslouchat v okamžiku, kdy o tom nikdo neví.

Zdroje: oznámení na blogu pro vývojáře Androidu, dokumentace Nearby Connections a její oddíly o strategiích a oprávněních, referenční příručky WifiManager a BluetoothAdapter.

Apple 5. srpna vyzval vývojáře, ať si připraví nový druh obrázků na stránky svých aplikací, a vydal k nim doporučené postupy spolu se šablonami pro Figmu, Photoshop a Pixelmator. Je to poslední krok před podzimním spuštěním. Sám obchod se změní až v iOS 27 a iPadOS 27.

Obrázek nemusí být z aplikace

Apple pro tu novinku používá název Creative Assets. Vedle snímků obrazovky a videoukázek jde o třetí druh grafiky na stránce aplikace a liší se tím, k čemu slouží. Snímky obrazovky ukazují aplikaci za chodu, marketingový obrázek smí ukázat značku, sezónní nabídku nebo nový obsah. V příručce k tomu stojí, že smí zobrazovat i věci mimo aplikaci, pokud souvisejí s tím, k čemu aplikace je.

Uživatele se to týká na dvou místech. První je hlavička produktové stránky, tedy to, co člověk uvidí hned po jejím otevření. Druhé jsou výsledky vyhledávání: vývojář si nově vybere, který obrázek se u aplikace zobrazí, místo aby obchod sáhl po prvním snímku obrazovky. Stejná grafika se dá použít i v In-App Events a v placené inzerci Apple Ads.

Hlavičku dřív dostal jen ten, koho si Apple vybral

Sama hlavička není úplná novinka. Agentura Phiture, která se zabývá propagací aplikací v obchodech, ve shrnutí z 9. června píše, že Apple jen přejmenoval dosavadní Feature Banner na Header. Rozdíl je v tom, kdo se k němu dostane: dosud šlo o výsadu vybraných vývojářů a měnil se e-mailem redakci App Storu, teď se nahrává a schvaluje přímo v App Store Connect.

S tím souvisí druhá změna, kterou Apple popsal v oznámení z 8. června. Obrázky se posílají ke schválení nezávisle na aktualizaci aplikace, takže se stránka dá překreslit bez nové verze programu. Všechny podklady k jedné aplikaci drží pohromadě knihovna zvaná Asset Library a součástí je i náhled, který ukáže, jak stránka vypadá na iPhonu a iPadu, v jednotlivých jazycích, v tmavém režimu a na výšku i na šířku.

Co se na obrázky nesmí

Pravidla jsou v příručce vypsaná dost podrobně. Grafika musí splňovat věkové hodnocení 4+, i když je samotná aplikace určená starším. Nesmí na ní být konkrétní ceny a slevy, webové adresy ani symboly autorských práv, protože podle Applu má obsah zůstat srozumitelný po celém světě a nezastarat. Neověřitelná tvrzení, tedy třeba ocenění, které aplikace nikdy nedostala, jsou zakázaná také.

Dva zákazy jsou zajímavější než ostatní. Vývojář nesmí na obrázek dát loga jiných platforem ani konkurenčních obchodů s aplikacemi. A nesmí si tam připsat ani vyznamenání od Applu samotného, tedy Editor's Choice, App of the Day, Game of the Day nebo Apple Design Award, protože ta se u aplikace zobrazují sama. U her platí navíc, že akční obrázky ano, ale bez krve a bez zbraně namířené na postavu nebo na diváka.

Videa se posuzují podobně, jen k tomu přibývá zvuk. Přehrávají se totiž automaticky a dokola, takže Apple radí, aby smyčka nikde nesekala a aby obrázek fungoval i beze zvuku. Zvuk je ve výchozím stavu ztlumený.

Na snímky obrazovky se pravidlo nemění

Kdo čeká, že aplikace budou mít stránku bez jediného skutečného obrázku z programu, ten se splete. Bod 2.3.3 pravidel pro schvalování aplikací pořád říká, že snímky obrazovky mají ukazovat aplikaci v provozu, ne jen úvodní grafiku, přihlašovací obrazovku nebo úvodní logo. Překlad je náš, pravidlo je v angličtině. Marketingová grafika ten požadavek neruší, přidává se vedle něj.

Za pozornost stojí i to, co Apple nikde neslibuje: že se změny obrázků budou schvalovat rychleji. Schvalování zůstává, jen se odděluje od vydání nové verze aplikace.

Kdy to uvidí uživatelé

Creative Assets se objeví v iOS 27 a iPadOS 27 a novějších. Vývojářské bety obou systémů běží od června, veřejné vydání Apple plánuje na podzim; přesné datum firma neuvedla. Do té doby se stránky aplikací v App Storu nemění.

Do stejného balíku změn v App Store Connect patří i nové časové příděly pro děti v iOS 27, kvůli kterým Apple v červenci rozšířil dotazník k věkovému hodnocení aplikací.

Zdroje: doporučené postupy pro podklady v App Storu a novinky pro vývojáře z 5. srpna, oznámení Applu z 8. června, pravidla pro schvalování aplikací a rozbor agentury Phiture.

Zápis přidala aktualizace z 3. srpna. Poznámky k vydání verze 5.05 ji popisují slovy „sdílejte svá data, třeba záznamy cvičení, spánek, životní funkce, kroky a další, z Google Health do Apple Health“. Co přesně se ven dostane, určí uživatel při udělování oprávnění – iOS se ptá na každý druh dat zvlášť. Jakmile je zápis povolený, vidí záznamy z Fitbitu i další aplikace napojené na HealthKit, tedy na systémové úložiště zdravotních dat v iPhonu, popsal změnu server GSMArena.

Číst umí od května, zapisovat od srpna

Aplikace Google Health vyšla letos v květnu spolu s levnějšími náramky Fitbit Air a postupně přebírá roli aplikace Fitbit. Na iPhonu od začátku uměla data z Apple Health číst: podle nápovědy si bere kroky, cvičení včetně tras, spánek a jeho fáze, tep a jeho variabilitu, okysličení krve, dechovou frekvenci, glykémii, hmotnost, výživu i záznamy menstruačního cyklu. Zdrojem můžou být hodinky Apple Watch, sám iPhone i další aplikace a zařízení napojené na HealthKit; načtená data se ukládají k účtu Google a aplikace z nich počítá své souhrnné metriky. Zobrazí z nich ale jen poslední tři měsíce; delší historii Google slibuje na později. Podmínkou propojení je iOS 16.4 nebo novější a dospělý účet Google.

Verze 5.05 kromě zápisu přidala i Smart Health Links – odkazy, přes které jde poslat zdravotní záznamy lékaři nebo rodině. Aktualizace už je v App Storu pod jménem Google Health (Fitbit).

Nápověda říká něco jiného než aplikace

Stránka nápovědy Googlu k propojení s Apple Health přitom v době psaní článku (5. srpna) stále uvádí, že aplikace data „zpátky do Apple Health nezapisuje ani neexportuje“ a že zápis „přibude později v tomto roce“. Poznámky k vydání v App Storu ho výslovně jmenují a web 9to5Mac ho u verze 5.05 popsal jako hotovou funkci. Stránka je přitom jinak podrobná: právě z ní pochází seznam čtených dat i limit tří měsíců historie. Dokumentace tedy za aplikací o několik dní zaostává – kdo se řídí jen nápovědou, o nové možnosti neví.

Dvanáct let přes prostředníky

Apple Health přišel v roce 2014 s iOS 8 jako centrální úložiště, do kterého aplikace zapisují a ze kterého čtou jen se souhlasem uživatele. Fitbit krátce nato oznámil, že podporu neplánuje. Kdo chtěl data z náramku dostat do zdravotního úložiště iPhonu, potřeboval synchronizační aplikaci třetí strany, nebo okliku přes jinou službu. Nezměnilo to ani převzetí Fitbitu Googlem – přímé spojení přinesla až letošní aplikace Google Health, nejdřív jedním směrem a od této aktualizace oběma.

Právě ta mezera dělala z dvojice iPhone a Fitbit nepohodlnou kombinaci. Trénink zaznamenaný náramkem neviděly aplikace, které nad HealthKitem stavějí, a kdo střídal náramek s hodinkami Apple Watch, měl historii měření roztrženou na dvě části. Obousměrná synchronizace obojí odstraňuje: záznamy z Fitbitu se v iPhonu chovají stejně jako data z hodinek Applu. Kdo má obě zařízení, měl by si po aktualizaci projít oprávnění – bez nich se žádná data nepřenesou.

Do širšího obrázku to zapadá: Google své zdravotní služby přeskládává a rozhraní Google Fit vypne na konci roku 2026. Google Health se má stát jedním místem, kde se zdravotní data scházejí – ať je naměřil náramek Fitbit, nebo hodinky Apple Watch.

Apple na červnové vývojářské konferenci ukázal, jak se v iOS 27 změní rodičovské limity. Místo jednotlivých aplikací se čas nastavuje po kategoriích: Zábava, Hry a Sociální sítě. Zajímavější než samotná funkce je ale to, jak se aplikace do té třetí kategorie dostane. Rozhoduje o tom odpověď vývojáře v dotazníku.

Co jsou časové příděly

Časové příděly (Time Allowances) oznámil Apple 8. června 2026 pro iOS 27, iPadOS 27 a macOS 27. Rodič v nich dítěti nastaví, kolik času smí strávit v celé skupině aplikací, ne v jedné konkrétní. Apple k posuvníku přidává doporučení opřená o výzkum dětského vývoje: podle Lifehackeru se u limitu ukazuje, jestli je pro daný věk „v mezích obecného doporučení“, a mezi podklady je i stanovisko Americké akademie pediatrů.

Do Zábavy a Her se aplikace zařadí sama. Rozhoduje primární nebo sekundární kategorie, kterou vývojář vyplnil v App Store Connect. Apple k tomu upozorňuje, že kategorie pro časové příděly nejsou totéž co kategorie, podle kterých čtenář aplikace v App Storu hledá.

U sociálních sítí rozhoduje prohlášení

Třetí kategorie funguje jinak. Zařazení v App Store Connect je u ní bez významu, rozhoduje odpověď na novou otázku ve věkovém dotazníku. Sociální funkci Apple popisuje jako možnost šířit dál, zesilovat nebo komentovat obsah od jiných uživatelů prostřednictvím sociálního proudu nebo podobného způsobu objevování, který obsah viditelně roznese k mnoha lidem. Definice je široká schválně: pod ni spadne i hra s veřejnou zdí příspěvků.

Kdo takové funkce přizná, dostane nejnižší možné věkové hodnocení 13+ a na stránce aplikace v App Storu nový popisek pro sociální sítě. Kdo je má, ale pro mladší třinácti let vypnuté, se pro tuhle skupinu do kategorie nedostane. Musí ale sáhnout aspoň po rozhraní Declared Age Range, kterým si věkové pásmo uživatele od systému vyžádá.

Od září je odpověď povinná

Otázky jsou v App Store Connect k dispozici od 9. července 2026 a odpovědět se dá dobrovolně hned. Od září 2026 bez nich neprojde odeslání nové aplikace ani aktualizace té stávající. Totéž platí pro notarizaci, tedy pro schválení aplikace, která se má rozdávat mimo App Store přes alternativní obchod.

Časování není náhodné. Obchody s aplikacemi se v posledním roce dostaly pod tlak zákonů, které po nich chtějí znát věk uživatele. Apple kvůli texaskému zákonu SB 2420 od 4. června 2026 podrobuje nové účty v Texasu ověření věku a u nezletilých do osmnácti let vyžaduje souhlas rodiče, který jde navíc kdykoli odvolat. Kategorie časových přídělů jsou proti tomu měkčí nástroj, stojí ale na téže věci: aby systém věděl, komu aplikaci půjčuje.

Kolik z toho je nové

Limity na jednotlivé aplikace i schvalování nákupů přes Ask to Buy má Obrazovka času roky. Lifehacker s odvoláním na server The Verge upozorňuje, že velká část toho, co Apple v červnu ukázal, jsou úpravy existujících funkcí, ne novinky. Opravdu nové je přepracované rozhraní Obrazovky času s přehledem denního průměru a nejpoužívanějších aplikací, funkce Ask to Browse, kterou dítě žádá o povolení nové stránky v Safari (u účtů do třinácti let je zapnutá ve výchozím nastavení), a rozšíření Komunikační bezpečnosti o rozpoznávání násilného obsahu ve fotkách a videích ve Zprávách.

Chybět naopak bude to, co by rodič čekal nejdřív: vlastní kategorie. Rozdělit sociální aplikace na dvě skupiny s jinými limity nejde, příděl platí pro celou kategorii najednou.

Slabé místo je vidět na první pohled. Zařazení do nejcitlivější kategorie stojí na tom, co o sobě vývojář prohlásí, a Apple při schvalování posuzuje především odpověď z dotazníku. Obchod s miliony položek se jinak než prohlášením roztřídit nedá, takže na hodnotě celého popisku bude znát, jak přísně se přiznání kontroluje v praxi.

Kdo si někdy zakládal účet v aplikaci a místo esemesky mu telefon na vteřinu zazvonil, narazil na ověření prozvoněním. Server zavolá na zadané číslo, aplikace si v telefonu přečte, odkud hovor přišel, porovná ho s očekávaným tvarem a hovor sama zavěsí. Uživatel nic neopisuje. Aby to fungovalo, musí ale aplikace vidět do výpisu hovorů – a to je v Androidu citlivé oprávnění READ_CALL_LOG.

Google v oznámení pravidel z 15. července 2026 napsal, že pravidla pro oprávnění k SMS a výpisu hovorů přestanou ověření účtu telefonátem jako povolené použití uznávat. Vývojáři mají přejít na Digital Credentials API – buď přímo, nebo přes poskytovatele ověřování, který na něm staví – anebo na SMS Retriever API.

Výjimka, která platila jen do doby, než bude čím ji nahradit

Přístup k výpisu hovorů má v Obchodu Play od začátku úzké mantinely. Standardně ho dostane aplikace, kterou si uživatel nastavil jako výchozí telefon nebo asistenta. Všechno ostatní jsou dočasné výjimky, a Google u nich má napsanou podmínku: platí jen tehdy, když ta funkce jinak udělat nejde.

Ověření účtu telefonátem je v tabulce výjimek uvedené doslova jako „zařízení se dá ověřit tak, že se na ně zavolá; přijetí hovoru se potvrdí ověřením čísla ve výpisu hovorů“ (přeloženo). Ruší se tedy nikoli proto, že by přestalo fungovat, ale proto, že podle Googlu odpadl důvod, na kterém výjimka stála.

Jak taková aplikace vypadá zevnitř, je vidět v dokumentaci poskytovatelů ověřování. Sinch popisuje u své knihovny pro Android čtyři metody a u prozvonění (flash call) uvádí, že k automatickému zpracování je READ_CALL_LOG potřeba. Bez něj knihovna kód nezachytí a musí uživatele požádat, aby číslo opsal ručně.

Dvě data, která si nesedí

Kdy to začne platit, není z Googlu jednoznačné. Oznámení z 15. července říká, že na úpravu aplikací je nejméně třicet dní. Stránka samotného pravidla ale nese tutéž větu s poznámkou „effective January 27, 2027“, tedy s účinností od 27. ledna 2027. Vývojář, který si přečte jen oznámení, si termín odhadne o půl roku dřív, než jak stojí v pravidle.

Kdo se řídí kratší lhůtou, neriskuje nic; obráceně to neplatí. Datum účinnosti stojí na stránce toho konkrétního pravidla, ne v souhrnném oznámení.

Náhrada se ptá operátora, ne telefonu

Digital Credentials API řeší ověření čísla úplně jinak. Aplikace si vyžádá od telefonu token TS.43, což je doklad vydaný operátorem, a její server ten token vymění u operátora nebo u agregátora za ověřené číslo. Číslo tedy potvrzuje ten, kdo ho přidělil, ne výpis hovorů v telefonu. Google uvádí podporu od Androidu 10 a v podmínkách rovnou píše, že vývojář potřebuje účet u agregátora nebo operátora, obvykle jako placené cloudové rozhraní.

Druhá jmenovaná cesta, SMS Retriever API, se bez operátora i agregátora obejde. Server pošle esemesku s jednorázovým kódem a otiskem aplikace, služby Google Play podle toho otisku poznají, komu zpráva patří, a předají její text jenom té aplikaci. Google u něj výslovně uvádí, že si nežádá žádné oprávnění navíc. Proč vývojáři sahali po prozvonění, když esemeska existuje, Google v oznámení neřeší.

Co z toho pozná majitel telefonu

Prakticky jednu věc: přihlašování, které dnes v některých aplikacích chce vidět seznam hovorů, si o něj po změně říct nesmí. Google to oprávnění řadí mezi vysoce riziková a citlivá a mimo hlavní funkci aplikace ho nepovoluje.

Kolika aplikací se změna týká, Google neuvádí – výjimky se udělují jednotlivě přes formulář v Play Console a jejich počet zveřejněný není.

Zdroje

• Policy announcement: July 15, 2026, Play Console Help
• Use of SMS or Call Log permission groups, Play Console Help
• The verification process, dokumentace Sinch Verification API
• Verify phone numbers with digital credentials, Android Developers
• Automatic SMS Verification with the SMS Retriever API, Google Identity

Telefon s Androidem počítá kroky sám a aplikace si je od něj berou. Dvanáct let k tomu slouží rozhraní Google Fit. Teď má spočítané dny: v příručce pro vývojáře Google píše, že Fit bude podporovat do konce roku 2026.

O konci se ví dopředu, blíží se datum

Není to čerstvé oznámení, jen se přiblížila lhůta. Na vývojářských stránkách Google uvádí, že rozhraní Google Fit včetně REST API bude v roce 2026 zrušeno a že od 1. května 2024 se k němu nikdo nový nepřihlásí. Příručka k přechodu, naposledy upravená 18. května 2026, to shrnuje jednou větou nahoře na stránce: podpora vydrží do konce roku.

Jedna odpověď v návodu je nezvykle strohá. Na dotaz, co bude s REST API po skončení, tam stojí, že alternativa neexistuje. Aplikace, které si data z Fitu tahaly ze serveru na server, tedy nemají kam přejít jedna k jedné.

Náhrady jsou tři a každá je pro něco jiného

Tabulka v příručce rozděluje cesty podle toho, co aplikace dělá. Kdo počítá kroky na telefonu, má jít na Health Connect. Kdo je doprovodnou aplikací k nositelnému přístroji a potřebuje serverovou stranu, má jít na Google Health API. Kdo používal Fit na hodinkách s Wear OS, přechází na Health Services. Pro ekosystém Fitbitu zůstává Fitbit Web API, které je podle Googlu vázané na účet, ne na přístroj.

Rozdíl je hlavně v tom, kde data leží

Fit stál na cloudu. Aplikace se musela zaregistrovat v konzoli Google Cloud, uživatel jí musel dát souhlas přes OAuth 2.0 a naměřené hodnoty putovaly na servery Googlu.

Health Connect je postavený obráceně. Google ho ve srovnávací tabulce popisuje jako zaměřený na přístroj: data leží v telefonu, oprávnění se udělují jako běžná systémová oprávnění a přihlášení k účtu Google k tomu potřeba není. Na Androidu 14 a novějším je Health Connect součástí systému, najde se v Nastavení pod položkou Zabezpečení a soukromí a odinstalovat nejde. Na Androidu 13 a starším je to aplikace z Obchodu Play; nejnižší podporovaná verze je Android 9 se službami Google Play. V pracovním profilu Health Connect nefunguje, i když si v něm uživatel oprávnění nastaví.

Vývojářům Google slibuje ještě dvě věci: měření kroků přes Health Connect nechce účet Google ani schvalování rozsahů oprávnění a je podle něj šetrnější k baterii.

Uživatelům Google slíbil pozvánku

Vývojáři vědí, co dělat, majitelé telefonů zatím ne. Google 7. května 2026 oznámil, že se z aplikace Fitbit stává Google Health, a v témž textu napsal, že uživatele Google Fitu k přesunu dat do Google Health vyzve „později letos“. Přejmenování už proběhlo: podle nápovědy se aplikace měnila od 19. května a většině lidí se aktualizovala sama mezi 19. a 26. květnem. Z Fitbit Premium se stalo Google Health Premium, které je dostupné i v Česku.

Nápověda Google Fitu se ale k 1. srpnu 2026 o žádném konci nezmiňuje. Pořád jsou v ní návody, jak sbírat Heart Points nebo zapnout tmavý motiv; k datům odkazuje na obecný návod ke Google Takeout, kterým si je lze stáhnout do archivu. Aplikace je dál v Obchodu Play, má tam přes sto milionů stažení, hodnocení 3,3 hvězdy z 683 000 recenzí a poslední aktualizaci dostala 14. července 2026. Health Connect má v témže výpisu přes pět set milionů stažení a 3,2 hvězdy z 86 800 recenzí.

Aplikace jiných výrobců už přepínají

Že se ekosystém stěhuje, je vidět mimo Google. Strava má v nápovědě samostatné návody na Health Connect a na Google Health a oba upravila koncem července. U Google Health píše, že se propojení změnilo: nově se do Stravy přenese jakýkoli zaznamenaný druh aktivity, i bez GPS, a dá se vybrat, které druhy se mají synchronizovat. Kdo propojení neaktualizuje, dostane dál jen kolo, běh, turistiku a chůzi se zapnutým GPS. Mezi souvisejícími návody u obou článků jsou Huawei Health, Samsung Health a Apple Health, Google Fit ne.

Co z toho plyne

Do konce podpory zbývá pět měsíců. Rozhraní skončí, náhrady existují a fungují, ale nástroj, který uživateli přenese historii z Fitu, Google zatím jen slíbil. Aplikace, která má v Obchodu Play přes sto milionů stažení, přitom v polovině července dostala další aktualizaci a v její nápovědě o konci nestojí nic. Podle nás je to horší kombinace než rovnou oznámené datum vypnutí: kdo si na Fit zvykl, nemá jak poznat, že by se měl začít zajímat.

Zdroje: příručka k přechodu z Google Fitu, otázky a odpovědi k přechodu, vývojářské stránky Google Fit, dostupnost Health Connect, oznámení aplikace Google Health, nápověda k přejmenování aplikace, nápověda Google Fitu ke stažení dat, nápověda Stravy ke Google Health a zpráva o vývojářské verzi Google Fitu z roku 2014.

Spotify oznámilo 30. července běžecký režim Running Mode. Aplikace z playlistu poskládá běh: uživatel jí řekne, jak dlouho poběží, jaký typ tréninku chce a v jakém tempu, a ona k tomu vybere hudbu.

Funkce je zatím jen v aplikaci pro iPhone, jen pro předplatitele a jen v sedmi zemích – v USA, Kanadě, Británii, Irsku, Austrálii, na Novém Zélandu a ve Švédsku. Česko mezi nimi není a majitelé telefonů s Androidem podle serveru Android Authority čekají taky.

Předvolba, typ tréninku a počet úderů za minutu

Režim se hledá ve Fitness hubu, tedy v oddílu, který Spotify otevřelo 27. dubna spolu s partnerstvím s Pelotonem; předplatitelé v podporovaných zemích tam mají přes 1 400 lekcí. Uvnitř běžeckého režimu je pětadvacet připravených předvoleb a u každé se dá změnit typ tréninku – Spotify jmenuje intervaly, stálé tempo a pyramidu –, délka, počet úderů za minutu a druh hudby.

K hudbě lze zapnout hlasové pokyny, které během tréninku říkají, co dělat. Jsou zatím jen anglicky. Ve stejný den dostali uživatelé na Androidu i jinde ještě druhou novinku, poznámky ke skladbám ve vlastních playlistech.

Tempo se vybírá předem

Podstatný je způsob, jakým se určí rychlost hudby. V oznámení stojí, že Spotify „přizpůsobuje údery vámi zvolenému tempu“ (přeloženo z angličtiny) – tedy tempo, které si člověk nastaví, než vyrazí. Že by telefon během běhu měřil, jak rychle běžec došlapuje, firma neuvádí nikde: ani v tiskové zprávě, ani v popisu funkce, který přebraly servery o Applu.

Je to rozdíl proti tomu, co Spotify pod stejným jménem dělalo před jedenácti lety.

V roce 2015 tempo počítal telefon sám

Funkci Spotify Running firma ukázala na tiskové akci 20. května 2015, ve stejné várce novinek jako podcasty a video. Časopis TIME ji tehdy popsal jednou větou: aplikace pozná tempo běžce a hned začne hrát skladby, které mu odpovídají. Vyšla nejdřív pro iPhone, na Android dorazila až v září téhož roku.

Jak to fungovalo v praxi, popsala v červnu 2015 Alison Griswold pro Slate. Po spuštění playlistu se z aplikace ozvalo „Začni běžet, aby se změřilo tempo“ (přeloženo z angličtiny) a telefon pak z akcelerometru a gyroskopu spočítal kadenci – tedy počet došlapů za minutu – a hudbu k ní dohledal. Změnám rychlosti se ale nepřizpůsoboval: jednou naměřené tempo zůstalo pevné a dál se dalo jen přepsat ručně. Tým o automatickém přizpůsobování podle Spotify uvažoval, ale první verze měla po doporučení sportovních vědců držet stálý rytmus. Ke startu si Spotify nechalo složit šest vlastních skladeb.

Proč byla ta stará funkce těžká

Slabinou nebylo měření, ale hudební katalog. Griswoldová v témže textu cituje Nicholase Arcolana, datového analytika běžecké aplikace RunKeeper: většina skladeb má kolem 140 úderů za minutu s velkým nakupením na 120, elektronická taneční hudba je z definice často na 128 a rock s popem se drží mezi 120 a 130. Rychlejších než 150 úderů je podle článku jen 16 procent skladeb.

Běžci jsou přitom jinde. Prostřední uživatel RunKeeperu podle Arcolana došlapoval 152krát až 155krát za minutu a trenéři podle téhož textu doporučují 170 až 180 kroků za minutu, aby byl dopad na klouby menší; elitní běžci se drží kolem 180. Čím rychleji tedy člověk běžel, tím méně měl Spotify z čeho vybírat.

Konec v únoru 2018

Spotify oznámilo konec funkce 9. února 2018 a vypnulo ji 26. února. Vysvětlení v oznámení není: stojí v něm jen věta, že rušení funkcí firma bere vážně a že energii vkládá do nových způsobů, jak službu dělat. Uživatele odkázala na běžecké playlisty v sekci Workout a na propojení s aplikacemi Nike+ Run Club a Runkeeper. Že za zrušením byl malý zájem, tvrdí až weby, které o tom psaly později.

Co z toho má majitel telefonu

Kdo běhá s telefonem v kapse nebo na pásce na paži, dostává po osmi letech zpátky funkci, která si s ním sama neporadí – musí jí tempo zadat. Naše hodnocení: pro trénink podle plánu, kde je rychlost stejně předem daná, to stačí, a Spotify se tím vyhnulo problému, na který stará verze narazila. Kdo běhá bez plánu a chce, aby se hudba přizpůsobila jemu, přijde zkrátka.

Do Česka to zatím nemíří a Spotify k rozšíření do dalších zemí nic neřeklo. Náhradu jinde v aplikaci nenajdete: funkce Smart Reorder, kterou Spotify pustilo předplatitelům 25. února, playlist přeskládá podle tóniny a počtu úderů za minutu kvůli plynulejším přechodům, ale cílové tempo si u ní zadat nejde.

Zdroje

• Spotify: Spotify's New Running Mode Brings Personalization to Your Workout (30. 7. 2026)
• Spotify: Introducing Fitness With Spotify (27. 4. 2026)
• Spotify: oznámení o zrušení běžecké funkce (9. 2. 2018)
• TIME: Everything You Need to Know About the New Spotify (20. 5. 2015)
• Slate: Coach Spotify (9. 6. 2015)
• GSMArena: Spotify Running for Android is rolling out now (16. 9. 2015)
• 9to5Mac: Spotify for iOS adds new music feature (30. 7. 2026)
• Android Authority: Spotify's getting a cool new feature for runners (30. 7. 2026)
• Engadget: Spotify can reorder your playlists by BPM and key (25. 2. 2026)

Zatím to není novinka na papíře. V Brazílii rozhraní vrací skutečná data od 17. března, v americkém Texasu od konce května. Do poloviny srpna se podle oznámení přidá Austrálie a Kanada, do konce roku pak zbytek světa včetně Spojených států.

Aplikace se dozví pásmo, ne datum narození

Rozhraní nevrací věk, ale rozmezí. Výchozí pásma jsou čtyři: 0 až 12, 13 až 15, 16 až 17 a 18 a víc. Vývojář si v konzoli Play může nastavit až tři vlastní hranice, musí být aspoň dva roky od sebe a měnit se dají jednou za rok.

Vedle pásma dostane aplikace i údaj o tom, odkud se věk vzal. Dokumentace rozlišuje čtyři úrovně:

• TIER_A – uživatel svůj věk sám uvedl.
• TIER_B – věk spravuje rodič nebo opatrovník.
• TIER_C – věk je odhadnutý z platební karty, e-mailové adresy, selfie, úředního dokladu nebo daňového čísla.
• TIER_D – věk je ověřený kombinací dokladu a selfie, nebo digitální identitou.

Ars Technica k oznámení napsala, že systém doklad ani selfie nevyžaduje, protože stojí na aplikaci Family Link. To sedí na cestu, kterou Google popisuje v oznámení, ale je to jen polovina věci: rozhraní umí předat i signál z ověření dokladem, jen ho neobstarává obchod Play sám.

Podmínky užití jsou proti tomu úzké. Údaj se smí použít jen k přizpůsobení obsahu podle věku a k plnění zákonů. Reklama, marketing, profilování uživatelů a analytika jsou vyjmenované jako zakázané; za porušení hrozí odebrání přístupu k rozhraní a stažení aplikace z obchodu. Knihovna je pořád v testovací fázi, poslední verze 0.0.4 vyšla v červenci.

Brazilský dekret žádá přesně to, co rozhraní umí

Oznámení na blogu mluví o rodičích a o partnerství s vývojáři. Zákon v něm nepadne ani jednou. Dokumentace pro vývojáře začíná odstavcem, kde padnou dva.

První je brazilský. Zákon 15 211/2025, kterému se v Brazílii říká Digital ECA, doplnil v březnu prováděcí dekret číslo 12 880/26 o 54 článcích. Ten mimo jiné ukládá obchodům s aplikacemi a operačním systémům, aby poskytovaly zdarma omezené věkové signály o uživatelích – a výslovně bez přesného data narození a bez profilu uživatele. Google spustil signály v Brazílii den poté, co zákon nabyl účinnosti.

Že rozhraní vrací pásmo místo data, tedy není jen ohled na soukromí. Je to popis toho, co po obchodech chce brazilský předpis.

V Texasu běží kvůli zákonu, o kterém se ještě soudí

Druhý zákon je texaský SB 2420, App Store Accountability Act. Guvernér ho podepsal 27. května 2025 s účinností od 1. ledna 2026. Ukládá obchodům zjišťovat věk „komerčně přiměřenou metodou ověření“ a omezit, co smějí lidé pod osmnáct let.

Účinnosti se zákon nedočkal. Federální soudce Robert Pitman ho v prosinci 2025 zablokoval předběžným opatřením s tím, že nejspíš porušuje první dodatek ústavy. Odvolací soud pátého obvodu ale 4. června blokaci pozastavil a napsal, že pro zastavení celého zákona není legitimní důvod. Nejvyšší soud pak 6. července odmítl blokaci obnovit, a to dvěma jednovětými usneseními.

Spor tím neskončil. Ústní jednání u pátého obvodu bylo nařízeno na 4. srpna. Sdružení Computer & Communications Industry Association, které za technologické firmy zákon napadá, ho nazvalo „širokým cenzurním režimem nad celým vesmírem mobilních aplikací“ (přeloženo z angličtiny). Podobné zákony podle Ars Techniky nabývají účinnosti také v Louisianě a Utahu.

Google v dokumentaci píše, že signály vrací uživatelům v Texasu, kteří si účet založili po 28. květnu 2026. Proč zrovna po tomhle datu, dokumentace neuvádí – s datem, kdy soud blokaci pozastavil, se neshoduje.

Kdo nechce, nesdílí

Sdílení věku je dobrovolné a ve výchozím nastavení vypnuté. Ovládá se z aplikace Family Link, kde rodič nastaví rozmezí jednou pro všechny aplikace, které rozhraní používají, a kdykoli to může vypnout. Dospělý svůj věk sdílí na výzvu aplikace.

Ta dobrovolnost je zároveň hlavní slabina. Kdo si nechce nechat věk hlídat, může si podle Ars Techniky založit jiný účet a věk zalhat; u dětských účtů není nastavení povinné a část rodičů ho neudělá. Rozhraní tak řeší spíš to, aby obchod Play vyhověl zákonům, než aby nezletilého někam nepustilo.

Použít ho navíc musí vývojář sám. Texaský zákon to po něm žádá, jinde je to na jeho rozhodnutí. Google to v oznámení popisuje jako přednost: aplikace na počasí podle něj nepotřebuje stejná nastavení jako zábavní služba.

Je to druhá věc, kterou Google letos přidal mezi obchod a vývojáře – od 30. září se v prvních čtyřech zemích začne ověřovat totožnost vývojářů. Tam se ověřuje ten, kdo aplikaci vydává. Tady ten, kdo si ji pouští.

Zdroje

• Delivering safer, age-appropriate experiences on Google Play – oznámení na blogu Android Developers, 29. 7. 2026
• Play Age Signals overview a Understand age signals responses – dokumentace pro vývojáře
• Play Age Signals release notes – verze knihovny
• Google's „privacy-preserving“ age verification system is coming to the Play Store – Ars Technica, 29. 7. 2026
• SCOTUS lets Texas enforce app store law that Big Tech calls „censorship regime“ – Ars Technica, 7. 7. 2026
• Brazil Regulates the Children and Adolescents Online Safety Act (Digital ECA) – Baker McKenzie, 19. 3. 2026

Sdružení operátorů GSMA vydalo 28. července 2026 specifikace RCS Universal Profile 4.1. Oznámil to technický ředitel sdružení Tom Van Pelt a hned v úvodu upozornil, že tahle verze je jiná než předchozí: nepřináší skoro žádné nové funkce pro uživatele. Podle oznámení místo toho zpevňuje základy, aby služba fungovala bezpečněji a stejně napříč sítěmi, přístroji a aplikacemi.

RCS je nástupce SMS. Běží po datech a umí to, co lidé znají z chatovacích aplikací: potvrzení o přečtení, ukazatel psaní, fotky v plném rozlišení, skupinové konverzace. Universal Profile je seznam funkcí, na kterém se operátoři, výrobci telefonů a tvůrci systémů dohodli, aby jim to fungovalo navzájem. Ve 4G je nasazení RCS na operátorovi, v 5G ho podle GSMA normy vyžadují.

Předchozí verze 4.0 z 26. března 2026 byla opakem téhle. Přidala videohovor, který se dá zahájit přímo z konverzace, formátovaný text a lepší kvalitu posílaných fotek, videí a zvuku.

Šifrování se doladilo podle toho, co se ukázalo při testech

Koncové šifrování se do RCS dostalo ve verzi 3.0 v březnu 2025. Stojí na protokolu MLS (Messaging Layer Security) a GSMA k němu tehdy napsalo, že RCS bude „první rozsáhlou službou pro zasílání zpráv, která podporuje interoperabilní koncové šifrování mezi klientskými implementacemi od různých poskytovatelů“ (přeloženo).

To je na tom to podstatné. WhatsApp šifruje konverzace mezi svými uživateli, iMessage mezi svými. RCS má šifrovat i tehdy, když jeden účastník píše z aplikace Zprávy od Googlu a druhý z iMessage na iPhonu.

Právě tady se ukázalo, že na papíře to vypadá jednodušeji, než to je. Verze 4.1 podle GSMA promítá do standardu poznatky z rozsáhlého testování součinnosti, aby šifrování fungovalo „bez ohledu na to, kdo dodává technologii pod ním“ (přeloženo). Na čem konkrétně testy vázly, v oznámení nestojí.

Přenos mezi sítěmi jde na gRPC

Druhá změna je vidět ještě méně. Universal Profile 4.1 mění způsob, jakým si sítě mezi sebou předávají zprávy a signalizaci: zavádí bezspojový přenos postavený na gRPC.

gRPC je otevřený framework na volání vzdálených procedur. Podle stránek projektu staví na obousměrném streamování přes HTTP/2, má knihovny v jedenácti jazycích a hodí se na propojování služeb uvnitř datových center i mezi nimi.

GSMA to samo přirovnává k dopravě: nestaví se nové silnice, mění se vozidla, která po nich jezdí. Menší auta uvezou tytéž informace s menší režií. Těžit z toho mají podle oznámení běžné konverzace, firemní zprávy, videohovory zahájené z chatu i hlášení spamu a podvodů.

Co z toho pozná uživatel, na tom se zdroje neshodnou

GSMA píše bez okolků, že si toho uživatel nemá všimnout: „Pro spotřebitele zůstanou tyto změny povětšinou nepovšimnuty, a přesně o to jde“ (přeloženo).

Server Android Authority to 31. července shrnul jinak. Podle něj přechod na gRPC přináší rychlejší doručování zpráv, menší vybíjení baterie a stabilnější spojení. Žádné takové tvrzení v oznámení GSMA není a měření k němu nikdo nezveřejnil. Za doložené proto bereme jen to, co říká sdružení: menší režii na přenosu a odolnější spojení mezi sítěmi.

Jediná novinka, kterou je vidět

Sdílení profilu. Uživatel bude moci v konverzaci ukázat jméno a obrázek z účtu, který už má, tedy od Googlu, od Applu nebo od operátora. Smysl to má hlavně ve skupinách, kde se ostatní účastníci hlásí jen telefonním číslem.

Součástí je ovládání, komu se ta informace pošle. Jak přesně se bude nastavovat, oznámení neuvádí, a nepíše ani to, kdy se funkce objeví v telefonech. Specifikace není totéž co vydaná aktualizace: dohodnutá verze standardu popisuje, co mají výrobci a operátoři udělat, ne co už udělali.

Na iPhonu šifrování běží, v Česku ho Apple uvádí u jednoho operátora

Apple přidal RCS do iPhonu v iOS 18.1. Koncové šifrování zkoušel v betě iOS 26.4 a do ostré verze ho pustil v iOS 26.5, která vyšla 11. května 2026. Podle serveru 9to5Mac je funkce i tam označená jako beta, je zapnutá ve výchozím stavu a vypíná se v nastavení Zpráv u položky RCS. Zašifrované vlákno se pozná podle zámku v záhlaví.

Že to zapne výrobce telefonu, ale nestačí. Apple vede seznam evropských operátorů a u každého vypisuje, které funkce iPhonu u něj fungují. Šifrované RCS je v něm k 31. červenci 2026 z českých sítí jen u T-Mobilu; u O2 ani u Vodafonu ho Apple neuvádí. Apple podle 9to5Mac dodává, že se funkce zavádí postupně a že ani u podporovaného operátora ji nemusí mít všichni zákazníci hned.

Náš názor: verze 4.1 je dobrá zpráva právě tím, jak je nudná. Standard, který místo nových funkcí opravuje to, co při testech nefungovalo, se chová tak, jak se standard chovat má. Horší je odstup papíru od praxe. Šifrování má RCS ve specifikaci od března 2025 a majitel českého iPhonu ho podle vlastního seznamu Applu dostane u jednoho ze tří operátorů.

Zdroje: oznámení GSMA k verzím 4.1, 4.0 a 3.0, stránka Universal Profile téhož sdružení, přehled operátorů od Applu, zpráva serveru 9to5Mac o iOS 26.5, shrnutí serveru Android Authority a stránky projektu gRPC.

Obchod Play se 22. července otevřel konkurenci. Američtí majitelé telefonů s Androidem si od té chvíle mohou stáhnout cizí obchod s aplikacemi přímo z Google Play, bez povolování instalace z neznámých zdrojů, a takový obchod navíc dostane přístup k celému katalogu Play. Není to nabídka od Googlu, ale plnění soudního příkazu.

Čtyři strany, které to nařizují

Trvalý soudní příkaz vydal 7. října 2024 soudce James Donato u federálního soudu pro severní Kalifornii ve sporu Epic Games proti Googlu. V prosinci 2023 porota rozhodla, že Google nezákonně ovládl distribuci aplikací pro Android i placení v nich.

Bod 12 zakazuje Googlu bránit tomu, aby se cizí obchody s aplikacemi šířily přes Google Play. Bod 11 mu ukládá pustit je ke katalogu Play, aby mohly nabízet tytéž aplikace; u aplikací, které nikde jinde nejsou, se stažení dokončí přes Google Play za týchž podmínek jako přímo z Play. Následující věta dodává, že si Google smí ponechat veškeré příjmy s takovým stažením spojené. Že inkasuje i z instalace, kterou uživatel našel u konkurence, tedy není klička – stojí to v příkazu.

Body 4 až 10 – zákaz podílu na tržbách pro toho, kdo distribuuje aplikace, zákaz vynucené exkluzivity, povinné otevření plateb – končí shodně 1. listopadu 2027. U katalogu a cizích obchodů žádné pevné datum konce není: tříletá lhůta se rozbíhá teprve tím, že je potřebná technika plně funkční. Osm měsíců, které na ni Google od vydání příkazu dostal, uplynulo už v červnu 2025, program se rozjel o víc než rok později. Devátý odvolací obvod mezitím 31. července 2025 jednomyslně potvrdil verdikt poroty i příkaz. Proč se spuštění opozdilo, žádný z otevřených zdrojů neuvádí.

Pět tisíc dolarů ročně za přezkum

Program se jmenuje Play Catalog Access a podmínky má Google v nápovědě. Kdo se chce ke katalogu dostat, musí být registrovaný jako organizace, mít obchod dostupný v USA, mířit na americké uživatele a fungovat jako otevřené tržiště s veřejnými a nediskriminačními pravidly. U každé aplikace musí ukázat jméno, vývojáře, popis i oprávnění a nepřekročit jedno procento pokusů o instalaci malwaru v klouzavém okně 30 dní.

Zaplatí za to 5 000 dolarů při vstupu za bezpečnostní a obsahový přezkum a pak tutéž částku každý další rok, aby o přístup nepřišel; tak to stojí v nápovědě a stejně to uvádí 9to5Google. Tech Times z toho počítá deset tisíc za první rok, nápověda ale roční platbu klade až po té vstupní. Účtovat Googlu příkaz dovoluje, jenže bod 12 žádá poplatek přiměřený a vycházející ze skutečných nákladů. Jestli tomu pět tisíc dolarů ročně odpovídá, se v dokumentaci nedozvíte a nenašel jsem to ani jinde. Spory má podle příkazu nejdřív posoudit tříčlenná technická komise, přičemž důkazní břemeno nese Google.

Katalog dostane obchod jako denní snímek přes úložiště Google Cloud Storage. Instalaci ale nedělá: když uživatel klepne na stažení, cizí obchod jen předá požadavek aplikaci Google Play přes rozhraní Inline Install API a dál běží obvyklá cesta včetně kontroly Play Protect i poplatku. Tech Times v den spuštění poznamenal, že příručka k tomuto rozhraní byla vedená jako připravovaná.

Vývojáře program zahrnul sám od sebe: americké výpisy jejich aplikací a her putují do katalogu automaticky, pokud to nezakážou. V Play Console je na to položka Catalog Settings se třemi volbami – všem obchodům, po jednom, nikomu. Bod 11 příkazu takovou možnost Googlu ukládá.

Dohoda, která spadla pod stůl

Ještě na jaře to vypadalo jinak. Google a Epic ohlásili v listopadu 2025 dohodu a do 4. března 2026 podali soudu upravený návrh, který měl příkaz nahradit mírnějším uspořádáním: místo šíření cizích obchodů uvnitř Play webový postup instalace pro registrované obchody, a k tomu bez práva vývojáře dát do aplikace odkaz ke stažení mimo Play.

Soudce Donato si ale na posouzení návrhu přizval nezávislou znalkyni, ekonomku Nancy Roseovou z MIT. Podle Tech Times shledala ve vyjádření z 12. července 2026, že by dohoda mohla odstranit důležitá soutěžní ustanovení příkazu. Stash z téhož vyjádření uvádí, že zrušení toho odkazu označila za zbytečnou a nákladnou chybu.

Tři dny nato, 15. července, obě firmy návrh společně stáhly. Google to zdůvodnil tím, že nechce protahovat řízení, které vnáší do ekosystému nejistotu; že za tím stojí posudek znalkyně, neřekla podle Stashe ani jedna strana. Platí tedy dál Donatův příkaz z října 2024 – a týden po stažení návrhu se Play otevřel.

Co z toho platí u nás

Z otevření obchodu nic. Bod 3 vymezuje působnost příkazu na Spojené státy a podmínky programu navíc vyžadují, aby se obchod na americké uživatele omezil.

Platí tu ale druhá věc, oznámená zvlášť. Viceprezident Paul Feng 24. června napsal na vývojářský blog Androidu, že se od 30. června 2026 dělí poplatek na dvě části: na poplatek za službu a k tomu poplatek za platbu ve výši 5 %, který se platí jen při použití platebního systému Google Play. Kdo pošle platbu jinudy nebo odkáže na vlastní web, těch pět procent neplatí – a právě tuhle možnost mají podle téhož textu vývojáři dodávající digitální obsah do Spojeného království a do Evropského hospodářského prostoru, tedy i k nám.

Druhé dveře se přivírají

Od 30. září 2026 bude Google vyžadovat ověření totožnosti vývojáře i u aplikací, které se na certifikované zařízení s Androidem dostanou úplně mimo Google Play. Nejdřív to platí v Brazílii, Indonésii, Singapuru a Thajsku, v roce 2027 se má rozšířit celosvětově. Google to přirovnává ke kontrole dokladů na letišti: potvrdí se totožnost cestujícího, ne obsah zavazadla.

Podle Tech Times proti tomu podepsaly otevřený dopis vedení Alphabetu mimo jiné Electronic Frontier Foundation a Vivaldi; projekt F-Droid uvedl, že by ho povinná registrace fakticky připravila o možnost fungovat. To už je moje úvaha, ne údaj ze zdroje: soud řešil, kdo smí do obchodu, kdežto tady jde o to, kdo smí na telefon.

Co se 22. července doopravdy změnilo, se pozná až podle toho, kdo se do programu přihlásí. Žádný ze zdrojů, které jsem si otevřel, jmenovitě nepotvrdil jediný obchod, jenž by ke katalogu Play přístup už měl.

Zdroje: znění soudního příkazu, podmínky programu Play Catalog Access, nápověda k zařazení výpisů, příspěvek Paula Fenga, nápověda k ověřování vývojářů, Tech Times, Stash a 9to5Google.

Sedm obchodů a čtyři země

Kontrola se na startu týká instalací ze sedmi obchodů: Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore a GetApps. Blog je uvádí jako obchody Googlu, Honoru, OPlusu (tedy OPPO), Samsungu, Transsionu, viva a Xiaomi. Google Play se sice v USA od 22. července otevřel konkurenčním obchodům, ale povinnost ověřovat vývojáře platí pro všech sedm stejně.

Nápověda Androidu upřesňuje, že jde o certifikovaná zařízení s Androidem 8 a novějším, tedy o telefony s předinstalovanými službami Googlu. Od června rozesílá Google podle blogu na většinu zařízení s Androidem systémovou službu Android Developer Verifier (balíček com.google.android.verifier), která před instalací ověří, že aplikace patří zaregistrovanému vývojáři.

Aplikaci bez registrace půjde po 30. září nainstalovat dvěma cestami: z počítače vývojářským nástrojem adb, nebo takzvaným pokročilým postupem.

Termín platí i mimo ty čtyři země

Do příspěvku na blogu přibyla 15. července věta, která rozsah rozšiřuje. Vývojáři vydávající na Google Play si mají do 30. září zkontrolovat, jestli jsou všechny jejich aplikace zaregistrované v Play Console. Důvod Google píše natvrdo: aby se vyhnuli „global removal from Google Play“, tedy odstranění z obchodu po celém světě. Zároveň uvádí, že 99 % aplikací na Play se zaregistrovalo automaticky.

Jsou to dvě různé věci. Kontrola při instalaci se 30. září zapne ve čtyřech zemích, kdežto vyřazení z Play hrozí kdekoli.

Jak vypadá pokročilý postup

Podobu obchvatu popsal Google 19. března. Je to jednorázový proces o pěti krocích: zapnout v nastavení vývojářský režim, potvrdit, že uživatele k tomu nikdo nenavádí, restartovat telefon a znovu se přihlásit, po jednodenní ochranné lhůtě se vrátit a potvrdit se otiskem prstu, obličejem nebo PINem. Teprve pak jdou instalovat aplikace od neověřených vývojářů, a to buď na sedm dní, nebo natrvalo. Varování, že aplikace ověřená není, zůstává; projde se přes něj tlačítkem.

Google to zdůvodňuje podvody, při kterých útočník oběť po telefonu navádí, aby si škodlivou aplikaci nainstalovala. Restart podle něj přeruší probíhající hovor i vzdálený přístup a denní lhůta rozbije uměle vyvolaný spěch. Odvolává se na zprávu sdružení Global Anti-Scam Alliance z roku 2025, podle které 57 % dotázaných dospělých za předchozí rok zažilo podvod a ztráty spotřebitelů po celém světě dosáhly 442 miliard dolarů.

Doklad totožnosti a poplatek 25 dolarů

Registrace má dva kroky. Nejdřív ověření totožnosti: zákonné jméno, adresa, e-mail a telefon, u organizací navíc identifikátor D-U-N-S a ověření firemního webu. Stránka pro vývojáře upozorňuje, že Google může chtít i doklad vydaný státem. Druhým krokem je registrace názvů balíčků, kde vývojář dokládá vlastnictví aplikace souborem APK podepsaným vlastním soukromým klíčem.

Za účet v Android Developer Console se platí 25 dolarů, což má nápověda konzole v seznamu častých dotazů jako samostatnou otázku. Vedle toho vzniká účet s omezenou distribucí: zdarma, bez dokladu totožnosti, ale aplikace se z něj dá nainstalovat nejvýš na dvacet zařízení, jejichž majitelé k tomu výslovně dají svolení. Tenhle typ účtu i pokročilý postup se mají podle Googlu spustit v srpnu, tedy měsíc před ostrým startem.

Co proti tomu namítá F-Droid

Repozitář svobodného softwaru F-Droid patří k nejhlasitějším odpůrcům. V otevřeném dopise z 24. února píše, že povinná registrace u jedné firmy promění otevřenou platformu v uzavřenou, a vývojářům doporučuje se do programu nehlásit „now or ever“, tedy teď ani nikdy. Dopis na webu keepandroidopen.org podepsalo přes sedmdesát organizací, mezi nimi Electronic Frontier Foundation, Free Software Foundation Europe, Software Freedom Conservancy a norské sdružení spotřebitelů Forbrukerrådet.

Část únorových výhrad mezitím padla. Dopis tvrdil, že pokročilý postup do září k dispozici nebude a že o něm Google odmítá sdělit podrobnosti; popis vyšel o necelý měsíc později a spuštění je slíbené na srpen. Hlavní námitka ale trvá. Podle serveru The Hacker News sestavuje a podepisuje F-Droid aplikace mnoha přispěvatelů, kteří vystupují pod přezdívkou a svou totožnost Googlu nedají, takže registrace každé aplikace pod jednou doloženou totožností je pro repozitář neproveditelná.

V textu z 1. července popisuje ověřovací službu záměrně slovníkem používaným pro škodlivý kód: běží prý na pozadí s nejvyššími oprávněními, nejde ji zablokovat ani odinstalovat a Play Protect ji neodhalí, protože je sám cestou, kterou se rozšiřuje. Věcné jádro té stížnosti leží jinde. Podle F-Droidu ověřování nezabrání tomu, aby někdo škodlivou aplikaci vydal poprvé; ztíží jen opakování téhož útočníka pod novým podpisovým klíčem. K tomu upozorňuje, že podmínky Android Developer Console v bodě 6.5 dovolují Googlu zrušit přístup tomu, kdo šíří „malware or other harmful applications“, přičemž slovo malware v tom dokumentu nikde definované není.

Číslo 99 % podle F-Droidu neukazuje ochotu vývojářů. Ti na Play byli podle něj zahrnuti automaticky na základě smlouvy, kterou s obchodem už měli. Ve čtyřech zemích, kde pravidlo začne platit, žije podle jeho odhadu kolem 580 milionů lidí.

Co zůstává nezodpovězené

Server The Hacker News, který termín rozebral 22. června, jmenuje tři otázky, na které Google před celosvětovým spuštěním neodpověděl: jak se může vývojář odvolat, když ho firma označí omylem, co si v registru totožností ponechá a jak dlouho, a jestli nabídne nějakou cestu repozitářům, které kontrolu vlastnictví jednotlivých aplikací nesplní bez změny způsobu práce. F-Droid k tomu přidává otázky za uživatele: co se 30. září stane s aplikacemi, které už v telefonu jsou, a jestli se z nich dá dostat k datům, pokud přestanou fungovat.

Majiteli telefonu mimo ty čtyři země se při instalaci zatím nezmění nic. Pokud ale některá jeho aplikace patří vývojáři, který se do konce září nezaregistruje, může zmizet z Google Play i jemu. A v roce 2027 se kontrola při instalaci má rozšířit všude.

Aplikace pro Android se dnes většinou píšou v jazyce Kotlin a souběžné operace v nich obstarávají korutiny – lehké úlohy, které umí uprostřed práce ustoupit a později pokračovat tam, kde skončily. Načítání dat ze sítě, animace, reakce na dotyk prstu: pod tím vším běží korutina. Tým Androidu 27. července popsal, proč byly pomalé a co s tím udělal kompilátor R8.

Výsledek: od verze 9.2.0 vývojářského nástroje Android Gradle Plugin zrychlí R8 běžné atomické operace dvakrát až čtyřikrát a spuštění a zrušení korutiny až dvojnásobně. Vývojář pro to nemusí udělat nic než přejít na novou verzi nástroje.

Osmdesát procent času padlo na dotaz, který mohl odpadnout

Nález přišel od týmu kolem Jetpack Compose, což je knihovna, kterou se dnes v Androidu skládá vzhled aplikací. Když se měřilo, kde se ztrácí čas, vyšlo najevo, že u prvku Modifier.clickable – tedy u obyčejného „na tohle se dá kliknout“ – spolklo osmdesát procent času vytváření a rušení vnitřních korutin.

Příčina je v knihovně kotlinx.atomicfu, kterou korutiny používají na atomické zápisy, tedy takové, co nemůže rozpůlit jiné vlákno uprostřed. Podle dokumentace projektu se atomická hodnota na Javě nahrazuje třídou AtomicXxxFieldUpdater ze standardní knihovny. Ta si ale položku hledá podle jména za běhu a pokaždé kontroluje, jestli existuje a jestli je přístupná. Každé spuštění, pozastavení, zrušení i dokončení korutiny volá aspoň jednu takovou operaci.

Kolik to dělá, ukázalo měření na telefonu Pixel 5 s rozhraním API 33. Přímá atomická reference zvládla dvojici zápisů za 50,7 nanosekundy, tatáž operace přes atomicfu potřebovala 135 nanosekund. Blog z toho počítá zpomalení přibližně 2,7krát a dodává, že běhové prostředí ART tuhle režii samo neodstraní.

Kompilátor to spočítá dopředu

R8 je nástroj, který v překladu aplikace zmenšuje a optimalizuje výsledný kód. Vidí přitom celý program naráz, takže pozná, že se ta reflexivní kontrola ptá pořád na totéž. Postup má tři kroky: k původní položce přidá číslo, které říká, kde přesně v paměti objektu hodnota leží, pak nahradí volání aktualizátoru přímým voláním do třídy sun.misc.Unsafe – a nakonec uklidí to, co zůstalo nepoužité.

Náhrada se nedělá naslepo. R8 ji provede jen tam, kde umí dokázat, že aktualizátor pochází z instrumentované položky a že typy sedí; jinde volání nechá být. Kde nemá jistotu, že hodnota není prázdná, vloží kontrolu. Jedna aplikace tak může mít část volání optimalizovanou a část ne.

Zisk se podle blogu projevil hlavně v Compose, jehož vlastní měřítka výkonu korutiny sledují. Po přechodu na novou verzi R8 v nich vyšlo dvojnásobné zlepšení u spouštění a rušení korutiny v LaunchedEffect. Číslo tedy pochází z měřítek jedné knihovny, ne z měření hotových aplikací.

Pomocná třída skončila v modulu, který na telefonu nebyl

K přístupu do sun.misc.Unsafe si R8 generuje vlastní pomocnou třídu, kterou v aplikaci sdílejí všechna optimalizovaná místa. A právě ta se stala předmětem hlášení, které do sledovače chyb dorazilo 23. července. Nepodal ho nikdo z Googlu, ale vývojář, kterému aplikace přestala fungovat po přechodu na verzi 9.3.0 zmíněného nástroje s R8 ve verzi 9.3.16.

Aplikace v hlášení má vedle základního modulu ještě jeden doinstalovatelný, který si telefon stáhne, teprve když ho uživatel potřebuje. R8 pojmenoval pomocnou třídu podle třídy, u které vznikla, a ta patřila právě do doinstalovatelného modulu. Podle hlásitele určilo právě zvolené jméno i to, kam ji kompilátor uloží. V základním balíčku ji přitom potřebovalo přes dvacet dalších tříd – a jsou to samé korutiny a zámky, od StateFlowImpl po vnitřní struktury knihovny Ktor.

Na telefonu to dopadlo tak, že aplikace nedoběhla ani do konce svého startu. Ohlásila NoClassDefFoundError, tedy že hledanou třídu nenašla. Když se stejná aplikace sestavila do jednoho spojeného balíčku, fungovala; chyba se projevila jen tam, kde si telefon stáhl samotný základ – tedy při běžné instalaci z obchodu. Hlásitel to doložil výpisem tříd z jednotlivých částí balíčku.

Oprava vznikla týž den. Autorem obou změn v repozitáři R8 je Søren Gjesse z Googlu a jejich smysl je prostý: pomocná třída pro Unsafe patří vždy do základního balíčku, ať se jmenuje po čemkoli. Vedle opravy přibyl i test, který stav znovu vyvolá, aby se nevrátil. Do hlavní vývojové větve obojí dorazilo 27. července, tedy v den, kdy vyšel blog o zrychlení.

Co z toho pozná majitel telefonu

Přímo nic – a to je na tom podstatné. Aplikace se nezrychlí tím, že si ji uživatel aktualizuje ze současné verze, ale až tehdy, když ji její autor znovu sestaví novějším nástrojem a novou verzi nahraje. U živě vyvíjené aplikace to je otázka nejbližšího vydání, u té, o kterou se nikdo nestará, se nestane nic.

Část zrychlení navíc přišla i bez R8. Blog uvádí, že po úpravách překladu za běhu v novějších verzích běhového prostředí Androidu se táž měřítka zlepšila asi o patnáct procent sama od sebe. Kdo má telefon s čerstvým systémem, kus zisku už tedy má.

Stojí za zaznamenání, že poznámky k vydání Android Gradle Pluginu 9.2.0 z letošního dubna o téhle optimalizaci nemluví ani slovem – mezi změnami v R8 popisují jen dvě jiné úpravy pravidel. Vývojář se o ní dozvěděl až z blogu o tři měsíce později. Podle nás je to škoda: změna, která přepisuje způsob práce s pamětí ve všech knihovnách postavených na atomických operacích, si zmínku v poznámkách zaslouží, i kdyby jen jednořádkovou.

Zdroje: Android Developers Blog, hlášení b/537973315, repozitář R8, kotlinx.atomicfu, poznámky k vydání AGP 9.2.0. O tom, co se v systému změnilo pro uživatele, jsme psali v článku Android 17 přinesl bubliny a strop na paměť aplikací.