Podgląd: Uprawnienia i interfejsy API z dostępem do informacji poufnych

Podgląd zasad

Ten artykuł przedpremierowy opisuje niedawno ogłoszone zmiany.

Aby zapewnić użytkownikom lepsze wrażenia, wprowadzamy nowe ograniczenia dotyczące korzystania z uprawnień USE_FULL_SCREEN_INTENT. W przypadku aplikacji kierowanych na Androida U (poziom API 34) i nowsze wersje zmieniamy te uprawnienia na uprawnienia aplikacji ze specjalnym dostępem. Domyślnie uprawnienia te będą przyznawane tylko tym aplikacjom, których główna funkcjonalność wymaga powiadomień pełnoekranowych. Pozostałe aplikacje będą musiały poprosić użytkownika o wyrażenie zgody. (zmiany obowiązujące od 31 maja 2024 roku)

Aby zapewnić użytkownikom większą prywatność, wprowadzamy zasady dotyczące uprawnień do zdjęć i filmów. Dzięki nim mniej aplikacji będzie mogło prosić o przyznanie szerokich uprawnień do zdjęć i filmów (READ_MEDIA_IMAGES i READ_MEDIA_VIDEO). Aplikacje mogą uzyskiwać dostęp do zdjęć i filmów wyłącznie w celach bezpośrednio związanych ze swoimi funkcjami. W przypadku aplikacji, które mają jednorazową lub rzadką potrzebę dostępu do tych plików, wymagane jest użycie selektora systemowego, takiego jak selektor zdjęć w Androidzie. (obowiązują od 31 sierpnia 2024 r.)

Aktualizujemy zasady dotyczące Health Connect, aby dostosować je do zasad dotyczących aplikacji do dbania o zdrowie i usprawnić proces składania wniosku związanego z Health Connect. Dotychczasowy wniosek oparty na formularzu zostanie w tym roku zastąpiony nową deklaracją w Konsoli Play. (obowiązują od 31 sierpnia 2024 r.)

Aktualną wersję artykułu „Uprawnienia i interfejsy API z dostępem do informacji poufnych” znajdziesz na tej stronie.

Prośby dotyczące uprawnień i interfejsów API z dostępem do informacji poufnych powinny być zrozumiałe dla użytkowników. Możesz prosić tylko o uprawnienia i stosowanie interfejsów API, które mają dostęp do danych poufnych, jeśli są konieczne do zaimplementowania bieżących funkcji lub usług wymienionych w informacjach o aplikacji w Google Play. Nie możesz używać uprawnień ani interfejsów API z dostępem do informacji poufnych, które przyznają dostęp do danych użytkownika lub urządzenia, na potrzeby funkcji lub działań, które są nieujawnione, niezaimplementowane albo niedozwolone. Nigdy nie wolno sprzedawać ani udostępniać w celu sprzedaży danych osobowych ani poufnych, do których dostęp jest uzyskiwany po udzieleniu uprawnień lub przez interfejs API z dostępem do informacji poufnych.

Prośby o uprawnienia i dostęp API do danych poufnych wyświetlaj w odpowiednim kontekście (stosując żądania stopniowe). Dzięki temu użytkownicy będą rozumieć, do czego aplikacja potrzebuje konkretnych danych. Dane można wykorzystywać wyłącznie w celach, na które użytkownik wyraził zgodę. Jeśli chcesz użyć danych w innych celach, zapytaj użytkowników, czy zgadzają się na dodatkowe sposoby korzystania z danych, i uzyskaj od nich taką zgodę.

Uprawnienia z ograniczeniami

W uzupełnieniu wymienionych tu zasad – uprawnienia z ograniczeniami to takie, które są określane jako niebezpieczne, szczególne lub wymagające podpisu albo są zgodne z poniższym opisem. Podlegają one tym dodatkowym wymaganiom i ograniczeniom:

  • Dane dotyczące użytkowników lub urządzeń, do których dostęp uzyskuje się na podstawie uprawnień z ograniczeniami, są uznawane za dane osobowe i poufne użytkowników. W takim przypadku obowiązują zasady dotyczące danych użytkownika.
  • Jeśli użytkownik odrzuci prośbę o przyznanie uprawnienia z ograniczeniami, musisz uszanować jego decyzję. Nie wolno fałszywie nakłaniać ani zmuszać użytkowników do przyznawania uprawnień, które nie mają krytycznego znaczenia. Musisz podjąć uzasadnione działania, by dostosować funkcjonowanie aplikacji do użytkowników, którzy nie przyznali dostępu do uprawnień newralgicznych (np. umożliwiając ręczne wpisanie numeru telefonu użytkownikowi, który ograniczył dostęp aplikacji do rejestrów połączeń).
  • Zabronione jest korzystanie z uprawnień w sposób niezgodny z zasadami Google Play dotyczącymi złośliwego oprogramowania (w tym nadużywanie podwyższonych uprawnień).

Niektóre uprawnienia z ograniczeniami są objęte dodatkowymi wymaganiami (szczegóły znajdują się poniżej). Takie ograniczenia mają chronić prywatność użytkownika. W bardzo rzadkich przypadkach możemy zgodzić się na odstępstwa od podanych poniżej wymagań, gdy aplikacja oferuje funkcje, które są bardzo atrakcyjne lub mają znaczenie krytyczne, i nie można ich zapewnić w inny sposób. Takie wyjątki rozważamy, biorąc pod uwagę potencjalne zagrożenia dla prywatności i bezpieczeństwa użytkowników.

Uprawnienia dostępu do SMS-ów i rejestru połączeń

Uprawnienia dostępu do SMS-ów i rejestru połączeń są traktowane jako osobowe i poufne dane użytkownika. Podlegają zasadom opisanym w sekcji Dane osobowe i poufne oraz tym ograniczeniom:

Uprawnienia z ograniczeniami Wymaganie
Grupa uprawnień Rejestr połączeń (np. READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS) Musi być aktywnie zarejestrowana jako domyślna aplikacja telefonu lub pomocnicza na urządzeniu.
Grupa uprawnień SMS (np. READ_SMS, SEND_SMS, WRITE_SMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, RECEIVE_MMS) Musi być aktywnie zarejestrowana jako domyślna aplikacja do obsługi SMS-ów lub Asystenta na urządzeniu.

 

Aplikacje, których nie można ustawić jako domyślnej aplikacji do obsługi SMS-ów, telefonu lub Asystenta, nie mogą deklarować korzystania z powyższych uprawnień w manifeście. Obejmuje to tekst zastępczy w manifeście. Poza tym, zanim aplikacja wyświetli użytkownikowi prośbę o zaakceptowanie dowolnego z powyższych uprawnień, musi być aktywnie zarejestrowana jako domyślna aplikacja do obsługi SMS-ów, telefonu lub Asystenta. Musi też niezwłocznie przestać korzystać z danego uprawnienia, gdy straci status domyślnej aplikacji do obsługi. Dozwolone przypadki użycia i wyjątki są opisane na tej stronie w Centrum pomocy.

Aplikacja może korzystać z uprawnienia (i dowolnych danych uzyskanych na jego podstawie) wyłącznie do udostępniania swoich zatwierdzonych, kluczowych funkcji. Kluczowa funkcja to podstawowe przeznaczenie aplikacji. Może to być zestaw podstawowych funkcji, z których każda musi być w widoczny sposób udokumentowana i wskazana w opisie aplikacji. Aplikacja bez kluczowych funkcji jest uważana za „zepsutą”, czyli bezużyteczną. Przesyłanie, udostępnianie lub licencjonowane użycie tych danych może odbywać się wyłącznie w związku z zapewnianiem działania kluczowych funkcji i usług aplikacji. Nie wolno używać tych danych do innych celów (np. usprawniania innych aplikacji lub usług bądź w celach marketingowych). Do odczytywania danych uzyskiwanych na podstawie uprawnień dostępu do rejestru połączeń lub SMS-ów nie wolno używać alternatywnych rozwiązań (w tym innych uprawnień, interfejsów API ani zewnętrznych źródeł danych).

 

Dostęp do lokalizacji

Lokalizacja urządzenia uznawana jest za dane osobowe i poufne użytkownika podlegające zasadom dotyczącym danych osobowych i informacji poufnych, zasadom dotyczącym lokalizacji w tle oraz tym wymogom:

  • Aplikacja nie może korzystać z danych wymagających dostępu do lokalizacji (np. ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION czy ACCESS_BACKGROUND_LOCATION), które nie są już konieczne do udostępniania bieżących funkcji lub usług aplikacji.
  • Aplikacja nie powinna nigdy prosić użytkowników o dostęp do lokalizacji, jeśli ma to służyć tylko do wyświetlania reklam lub analizy danych. Aplikacje, w których dozwolone użycie tych danych jest poszerzone o wyświetlanie reklam, muszą być zgodne z naszymi zasadami dotyczącymi reklam.
  • Aplikacje powinny prosić o przyznanie dostępu na najniższym poziomie (np. do przybliżonej lokalizacji zamiast dokładnej, na pierwszym planie zamiast w tle) niezbędnym do zapewnienia działania funkcji lub usługi, która wymaga danych o lokalizacji. Użytkownicy powinni spodziewać się, że ta funkcja lub usługa potrzebuje żądanego poziomu dostępu do lokalizacji. Możemy odrzucić aplikacje, które proszą o dostęp do lokalizacji w tle lub z niej korzystają bez wystarczającego uzasadnienia.
  • Lokalizacji w tle można używać wyłącznie do udostępniania użytkownikowi funkcji przynoszących mu korzyści i ściśle związanych z podstawowym przeznaczeniem aplikacji.

Aplikacja może korzystać z dostępu do lokalizacji jako usługa działająca na pierwszym planie (gdy aplikacja ma dostęp tylko na pierwszym planie, np. „podczas używania”), jeśli takie użycie:

  • jest kontynuacją wywołanego przez użytkownika działania w aplikacji,
  • zostaje zakończone natychmiast po prawidłowym wykonaniu przez aplikację działania wywołanego przez użytkownika.

Aplikacje przeznaczone dla dzieci muszą być zgodne z zasadami programu Dla całej rodziny.

Więcej informacji o wymaganiach wynikających z tych zasad znajdziesz w tym artykule pomocy.

 

Uprawnienia dostępu do wszystkich plików

Atrybuty plików i katalogów na urządzeniu użytkownika są traktowane jako osobowe i poufne dane użytkownika. Podlegają zasadom opisanym w sekcji Dane osobowe i poufne oraz tym ograniczeniom:

  • Aplikacje powinny prosić o dostęp do pamięci urządzenia, jeśli jest on niezbędny do działania aplikacji, i nie mogą prosić o dostęp do pamięci urządzenia w imieniu osób trzecich w żadnym celu niezwiązanym z niezbędnymi, widocznymi dla użytkownika funkcjami aplikacji.
  • Urządzenia z Androidem w wersji R lub nowszej wymagają uprawnień MANAGE_EXTERNAL_STORAGE, by zarządzać dostępem w pamięci współdzielonej. Wszystkie aplikacje kierowane na Androida R i żądające szerokiego dostępu do pamięci współdzielonej („Dostęp do wszystkich plików”) muszą przed opublikowaniem pomyślnie przejść odpowiednią kontrolę dostępu. Aplikacje, które mogą korzystać z tych uprawnień, muszą wyraźnie informować użytkowników o włączeniu opcji „Dostęp do wszystkich plików” w ustawieniach „Aplikacje ze specjalnym dostępem”. Więcej informacji o wymaganiach dotyczących Androida R znajdziesz w tym artykule w Centrum pomocy.

 

Uprawnienia do zdjęć i filmów

Zdjęcia i filmy na urządzeniu użytkownika są traktowane jako dane osobowe i wrażliwe podlegające zasadom dotyczącym danych użytkownika w Google Play. Aplikacje mogą uzyskiwać dostęp do zdjęć i filmów wyłącznie w celach bezpośrednio związanych z funkcjami aplikacji. Nie mogą prosić o dostęp w imieniu osób trzecich w żadnym celu niezwiązanym z funkcjami aplikacji dla użytkownika. Aby zapewnić większą ochronę prywatności, zachęcamy do korzystania z selektora systemowego, takiego jak selektor zdjęć.

Aplikacje wymagające szerokiego dostępu do zdjęć i plików wideo znajdujących się w pamięci współdzielonej na urządzeniach muszą przejść odpowiednią kontrolę dostępu i wykazać główny przypadek użycia, który wymaga stałego lub częstego dostępu do zdjęć / plików wideo znajdujących się w pamięci współdzielonej. W przypadku aplikacji, które mają jednorazową lub rzadką potrzebę dostępu do tych plików, wymagane jest użycie selektora systemowego, takiego jak selektor zdjęć na Androidzie.

Szeroki dostęp do zdjęć i filmów podlega też tym wymaganiom:

  • Aplikacje kierowane na Androida 13 (poziom API 33) lub nowszego potrzebują uprawnienia READ_MEDIA_IMAGES lub READ_MEDIA_VIDEO, aby uzyskać szeroki dostęp do plików ze zdjęciami i filmami przechowywanych w pamięci współdzielonej na urządzeniu. Wszystkie aplikacje, które są kierowane na Androida 13 lub nowszego i proszą o uprawnienia READ_MEDIA_IMAGES lub READ_MEDIA_VIDEO, muszą przejść odpowiednią kontrolę praw dostępu przed publikacją.
    • Aplikacje, które proszą o dostęp do uprawnienia READ_MEDIA_VIDEO lub READ_MEDIA_IMAGES, muszą wykazać, że ich główne zastosowanie wymaga ciągłego lub częstego dostępu do zdjęć/filmów znajdujących się w pamięci współdzielonej.

Jeśli Twoja aplikacja nie wymaga szerokiego dostępu do uprawnień READ_MEDIA_VIDEO lub READ_MEDIA_IMAGES albo nie kwalifikuje się do skorzystania z nich, musisz usunąć te uprawnienia z pliku manifestu aplikacji, aby spełnić wymagania dotyczące weryfikacji zgodności z zasadami.

Zgodnie z zasadami dotyczącymi uprawnień z ograniczeniami należy dołożyć wszelkich starań, aby uwzględnić użytkowników, którzy nie przyznają szerokiego dostępu do plików multimedialnych na swoich urządzeniach. Dotyczy to dalszego umożliwiania korzystania z funkcji lub głównej funkcjonalności aplikacji.

Aplikacje, w przypadku których dostęp do zdjęć lub filmów jest uzasadniony, ale które nie kwalifikują się do otrzymania uprawnienia READ_MEDIA_IMAGES ani READ_MEDIA_VIDEO, mogą korzystać z selektora systemowego, takiego jak selektor zdjęć. Więcej informacji znajdziesz w tym artykule w Centrum pomocy.

 

Uprawnienia do wyświetlania pakietów (aplikacji)

Lista zainstalowanych aplikacji pobierana z urządzenia jest traktowana jako osobowe i poufne dane użytkownika. Podlega ona zasadom dotyczącym danych osobowych i poufnych oraz tym ograniczeniom:

Aplikacje, których podstawowym celem jest uruchamianie innych aplikacji zainstalowanych na urządzeniu, wyszukiwanie ich i współdziałanie z nimi, mogą mieć wgląd w inne aplikacje na tych zasadach:

  • Duża widoczność aplikacji: aplikacja ma szeroki wgląd w zainstalowane aplikacje („pakiety”) na urządzeniu.
    • W przypadku aplikacji używających interfejsu API na poziomie 30 lub nowszym duża widoczność zainstalowanych aplikacji oparta na uprawnieniu QUERY_ALL_PACKAGES jest ograniczona do konkretnych przypadków użycia – gdy aplikacja wymaga do działania informacji o aplikacjach lub współdziałania z niektórymi lub wszystkimi aplikacjami na urządzeniu.
      • Nie możesz używać uprawnienia QUERY_ALL_PACKAGES, jeśli aplikacja może działać z bardziej szczegółową deklaracją widoczności pakietów, np. gdy wyszukuje określone pakiety i wchodzi z nimi w interakcje, zamiast wysyłać prośby o dużą widoczność.
    • Możliwość korzystania z alternatywnych metod szacowania dużej widoczności powiązanej z uprawnieniem QUERY_ALL_PACKAGES również jest ograniczona do podstawowych funkcji aplikacji dostępnych dla użytkowników i współdziałania z aplikacjami wykrytymi za pomocą tej metody.
    • Dozwolone przypadki użycia uprawnienia QUERY_ALL_PACKAGES znajdziesz w tym artykule w Centrum pomocy.
  • Ograniczona widoczność aplikacji: aplikacja maksymalnie ogranicza dostęp do danych, wyszukując określone aplikacje za pomocą bardziej precyzyjnych metod (np. wysyła zapytania dotyczące konkretnych aplikacji, które spełniają wymagania deklaracji w pliku manifestu). Tej metody możesz używać do wysyłania zapytań dotyczących aplikacji, gdy Twoja aplikacja współdziała z tymi aplikacjami lub nimi zarządza zgodnie z zasadami. 
  • Widoczność zasobów reklamowych aplikacji zainstalowanych na urządzeniu musi być bezpośrednio związana z głównym przeznaczeniem lub podstawową funkcją, z której korzystają ich użytkownicy. 

Dane o zasobach aplikacji rozpowszechnianych w Google Play nie mogą być sprzedawane ani udostępniane na potrzeby analityki i zarabiania na reklamach.

 

Accessibility API

Za pomocą interfejsu Accessibility API nie można:

  • zmieniać ustawień użytkownika bez jego zgody ani uniemożliwiać użytkownikowi wyłączenia lub odinstalowania jakiejkolwiek aplikacji bądź usługi, chyba że za zgodą rodzica lub opiekuna wyrażonej w aplikacji do kontroli rodzicielskiej lub za zgodą upoważnionego administratora w ramach oprogramowania do zarządzania w firmach;
  • obchodzić wbudowanych w Androida ustawień prywatności ani powiadomień;
  • zmieniać ani wykorzystywać interfejsu w sposób, który wprowadza w błąd lub narusza zasady dla deweloperów w Google Play.

Interfejs Accessibility API nie służy do zdalnego nagrywania dźwięku połączeń i nie może być do tego używany.

Korzystanie z interfejsu Accessibility API musi być udokumentowane w informacjach o aplikacji w Google Play.

Wytyczne dotyczące atrybutu IsAccessibilityTool

Aplikacje, których podstawowym przeznaczeniem jest bezpośrednie wspieranie osób z niepełnosprawnościami, mogą za pomocą atrybutu IsAccessibilityTool publicznie zaznaczyć, że są aplikacjami ułatwień dostępu.

Aplikacje, które nie kwalifikują się do korzystania z atrybutu IsAccessibilityTool, nie mogą używać tej flagi. Muszą też spełniać wymagania w zakresie wyraźnego informowania i uzyskiwania zgody na gromadzenie informacji, jak opisano w zasadach dotyczących danych użytkownika, ponieważ ich funkcje związane z ułatwieniami dostępu nie są oczywiste dla odbiorcy. Więcej informacji znajdziesz w Centrum pomocy, w artykule dotyczącym interfejsu AccessibilityService API.

Gdy to możliwe, zamiast interfejsu Accessibility API aplikacje muszą korzystać z bardziej ograniczonych uprawnień i interfejsów API, aby zapewnić oczekiwane działanie.

 

Prośba o uprawnienia do instalowania pakietów

Uprawnienie REQUEST_INSTALL_PACKAGES umożliwia aplikacji żądanie zainstalowania jej pakietów. Aby aplikacja mogła z niego skorzystać, jej główna funkcjonalność musi obejmować:

  • wysyłanie lub odbieranie pakietów aplikacji,
  • umożliwianie instalowania przez użytkownika pakietów aplikacji.

Dozwolone funkcje to:

  • przeglądanie stron lub wyszukiwanie w internecie;
  • usługi komunikacyjne, które obsługują załączniki;
  • udostępnianie lub transfer plików albo zarządzanie nimi;
  • zarządzanie urządzeniami firmowymi;
  • tworzenie i przywracanie kopii zapasowej;
  • migracja danych z urządzenia / przenoszenie danych z telefonu;
  • w przypadku aplikacji towarzyszących – synchronizowanie telefonu z urządzeniem do noszenia lub urządzeniem IoT (np. zegarkiem smartwatch lub telewizorem smart TV).

Główna funkcjonalność to ogólne przeznaczenie aplikacji. Główna funkcjonalność, a także wszelkie ważne funkcje, które się na nią składają, muszą być w widoczny sposób udokumentowane i umieszczone w opisie aplikacji.

Uprawnienie REQUEST_INSTALL_PACKAGES nie może być wykorzystywane do przeprowadzania samoaktualizacji, wprowadzania modyfikacji ani do łączenia w pakiety innych plików APK w pliku zasobów w celach innych niż zarządzanie urządzeniem. Wszystkie aktualizacje i instalacje pakietów muszą być zgodne z zasadami Google Play dotyczącymi nadużywania urządzeń lub sieci, a także muszą być inicjowane przez użytkownika.

 

Uprawnienia Health Connect by Android

Health Connect to platforma Androida, która umożliwia aplikacjom do dbania o zdrowie i kondycję przechowywanie oraz udostępnianie danych na urządzeniu w ramach ujednoliconego ekosystemu. Pozwala też użytkownikom kontrolować w 1 miejscu, które aplikacje mogą odczytywać i zapisywać dane dotyczące ich zdrowia i aktywności fizycznej. Health Connect obsługuje odczytywanie i zapisywanie różnych typów danych, od liczby kroków po temperaturę ciała.

Dane, do których deweloperzy mają dostęp dzięki uprawnieniom do Health Connect, są uznawane za osobowe i poufne dane użytkownika podlegające zasadom dotyczącym takich danych. Jeśli Twoja aplikacja jest uznawana za aplikację związaną ze zdrowiem lub ma takie funkcje i uzyskuje dostęp do danych dotyczących zdrowia, w tym danych z Health Connect, musi być zgodna z zasadami aplikacji związanych ze zdrowiem.

Informacje o pierwszych krokach w Health Connect można znaleźć w tym przewodniku dla programistów aplikacji na Androida. Jeśli chcesz poprosić o dostęp do typów danych z Health Connect, zapoznaj się z tym artykułem.

Aby odczytywać lub zapisywać dane w Health Connect, aplikacje rozpowszechniane w Google Play muszą spełniać te wymagania.

Uzyskiwanie dostępu do danych Health Connect i korzystanie z nich w odpowiedni sposób

Z Health Connect można korzystać tylko zgodnie z odpowiednimi zasadami i Warunkami korzystania z usługi oraz tylko w zatwierdzonych przypadkach użycia określonych w tych zasadach. Oznacza to, że można prosić o uprawnienia tylko wtedy, gdy aplikacja lub usługa jest zgodna z jednym z zatwierdzonych przypadków użycia.

Zatwierdzone przypadki użycia obejmują fitness i dbanie o zdrowie, nagrody, treningi fitness, programy fitness dla firm, opiekę medyczną, badania medyczne oraz gry. Aplikacje, którym przyznano dostęp do tych uprawnień, nie mogą rozszerzać ich wykorzystania na nieujawnione lub niedozwolone cele.

O dostęp do uprawnień Health Connect mogą ubiegać się wyłącznie aplikacje lub usługi z co najmniej 1 funkcją, której głównym celem jest poprawa stanu zdrowia i kondycji użytkowników. Należą do nich:

  • aplikacje lub usługi umożliwiające użytkownikom bezpośrednie rejestrowanie, raportowanie, monitorowanie lub analizowanie danych o aktywności fizycznej, śnie, stanie psychicznym lub odżywianiu, pomiarów parametrów zdrowotnych, opisów fizycznych bądź innych opisów i pomiarów związanych ze zdrowiem lub aktywnością fizyczną;
  • aplikacje lub usługi umożliwiające użytkownikom przechowywanie na urządzeniu do noszenia lub telefonie danych o aktywności fizycznej, śnie, stanie psychicznym lub odżywianiu, pomiarów parametrów zdrowotnych, opisów fizycznych bądź innych opisów i pomiarów związanych ze zdrowiem lub aktywnością fizyczną, a także udostępnianie tych danych innych aplikacjom na urządzeniu, które spełniają wymogi dopuszczonych przypadków użycia.

Dostęp do Health Connect nie może być realizowany w sprzeczności z tymi zasadami lub jakimikolwiek innymi obowiązującymi przepisami lub Warunkami korzystania z Health Connect. Obejmuje to te cele:

  • Nie wolno używać Health Connect do tworzenia aplikacji, środowisk lub aktywności (ani jako dodatku do nich), jeśli istnieje uzasadnione ryzyko, że wykorzystanie danych z Health Connect lub wadliwe działanie tej platformy może doprowadzić do śmierci, obrażeń, szkód środowiskowych lub zniszczenia mienia (na przykład na potrzeby konstruowania i eksploatowania zakładów jądrowych, systemów kierowania ruchem lotniczym, systemów podtrzymywania życia czy uzbrojenia).
  • Nie wolno uzyskiwać dostępu do danych zebranych przez Health Connect za pomocą aplikacji bez interfejsu graficznego. Aplikacje muszą wyświetlać łatwo rozpoznawalną ikonę w panelu aplikacji, ustawieniach aplikacji na urządzeniu, ikonach powiadomień itp.
  • Nie wolno używać Health Connect z aplikacjami, które synchronizują dane między niezgodnymi urządzeniami lub platformami.
  • Nie wolno używać Health Connect do łączenia się z aplikacjami, usługami lub funkcjami skierowanymi wyłącznie do dzieci.
  • Deweloper musi podjąć wszelkie odpowiednie kroki w celu zabezpieczenia wszystkich aplikacji lub systemów korzystających z Health Connect przed nieautoryzowanym lub bezprawnym dostępem, użyciem, zniszczeniem, utratą, zmianą lub ujawnieniem danych.

Deweloper odpowiada także za zapewnienie zgodności z wszelkimi przepisami i wymaganiami prawnymi, które mogą obowiązywać w przypadku zamierzonego wykorzystania Health Connect oraz wszelkich danych z tej platformy. Z wyjątkiem informacji jednoznacznie podanych na oznaczeniach lub w opisach konkretnych usług Google, Google nie promuje ani nie gwarantuje poprawności żadnych danych przechowywanych w Health Connect, a także nie gwarantuje ich użyteczności w żadnym celu, zwłaszcza w kontekście badań, zdrowia lub medycyny. Google w pełni wyłącza swoją odpowiedzialność za korzystanie z danych uzyskanych przez Health Connect.

Ograniczone użytkowanie

Podczas korzystania z Health Connect dostęp do danych i ich wykorzystanie muszą podlegać określonym ograniczeniom:

  • Wykorzystanie danych powinno być ograniczone do zapewniania lub ulepszania odpowiedniego przypadku użycia bądź funkcji widocznych w interfejsie aplikacji.
  • Dane użytkownika mogą być przekazywane osobom trzecim wyłącznie za wyraźną zgodą użytkownika: w celach bezpieczeństwa (np. do badania nadużyć), w celu zachowania zgodności z obowiązującymi przepisami i rozporządzeniami lub w ramach fuzji bądź przejęć.
  • Dostęp człowieka do danych użytkownika musi być ograniczony, chyba że uzyskano wyraźną zgodę użytkownika, do celów związanych z bezpieczeństwem lub zachowaniem zgodności z przepisami bądź gdy dane są agregowane na potrzeby operacji wewnętrznych zgodnie z wymaganiami prawnymi.
  • Wszelkie inne przypadki przekazywania, wykorzystywania lub sprzedawania danych z Health Connect są zabronione. Ten zakaz obejmuje:
    • przekazywanie lub sprzedawanie danych użytkownika osobom trzecim, na przykład platformom reklamowym, brokerom danych czy jakimkolwiek innym podmiotom zajmującym się handlem danymi;
    • przekazywanie, sprzedawanie lub wykorzystywanie danych użytkownika do wyświetlania reklam, w tym reklam spersonalizowanych i opartych na zainteresowaniach;
    • przekazywanie, sprzedawanie lub wykorzystywanie danych użytkownika do określenia zdolności kredytowej lub na inne potrzeby związane z udzielaniem pożyczek;
    • przekazywanie, sprzedawanie lub wykorzystywanie danych użytkownika na potrzeby innego produktu lub usługi, które mogą kwalifikować się jako urządzenie medyczne według definicji w artykule 201(h) Federalnej ustawy o żywności, lekach i kosmetykach (Federal Food Drug & Cosmetic Act), jeśli dane użytkownika będą używane przez urządzenie medyczne do wykonywania jego przewidzianej prawnie funkcji;
    • przekazywanie, sprzedawanie lub wykorzystywanie danych użytkownika do jakiegokolwiek celu lub w jakikolwiek sposób związany z chronionymi informacjami zdrowotnymi (PHI, zgodnie z definicją HIPAA), chyba że deweloper otrzyma wcześniej od Google pisemną zgodę na takie użycie.

Dane w minimalnym zakresie

Możesz prosić o dostęp tylko do tych uprawnień, które są niezbędne do realizowania funkcji lub usług zawartych w Twoim produkcie. Prośby te muszą być precyzyjne i ograniczone tylko do faktycznie potrzebnych danych.

Przejrzyste i precyzyjne metody powiadamiania i kontroli

Health Connect zarządza danymi o stanie zdrowia i kondycji, w tym informacjami poufnymi, i wymaga, aby wszystkie aplikacje posiadały kompleksową politykę prywatności. Polityka prywatności musi w przejrzysty sposób wskazywać, w jaki sposób aplikacja gromadzi, wykorzystuje i udostępnia dane użytkowników. Poza informacjami wymaganymi prawnie deweloperzy muszą umieścić w polityce prywatności także:

  • dokładne przedstawienie tożsamości aplikacji ze wskazaniem danych, do których uzyskuje ona dostęp, i ich związku z najważniejszymi funkcjami aplikacji lub rekomendacjami;
  • praktyki z zakresu przechowywania i usuwania danych;
  • procedury obsługi danych, jak przesyłanie ich przy użyciu nowoczesnych metod kryptograficznych (np. protokołu HTTPS).

Więcej informacji na temat wymagań wobec aplikacji łączących się z Health Connect znajdziesz w tym artykule w Centrum pomocy.

 

Usługa VPN

VpnService to klasa bazowa, która umożliwia Twoim aplikacjom rozszerzanie i tworzenie własnych rozwiązań VPN. Tylko aplikacje używające VpnService i mające VPN jako główną funkcję mogą tworzyć na poziomie urządzenia bezpieczne tunele do serwera zdalnego. Do wyjątków należą aplikacje, które wymagają serwera zdalnego do obsługi swoich głównych funkcji, na przykład:

  • aplikacje do kontroli rodzicielskiej iaplikacje do zarządzania;
  • śledzenie użytkowania aplikacji;
  • aplikacje zabezpieczające urządzenie (np. antywirusy, aplikacje do zarządzania urządzeniami mobilnymi, zapory sieciowe);
  • narzędzia związane z;siecią (na przykład do dostępu zdalnego);
  • aplikacje do przeglądania internetu;
  • aplikacje operatora, które wymagają sieci VPN, aby umożliwić dostęp do usług telefonicznych lub komunikacyjnych.

Klasy VpnService nie można używać do:

  • zbierania danych osobowych i wrażliwych użytkowników bez podania dobrze widocznej informacji i uzyskania zgody;
  • przekierowywania lub modyfikowania ruchu użytkowników z innych aplikacji na urządzeniu na potrzeby generowania przychodu (na przykład przekierowywania ruchu z reklam przez kraj inny niż kraj użytkownika);

Aplikacje używające klasy VpnService muszą:

 

Uprawnienie dostępu do precyzyjnych alarmów

Wprowadzimy nowe uprawnienie USE_EXACT_ALARM, które będzie dawało dostęp do funkcji precyzyjnego alarmu w aplikacjach na Androidzie w wersji od 13 wzwyż (docelowy poziom API 33).

USE_EXACT_ALARM to uprawnienie z ograniczonym dostępem, które aplikacje mogą deklarować wyłącznie wtedy, gdy ich główna funkcja wymaga precyzyjnego alarmu. Aplikacje, które proszą o to uprawnienie, są weryfikowane, a te, które nie spełniają kryteriów dopuszczalnego użytkowania, nie mogą być publikowane w Google Play.

Zasady dopuszczalnego użytkowania uprawnienia dostępu do precyzyjnych alarmów

Aplikacja może używać uprawnienia USE_EXACT_ALARM tylko wtedy, gdy jej główna, widoczna dla użytkowników funkcja wymaga wykonywania działań w precyzyjnym czasie. Na przykład:

  • Aplikacja to budzik lub stoper.
  • Aplikacja to kalendarz, który wyświetla powiadomienia o wydarzeniach.

Jeśli Twój przypadek użycia funkcji precyzyjnego alarmu nie został opisany powyżej, zastanów się, czy nie można w tym przypadku użyć uprawnienia SCHEDULE_EXACT_ALARM.

Więcej informacji o funkcji precyzyjnego alarmu znajdziesz w tym przewodniku dla deweloperów.

 

Uprawnienia do intencji pełnoekranowej

W przypadku aplikacji kierowanych na Androida 14 (interfejs API na poziomie 34) i nowsze wersje USE_FULL_SCREEN_INTENT to specjalne uprawnienie dostępu aplikacji. Aplikacje automatycznie otrzymują uprawnienie USE_FULL_SCREEN_INTENT tylko wtedy, gdy ich główna funkcjonalność należy do jednej z tych kategorii wymagających powiadomień o wysokim priorytecie:

  • ustawianie alarmu,
  • odbieranie rozmów telefonicznych lub wideo.

Aplikacje, które wymagają tego uprawnienia, są weryfikowane, a te, które nie spełniają tych kryteriów, nie otrzymują tego uprawnienia automatycznie. W takim przypadku trzeba poprosić użytkownika o zezwolenie na korzystania z uprawnienia USE_FULL_SCREEN_INTENT.

Przypominamy, że każde skorzystanie z uprawnienia USE_FULL_SCREEN_INTENT musi być zgodne ze wszystkimi Zasadami dla deweloperów w Google Play, w tym z zasadami dotyczącymi niechcianego oprogramowania mobilnego, nadużywania urządzenia lub sieci i reklam. Powiadomienia intencji pełnoekranowej nie mogą ingerować w urządzenie użytkownika, zakłócać jego działania, uszkadzać go ani uzyskiwać do niego dostępu w nieautoryzowany sposób. Aplikacje nie mogą też zakłócać działania urządzenia ani innych aplikacji.

Więcej informacji na temat uprawnienia USE_FULL_SCREEN_INTENT znajdziesz w naszym Centrum pomocy.

Czy to było pomocne?

Jak możemy ją poprawić?

Potrzebujesz dodatkowej pomocy?

Wykonaj te czynności:

Szukaj
Wyczyść wyszukiwanie
Zamknij wyszukiwanie
Menu główne
5557777314272924726
true
Wyszukaj w Centrum pomocy
true
true
true
true
true
92637
false
false