Szybka odpowiedź
Odrzucenie za Broken Functionality oznacza, że weryfikator Google stwierdził, iż przesłana przez Ciebie wersja ulegała awarii, była wymuszenie zamykana, zawieszała się lub w inny sposób działała nieprawidłowo; przykłady samego Google to aplikacje, które się nie instalują, instalują się, ale nie wczytują, albo wczytują się, ale nie reagują. To decyzja dotycząca zgodności wersji z zasadami, a nie odmowa dostępu do wersji produkcyjnej, i według Google samo odrzucenie nie wpływa na status Twojego konta dewelopera. Odtwórz problem na wersji dystrybuowanej przez Play, upewnij się, że weryfikatorzy mogą się zalogować dzięki Sign-in details (dawniej App access), popraw każdą ścieżkę, której to dotyczy, a potem wyślij poprawioną wersję do sprawdzenia. Odwołuj się tylko wtedy, gdy możesz wykazać, że ustalenie było błędne.
Stan na 16 października 2026 r.. Każdą zasadę na tej stronie sprawdziliśmy tego dnia na stronach zasad Google Play i w Pomocy Play Console, a każda jest podlinkowana w miejscu użycia. Cytowane niżej zgłoszenia deweloperów świadczą o tym, co deweloperzy widzieli w 2026 roku, a nie o diagnozie Google dotyczącej ich aplikacji. Nie podajemy rankingu przyczyn, bo żadne publiczne dane go nie potwierdzają.
Ten artykuł dotyczy odrzuceń wersji na podstawie zasady Broken Functionality. Jeśli Google odmówiło dostępu do wersji produkcyjnej po Twoim teście zamkniętym albo poinformowało, że potrzebne są dalsze testy, to inna decyzja z inną poprawką: przeczytaj zamiast tego co zrobić, gdy Google Play informuje, że wymagane są dalsze testy oraz dlaczego wnioski po testach zamkniętych są odrzucane.
O czym jest ten artykuł
Co oznacza Broken Functionality w Google Play?
To jedna z dwóch sekcji zasady Google dotyczącej funkcjonalności, treści i wrażeń użytkownika (Functionality, Content, and User Experience). Druga sekcja, Limited Functionality and Content, dotyczy aplikacji o zbyt małej użyteczności. Broken Functionality dotyczy aplikacji, która w przesłanej postaci nie działa.
Nie zezwalamy na aplikacje, które ulegają awariom, są wymuszenie zamykane, zawieszają się lub w inny sposób działają nieprawidłowo.
Pod tym zdaniem Google podaje trzy przykłady typowych naruszeń: aplikacje, które się nie instalują, aplikacje, które się instalują, ale nie wczytują, oraz aplikacje, które się wczytują, ale nie reagują. Traktuj je jako trzy miejsca, w których warto szukać. Takie samo powiadomienie może wywołać weryfikator, który nie może zainstalować wersji, widzi pusty lub nieskończenie ładujący się ekran albo dotyka elementu sterującego i nic się nie dzieje.
W starszych linkach do Pomocy i wątkach na forach wciąż możesz trafić na nazwę Minimum Functionality. Obecna sekcja zasad nazywa się Limited Functionality and Content i obejmuje aplikacje ze statycznym tekstem lub plikami PDF, aplikacje z bardzo małą ilością treści oraz aplikacje, które z założenia nic nie robią. Powiadomienie może powoływać się na którąkolwiek z tych sekcji, a poprawki się różnią, więc zanim cokolwiek zmienisz, sprawdź, którą wskazuje Twoje powiadomienie.
Cztery decyzje, które łatwo ze sobą pomylić
| Decyzja | Czego dotyczy | Od czego zacząć |
|---|---|---|
| Broken Functionality | Czego dotyczyPrzesłana wersja ulegała awarii, zawieszała się, nie wczytywała się lub nie reagowała u weryfikatora. | Od czego zacząćOdtwórz problem na wersji dystrybuowanej przez Play, popraw go na każdej ścieżce, której dotyczy, prześlij ponownie. |
| Limited Functionality and Content | Czego dotyczyAplikacja działa, ale ma za mało własnej użyteczności lub treści. | Od czego zacząćDodaj prawdziwą funkcjonalność. Sama poprawka błędu tu nie wystarczy. |
| Brakujące lub niedziałające Sign-in details | Czego dotyczyWeryfikatorzy nie przeszli przez logowanie, członkostwo, paywall, kod jednorazowy lub kontrolę regionu. | Od czego zacząćZaktualizuj Sign-in details w App content, a potem wyślij zmianę do sprawdzenia. |
| Nieprzyznany dostęp do wersji produkcyjnej | Czego dotyczyPo teście zamkniętym Google uznało, że aplikacja wymaga dalszych testów lub nie jest gotowa na wersję produkcyjną. | Od czego zacząćOsobny proces bez powiadomienia o błędzie w kodzie. Zobacz wymagane dalsze testy. |
Gdzie Google pokazuje, co nie działało?
Zacznij od e-maila o egzekwowaniu zasad i strony Policy status w Play Console. Razem wskazują zasadę i wersję, której dotyczy decyzja, a według Google strona Policy status pokazuje też wszelkie dostępne dodatkowe informacje. Zrzuty ekranu, dane urządzenia i ślady stosu nie są obiecane, więc nie czekaj na nie.
Otwórz Play Console, wybierz aplikację i przejdź do jej strony Policy status. Zanim dotkniesz kodu, zapisz cztery rzeczy: wskazaną sekcję zasad, kod wersji i ścieżkę, które były sprawdzane, datę oraz wszelkie załączone dowody. Sprawdź też e-mail i powiadomienia w Play Console, bo właśnie tam Google podaje, jaką zasadę naruszyła wersja.
Jak naprawdę wyglądają powiadomienia w 2026 roku
Nie istnieje jeden e-mail o Broken Functionality, który dostają wszyscy, a każda strona, która drukuje go jako dokładny szablon, zgaduje. Deweloperzy, którzy w 2026 roku publicznie zamieścili swoje powiadomienia, opisują bardzo różny poziom szczegółów:
- Etykieta powiadomienia o treści „Broken Functionality: Unresponsive UI elements” (niereagujące elementy interfejsu), zamieszczona 2 września 2026 r. przez dewelopera, którego aplikacja podczas pierwszej synchronizacji danych pokazywała ekran ponowienia próby w trybie offline (Społeczność Pomocy Play Console).
- Przykład od weryfikatora o treści „For example, your app does not open or load.” (na przykład Twoja aplikacja się nie otwiera ani nie wczytuje), zacytowany w czerwcu 2026 r. przez twórcę gry, której ekran tytułowy się wczytywał. Autor napisał później, że gra została opublikowana po zmianie sposobu, w jaki przycisk Wstecz w Androidzie z niej wychodził.
- Powiadomienie, które jeden z deweloperów opisał w sierpniu 2026 r. jako zaledwie dwa słowa, „Broken functionality”, bez niczego więcej.
To fragmenty przytoczone przez deweloperów, a nie uwierzytelnione e-maile od Google, i każdy z nich to pojedynczy przypadek. Pokazują zakres szczegółów, jakie możesz dostać, a nie to, co powie Twoje powiadomienie, ani dlaczego Twoja aplikacja nie przeszła.
Jeśli Twoje powiadomienie jest niejasne
Traktuj wskazaną zasadę jako objaw do odtworzenia, a nie jako diagnozę. Pięć kontroli z następnej sekcji ułożyliśmy tak, żeby każda wykluczała inne miejsce, w którym może ukrywać się błąd.
Co sprawdzić najpierw po odrzuceniu za Broken Functionality?
Wykonaj pięć kontroli na dokładnie tej wersji, którą sprawdzało Google. Są ułożone od najtańszej do wykluczenia do najtrudniejszej, a nie według tego, jak często występuje dana przyczyna, bo żadne publiczne dane nie pokazują, jak często zdarza się każda z nich.
Pięć kontroli po kolei
Zainstaluj wersję dystrybuowaną przez Play, a nie wersję debug
Zainstaluj aplikację ze swojej ścieżki testów na czystym urządzeniu zalogowanym na konto Google, na którym aplikacja nigdy nie była uruchamiana, a potem otwórz ją tak, jak zrobiłby to weryfikator. Google Play podpisuje dystrybuowane wersje Twoim kluczem podpisywania aplikacji (Use Play App Signing), więc każda usługa sprawdzająca odcisk cyfrowy certyfikatu, na przykład Google Sign-In, Mapy albo klucz API ograniczony nazwą pakietu i SHA-1, może działać w wersji debug i zawodzić w wersji ze sklepu. Jeden z deweloperów w 2025 roku powiązał błąd występujący tylko w wersji release z brakiem uprawnienia do internetu w manifeście wersji produkcyjnej.
Upewnij się, że weryfikator może wejść do aplikacji
Jeśli jakakolwiek część aplikacji jest ukryta za logowaniem, członkostwem, lokalizacją lub inną blokadą, Google wymaga podania danych dostępu. Sprawdź, czy Sign-in details (dawniej App access) zawiera dane logowania, które działają dzisiaj, z każdego kraju i bez kodu jednorazowego. Następna sekcja omawia to krok po kroku.
Przetestuj backend spoza własnej sieci
Ekrany logowania i ekrany z danymi zawodzą, gdy serwer jest nieosiągalny z sieci weryfikatora. Deweloperzy w 2026 roku powiązali błędy z przypadkową regułą zapory, która blokowała żądanie kodu logowania, oraz zgłaszali błąd zaufania certyfikatu widoczny na ekranie logowania. Testuj przez dane komórkowe i inną sieć, a także z innego kraju, jeśli Twój serwer filtruje ruch według regionu.
Dotknij każdego widocznego elementu i otwórz każdy pusty ekran
Każdy przycisk i link powinien reagować odpowiednią treścią. Sporządzona przez Google lista kontrolna Broken Functionality w Społeczności Pomocy Play Console mówi: „Upewnij się, że Twoja aplikacja nie ma żadnych pustych stron bez odpowiednich zastrzeżeń lub komunikatów o błędach”. Usuń niedokończone funkcje, zamiast wypuszczać przycisk, który nic nie robi, i sprawdź, czy każda funkcja obiecana w opisie w sklepie naprawdę działa w tej wersji. Prawidłowo pustej liście, na przykład gdy nie ma jeszcze zapisanych elementów, daj zdanie, które to wyjaśnia, i kolejny krok. Jeśli Twoja nawigacja jest nietypowa, na przykład dotknięcie w dowolnym miejscu, aby kontynuować, dodaj widoczną wskazówkę, której nowy użytkownik nie może przeoczyć.
Sprawdź uruchamianie, przycisk Wstecz i raporty, które Play już ma
Uruchom aplikację od zera, obróć ekran, przenieś ją w tło i przywróć, a na każdym ekranie naciśnij Wstecz. Potem przeczytaj raport przedpremierowy i Android vitals dla sprawdzanej wersji. Zarejestrowana tam awaria to najmocniejszy dowód, jaki dostaniesz, a czysty raport ma ograniczenia, które wyjaśnia sekcja po następnej.
Jak przekazać weryfikatorom Google dane logowania?
W Play Console przejdź do Policy and programs, potem App content, potem Sign-in details. Ta sekcja nazywała się wcześniej App access (Dostęp do aplikacji), więc starsze wpisy i niektóre przetłumaczone strony Pomocy wciąż używają tej nazwy.
Jeśli dostęp do całej aplikacji lub jej części jest ograniczony na podstawie danych logowania, członkostwa, lokalizacji lub innych form uwierzytelniania, musisz podać wszystkie dane wymagane do uzyskania dostępu do aplikacji.
Dodaj lub zaktualizuj instrukcje
- Otwórz Play Console i przejdź do strony App content (Policy and programs > App content).
- W sekcji Sign-in details wybierz Start albo Manage, jeśli instrukcje były już dodane.
- Wybierz + Add new instructions i wpisz dane dostępu. Pola Any other instructions użyj do wszystkiego, co nietypowe, na przykład hasła jednorazowego, uwierzytelniania wieloskładnikowego lub logowania z więcej niż dwoma polami.
- Zapisz zmiany. Możesz dodać maksymalnie pięć zestawów instrukcji.
- Przejdź do Publishing overview, znajdź zmianę w sekcji Changes ready to send for review i wybierz Send for review. Samo zapisanie niczego nie wysyła.
Co oznacza działający dostęp
Wymagania Play Console Google każą „podać aktywne konto demonstracyjne, dane logowania i wszystkie inne zasoby potrzebne Google Play do sprawdzenia Twojej aplikacji”. Wymagania dotyczące danych logowania wyjaśniają, co to oznacza:
- Konto aktywne i wielokrotnego użytku, a nie jednorazowe zaproszenie ani wersja próbna, która wygaśnie w trakcie weryfikacji.
- Dane logowania, które omijają kody jednorazowe i weryfikację dwuetapową, bo weryfikator nie odbierze kodu wysłanego na Twój telefon lub skrzynkę.
- Dostęp działający z każdej lokalizacji, jeśli aplikacja ogranicza dostęp według regionu, oraz pełny dostęp do płatnych lub zablokowanych funkcji, które weryfikator musi zobaczyć, bez pobierania od niego opłat.
- Dane napisane po angielsku i aktualne. Jeśli zmienisz hasło lub usuniesz konto testowe, zaktualizuj Sign-in details tego samego dnia.
- Jeśli logowanie wymaga czegoś, co nie jest tekstem, na przykład kodu QR lub kodu kreskowego, wygeneruj dla niego statyczny adres URL i dodaj go do Sign-in details. Jeśli aplikacja prosi użytkowników o ustawienie własnego kodu PIN lub korzysta z logowania przez media społecznościowe, wyjaśnij w instrukcjach, jak weryfikator może przez to przejść.
Brak dostępu to nie to samo co niedziałające logowanie
Jeśli powiadomienie powołuje się na Sign-in details, żadna zmiana w kodzie nie pomoże, dopóki dane dostępu nie zostaną poprawione i wysłane do sprawdzenia. Jeśli dane logowania były w porządku, a samo logowanie nie zadziałało, to problem Broken Functionality i należy szukać przyczyny w kontroli backendu opisanej wyżej.
Co, jeśli aplikacja działa na Twoim telefonie, a Google nie przysłało zrzutu ekranu?
W takim razie to nie Twój telefon jest środowiskiem, w którym wystąpił błąd. Odtwórz problem na wersji ze sklepu, na czystym urządzeniu i w innej sieci, a zanim cokolwiek zdecydujesz, przeczytaj dwa raporty, które Play Console już ma dla tej wersji.
Raport przedpremierowy
Znajdziesz go w Test and release > Testing > Pre-launch report. Google generuje go automatycznie po przesłaniu pakietu aplikacji lub pliku APK, w miarę dostępnych zasobów, uruchamiając aplikację na urządzeniach testowych. Sprawdź, do których ekranów faktycznie dotarło automatyczne przeszukiwanie: jeśli zatrzymało się na ekranie logowania, nigdy nie zobaczyło reszty aplikacji. Google dodaje ograniczenie, o którym warto wiedzieć: „Dane logowania mogą być automatycznie wprowadzane tylko w aplikacjach na Androida, które korzystają ze standardowych widżetów Androida” (Use a pre-launch report to identify issues). Czysty raport to dowód, a nie zaliczenie. Google mówi to samo o swoich kontrolach przed weryfikacją: „Przejście wszystkich kontroli przed weryfikacją nie gwarantuje przejścia formalnego procesu weryfikacji aplikacji”.
Android vitals
Znajdziesz je w Monitor and improve > Android vitals > Crashes and ANRs. Google zbiera te dane tylko od użytkowników, którzy zgodzili się udostępniać dane o użytkowaniu i diagnostyce (Monitor technical quality with Android vitals), więc nowa aplikacja w małym teście może nie pokazywać niczego. Pusta strona Android vitals nie dowodzi, że aplikacja nigdy nie uległa awarii.
Prawdziwi ludzie na prawdziwych urządzeniach
Test zamknięty istnieje po to, żeby wykryć tego rodzaju problemy przed publiczną premierą. Testerzy na różnych telefonach, wersjach Androida i w różnych sieciach docierają do ekranów, do których dociera weryfikator, a ich opinie pokazują, gdzie coś przestaje działać. To pomaga znaleźć i naprawić usterki; nie zmienia sposobu, w jaki Google weryfikuje aplikację. Jeśli potrzebujesz podstaw samej ścieżki, zobacz, jak działają testy zamknięte w Google Play.
Poprawić i przesłać ponownie czy się odwołać?
Popraw i prześlij ponownie, gdy potrafisz odtworzyć błąd lub znajdziesz prawdopodobną przyczynę. Odwołaj się, gdy masz dowody, że wskazane ustalenie jest błędne. Nigdy nie przesyłaj ponownie tej samej, niezmienionej wersji: Google każe deweloperom nie publikować ponownie odrzuconej aplikacji, dopóki naruszenie nie zostanie naprawione.
Poprawić, doprecyzować czy się odwołać?
Odpowiedz na trzy pytania o Twoje powiadomienie i Twoje własne testy. Nic, co wybierzesz, nie opuszcza tej strony.
Odpowiedz na pytania, żeby zobaczyć rekomendację. Jeśli nie potrafisz odtworzyć błędu, rozstrzyga trzecie pytanie.
Popraw błąd, potem prześlij ponownie na każdej ścieżce
Popraw i prześlij ponownieMasz powtarzalny błąd, a to najlepsza możliwa sytuacja. Popraw go, przetestuj poprawkę na wersji ze sklepu, a potem wykonaj opisane niżej kroki ponownego przesłania, żeby na żadnej ścieżce nie został aktywny niezgodny pakiet.
Przetestuj wersję ze sklepu, zanim zdecydujesz
Najpierw testWersja debug to nie to, co uruchamiał weryfikator. Zainstaluj aplikację ze swojej ścieżki testów na czystym urządzeniu z nowym kontem, w sieci, której nie kontrolujesz, i wykonaj pięć kontroli. Decyzję podejmij dopiero potem.
Popraw Sign-in details, potem wyślij do sprawdzenia
Poprawka dostępuZaktualizuj instrukcje, podając dane logowania wielokrotnego użytku, które omijają kody jednorazowe, zapisz je, a potem wyślij zmianę do sprawdzenia z Publishing overview. Według Google możesz to zrobić bez kontaktowania się z zespołem pomocy ds. zasad i bez czekania na niego.
Dodaj użyteczność, nie tylko poprawki
PrzebudowaLimited Functionality and Content dotyczy tego, ile aplikacja robi. Zanim prześlesz ją ponownie, dodaj prawdziwe funkcje lub treści właściwe dla tej aplikacji; poprawka stabilności nie odpowiada na to ustalenie.
Uczyń zamysł oczywistym, potem zdecyduj
DoprecyzujNawet jeśli ekran offline, pusty stan lub nietypowy gest są zamierzone, weryfikator i tak może uznać je za błąd. Dodaj widoczną wskazówkę, wyjaśnienie i kolejny krok. Możesz odwołać się z dowodami, ale czytelniejszy ekran rozwiewa też wątpliwości kolejnego weryfikatora.
Odwołaj się z dowodami
OdwołaniePrzetestowałeś wersję ze sklepu na czystym urządzeniu i w innej sieci i nie znalazłeś żadnego problemu. Odwołaj się raz, podając kod wersji, urządzenie i wersję Androida, dokładne kroki oraz nagranie ekranu ze ścieżką wskazaną w powiadomieniu.
Ponowne przesłanie poprawionej wersji
Kroki ponownego przesłania według Google to coś więcej niż wgranie nowego kodu wersji:
- Przeczytaj zasadę wskazaną w e-mailu i w powiadomieniach, a także sprawdź aplikację pod kątem pozostałych zasad; Google ostrzega, że kolejne naruszenia mogą prowadzić do dalszych działań egzekucyjnych.
- Zaktualizuj każdy typ wersji zawierający wersję, której dotyczy decyzja, nie tylko wersję produkcyjną: również ścieżki testu otwartego, zamkniętego i wewnętrznego.
- Prześlij poprawiony pakiet aplikacji i dezaktywuj pakiety niezgodne z zasadami. Google ostrzega, że jeśli ich nie dezaktywujesz, ponowne przesłanie się nie powiedzie, a opublikowane wersje mogą zostać usunięte.
- Na każdej ścieżce, której to dotyczy, wybierz Manage track i Create new release, dodaj poprawiony pakiet (albo odrzuć wersję roboczą zawierającą pakiet naruszający zasady) i upewnij się, że niezgodna wersja jest na liście Not included.
- Zapisz, wybierz Review release i wdróż wersję.
Potem zmiana czeka na przetworzenie. Google mówi: „Przetwarzanie może potrwać kilka godzin lub do siedmiu dni (a w wyjątkowych przypadkach dłużej)” (Control when app changes are reviewed and published).
Poprawione, ale ostrzeżenie nadal jest widoczne
Jeśli poprawiona wersja jest opublikowana, a Policy status nadal pokazuje problem, porównaj kody wersji i ścieżki wskazane w ostrzeżeniu z tym, co jest teraz aktywne: niezgodny pakiet pozostawiony na ścieżce testów to pierwsza rzecz do wykluczenia. Nowsza wersja nie usuwa automatycznie każdego wpisu o egzekwowaniu zasad. Jeśli wszystko się zgadza, skontaktuj się z pomocą Play Console, podając kody wersji, ścieżki, których to dotyczy, i numer wcześniejszego zgłoszenia, jeśli go masz.
Odwołanie od decyzji
Google przywraca aplikacje, gdy popełniło błąd i stwierdzi, że aplikacja nie narusza jego zasad. Aby się odwołać, postępuj zgodnie z instrukcjami w e-mailu o egzekwowaniu zasad lub użyj formularza odwołania Google. Możesz złożyć jedno odwołanie na jedno działanie egzekucyjne (Managing policy violations and appeals), a Google odpowiada na odwołania po chińsku, angielsku, japońsku i koreańsku. Google nie publikuje czasu odpowiedzi na odwołania, a zgłoszenia deweloperów mieszają odpowiedzi na odwołania z późniejszymi weryfikacjami wersji, więc planuj bez konkretnej daty.
Napisz odwołanie jako zestaw dowodów, a nie wyraz frustracji: kod sprawdzanej wersji, urządzenie i wersja Androida, na których testowałeś, dokładne kroki, nagranie ekranu ze ścieżką wskazaną w powiadomieniu oraz to, co zmieniłeś, jeśli cokolwiek.
Czy odrzucenie za Broken Functionality szkodzi Twojemu kontu lub testowi zamkniętemu?
Samo odrzucenie nie wpływa na status Twojego konta dewelopera. Powtarzające się odrzucenia mogą prowadzić do zawieszenia, a zawieszenia liczą się jako ostrzeżenia (strikes), więc popraw aplikację, zanim prześlesz ją ponownie. To, co odrzucenie robi z trwającym testem zamkniętym, nie jest udokumentowane.
Strona Google Enforcement Process wyjaśnia tę różnicę:
- „Odrzucenia nie wpływają na status Twojego konta dewelopera Google Play”.
- „Jeśli aktualizacja istniejącej aplikacji została odrzucona, wersja aplikacji opublikowana przed aktualizacją pozostanie dostępna w Google Play”.
- „Zawieszenie może nastąpić w wyniku rażących lub wielokrotnych naruszeń zasad, a także powtarzających się odrzuceń lub usunięć aplikacji”.
Google nie publikuje liczby odrzuceń, która byłaby bezpieczna. Ponowne przesyłanie tego samego błędu to dokładnie wzorzec opisany w trzecim cytacie.
A co z 14-dniowym testem zamkniętym?
Wymagania dotyczące testowania Google oczekują od kont osobistych utworzonych po 13 listopada 2023 r. co najmniej 12 testerów nieprzerwanie uczestniczących w teście przez co najmniej 14 dni, zanim złożysz prośbę o dostęp do wersji produkcyjnej. Nie mówią, czy odrzucenie wersji na ścieżce testu zamkniętego za naruszenie zasad zeruje ten okres, wstrzymuje go czy zachowuje, a twierdzenia z forów w jedną lub drugą stronę to domysły. Co możesz sprawdzić: czy Twoi testerzy nadal mają zatwierdzoną wersję na ścieżce oraz co Panel pokazuje na temat dostępu do wersji produkcyjnej. Podczas poprawiania utrzymuj testerów w teście, a jeśli Panel się zmieni, zapytaj pomoc Play Console o swój przypadek. Samą zasadę wyjaśnia artykuł co oznacza 14 dni z rzędu.
Czy Google odrzuci aplikację WebView lub TWA jako niedziałającą?
Nie z powodu samej technologii. Google dokumentuje zarówno Trusted Web Activities, jak i WebView dla aplikacji na Androida, a żadna zasada nie zakazuje takiej architektury. Pytania brzmią: czy aplikacja działa, czy ma wystarczającą użyteczność i czy masz prawo opakować daną stronę internetową.
Nie zezwalamy na aplikacje, których głównym celem jest kierowanie ruchu partnerskiego do witryny lub udostępnianie widoku witryny w webview bez zgody jej właściciela lub administratora.
W przypadku aplikacji opartej na stronie internetowej kontrole Broken Functionality są takie same jak dla każdej innej aplikacji: strona musi wczytywać się w aplikacji po czystej instalacji, stany offline i błędów muszą się same wyjaśniać, a każdy link musi gdzieś prowadzić. Jeśli aplikacja jest głównie cienkim widokiem strony internetowej, większym ryzykiem jest sekcja Limited Functionality and Content. Nie wykazano, żeby samo przejście z TWA na WebView lub odwrotnie naprawiało odrzucenie.
Jak PrimeTestLab pomaga przed kolejną weryfikacją?
Nie możemy poprawić Twojego kodu ani zmienić decyzji Google. Dostarczamy stronę testową: prawdziwych ludzi na prawdziwych urządzeniach, którzy korzystają z Twojej aplikacji w ramach Twojego testu zamkniętego, dzięki czemu problemy takie jak opisane wyżej pojawiają się w ich opiniach, zanim znajdzie je weryfikator.
PrimeTestLab zapewnia 12 lub więcej prawdziwych testerów na prawdziwych urządzeniach z systemem od Androida 7 do 17, uczestniczących w teście przez pełne 14 dni, a testy startują w ciągu 4-6 godzin. Przeprowadziliśmy zarządzane testy dla 12 100+ aplikacji z testerami z 120+ krajów.
Testy na własną rękę czy testy zarządzane
| Zadanie | Samodzielnie | Z PrimeTestLab |
|---|---|---|
| Znalezienie testerów | SamodzielnieZnajomi, grupy i fora, zwykle z podobnymi telefonami | Z PrimeTestLabPrawdziwi testerzy na prawdziwych urządzeniach, przypisani do Twojej aplikacji |
| Różnorodność urządzeń i wersji Androida | SamodzielnieTo, co akurat mają Twoi ochotnicy | Z PrimeTestLabUrządzenia z Androidem od 7 do 17 |
| Codzienne używanie i opinie | SamodzielnieZależy od dobrej woli | Z PrimeTestLabTesterzy korzystają z aplikacji i zgłaszają, co nie działa |
| Utrzymanie 12 testerów w teście przez 14 dni | SamodzielnieSam gonisz tych, którzy odpadają | Z PrimeTestLabOsoby, które odpadną, są zastępowane, więc liczba się utrzymuje |
| Poprawienie kodu i reakcja na powiadomienie | SamodzielnieTy | Z PrimeTestLabNadal Ty; my przekazujemy, co znaleźli testerzy |
| Decyzja Google | SamodzielnieGoogle | Z PrimeTestLabNadal Google; nikt nie może obiecać zatwierdzenia |
Jeśli Google nie przyzna dostępu do wersji produkcyjnej po Twoim pełnym teście z PrimeTestLab, wybierasz bezpłatny ponowny test lub pełny zwrot pieniędzy; zobacz zasady zwrotów i bezpłatnych ponownych testów. Dotyczy to wymagań dotyczących testowania, a nie odrzucenia Twojego kodu za naruszenie zasad. Plany zaczynają się od $19.99 plus 5% opłaty serwisowej przy płatności (minimum $1.50), a jednorazowa opłata rejestracyjna Google w wysokości 25 USD jest osobna. Porównaj plany na stronie z cennikiem.
Najczęściej zadawane pytania
Czym jest zasada Broken Functionality w Google Play?
To sekcja zasady Google Play dotyczącej funkcjonalności, treści i wrażeń użytkownika (Functionality, Content, and User Experience). Google nie zezwala na aplikacje, które ulegają awariom, są wymuszenie zamykane, zawieszają się lub w inny sposób działają nieprawidłowo, a jako typowe naruszenia podaje aplikacje, które się nie instalują, aplikacje, które się instalują, ale nie wczytują, oraz aplikacje, które się wczytują, ale nie reagują.
Czy Broken Functionality to to samo co Minimum Functionality?
Nie. Minimum Functionality to starsza nazwa sekcji, którą Google nazywa teraz Limited Functionality and Content i która obejmuje aplikacje o zbyt małej użyteczności lub ilości treści. Broken Functionality obejmuje aplikacje, które w przesłanej postaci nie działają. Obie sekcje należą do tej samej zasady, ale wymagają różnych poprawek.
Gdzie dodać dane konta demonstracyjnego do weryfikacji w Google Play?
W Play Console przejdź do Policy and programs, potem App content, potem Sign-in details (dawniej App access). Wybierz Start lub Manage, dodaj instrukcje i zapisz je, a potem wyślij zmianę do sprawdzenia ze strony Publishing overview. Dane logowania powinny być wielokrotnego użytku i nie mogą zależeć od kodu jednorazowego wysyłanego na Twój telefon.
Czy odrzucenie liczy się jako ostrzeżenie dla mojego konta dewelopera?
Google mówi, że odrzucenia nie wpływają na status Twojego konta dewelopera. Zawieszenia liczą się jako ostrzeżenia (strikes), a Google wymienia powtarzające się odrzucenia lub usunięcia aplikacji wśród powodów zawieszenia, więc popraw wskazany problem, zanim prześlesz aplikację ponownie.
Ile trwa weryfikacja po ponownym przesłaniu poprawionej aplikacji?
Google mówi, że przetwarzanie zmian w aplikacji może potrwać kilka godzin lub do siedmiu dni, a w wyjątkowych przypadkach dłużej. Dotyczy to weryfikacji poprawionej wersji. Google nie publikuje czasu odpowiedzi na odwołania.
Czy mogę odwołać się od odrzucenia za Broken Functionality?
Tak, jeśli uważasz, że ustalenie jest błędne. Postępuj zgodnie z instrukcjami w e-mailu o egzekwowaniu zasad lub użyj formularza odwołania Google. Możesz złożyć jedno odwołanie na jedno działanie egzekucyjne, więc podaj kod sprawdzanej wersji, urządzenie i kroki, które testowałeś, oraz nagranie ścieżki wskazanej w powiadomieniu.
Czy odrzucenie za Broken Functionality zeruje mój 14-dniowy test zamknięty?
Google tego nie dokumentuje. Wymaganie to co najmniej 12 testerów nieprzerwanie uczestniczących w teście przez co najmniej 14 dni, zanim poprosisz o dostęp do wersji produkcyjnej. Podczas poprawiania wersji utrzymuj testerów w teście, obserwuj Panel i zapytaj pomoc Play Console, jeśli Twoja kwalifikacja się zmieni.
Dlaczego moja aplikacja została odrzucona, skoro działa na moim telefonie?
Twój telefon to jedna wersja, jedno konto, jeden zestaw danych i jedna sieć. Zainstaluj wersję dystrybuowaną przez Play na czystym urządzeniu z nowym kontem, a potem przetestuj puste treści i nieudane żądania sieciowe. Wersja ze sklepu podpisana kluczem podpisywania aplikacji może zawodzić tam, gdzie działa Twoja wersja debug, więc testuj tę wersję, którą zainstalował weryfikator.
Moja aplikacja korzysta z Google Sign-In lub kodu jednorazowego. Co przekazać weryfikatorom?
Google wymaga danych logowania, które są wielokrotnego użytku, działają z każdej lokalizacji i omijają hasła jednorazowe lub weryfikację dwuetapową. Przekaż weryfikatorom konto testowe i instrukcje, które pozwalają dotrzeć do każdej zablokowanej funkcji, także płatnych. Potem sam przetestuj dokładnie te dane, które podałeś; wyjaśnienie, jak zwykły użytkownik otrzymuje kod, nie jest działającym dostępem.
Google nie przysłało zrzutu ekranu ani logu awarii. Co teraz?
Sprawdź Policy status i e-mail o egzekwowaniu zasad pod kątem wersji, której dotyczy decyzja, oraz wszelkich szczegółów dodanych przez Google. Potem odtwórz główną ścieżkę użytkownika na przesłanej wersji i nagraj własne wideo oraz logi. Czysta strona Android vitals lub czysty raport przedpremierowy nie dowodzą, że każdy ekran i każde żądanie do backendu zadziałały u weryfikatora.
Czy aplikacje TWA i WebView są automatycznie odrzucane?
Nie. Google dokumentuje obie technologie i żadna zasada ich nie zakazuje. Google ogranicza natomiast aplikacje, które opakowują stronę internetową bez zgody jej właściciela, oraz aplikacje o zbyt małej funkcjonalności lub ilości treści. Zdiagnozuj faktyczny błąd, na przykład logowania, nawigacji lub sieci; przejście z jednego rodzaju opakowania na drugi nie jest udokumentowaną poprawką.
Podsumowanie
Podsumowanie
Odrzucenie za Broken Functionality mówi, że sprawdzana przez Google wersja nie działała: ulegała awarii, zawieszała się, nie wczytywała się lub nie reagowała. Sprawdź, na jaką zasadę powołuje się powiadomienie, odtwórz problem na wersji dystrybuowanej przez Play, upewnij się, że weryfikatorzy mogą się zalogować dzięki Sign-in details, przetestuj backend spoza swojej sieci i spraw, żeby każdy element sterujący i pusty ekran sam się wyjaśniał. Popraw każdą ścieżkę, której to dotyczy, i wyślij poprawioną wersję do sprawdzenia. Odwołuj się tylko z dowodami, że ustalenie było błędne. Samo odrzucenie nie jest ostrzeżeniem dla konta, ale powtarzające się ponowne przesyłanie bez poprawek może do niego doprowadzić.
Jeśli chcesz, żeby prawdziwi ludzie na prawdziwych urządzeniach znaleźli niedziałający ekran, zanim zrobi to kolejny weryfikator, PrimeTestLab zajmie się stroną testu zamkniętego, a Ty w tym czasie poprawisz aplikację.
Oficjalna dokumentacja Google
Co może się zmienić na tej stronie
- Etykiety w Play Console się zmieniają. Sign-in details jeszcze niedawno nazywało się App access, a niektóre przetłumaczone strony Pomocy wciąż używają starej nazwy.
- Treść powiadomień nie jest publikowana jako szablon i różni się w zależności od przypadku; ufaj swojemu e-mailowi i stronie Policy status bardziej niż jakiemukolwiek przykładowi z tej strony.
- Google nie dokumentuje, co odrzucenie za naruszenie zasad robi z trwającym testem zamkniętym. Jeśli opublikuje taką regułę, ta strona się do niej dostosuje.
Źródła sprawdzone: 16 października 2026 r..