Android 17 jest już na ostatniej prostej. Google bierze się za tłuste aplikacje, sieć lokalną i… komputery kwantowe.
Czwarta beta Androida 17 to ostatnie planowane wydanie testowe przed premierą stabilnej wersji, którą – według deklaracji firmy – powinniśmy zobaczyć około czerwca. Dla zwykłego użytkownika oznacza to jedno: większych rewolucji już nie będzie, teraz zaczyna się szlifowanie i polowanie na bugi. Dla deweloperów – to moment, w którym wymówki się kończą. API jest już ustabilizowane, a Google bardzo wyraźnie mówi: „sprawdźcie swoje aplikacje, bo inaczej to my je sprawdzimy za was”.
I tu dochodzimy do najciekawszej nowości. Google postanowił wziąć się za najbardziej problematyczny element mobilnego ekosystemu: przeżarte pamięcią, lagujące, wiecznie żyjące w tle apki.
Nowy szeryf w mieście: twarde limity na RAM i zabijanie „tłustych” aplikacji
Android 17 coraz bliżej premieryNajważniejsza zmiana w Androidzie 17 beta 4 to wprowadzenie sprzętowo egzekwowanych limitów pamięci dla aplikacji. Nie chodzi o mechanizm typu „brakuje RAM-u, więc system coś ubije” a o bardziej deterministyczne podejście. Google definiuje bazowe limity zużycia pamięci w zależności od całkowitej ilości RAM w urządzeniu – a system aktywnie monitoruje, co te limity przekracza.
Jeżeli aplikacja zaczyna zachowywać się jak odkurzacz na RAM, to Android 17 nie będzie się długo zastanawiał. W ruch idzie nowy mechanizm „MemoryLimiter” – jeżeli testując jako programista zobaczysz tę nazwę w ApplicationExitInfo.getDescription() to znaczy, iż system uznał twoją apkę za problem i ją po prostu zabił. Nie z powodu ogólnego braku zasobów, ale dlatego, iż przekroczyła ustalone granice przyzwoitości.
Google podkreśla, iż limity są ustawione „konserwatywnie” i mają na celowniku przede wszystkim skrajne przypadki: gigantyczne wycieki pamięci, źle napisane pętle i aplikacje, które po kilku godzinach działania potrafią zamienić 12‑gigabajtowego sztandarowca w zacinający się kalkulator.
Z punktu widzenia użytkownika to dobra wiadomość. Mniej „zamrożeń” interfejsu i mniej sytuacji, w których system nagle wyrzuca z pamięci aplikację z której właśnie korzystasz, bo jakaś inna od godziny trzyma w RAM-ie pół Internetu. Mniej drenażu baterii przez procesy, które dawno powinny zostać uśpione. Krócej mówiąc: mniej cierpienia za cudze lenistwo.
Koniec wymówek na tabletach i składakach. Resizowalność nie jest już opcjonalna
Google od lat próbuje przekonać deweloperów, iż tablety i składane telefony to nie jest egzotyczna ciekawostka, tylko pełnoprawna część ekosystemu. Problem w tym, iż wielu twórców aplikacji wciąż traktuje je jak zło konieczne i zwyczajnie „opt‑outuje” z obsługi resizowalności, orientacji czy niestandardowych proporcji.
W Androidzie 17 ta furtka się zamyka. jeżeli aplikacja celuje w nowy system (target SDK 17), to nie może już zrezygnować z utrzymywania orientacji, resizowalności i ograniczeń proporcji na dużych ekranach. Innymi słowy: koniec z apkami, które na tablecie wyglądają jak powiększony ekran z telefonu. Koniec z dziwnymi zachowaniami po obróceniu składaka. Koniec z „nie wspieramy tej konfiguracji, bo tak”.
Dla użytkowników Galaxy Foldów, Pixel Foldów, tabletów z Androidem i całej reszty większych urządzeń to potencjalnie jedna z ważniejszych zmian w ogóle. jeżeli Google konsekwentnie będzie egzekwować te wymagania to wreszcie może zniknie przepaść między jakością systemu na iPadOS-a a na system Google’a.
Sieć lokalna pod kluczem. Koniec z cichym skanowaniem twojego routera
Android 17 mocno przykręca też śrubę w kwestii dostępu do sieci lokalnej. Do tej pory wiele aplikacji mogło – mniej lub bardziej po cichu – zaglądać w twoją sieć domową, skanować urządzenia, utrzymywać połączenia, które nie zawsze były oczywiste dla użytkownika. W nowej wersji systemu domyślnie jest to zablokowane dla aplikacji celujących w Androida 17.
Jeśli deweloper chce mieć szeroki, trwały dostęp do sieci lokalnej to musi poprosić o nowe uprawnienie ACCESS_LOCAL_NETWORK i jasno uzasadnić po co mu to. Google sugeruje, by tam, gdzie to możliwe, korzystać z tzw. „privacy preserving pickers” – mechanizmów, które pozwalają użytkownikowi wybrać konkretne urządzenie czy zasób, zamiast dawać aplikacji pełny wgląd w całą sieć.
To kolejny krok w stronę modelu, w którym aplikacja nie dostaje „na wszelki wypadek” pełnego dostępu do wszystkiego, co jest w zasięgu Wi‑Fi. Dla części twórców systemu do smart‑domu czy zarządzania NAS‑ami będzie to oznaczało konieczność przeprojektowania kodu. Dla użytkownika – mniej niewidocznego ruchu w sieci lokalnej i mniejsze ryzyko, iż jakaś aplikacja robi coś, o czym wolałbyś wiedzieć.
Na poziomie bezpieczeństwa sieciowego Android 17 robi jeszcze jeden istotny krok: domyślnie włącza Certificate Transparency (CT). W Androidzie 16 ten mechanizm był dostępny, ale aplikacje musiały się na niego świadomie zdecydować. Teraz jest odwrotnie – CT jest standardem, a nie opcją.
W praktyce CT to publiczne logi certyfikatów TLS, które pozwalają wykrywać fałszywe lub nieautoryzowane certyfikaty wystawione dla danej domeny. Dzięki temu trudniej jest przeprowadzić atak typu man‑in‑the‑middle oparty na „lewych” certyfikatach. Dla użytkownika to niewidoczna warstwa ochrony, ale z punktu widzenia bezpieczeństwa całego ekosystemu – bardzo istotna.
Post‑kwantowe bezpieczeństwo w kieszeni. ML‑DSA w Android Keystore
Google dodaje obsługę algorytmu ML‑DSA (Module‑Lattice‑Based Digital Signature Algorithm), który został wystandaryzowany przez NIST jako jedna z odpowiedzi na przyszłe zagrożenia ze strony komputerów kwantowych. Na obsługiwanych urządzeniach można generować klucze ML‑DSA (w wariantach ML‑DSA‑65 i ML‑DSA‑87) i używać ich do tworzenia podpisów odpornych na ataki z wykorzystaniem przyszłych maszyn kwantowych – i to wszystko w bezpiecznym hardware’owym module.
Czy to ważne na dziś? Szczerze to… nie. Tym niemniej bardzo ciekawe. Google sam przyznaje, iż realne korzyści pojawią się raczej w latach 30., kiedy komputery kwantowe zaczną być na tyle zaawansowane, by zagrażać klasycznym schematom kryptograficznym. Ale wdrożenie takich mechanizmów zajmuje lata, a dane, które szyfrujemy dziś, mogą być interesujące także za dekadę. Z punktu widzenia długoterminowego bezpieczeństwa to ruch w dobrym kierunku – choćby jeżeli na razie brzmi jak marketingowy „buzzword”.
