Google Android App Functions zbudowało klatkę bezpieczeństwa, ale większość agentów AI pozostaje na zewnątrz
Google stworzył dla agentów Androida kontrolowaną drogę do innych aplikacji, jednak większość użytkowników wciąż nie może jej zobaczyć, zarządzać nią ani sensownie z niej korzystać. Google Android App Functions określają obecnie, w jaki sposób zatwierdzeni asystenci mogą wykrywać i wykonywać konkretne działania w różnych aplikacjach. Problem polega na tym, że architektura bezpieczeństwa pojawiła się przed powstaniem szerokiego ekosystemu agentów.
To coś więcej niż kolejna niedokończona funkcja Androida. Google decyduje, kto może działać wewnątrz aplikacji, co tacy uczestnicy mogą wykrywać oraz które operacje udostępniają deweloperzy. Te decyzje tworzą płaszczyznę kontroli dla przyszłych agentów, którzy będą tworzyć notatki, wyszukiwać zdjęcia, uruchamiać multimedia lub kompletować koszyki zakupowe.
Jednocześnie odróżniają one podejście Google od agentów obsługujących telefony poprzez interpretowanie ekranów i naśladowanie stuknięć. Systemy sterujące ekranem mogą działać bez głębokiej integracji z aplikacjami, ale pozostają podatne na zmiany układu i wprowadzające w błąd treści. App Functions oferują czystszą ścieżkę, choć mogą z niej korzystać wyłącznie zatwierdzeni agenci i uczestniczące aplikacje.
Google już zademonstrował ograniczone integracje, w tym pobieranie zdjęć z Samsung Gallery przez Gemini. Android 17 dalej rozszerza ten framework. Mimo to typowy właściciel Androida nie znajdzie uniwersalnego panelu agentów wypełnionego asystentami firm trzecich i zgodnymi działaniami.
Ta luka wyjaśnia pozorną sprzeczność. Klatka nie jest dosłownie pusta, ale jej populacja pozostaje niewielka, kontrolowana i trudna do zbadania przez zwykłych użytkowników. Google zabezpieczył wejście, zanim otworzył wokół niego rynek.
Google Android App Functions zmieniło sposób, w jaki agenci wchodzą do aplikacji
App Functions zastępują symulowane sterowanie ekranem zadeklarowanymi, ustrukturyzowanymi operacjami, które Android może rozpoznać i ograniczyć.
Funkcja aplikacji to odrębne działanie, które aplikacja udostępnia zatwierdzonemu wywołującemu. Aplikacja do notatek może udostępniać „utwórz notatkę”, a aplikacja multimedialna — „odtwórz utwór”. Agent przesyła ustrukturyzowane parametry zamiast poruszać się po widocznym interfejsie aplikacji.
Oficjalny framework App Functions opisuje dwie strony. Aplikacja dostawcy deklaruje działanie, a zaufany agent je wykrywa i wykonuje. Android pośredniczy w wymianie za pośrednictwem AppFunctionManager i powiązanych usług.
Ta architektura ma znaczenie, ponieważ interfejs wizualny został zaprojektowany z myślą o ludzkiej ocenie. Człowiek zauważa, że przycisk się przesunął, odbiorca wygląda na niewłaściwego albo suma zakupu się zmieniła. Zautomatyzowany system może kontynuować działanie po błędnym odczytaniu ekranu lub wykonaniu wrogich instrukcji osadzonych w wyświetlanej treści.
Ustrukturyzowane funkcje zawężają dostępne działanie. Agent nie otrzymuje nieograniczonej kontroli tylko dlatego, że może poprosić aplikację o wykonanie jednej operacji. Dostawca definiuje funkcję, jej dane wejściowe oraz zwracany wynik.
Android śledzi również, czy dana funkcja jest włączona. Żądanie wykonania może zakończyć się niepowodzeniem, jeśli funkcja nie istnieje, nie można jej znaleźć lub jest niedostępna. Tworzy to wyraźniejszą granicę niż przyznanie agentowi ogólnego dostępu do interfejsu aplikacji.
Framework trafił do platformy na poziomie API 36, czyli w wersji związanej z Androidem 16. Dokumentacja Google nadal opisuje App Functions jako beta lub eksperymentalny podgląd. Android 17 dodaje rejestrację w czasie działania, funkcje ograniczone do aktywności, zaktualizowane poziomy dostępu oraz bardziej szczegółowe mechanizmy wykrywania.
Te zmiany pokazują, że Google traktuje sprawczość między aplikacjami jako zagadnienie systemu operacyjnego. Nie pozostawia każdemu twórcy asystenta wymyślania prywatnej warstwy integracji. Platforma zapewnia wspólne identyfikatory, metadane, zarządzanie stanem, żądania, odpowiedzi i kontrole uprawnień.
Różnica staje się wyraźniejsza w prostym scenariuszu robienia notatek. Agent otrzymuje polecenie: „Zapisz adres hotelu w moich notatkach podróżnych”. Wyszukuje zgodną funkcję, identyfikuje aplikację docelową, przekazuje tytuł i treść, a następnie otrzymuje wynik.
Agent sterujący ekranem zamiast tego otworzyłby aplikację, odnalazł przycisk, wybrał notatnik, ustawił fokus w polu tekstowym, wprowadził treść i nacisnął zapis. Każde wizualne przejście dodaje kolejne miejsce, w którym do sekwencji może wkraść się niejednoznaczność lub manipulacja.
App Functions nie gwarantują, że agent właściwie zrozumiał pierwotne żądanie. Nie dowodzą też, że aplikacja bezpiecznie wdrożyła swoje działanie. Zmniejszają powierzchnię ryzyka, zastępując otwartą podróż przez interfejs operacją, którą deweloperzy wyraźnie zadeklarowali.
To pierwsza istotna zmiana. Android ma teraz natywne słownictwo dla agentów działających wewnątrz aplikacji, zamiast jedynie mówić o tych aplikacjach lub uruchamiać ich ekrany.
Druga zmiana jest mniej widoczna. Android umieszcza wykonywanie działań między aplikacjami za uprawnieniami, których zwykłe aplikacje nie mogą po prostu zakładać. Ta decyzja sprawia, że App Functions z wygodnego API staje się systemem kontroli dostępu.
Model uprawnień oddaje kontrolę Google i producentom urządzeń
Przewaga w zakresie bezpieczeństwa wynika z ograniczenia zdolnych wywołujących, lecz to samo ograniczenie utrzymuje niezależnych agentów Androida poza bramą.
Aplikacja może wykonywać własne funkcje bez specjalnych uprawnień. Wykonywanie między pakietami wygląda inaczej. AppFunctionManager wymaga, aby wywołujący agent posiadał uprawnienie Androida autoryzowane do wykrywania lub wykonywania funkcji w innych aplikacjach.
Pierwotne prace nad frameworkiem Androida przypisały EXECUTE_APP_FUNCTIONS wstępnie zainstalowanym lub systemowym aplikacjom posiadającym rolę asystenta. Powiązane zaufane uprawnienie służyło ściśle kontrolowanym komponentom inteligencji systemowej. Historia uprawnienia pokazuje, jak wyraźnie Android powiązał wykonywanie przez agentów z uprzywilejowanymi rolami.
Obecny framework ewoluuje w kierunku bardziej szczegółowych poziomów dostępu. Deweloperzy mogą oznaczać funkcje jako przeznaczone dla samej aplikacji, wywołujących systemowych lub wywołujących certyfikowanych przez Androida. Certyfikacja nie jest jednak równoznaczna ze zwykłym uprawnieniem w czasie działania, które każdy pobrany asystent otrzymuje po wyświetleniu prośby.
To rozróżnienie wyjaśnia, dlaczego funkcja wydaje się nieobecna na zwykłym telefonie. Użytkownicy są przyzwyczajeni do zatwierdzania dostępu do aparatu, mikrofonu, kontaktów i lokalizacji. Niekoniecznie mogą jednak zainstalować dowolnego asystenta i przyznać mu szerokie uprawnienia App Functions z poziomu standardowego ekranu ustawień.
Google zapobiega niebezpiecznemu wyścigowi na dno. Gdyby każda aplikacja mogła wywoływać każdą udostępnioną funkcję po jednej niejasnej prośbie o zgodę, agresywni asystenci zabiegaliby o szerokie uprawnienia. Użytkownicy mogliby je zatwierdzać, nie rozumiejąc, jak wiele istotnych działań staje się dostępnych.
Agenci między aplikacjami niosą inne ryzyko niż pasywne chatboty. Błędna odpowiedź jest niedogodnością. Błędne działanie może wysłać wiadomość do niewłaściwej osoby, ujawnić prywatny dokument, zmodyfikować zapis lub rozpocząć transakcję.
Prompt injection jeszcze wyraźniej podkreśla tę różnicę. Agent może napotkać tekst zaprojektowany tak, aby nadpisać intencję użytkownika podczas czytania strony internetowej, wiadomości, dokumentu lub obrazu. Niedawne badania nad agentami mobilnymi analizują konkretnie, w jaki sposób agenci Androida sterowani przez usługi dostępności mogą być narażeni na pośredni prompt injection.
Granica uprawnień nie może uodpornić modelu na manipulację. Może ograniczyć, które aplikacje działają jako agenci i do których funkcji ci agenci docierają. Daje też aplikacjom dostawców określoną ścieżkę wykonania, w której mogą walidować argumenty i stosować własne kontrole.
Centralna kontrola tworzy jednak kolejny problem. Google i producenci urządzeń z Androidem stają się w praktyce arbitrami tego, które asystenty otrzymują dostęp pierwszej klasy. Niezależny agent może stworzyć zaawansowany planer, a mimo to nie mieć uprawnienia do orkiestracji aplikacji firm trzecich za pośrednictwem oficjalnego frameworka.
Presja ta dotyka trzech grup.
Po pierwsze, twórcy asystentów muszą zakwalifikować się do zaufanej ścieżki Androida albo polegać na mniej bezpośrednich technikach. Mogą korzystać z deep linków do aplikacji, istniejących intentów, usług dostępności lub symulować interakcje za pomocą narzędzi deweloperskich. Żadna z tych metod nie zapewnia takiego samego ustandaryzowanego dostępu.
Po drugie, twórcy aplikacji muszą zdecydować, które funkcje warto udostępniać. Każda funkcja wymaga wdrożenia, testowania, walidacji danych wejściowych, obsługi cyklu życia i pracy nad zgodnością. Niewielki zespół aplikacji może wahać się, dopóki wystarczająca liczba użytkowników nie będzie posiadać agenta zdolnego wywoływać te funkcje.
Po trzecie, użytkownicy muszą ufać obu stronom transakcji. Potrzebują pewności, że asystent poprawnie zinterpretował żądanie oraz że aplikacja dostawcy nie wykona nieoczekiwanie szerokiej operacji.
Powstaje w ten sposób znany problem zimnego startu platformy. Agenci potrzebują użytecznych funkcji, zanim przyciągną użytkowników. Twórcy aplikacji potrzebują aktywnych agentów, zanim integracja będzie warta czasu inżynierów. Google może przerwać ten cykl dzięki Gemini i znaczącym partnerom, lecz niezależni uczestnicy pozostają zależni od jego polityki dostępu.
Projekt jest zatem jednocześnie klatką bezpieczeństwa i bramą dystrybucyjną. Ograniczenie wykonywania zmniejsza natychmiastowe nadużycia, podczas gdy certyfikacja i przywileje platformy kształtują to, kto może tworzyć znaczącą automatyzację Androida.
Projekt Google stawiający bezpieczeństwo na pierwszym miejscu zderza się z problemem adopcji
Podstawowy kompromis jest prosty: ściślejsza kontrola sprawia, że agentów Androida można wdrażać bezpieczniej, ale wolniejszy dostęp czyni framework mniej użytecznym obecnie.
Google publicznie wyprowadził App Functions poza mało znane odwołania do API w lutym 2026 roku. Zespół Android dla deweloperów określił te możliwości jako będące na wczesnym etapie i opisał prywatność oraz bezpieczeństwo jako fundamentalne priorytety projektowe.
Firma przedstawiła również konkretne wdrożenie. Gemini mógł interpretować żądanie, uruchamiać App Function w Samsung Gallery i zwracać wybrane zdjęcia w interfejsie Gemini. Według integracji Samsung, to doświadczenie rozpoczęło się w serii Galaxy S26, z planowanym rozszerzeniem na kolejne urządzenia Samsung.
Ten przykład dowodzi, że framework nie jest pustą powłoką kodu. Ujawnia również, jak ograniczone pozostaje wdrożenie. Demonstracja obejmuje asystenta Google, dużego producenta Androida, aplikację galerii pierwszej strony i wybrane urządzenia.
Szeroki ekosystem wyglądałby inaczej. Użytkownicy mogliby wybierać spośród zakwalifikowanych agentów. Tysiące aplikacji udostępniałyby udokumentowane operacje. Android pokazywałby, który agent wywołał którą funkcję, jakie dane zostały przeniesione i które działania wymagają potwierdzenia.
Istniejący framework zapewnia kilka elementów tej przyszłości, ale nie pełne doświadczenie publiczne. Deweloperzy mogą definiować metadane, publikować funkcje, obserwować stan i przetwarzać żądania wykonania. Android 17 wprowadza również bardziej dynamiczną rejestrację oraz zachowania specyficzne dla aktywności.
Aktualizacja Google Android 17 obejmuje testową aplikację agenta i polecenia ADB do celów deweloperskich. ADB, czyli Android Debug Bridge, to interfejs deweloperski do kontrolowania i analizowania urządzeń. Narzędzia te pomagają programistom weryfikować funkcje, zanim agenci konsumenccy zaczną je szeroko obsługiwać.
Wsparcie testowania jest konieczne, ale nie jest równoznaczne z adopcją. Deweloper może udowodnić, że „utwórz notatkę” zwraca oczekiwaną odpowiedź, nie wiedząc, ilu rzeczywistych asystentów ją wywoła. Zgodna funkcja może pozostawać uśpiona na milionach urządzeń.
Framework potrzebuje również wspólnych schematów. Dwie aplikacje do robienia notatek mogą udostępniać podobne działania pod różnymi nazwami, z innymi argumentami i formatami wyników. Jeśli każdy dostawca wymyśla własny kontrakt, agenci muszą rozumieć rosnący zbiór zastrzeżonych interfejsów.
Standardowe schematy pozwalają agentom wyszukiwać według możliwości zamiast zapamiętywać każdą aplikację. Model metadanych Androida obsługuje informacje o schematach, lecz użyteczna interoperacyjność nadal zależy od tego, czy deweloperzy zbiegną się wokół spójnych definicji.
Kontrola użytkownika stanowi kolejną nierozwiązaną warstwę. Aplikacja może utrzymywać stan włączenia swoich funkcji, a nowsze metadane mogą wyrażać różne poziomy dostępu. Zwykli użytkownicy potrzebują jednak zrozumiałego modelu, który odpowiada na praktyczne pytania.
Czy Gemini może tworzyć notatki, ale nie może ich usuwać? Czy inny certyfikowany agent może przeszukiwać zdjęcia bez udostępniania ich na zewnątrz? Czy zatwierdzenie obowiązuje jednorazowo, dla każdej aplikacji, dla każdej funkcji czy dla każdego wrażliwego żądania? Czy użytkownik może przejrzeć historię działań, gdy coś pójdzie nie tak?
Google musi równoważyć te mechanizmy kontrolne z ograniczeniem tarcia. Potwierdzanie każdej nieszkodliwej czynności niweczy wygodę agenta. Zatwierdzanie szerokich kategorii może ukrywać ryzyko. Użyteczny system powinien pozwalać na szybkie wykonywanie rutynowych operacji, jednocześnie zatrzymując się przed nieodwracalnymi lub wrażliwymi krokami.
Problem ten przypomina projektowanie uprawnień, lecz intencja agenta zmienia się w trakcie zadania. Uprawnienie do kamery daje dostęp do znanego czujnika. Agent może zacząć od odczytania listy, wywnioskować kilka podzadań, skonsultować wiele aplikacji i zaproponować zakup. Granica istotna z punktu widzenia konsekwencji pojawia się w połowie procesu.
To sprawia, że polityka jest ważniejsza niż pojedyncze uprawnienie. Android musi połączyć tożsamość wywołującego, zakres funkcji, reguły dostawcy, preferencje użytkownika, wrażliwość transakcji i bieżący kontekst.
Metafora klatki oddaje tylko część tego projektu. Android nie izoluje jednego niezaufanego procesu w pudełku. Koordynuje zaufanych wywołujących przez wąsko udostępnione drzwi, przy czym każda aplikacja zachowuje odpowiedzialność za to, co dzieje się za jej drzwiami.
Dla deweloperów natychmiastowa kalkulacja pozostaje niepewna. Obsługa Google Android App Functions daje aplikacji miejsce w przyszłych przepływach pracy agentów. Oznacza także inwestowanie w interfejs beta, którego dystrybucja, certyfikacja i zapotrzebowanie użytkowników wciąż się rozwijają.
Agenci Sterujący Ekranem Są Szybsi do Uruchomienia i Trudniejsi do Zaufania
Głównym przeciwnikiem Google nie jest inna platforma mobilna; jest nim skrót polegający na pozwalaniu agentom obsługiwać ekrany jak ludzie.
Agent sterujący ekranem może rozpocząć pracę przy mniejszej liczbie partnerstw. Odczytuje piksele lub drzewo dostępności, decyduje, gdzie wejść w interakcję, i generuje stuknięcia, przesunięcia oraz wprowadzanie tekstu. Jeśli człowiek może wykonać zadanie za pośrednictwem interfejsu, agent może spróbować tej samej drogi.
Ta uniwersalność jest atrakcyjna. Deweloperzy nie potrzebują, by każda docelowa aplikacja publikowała funkcję. Badacze mogą testować agentów w istniejącym oprogramowaniu, a startupy mogą demonstrować szeroki zakres działania przed wynegocjowaniem integracji.
Własne badania Google nad Androidem pomogły ugruntować to podejście. Zbiór danych Android in the Wild zawiera 715 000 epizodów obejmujących 30 000 instrukcji w wielu wersjach Androida i typach urządzeń. Odzwierciedla skalę potrzebną do trenowania lub oceniania systemów działających poprzez zróżnicowane interfejsy.
Jednak szeroka kontrola wizualna zastępuje jawne kontrakty wnioskowaniem. Agent musi ustalić, co oznacza każdy ekran, czy treść jest wiarygodna i czy interakcja przyniosła zamierzony wynik.
Etykieta przycisku może zmienić się po aktualizacji aplikacji. Okno dialogowe może zasłonić oczekiwany cel. Złośliwa strona może umieścić instrukcje tam, gdzie model je odczyta. Proces płatności może dodać opłatę lub zmienić produkt przed ostatecznym potwierdzeniem.
Ludzie również popełniają błędy w takich sytuacjach, ale agenci mogą powtarzać je szybciej i na większą skalę. Mogą działać w tle, kontynuować pracę między aplikacjami i obsługiwać informacje, których użytkownik nigdy bezpośrednio nie przegląda.
App Functions przenosi interpretację na inną warstwę. Agent nadal interpretuje żądanie użytkownika, lecz nie musi wnioskować o mechanice każdego ekranu. Wybiera zadeklarowaną operację i przekazuje informacje o określonym typie.
Przypomina to różnicę między używaniem interfejsu programowania aplikacji a automatyzacją witryny przez przeglądarkę. API zwykle oferują większą stabilność i bardziej przejrzyste dane wejściowe. Automatyzacja przeglądarki dociera do usług bez API, lecz musi radzić sobie ze zmianami układu, sesji i treści.
Ustrukturyzowana ścieżka poprawia także rozliczalność. Android może zidentyfikować pakiet wywołujący, funkcję docelową, żądanie i wynik. Aplikacje dostawców mogą odrzucać nieprawidłowe argumenty lub wymagać własnego potwierdzenia. Polityka platformy może traktować funkcje wrażliwe inaczej niż zwykłe.
Nic z tego nie eliminuje potrzeby zabezpieczeń na poziomie modelu. Przejęty agent może wywołać dozwoloną funkcję z niewłaściwego powodu. Niedbały dostawca może udostępnić operację ze słabą walidacją. Zaufany wywołujący nadal może błędnie zrozumieć niejednoznaczne instrukcje.
Ustrukturyzowane operacje mogą również zwiększać niezawodność szkodliwych działań. Złośliwy agent, który dotrze do funkcji „wyślij płatność”, nie musi poruszać się po mylącym interfejsie. Wartość zabezpieczeń zależy od ograniczania dostępu, sprawdzania intencji i wymagania potwierdzenia we właściwym momencie.
Dlatego zbyt szerokie otwarcie EXECUTE_APP_FUNCTIONS zniwelowałoby znaczną część korzyści architektonicznych. Google nie może po prostu umieścić uprawnienia w standardowym oknie dialogowym i uznać problem za rozwiązany. Platforma potrzebuje reguł kwalifikacji oraz obserwowalnego zachowania, które użytkownicy mogą zrozumieć.
Jednocześnie ograniczanie dostępu wywiera presję na korzystanie z automatyzacji ekranu. Niezależni asystenci wybiorą drogę, która pozwoli im wypuścić produkt. Jeśli oficjalne drzwi pozostaną niedostępne, część deweloperów wróci do usług dostępności, narzędzi opartych na ADB lub automatyzacji urządzeń.
Rezultatem jest paradoks polityki. Google chce, by agenci korzystali z bezpieczniejszej, ustrukturyzowanej ścieżki, lecz musi uczynić ją wystarczająco osiągalną, aby wyparła bardziej ryzykowne alternatywy.
Konkurenci i projekty open source mogą wykorzystać tę lukę, oferując agentów, którzy wydają się sprawniejsi w istniejących aplikacjach. Ich demonstracje mogą obejmować więcej zadań, ponieważ nie czekają na integrację ze strony dostawców. System Google może wyglądać na ograniczony właśnie dlatego, że egzekwuje granice.
Konsumenci nie będą oceniać tych architektur na podstawie dokumentacji API. Zauważą, czy agent potrafi wykonać żądanie. Jeśli rywal sterujący ekranem obsługuje dziesięć aplikacji, podczas gdy ustrukturyzowana ścieżka Gemini obsługuje dwie, zdolność może przeważyć nad abstrakcyjnym bezpieczeństwem w decyzji zakupowej.
Deweloperzy mierzą się z tym samym napięciem podczas projektowania przepływów pracy AI. Niezawodna automatyzacja zależy od przewidywalnych danych wejściowych, kontrolowanych działań i widocznych punktów kontroli. Ogólna kontrola interfejsu zapewnia zasięg, podczas gdy ustrukturyzowane funkcje oferują wyraźniejsze gwarancje.
Google musi zamknąć tę lukę w możliwościach, nie zmieniając agentów Androida w nieograniczone zdalne sterowanie. App Functions zapewnia mechanizm, lecz to polityka wdrażania i dostępu decyduje, czy deweloperzy rzeczywiście z niego skorzystają.
Prawdziwym Testem Jest To, Czy Klatka Stanie Się Rynkiem
Kolejna faza zależy od udziału aplikacji, dostępu agentów i widocznej dla użytkowników kontroli, a nie od większej liczby klas frameworka.
Pierwszym sygnałem, na który warto zwrócić uwagę, jest liczba i różnorodność produkcyjnych aplikacji udostępniających App Functions. Samsung Gallery jest użyteczną demonstracją, ponieważ wyszukiwanie zdjęć wiąże się z danymi osobistymi i rozpoznawalnym zadaniem użytkownika. Nie świadczy jednak o szerokim wsparciu w komunikacji, produktywności, finansach, zakupach, podróżach i mediach.
Duże aplikacje muszą udostępniać więcej niż promocyjne działania demonstracyjne. Powtarzalne, praktyczne przepływy pracy pokażą, czy framework oszczędza użytkownikom znaczący wysiłek. Tworzenie notatki, znajdowanie konkretnego zdjęcia, uruchamianie playlisty i dodawanie produktów do koszyka to wczesne testy.
Adopcja wzmacnia podejście Google, jeśli kilku niezależnych twórców aplikacji ogłosi działające integracje. Osłabia argument, jeśli wsparcie pozostanie skoncentrowane w oprogramowaniu Google, aplikacjach producentów urządzeń i wybranych partnerach premierowych.
Drugim sygnałem jest dostęp dla agentów spoza Google. Nowsze metadane Androida odnoszą się do wywołujących certyfikowanych przez Androida, sugerując drogę szerszą niż jeden asystent własny. Decydujące pytanie brzmi, czego wymaga certyfikacja i czy kwalifikujący się agenci zewnętrzni mogą konkurować na rozsądnych warunkach.
Wiarygodny program potrzebuje opublikowanych kryteriów, obowiązków dotyczących bezpieczeństwa, procedur cofania dostępu i przewidywalnej weryfikacji. Deweloperzy powinni wiedzieć, jak agent uzyskuje dostęp i jakie zachowanie powoduje jego utratę.
Bez tych szczegółów system uprawnień może stać się prywatną przewagą dystrybucyjną Gemini. Google może argumentować, że ścisły dostęp chroni użytkowników, podczas gdy rywale mogą twierdzić, że te same reguły chronią pozycję Google jako domyślnego agenta Androida.
Dowody na istnienie wielu certyfikowanych agentów wzmocniłyby interpretację stawiającą bezpieczeństwo na pierwszym miejscu. Trwała wyłączność dla własnych produktów wzmocniłaby interpretację o blokowaniu dostępu. Legitymizacja frameworka zależy od odróżnienia wymogów zaufania od preferencyjnego dostępu.
Trzecim sygnałem jest doświadczenie kontroli i audytu dostępne dla użytkownika. Szersze wdrożenie Gemini Intelligence przez Google obiecuje proaktywną automatyzację na telefonach i innych urządzeniach. Więcej działań w tle sprawia, że widoczność staje się coraz ważniejsza.
Użytkownicy muszą widzieć, jakie funkcje istnieją, którzy agenci mogą je wywoływać i które uprawnienia pozostają aktywne. Potrzebują też historii wyjaśniającej, o co poprosił agent i co zwróciła każda aplikacja.
Użyteczny interfejs kontroli powinien oddzielać wygodę niskiego ryzyka od istotnych uprawnień. Odtworzenie utworu nie zasługuje na takie samo tarcie jak wysłanie wiadomości czy złożenie zamówienia. Platforma powinna komunikować tę różnicę, zanim wystąpi błąd.
Projektowanie potwierdzeń będzie najtrudniejszą częścią. Zbyt wiele monitów przyzwyczaja użytkowników do zatwierdzania wszystkiego. Zbyt mało monitów pozostawia użytkowników zaskoczonych działaniami, których nie zamierzali. Zatwierdzenia kontekstowe muszą pozostać jasne, nie zamieniając każdego przepływu pracy w sekwencję przerw.
Google powinno także wyjaśnić, gdzie odbywa się przetwarzanie. Niektóre funkcje mogą wykonywać się na lokalnym stanie aplikacji, podczas gdy rozumowanie asystenta może obejmować usługi chmurowe. Użytkownicy muszą rozumieć, kiedy ich dane opuszczają urządzenie i która strona je otrzymuje.
Mechanizmy kontroli stanu frameworka mogłyby obsługiwać awaryjne cofanie uprawnień. Jeśli agent zachowuje się nieoczekiwanie, użytkownicy powinni móc wyłączyć jego uprawnienia między aplikacjami bez przeszukiwania poszczególnych aplikacji. Aplikacje dostawców również powinny móc szybko zawieszać wrażliwe funkcje.
Deweloperzy będą także szukać narzędzi operacyjnych. Potrzebują dzienników nieudanych wywołań, walidacji schematów, testów zgodności, zgłaszania nadużyć oraz jasnego zachowania w różnych wersjach Androida. Framework staje się ekosystemem dopiero wtedy, gdy zespoły potrafią obsługiwać go w środowisku produkcyjnym.
Etapowe wdrażanie Google jest możliwe do obrony. Udostępnienie nieograniczonej międzyaplikacyjnej sprawczości przed stworzeniem mechanizmów kontroli zaprosiłoby do przewidywalnych porażek. Firma zbudowała zamiast tego kontrole uprawnień, kontrakty dostawców, narzędzia testowe i rozszerzające się API platformy, zanim umożliwiła powszechny dostęp.
Sceptyczny pogląd jest równie możliwy do obrony. Bezpieczny framework z niewielką liczbą wywoływalnych funkcji nie zapewnia dużej wartości konsumentom. Ściśle kontrolowana ścieżka może również popchnąć niezależnych deweloperów w stronę dokładnie tej automatyzacji ekranu, którą framework zaprojektowano, aby zastąpić.
Funkcje aplikacji Google Android znajdują się zatem w ważnym, lecz niepełnym momencie przejściowym. Android ma już natywny mechanizm, który umożliwia agentom wykrywanie i wykonywanie ograniczonych operacji. Platforma nie wykazała jeszcze, że mechanizm ten może wspierać otwarty, konkurencyjny i szeroko przyjęty rynek agentów.
W ciągu najbliższych kilku miesięcy warto obserwować wdrożenia produkcyjne wykraczające poza partnerów premierowych, opublikowane zasady dostępu dla zewnętrznych agentów oraz widoczną historię uprawnień dla użytkowników. Łącznie te sygnały pokażą, czy Google zbudowało wspólną infrastrukturę, czy chroniony pas dla Gemini.
Dla właścicieli urządzeń z Androidem praktyczne pytanie nie brzmi, czy agent AI może dotknąć ekranu. Systemy eksperymentalne już pokazały, że potrafi. Pytanie brzmi, czy Android może pozwolić agentom działać w osobistych aplikacjach bez wymagania od użytkowników rezygnacji z rzeczywistej kontroli.
Dla deweloperów decyzja nadchodzi wcześniej. Muszą zidentyfikować bezpieczne, użyteczne operacje, które zasługują na uporządkowane udostępnienie, oraz określić, gdzie powinno pojawić się potwierdzenie. Czekanie pozwala uniknąć pracy w krótkim terminie, lecz może sprawić, że aplikacja stanie się niewidoczna, gdy użytkownicy zaczną delegować zadania zamiast otwierać interfejsy.
Google zbudowało wejście i zamontowało zamek. Teraz musi udowodnić, że zaufani agenci, niezależni deweloperzy i zwykli użytkownicy mogą wszyscy otrzymać właściwe klucze.
