Voorbeeld: Apparaat- en netwerkmisbruik

Preview van het beleid (ingangsdatum: 31 mei 2024)

Dit artikel bevat wijzigingen uit onze beleidsupdates van oktober 2023.

We voegen een nieuw voorbeeld toe aan ons Beleid tegen misbruik van apparaten en netwerken om aan te geven dat we niet toestaan dat apps het recht voor intentie op volledig scherm gebruiken om interactie van gebruikers af te dwingen via storende advertenties of meldingen.

Ga naar deze pagina voor het huidige artikel Apparaat- en netwerkmisbruik.

We staan geen apps toe die het apparaat van de gebruiker, andere apparaten of computers, servers, netwerken, Application Programming Interfaces (API's) of services, met inbegrip van, maar niet beperkt tot andere apps op het apparaat, een Google-service of het netwerk van een erkende provider, verstoren, onderbreken, beschadigen of daartoe op onbevoegde wijze toegang verkrijgen.

Apps op Google Play moeten voldoen aan de standaardvereisten voor systeemoptimalisatie van Android die zijn vastgelegd in de richtlijnen voor core app-kwaliteit (Core App Quality Guidelines) voor Google Play.

Een app die wordt gedistribueerd via Google Play, mag zichzelf niet aanpassen, vervangen of updaten via een andere methode dan het updatemechanisme van Google Play. Ook mag een app geen uitvoerbare code (zoals dex-, jar- of so-bestanden) downloaden via een andere bron dan Google Play. Deze beperking geldt niet voor code die wordt uitgevoerd op een virtuele machine of een interpreter die indirecte toegang biedt tot Android-API's (zoals JavaScript in een WebView of browser).

Apps of code van derden (zoals SDK's) met geïnterpreteerde talen (JavaScript, Python, Lua, enzovoort) die tijdens de runtime zijn geladen (bijv. niet verpakt bij de app), mogen geen potentiële schendingen van het Google Play-beleid toestaan.

We staan geen code toe die kwetsbaarheden in de beveiliging introduceert of misbruikt. Raadpleeg het Programma voor de verbetering van de beveiliging van apps voor meer informatie over de meest recente beveiligingsproblemen die zijn gemarkeerd voor ontwikkelaars.

Voorbeelden van veelvoorkomende schendingen van het Beleid tegen misbruik van apparaten en netwerken:

• Apps die de advertentieweergave in een andere app verstoren of blokkeren.
• Cheat-apps die de gameplay van andere apps beïnvloeden.
• Apps met instructies voor het hacken van services, software of hardware, of die beveiligingsmaatregelen omzeilen.
• Apps die toegang krijgen tot een service of API of deze gebruiken op een manier die de servicevoorwaarden ervan schendt.
• Apps die niet in aanmerking komen voor opname op de toelatingslijst en die proberen het energiebeheer van het systeem te omzeilen.
• Apps die proxyservices aan derden mogelijk maken, mogen dat alleen doen in apps waar dat het primaire, op gebruikers gerichte doel van de app is.
• Apps of code van derden (zoals SDK's) die uitvoerbare code, zoals dex-bestanden of native code, downloaden via een andere bron dan Google Play.
• Apps die andere apps installeren op een apparaat zonder voorafgaande toestemming van de gebruiker.
• Apps die een link bevatten naar kwaadwillende software of de distributie of installatie daarvan mogelijk maken.
• Apps of code van derden (zoals SDK's) die een WebView met toegevoegde JavaScript-interface bevatten die niet-vertrouwde webcontent laadt (bijvoorbeeld een http://-URL) of niet-geverifieerde URL's die zijn verkregen via niet-vertrouwde bronnen (bijvoorbeeld URL's die zijn verkregen via niet-vertrouwde intenties).
• Apps die het recht voor intentie op volledig scherm gebruiken om interactie van gebruikers af te dwingen via storende advertenties of meldingen.

 

Gebruik van services op de voorgrond Het recht Service op de voorgrond zorgt dat op gebruikers gerichte services op de voorgrond juist worden gebruikt. Als apps Android 14 of nieuwer targeten, geeft u een geldig type op voor elke service op de voorgrond die in uw app wordt gebruikt. Definieer ook het juiste recht voor services op de voorgrond voor dat type. Als voor de use case van uw app bijvoorbeeld de geolocatie voor een kaart is vereist, definieert u het recht FOREGROUND_SERVICE_LOCATION in uw app-manifest. Voor apps mag alleen een recht voor services op de voorgrond worden gedefinieerd als het gebruik hiervan: een functie aanbiedt die nuttig is voor de gebruiker en relevant is voor de kernfunctionaliteit van de app, wordt gestart door de gebruiker of door de gebruiker kan worden opgemerkt (bijvoorbeeld de audio van een nummer dat wordt afgespeeld, media die naar een ander apparaat wordt gecast, een duidelijke en nauwkeurige gebruikersmelding, een verzoek van een gebruiker om een foto te uploaden naar de cloud), kan worden gestopt door de gebruiker, niet kan worden onderbroken of uitgesteld door het systeem zonder dat dit leidt tot een negatieve gebruikerservaring of zorgt dat de door de gebruiker verwachte functie niet werkt zoals verwacht (een telefoongesprek moet bijvoorbeeld meteen starten en kan niet worden uitgesteld door het systeem), alleen wordt uitgevoerd zolang dit nodig is om de taak af te ronden. De volgende use cases voor services op de voorgrond zijn vrijgesteld van de criteria hierboven: services op het voorgrond van het type systemExempted of shortService, services op de voorgrond van het type dataSync alleen als functies voor Play Asset Delivery worden gebruikt. Hier vindt u meer informatie over het gebruik van services op de voorgrond.

 

Door de gebruiker gestarte gegevensoverdrachtstaken Apps mogen alleen gebruikmaken van de API voor door de gebruiker gestarte gegevensoverdrachtstaken als het gebruik: is gestart door de gebruiker, bedoeld is voor gegevensoverdrachtstaken via het netwerk, alleen wordt uitgevoerd zolang dit nodig is om de gegevensoverdracht af te ronden. Hier vindt u meer informatie over het gebruik van de API voor door de gebruiker gestarte gegevensoverdrachten.

 

Vereisten aan de markering FLAG_SECURE FLAG_SECURE is een flag die in de code van een app wordt opgegeven om aan te geven dat de UI gevoelige gegevens bevat die moeten worden beperkt tot een beveiligde omgeving tijdens het gebruik van de app. Deze flag is ontworpen om te voorkomen dat de gegevens worden weergegeven in screenshots of op niet-beveiligde schermen. Ontwikkelaars geven deze flag op wanneer de content van de app niet mag worden uitgezonden, bekeken of anderszins overgedragen buiten de app of het apparaat van de gebruiker. Uit veiligheids- en privacyoverwegingen moeten alle apps die worden gedistribueerd op Google Play zich houden aan de definitie FLAG_SECURE van andere apps. Dit houdt in dat het niet is toegestaan voor apps om de FLAG_SECURE-instellingen in andere apps te omzeilen of hier de mogelijkheid toe te bieden. Apps die worden aangemerkt als een toegankelijkheidstool zijn vrijgesteld van deze vereiste, mits ze geen door middel van FLAG_SECURE beschermde content sturen of (in het cachegeheugen) opslaan voor toegang buiten het apparaat van de gebruiker.

 

Apps die Android-containers op het apparaat uitvoeren Apps met Android-containers op het apparaat bieden omgevingen die een onderliggend Android OS geheel of gedeeltelijk simuleren. De functionaliteit binnen deze omgevingen komt misschien niet overeen met de volledige suite van Android-beveiligingsfuncties. Daarom kunnen ontwikkelaars ervoor kiezen een manifest-flag voor een beveiligde omgeving toe te voegen om aan Android-containers op het apparaat door te geven dat ze niet mogen worden uitgevoerd in hun gesimuleerde Android-omgeving. Manifest-flag voor beveiligde omgeving REQUIRE_SECURE_ENV is een flag die kan worden gedefinieerd in het manifest van een app om aan te geven dat deze app niet moet worden uitgevoerd in apps met Android-containers op het apparaat. Uit veiligheids- en privacyoverwegingen moeten apps die Android-containers op het apparaat bieden, alle apps respecteren waarvoor deze flag is gedefinieerd en: De manifesten van apps die ze in hun Android-container op het apparaat willen laden, controleren op deze flag. De apps waarvoor deze flag is gedefinieerd, niet laden in hun Android-container op het apparaat. Niet fungeren als proxy door API's te onderscheppen of aan te roepen op het apparaat zodat geïnstalleerd lijken in de container. Omzeiling van de flag niet mogelijk maken en geen tijdelijke oplossingen daarvoor aanbieden (zoals een oudere versie van een app laden om de flag REQUIRE_SECURE_ENV van de huidige app te omzeilen). Meer informatie over dit beleid vindt u in ons Helpcentrum.