Google Pixel jako výkladní skříň Androidu? Už dávno ne!

Už dlouhá léta mám pocit, že Google nevěnuje přístupnosti Androidu takovou pozornost, jakou by si zasloužila. TalkBack se sice dál vyvíjí a dostává nové funkce, ale z pohledu každodenního používání už pro mě dávno nepředstavuje tak jednoznačnou jistotu jako kdysi. A bohužel se zdá, že podobný problém se netýká jen odečítače obrazovky. Stále častěji totiž narážíme na situace, kdy Google nedokáže dostatečně uhlídat ani kvalitu softwaru na vlastních telefonech Pixel.

Právě Pixely přitom dlouhé roky platily za zařízení, na kterých měl Android ukazovat svou nejlepší možnou podobu. Kdysi tuto roli velmi přesvědčivě plnila rodina Nexus. Nebyla bezchybná, ale představovala čistý Android, rychlé aktualizace a především určitý referenční bod. Člověk mohl oprávněně očekávat, že pokud má někde nový Android fungovat správně, bude to právě na zařízení přímo podporovaném Googlem.

Dnes už si tím ale zdaleka tak jistý nejsem. Aktuální situace kolem Androidu 17 QPR1 a říjnové aktualizace Pixelů je podle mě velmi dobrým příkladem toho, proč už Pixel automaticky nepovažuji za „výkladní skříň Androidu“.

Co se pokazilo po zářijovém Androidu 17 QPR1

Google vydal Android 17 QPR1 pro podporované Pixely 15. září 2026. Krátce poté se začala objevovat hlášení uživatelů o výrazně horší plynulosti systému. Nešlo pouze o občasné škubnutí animace. U některých zařízení se objevovalo několikasekundové zamrzání aplikací, velmi pomalé reakce systému, problémy při přepínání aplikací, prodlevy při pořizování screenshotů, pády aplikací nebo hlášení, že System UI nereaguje.

Nejvíce je problém vidět v hlášeních majitelů Pixelů 7 a 8, ale podobné zkušenosti se objevily také u Pixelu 9a, řady Pixel 10 a dalších modelů, které QPR1 obdržely. Současně je nutné zdůraznit, že nejde o problém, který by postihl úplně každý telefon. Některým uživatelům fungují stejné modely bez zásadních obtíží. To ale ještě neznamená, že je možné problém jednoduše smést ze stolu jako několik náhodných stížností.

GrapheneOS našel konkrétní příčinu

Nejdůležitější posun přišel od projektu GrapheneOS. Jeho vývojáři totiž neřešili pouze subjektivní dojmy z pomalejšího telefonu, ale dohledali konkrétní regresi v kernelové větvi Pixelů, kterou přinesl Android 17 QPR1.

Problém souvisí s chováním takzvaného mmap read-ahead, tedy mechanismu, který se zjednodušeně řečeno snaží dopředu načítat data, jež bude systém pravděpodobně potřebovat. Změna v QPR1 může za určitých podmínek při tlaku na paměť potlačit i synchronní přednačítání. Výsledkem jsou výrazně pomalejší přístupy k datům a následně viditelné záseky, lagy nebo úplná zamrznutí.

GrapheneOS uvádí velmi konkrétní měření. Při sekvenčním čtení studeného 128MB souboru přes mmap v situaci s méně než 20 MB volného swapu a současně více než 1 GB dostupné RAM trval test s chováním QPR1 mediánově přibližně 2,36 sekundy. Po obnovení předchozího chování Androidu 17 se stejný test dostal přibližně na 0,40 sekundy.

To je velmi podstatné. Najednou totiž nemluvíme jen o tom, že se někomu „zdá telefon pomalejší“. Máme popsanou konkrétní systémovou regresi a také konkrétní opravu.

GrapheneOS opravil problém dříve než Google

A právě zde začíná být současná situace pro Google opravdu nepříjemná. GrapheneOS opravu připravil a vydal ve své vlastní větvi. Ve svých release notes výslovně uvádí obnovení předchozího chování mmap read-ahead s cílem odstranit stuttering způsobený tlakem na paměť po změně v upstream Pixel kernelu z Androidu 17 QPR1.

Jinými slovy: komunitní projekt postavený nad Androidem dokázal konkrétní regresi analyzovat, opravit a vydat řešení, zatímco uživatelé standardního systému na telefonech přímo od Googlu na ekvivalentní opravu stále čekají.

Nechci tím tvrdit, že vývoj GrapheneOS a oficiální distribuce Googlu jsou srovnatelné procesy. Google musí testovat mnohem širší spektrum konfigurací, regionů, operátorů a funkcí. Přesto je to pro firmu velikosti Googlu velmi nepříjemná vizitka. Zvlášť když jde o vlastní telefony a o chybu, která může zasahovat samotnou základní odezvu systému.

Říjnová aktualizace? Především promarněná příležitost

O to větší očekávání směřovalo k říjnové aktualizaci Pixelů, kterou Google začal vydávat 6. října 2026. Pokud někdo čekal větší balík oprav zářijových problémů, oficiální seznam změn musel působit poněkud rozpačitě.

Google v něm uvádí pouze tři hlavní funkční opravy:

  • opravu situace, kdy se při práci s vyhledávacími poli někdy neobjevila virtuální klávesnice,
  • opravu občasného šumu nebo zkreslení vyzvánění při některých VoIP hovorech,
  • opravu nesprávné orientace uložených fotografií a videí na řadě Pixel 11.

Samozřejmě jsou součástí aktualizace také bezpečnostní záplaty a ty rozhodně není vhodné podceňovat. Říjnový Pixel Update Bulletin potvrzuje bezpečnostní úroveň 5. října 2026. Jenže z pohledu uživatele, kterému telefon po zářijovém QPR1 zamrzá nebo výrazně ztratil plynulost, je podstatné něco jiného: Google v oficiálním seznamu říjnových oprav nezmiňuje odstranění známé kernelové regresní chyby QPR1.

A hlášení uživatelů po instalaci říjnového updatu ukazují, že minimálně u části zařízení problémy skutečně pokračují. Objevují se majitelé Pixelů 7, 8, 9a i Pixelů 10, kteří popisují pokračující lagy, stuttering nebo nutnost telefon pravidelně restartovat. Vedle toho samozřejmě existují i uživatelé, kterým se stav zlepšil nebo žádné potíže nemají. Situace tedy není plošná, ale rozhodně ji nelze považovat za uzavřenou.

Bluetooth a další potíže Androidu 17

Výkon navíc není jediným tématem. V oficiální komunitě Google Pixel se objevují také hlášení o problémech s Bluetooth audiem po Androidu 17 a zářijové aktualizaci. Majitelé Pixelů 8 a 10 například popisují přerušování nebo stuttering zvuku v automobilech i sluchátkách.

Opět platí, že uživatelská hlášení sama o sobě neznamenají, že stejnou závadu má každý Pixel. Ukazují ale další oblast, kde současný stav nepůsobí tak uhlazeně, jak bych od telefonu přímo od Googlu očekával.

Pixel 11 je potřeba hodnotit odděleně

Je zde také jedna důležitá technická poznámka. Nejnovější řadu Pixel 11 není správné automaticky zahrnovat mezi telefony postižené stejnou regresí Androidu 17 QPR1. Podle informací GrapheneOS dostala řada Pixel 11 na začátku září jinou opravnou verzi s úrovní záplat 1. září 2026, nikoli samotný Android 17 QPR1.

Na Pixelech 11 se sice rovněž objevují uživatelská hlášení o Bluetooth, Android Auto, fotoaparátu nebo dalších chybách, ale je potřeba je posuzovat jako samostatné problémy. Míchání všech chyb všech Pixelů do jednoho seznamu by bylo zavádějící.

Ani QPR2 Beta 7 zatím nedává jasnou odpověď

Google mezitím pokračuje ve vývoji Androidu 17 QPR2. Dne 9. října 2026 vydal QPR2 Beta 7. Oficiální poznámky uvádějí například opravu nadměrného vybíjení v klidovém režimu při používání funkce Flip to Shh nebo opravu selhávajícího stahování přes systémový DownloadManager.

Jenže ani v oficiálním seznamu nejvýznamnějších oprav Beta 7 není kernelová regresní chyba z QPR1 výslovně uvedena. To samozřejmě neznamená, že v interních změnách Googlu nemohla být nějaká související úprava provedena. Bez jasného potvrzení ale v tuto chvíli nelze tvrdit, že Google problém definitivně vyřešil.

A právě to je podle mě další slabina současné komunikace. Pokud se objeví chyba, která může citelně degradovat výkon několika generací vlastních telefonů, měl by Google uživatelům velmi jasně říct, že o ní ví, co ji způsobuje a kdy mohou očekávat opravu.

Proč je to u Pixelu větší problém než u běžného telefonu

Každý výrobce někdy vydá problematickou aktualizaci. Android je dnes obrovský systém a nelze realisticky očekávat absolutní bezchybnost. Jenže u Pixelu je laťka právem nastavena výš.

Google vyvíjí Android. Google vyrábí a prodává Pixel. Google připravuje Pixel Drops, QPR aktualizace i měsíční bezpečnostní balíky. Pokud má tedy někde existovat maximálně odladěná kombinace hardware a Androidu, člověk logicky očekává právě Pixel.

Proto mi nestačí vysvětlení, že „někomu telefon funguje dobře“. To je samozřejmě důležité a je fér to uvést. Ale stejně tak je fér říct, že vydat aktualizaci s takto nepříjemnou regresí a následně ji nevyřešit ani v následujícím měsíčním balíku není úroveň, kterou bych od referenčního telefonu očekával.

Pro uživatele odečítače obrazovky je situace ještě citlivější

Pro nevidomého uživatele navíc není plynulost systému jen otázkou hezkých animací. Pokud se běžnému uživateli na chvíli zasekne grafická animace, může to být nepříjemné. Pokud ale systém na několik sekund zamrzne při práci s odečítačem obrazovky, přestane reagovat dotyk, přepínání aplikací nebo systémové rozhraní, dopad na použitelnost může být podstatně větší.

Odečítač obrazovky je závislý na rychlé a spolehlivé odezvě systému. Každá prodleva se proto může projevit nejen vizuálním škubnutím, ale také opožděnou hlasovou odezvou, nejistotou při ovládání a celkově horší orientací v telefonu.

A právě proto mě současný stav Pixelů z pohledu přístupnosti příliš neuklidňuje. Čistý Android a rychlé aktualizace mají svoji hodnotu, ale rychlost vydávání aktualizací sama o sobě nestačí. Důležitější je, aby byly aktualizace kvalitně otestované a aby závažné regrese byly rychle a transparentně opravené.

Od Nexusu k Pixelu: výkladní skříň už ztratila lesk

Rodinu Nexus jsem vždy vnímal jako zařízení, která ukazovala, jak si Google představuje čistý Android. Nebyla dokonalá, ale jejich smysl byl srozumitelný. Byla to určitá referenční platforma.

Pixel měl tuto myšlenku posunout ještě dál. Google získal mnohem větší kontrolu nad hardwarem, softwarem, aktualizacemi i vlastními čipy Tensor. Člověk by proto očekával, že výsledkem bude ještě těsnější propojení a kvalitnější optimalizace.

Jenže v roce 2026 už podle mě nelze automaticky říkat, že Pixel je výkladní skříní Androidu. Je to telefon s dlouhou podporou, čistým systémem, velmi rychlými aktualizacemi a řadou zajímavých funkcí. Současně je to ale také zařízení, u kterého může velká systémová aktualizace přinést regresi výkonu a uživatel pak týdny čeká, zda a kdy ji Google opraví.

To není reputace, kterou by si měl Google budovat.

Google by měl změnit přístup

Nečekám, že žádná aktualizace nikdy nebude obsahovat chybu. To by nebylo realistické. Očekávám ale tři základní věci:

  • lepší testování před vydáním stabilní aktualizace,
  • rychlou reakci na závažné regrese,
  • otevřenou komunikaci s uživateli.

Pokud komunitní projekt dokáže identifikovat konkrétní kernelovou regresi, připravit opravu a zveřejnit technické vysvětlení, je naprosto legitimní ptát se, proč stejnou úroveň reakce nevidíme rychleji také u Googlu.

Největším problémem totiž není samotná chyba. Chyby budou existovat vždy. Problém je ztráta důvěry. Uživatel by se při každém dalším QPR neměl ptát, zda mu aktualizace náhodou nezhorší telefon, který ještě před několika minutami fungoval dobře.

Závěr

Android 17 QPR1 je podle mě ukázkou problému, který Google nesmí dlouhodobě přehlížet. Máme doloženou regresi v kernelové větvi Pixelů, máme množství uživatelských hlášení o zpomalení a zamrzání a máme komunitní projekt, který už konkrétní příčinu opravil. Přesto říjnová stabilní aktualizace Googlu tuto opravu ve svém oficiálním seznamu změn neuvádí.

Neznamená to, že každý Pixel je dnes pomalý nebo nepoužitelný. To by nebyla pravda. Znamená to ale, že jistota, kterou by měl Pixel jako telefon přímo od tvůrce Androidu nabízet, je v současnosti výrazně menší, než bych očekával.

A právě zde vidím největší rozdíl proti době zařízení Nexus. Tehdy jsem měl pocit, že referenční telefon s čistým Androidem ukazuje ostatním výrobcům směr. Dnes mám u Pixelu stále častěji pocit, že jeho majitelé patří mezi první, na kterých se ukáže, co Google při vývoji a testování nestihl zachytit.

Pixel by měl být místem, kde Android funguje nejlépe. Neměl by být místem, kde uživatel čeká, zda další aktualizace napraví škody po té předchozí.

Použité zdroje

  • Google Pixel Community – Google Pixel Update, October 2026
  • Android Open Source Project – Pixel Update Bulletin, October 2026
  • Android Developers – Android 17 QPR2 release notes
  • GrapheneOS – vysvětlení a oprava výkonnostní regrese Androidu 17 QPR1
  • GrapheneOS – release notes
  • GrapheneOS GitLab – technické podrobnosti opravy mmap read-ahead
  • Android Authority – rozbor problémů s výkonem Pixelů po Androidu 17 QPR1
  • Google Pixel Community – hlášení problémů s Bluetooth po Androidu 17
  • Reddit / GooglePixel – zkušenosti uživatelů Pixelu 7 po zářijové aktualizaci
  • Reddit / GooglePixel – hlášení lagů a zamrzání Pixelu 8
  • Reddit / GooglePixel – reakce uživatelů po říjnové aktualizaci

Stav článku odpovídá informacím dostupným k 11. říjnu 2026. U uživatelských hlášení je třeba počítat s tím, že se nemusí týkat všech zařízení daného modelu a jejich příčina nemusí být ve všech případech totožná.



AndroidGoogleGoogle Pixel


Matěj Plch
Jmenuji se Matěj Plch a jsem od narození nevidomý. Deset let jsem se intenzivně věnoval propagaci mobilní platformy Google Android, kterou sám používám a podařilo se mi její přístupnostní nástroje rozšířit mezi české uživatele.