React-native: [Android] Suppression des autorisations inutilisées ajoutées au moment de la construction

Salut les lucidrains, merci d'avoir signalé ce problème !

React Native, comme vous l'avez probablement entendu, devient très populaire et la vérité est que nous sommes un peu dépassés par l'activité qui l'entoure. Il y a tout simplement trop de problèmes pour que nous puissions les gérer correctement.

• Si vous ne savez pas comment faire quelque chose ou que quelque chose ne fonctionne pas comme prévu mais que vous n'êtes pas sûr qu'il s'agisse d'un bogue , veuillez demander sur StackOverflow avec la balise react-native ou pour plus d'interactions en temps réel, demandez sur Discord dans le #react-native channel.
• S'il s'agit d'une demande de fonctionnalité ou d'un bogue que vous souhaitez corriger, veuillez le signaler sur Product Pains . Il dispose d'une fonction de classement qui nous permet de nous concentrer sur les problèmes les plus importants auxquels la communauté est confrontée.
• Nous accueillons les questions claires et les PR qui sont prêts pour une discussion approfondie. Veuillez fournir des captures d' version de React Native que vous utilisez. Merci pour vos contributions!

Supprimez-les simplement de votre AndroidManifest.xml si vous n'en avez pas besoin. Je crois que c'est pour AsyncStorage .

Il existe un endroit génial pour publier du code / poser une question avant de signaler un problème :

Je poste ceci ici parce que les problèmes de github n'ont pas très bien fonctionné pour nous et parce que StackOverflow est tellement mieux. Merci d'avoir lu! :)

@mkonicek ne sont-ils pas ajoutés au moment de la construction ? Dans ce cas, il n'est pas facile de les supprimer

+1

Même lorsque vous n'avez pas les autorisations LECTURE et ÉCRITURE dans votre AndroidManifest, elles apparaissent toujours lors de la construction. Vous n'avez qu'à supprimer complètement AsyncStorage ?

J'ai un problème similaire lorsque j'ai généré la version apk.

Avant l'installation, il a demandé des autorisations :

• Photos/Médias/Fichiers
• ID de l'appareil et informations sur l'appel

mais j'ai confirmé que j'avais complètement supprimé AsyncStorage et que je n'avais que

<uses-permission android:name="android.permission.INTERNET" />

dans mon AndroidManifest

@mkonicek @satya164 @bestander Ce problème pourrait-il être rouvert s'il vous plaît ? J'ai creusé un peu, je n'ai pas trouvé où ces autorisations ont été ajoutées. A ce jour il y a :

<android:uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<android:uses-permission android:name="android.permission.READ_PHONE_STATE"/>
<android:uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>

Ce que je ne suis pas sûr de ce qu'ils font, mais je ne pense pas qu'ils soient réellement utilisés car cela ne fonctionnerait pas sur Android 6.+ (autorisations d'exécution). Il semble également étrange de forcer les autorisations pour utiliser un module puisque dans NetInfoModule sur Android, React-native vous oblige à ajouter l'autorisation nécessaire à votre manifeste (voir NetInfoModule.java#L38 ).
Quoi qu'il en soit, ce n'est pas pour AsyncStorage car il utilise une base de données SQLite sous le capot , qui ne nécessite aucune autorisation. Même s'il utilisait une autre méthode de stockage comme SharedPreferences ou le stockage interne pour stocker des fichiers, il ne devrait nécessiter aucune autorisation (voir Options de stockage ).

Je suis sûr que cela vient de React-native, j'ai essayé un nouveau projet sans autre autorisation, et il y avait là une fois l'APK généré. J'ai également regardé toutes les applications Android dans la vitrine et chaque application a ces autorisations, sauf une qui n'a pas au moins READ_PHONE_STATE : Gestionnaire de publicités Facebook (voir _Autorisations : Voir les détails_ en bas).

Pas complètement lié non plus, mais c'est aussi une autorisation :

<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>

Cette autorisation (Dessiner sur d'autres applications) est nécessaire en mode débogage pour afficher l'erreur redbox, mais est toujours présente
en mode release, ce qui fait assez peur à l'utilisateur (même s'il n'est pas utilisé). Je pourrais probablement soumettre un PR pour cela (avoir 2 manifestes différents pour le débogage et la publication, n'utilise que l'autorisation dans le débogage).

Désolé pour le long message, mais ma société est en train de publier notre nouvelle application Android, et nous aimerions vraiment l'expédier sans autorisations inutiles car ce n'est pas quelque chose que la communauté Android aime vraiment.

Merci de votre attention.

Peut-être que Gradle fait ça ?
Je ne trouve aucune chaîne avec READ_PHONE_STATE dans le code.
Cela ne me dérange pas de rouvrir cela, mais pourriez-vous nous aider à enquêter sur cela ?

@facebook-github-bot rouvrir

D'accord, réouverture de ce problème.

@bestander Ouais, je pense que c'est ajouté automatiquement par Android/gradle car je n'ai trouvé aucune mention d'eux dans le code, mais je ne sais vraiment pas pourquoi. Je vais essayer d'enquêter rapidement et de vous répondre/soumettre un PR dès que je trouve quelque chose.

J'ai oublié de vérifier le journal de fusion manifeste ... Il s'avère que le problème est assez évident :

IMPLIED from /Users/mayouk/Dev/tmp/AwesomeProject/android/app/src/main/AndroidManifest.xml:1:1-23:12 reason: org.webkit.android_jsc has a targetSdkVersion < 4
android:uses-permission#android.permission.READ_PHONE_STATE
IMPLIED from /Users/mayouk/Dev/tmp/AwesomeProject/android/app/src/main/AndroidManifest.xml:1:1-23:12 reason: org.webkit.android_jsc has a targetSdkVersion < 4
android:uses-permission#android.permission.READ_EXTERNAL_STORAGE
IMPLIED from /Users/mayouk/Dev/tmp/AwesomeProject/android/app/src/main/AndroidManifest.xml:1:1-23:12 reason: org.webkit.android_jsc requested WRITE_EXTERNAL_STORAGE

Étant donné que android-jsc ne fournit pas de targetSdkVersion , la fusion manifeste a ajouté les autorisations pour diverses raisons (voir Autorisations implicites ). Apparemment, @astuetz a déjà corrigé ce https://github.com/facebook/android-jsc/pull/12 mais soit la nouvelle version de android-jsc n'a pas été publiée, soit elle n'est pas utilisée dans React-native actuellement. Si vous pouviez contacter les responsables de android-jsc pour résoudre ce problème, ce serait fantastique !

@brentvatne ping, est-il possible de publier un nouveau android-jsc ?

@Bhullnatik ce que nous faisons jusqu'à ce qu'une nouvelle version d'android-jsc soit publiée, c'est simplement supprimer les autorisations indésirables dans le manifeste de nos applications comme ceci :

<uses-permission
  android:name="android.permission.READ_PHONE_STATE"
  tools:node="remove"/>

@astuetz Je regardais la fusion manifeste sur la façon de résoudre ce problème jusqu'à ce qu'il soit résolu, merci pour le heads-up 😄

@bestander - bien sûr que je peux le faire, nous pourrions également vouloir mettre à jour vers r189384 @kmagiera?

@astuetz merci, cela m'a aidé, juste pour ajouter à cette information, je devais déclarer l'attribut tools dans

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.bepaw.esportninja">. 

Par défaut, il n'y a que xmlns:android , pas de xmlns:tools

@bestander @brentvatne Hé ! Une mise à jour pour ceci?

+1 pour cela.

J'ai l'impression que la suppression de SYSTEM_ALERT_WINDOW des versions de version est beaucoup plus critique que les autres autorisations discutées.

@marcshilling Il est tout aussi important de les supprimer à mon avis, mais celui-ci est un peu plus délicat. Le moyen le plus simple de le supprimer est de le supprimer dans la version AndroidManifest.xml , mais la configuration est un peu lourde à inclure dans chaque projet React Native.
L'autre moyen serait de supprimer l'utilisation, donc de ne plus avoir besoin de l'autorisation. Pour cela, je ne sais pas où/pour quoi il est utilisé, mais je n'ai pas vu de besoin particulier qui ne pourrait pas être satisfait avec autre chose. Je pourrais toutefois avoir tord.

Pour ceux qui souhaitent exclure SYSTEM_ALERT_WINDOW des versions de version sans fichiers Manifest séparés :

Dans votre manifeste :

<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" tools:remove="${excludeSystemAlertWindowPermission}"/>

En app/build.gradle :

    buildTypes {
        debug {
            manifestPlaceholders = [excludeSystemAlertWindowPermission: "false"]
        }
        release {
            manifestPlaceholders = [excludeSystemAlertWindowPermission: "true"]
        }
    }

Semble bien fonctionner.

@marcshilling Parfait ! Merci! Cela a été un peu embarrassant d'avoir à expliquer cela aux utilisateurs parce que je ne savais pas comment le supprimer. ??

Bonjour, j'ai été alerté de READ_PHONE_STATE par un utilisateur de l'une de mes applications.

J'obtiens la même raison dans le journal de construction

reason: org.webkit.android_jsc has a targetSdkVersion < 4

Espérons que cela soit résolu dans une future version.

Pour le moment, j'utilise les solutions de contournement de suppression d'autorisation mentionnées ici
astuetz - READ_PHONE_STATE - https://github.com/facebook/react-native/issues/5886#issuecomment -200869879
marcshilling - SYSTEM_ALERT_WINDOW - https://github.com/facebook/react-native/issues/5886#issuecomment -224397883

En plus d'ajouter l'espace de noms comme expliqué par mouneyrac (https://github.com/facebook/react-native/issues/5886#issuecomment-209218936)

Donc, je ne pouvais pas supprimer SYSTEM_ALERT_WINDOW avec la solution ci-dessus.

J'ai dû recourir à un hack (après avoir beaucoup poussé et poussé).

dans AndroidManifest.xml

    <uses-permission android:name="${permissionName}" tools:node="remove"/>

dans app/build.gradle

    buildTypes {
        debug {
            manifestPlaceholders = [permissionName: "android.permission.ACCESS_FINE_LOCATION"]
            ...
        }    
        release {
            manifestPlaceholders = [permissionName: "android.permission.SYSTEM_ALERT_WINDOW"]
            ...
        }
    }

En mode debug, je supprime ACCESS_FINE_LOCATION, puisque je n'utilise pas (ni en dev ni en prod). Toute autre autorisation non essentielle peut être utilisée (BIND_TV_INPUT ?).

En mode release, je supprime SYSTEM_ALERT_WINDOW. Si vous ne le supprimez pas de force, il sera fusionné.

Hacky, mais efficace

Si vous utilisez cette solution https://github.com/facebook/react-native/issues/5886#issuecomment -224397883, n'oubliez pas d'ajouter xmlns:tools comme décrit ici : https://github.com /facebook/react-native/issues/5886#issuecomment -209218936

@marcshilling Je pense que c'est quelque chose que nous pouvons avoir dans le modèle de générateur par défaut.

@marcshilling Votre solution n'a pas fonctionné pour moi aussi bien, mais celle de @jbrodriguez l'a fait.

Une chose que j'ai remarquée est qu'au lieu d'utiliser une autorisation réelle qui sera supprimée, vous pouvez également utiliser un nom d'autorisation inexistant comme REMOVE_ME .

Commentaire rapide : après la mise à jour de 0,30 à 0,32, il semble que react-native ajoute soudainement l'autorisation com.google.android.c2dm.permission.RECEIVE J'ai vu cela dans deux applications maintenant. Je doute qu'il ait besoin de cette nouvelle autorisation non plus.

L'utilisation des tools:remove de @marcshilling ne fonctionne pas non plus pour moi.

Ma solution pour éviter les autorisations inutiles (un mélange de ce qui précède) est :
Dans le app/src/main/AndroidManifest.xml , j'ai ajouté :

<uses-permission tools:node="remove" android:name="android.permission.READ_PHONE_STATE" />

Et dans un app/src/release/AndroidManifest.xml nouvellement créé, je mets :

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    >

    <!-- These are added by React Native for debug mode, but actually aren't needed in releasemode -->
    <uses-permission tools:node="remove" android:name="android.permission.SYSTEM_ALERT_WINDOW" />
</manifest>

La substitution de variable à l'intérieur d'un tools:node ne fonctionne pas pour moi, donc quelque chose comme tools:node="${someManifestPlaceholder}" ne fonctionnerait pas. Ainsi, l'approche ci-dessus de plusieurs fichiers AndroidManifest.xml qui fusionnent semble être une meilleure méthode pour ajouter/supprimer certaines autorisations sur une base debug vs release (ou la valeur par défaut main ).

@marcshilling votre solution n'a pas fonctionné pour moi, j'ai donc utilisé @jbrodriguez 's combiné avec @astuetz 's

Vous pensez que cela vaut la peine de créer un script pour automatiser cela ?

peut-être créer un package npm qui le rend à l'installation, puis se supprimer lui-même ?
Jamais fait quelque chose comme ça, je crois que c'est possible.

@mikelambert , concernant votre approche , faut-il autre chose pour que cela fonctionne ?

est-ce que gradle fusionne automatiquement app/src/release/AndroidManifest.xml en app/src/main/AndroidManifest.xml ?

cela me semble être l'approche la plus propre

Réflexions et commentaires appréciés! :)

Oui, il fusionne automatiquement les fichiers AndroidManifest.xml . Je crois que c'est tout ce qui était nécessaire pour que cela fonctionne pour moi, mais faites-moi savoir si j'ai raté quelque chose !

@mikelambert a aussi travaillé pour moi. J'ai cependant plusieurs buildTypes de version, donc j'avais besoin de release{X}/AndroidManifest.xml pour chaque type de build afin de le faire fonctionner.

Je ne sais pas comment vous pourriez capturer quelque chose comme ça dans un package npm.

Le correctif approprié (IMO) serait de le configurer dans le cadre du projet lorsque react-native init est exécuté. c'est-à-dire quelque chose de similaire à la façon dont cela est utilisé dans la configuration initiale du projet :
https://github.com/facebook/react-native/blob/master/local-cli/templates/HelloWorld/android/app/src/main/AndroidManifest.xml

@freakinruben tout ce que vous faites manuellement peut être fait dans un script ;)
la première version du script serait basique et ne prendrait en charge que les versions release/debug

plus tard, nous pouvons demander à l'utilisateur plus de configurations

@mikelambert bien sûr, nous

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" tools:node="remove" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" tools:node="remove" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" tools:node="remove"/>

Salut tout le monde,

Soyez prudent en laissant RN ajouter cette autorisation pour vous android.permission.READ_PHONE_STATE . Si vous essayez de publier une application sur le Google Play Store avec une telle autorisation (entre autres), il vous avertira avec :

Votre application a un apk avec le code de version X qui demande les autorisations suivantes : android.permission.READ_PHONE_STATE. Les applications utilisant ces autorisations dans un APK doivent avoir une politique de confidentialité définie.

Plus d'informations : https://play.google.com/intl/en-US_ALL/about/privacy-security/additional-requirements/. Alors oui, soyez prudent et assurez-vous de supprimer cette autorisation si vous n'en avez pas besoin jusqu'à ce que cela soit corrigé dans RN. Je pense que cela devrait être documenté quelque part pour le moment, juste pour que les personnes ayant des intentions de libération soient au courant.

La solution

@mikelambert Merci pour la meilleure solution.

@ferrannp c'était en fait la raison pour laquelle je suis arrivé ici. :) et les solutions ont bien fonctionné.

Petit récap depuis le 15 mars approche :

@mmazzarolo que se passe-t-il le 15 mars (demain) ?

@antoinerousseau : la nouvelle règle de politique de confidentialité de Google Play entre en vigueur

build.gradle

        classpath 'com.android.tools.build:gradle:1.2.3' // For Android 5.1

La règle suivante se bloque sur 5.1 :

    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" tools:node="remove"/>

06-02 15:06:54.102: E/AndroidRuntime(18353): android.view.WindowManager$BadTokenException: Unable to add window android.view.ViewRootImpl$W<strong i="11">@f03a0a2</strong> -- permission denied for this window type
06-02 15:06:54.102: E/AndroidRuntime(18353):    at android.view.ViewRootImpl.setView(ViewRootImpl.java:704)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:289)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:85)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at android.app.Dialog.show(Dialog.java:311)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at com.facebook.react.devsupport.DevSupportManagerImpl.showProgressDialog(DevSupportManagerImpl.java:762)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at com.facebook.react.devsupport.DevSupportManagerImpl.reloadJSFromServer(DevSupportManagerImpl.java:767)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at com.facebook.react.devsupport.DevSupportManagerImpl.handleReloadJS(DevSupportManagerImpl.java:658)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at com.facebook.react.XReactInstanceManagerImpl$3$1.run(XReactInstanceManagerImpl.java:412)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at android.os.Handler.handleCallback(Handler.java:815)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at android.os.Handler.dispatchMessage(Handler.java:104)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at android.os.Looper.loop(Looper.java:194)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at android.app.ActivityThread.main(ActivityThread.java:5631)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at java.lang.reflect.Method.invoke(Native Method)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at java.lang.reflect.Method.invoke(Method.java:372)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959)
06-02 15:06:54.102: E/AndroidRuntime(18353):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754)

La solution est de supprimer :

tools:node="remove

@iegik , je ne sais pas SYSTEM_ALERT_WINDOW pour publier des builds n'est pas une solution que je recommanderais aux autres.

Veuillez essayer ma suggestion ci-dessus, si vous ne souhaitez pas exiger cette autorisation dans vos versions de version.

@a-koka ça a déjà été expliqué plusieurs fois ci-dessus

@mikelambert Je dois demander l'autorisation SYSTEM_ALERT_WINDOW aux utilisateurs, car notre application se bloque quelque part lors de l'obtention des autorisations :(

@iegik D'après ce que je comprends, les applications en mode de publication normales ne devraient pas avoir besoin de SYSTEM_ALERT_WINDOW , et cela n'est utile que pour les applications en mode développement. Avez-vous un journal de ce crash, qui montre où se trouve ce "quelque part" ?

Bien sûr, vous pouvez le faire si cela correspond à vos besoins et ne vaut pas la peine d'être débogué pour vous... Je ne voulais tout simplement pas que les futurs lecteurs de ce fil pensent qu'ils doivent également demander cette autorisation, car ce fil est de savoir comment ne pas demander d'autorisations inutiles. :)

L'ajout de cette ligne fait planter mon application.
<uses-permission android:name="android.permission.READ_PHONE_STATE" tools:node="remove" />

@npaez , c'est vrai

ce n'est pas ce que node="remove " fait. Il supprime l'autorisation du manifeste généré, car d'autres bibliothèques, par exemple, peuvent ajouter des autorisations. Cela garantit que l'autorisation ne sera certainement pas là.
- Héron à Discord

La méthode de @marcshilling a fonctionné. (y)

Cela ne devrait pas être fermé car RN ajoute toujours cette autorisation implicitement :

<uses-permission android:name="android.permission.READ_PHONE_STATE" />

ce qui est super méchant, j'ai votre numéro de téléphone et IMEI si vous installez mon type d'autorisation d'application. Je ne voudrais pas installer d'applications qui le demandent...

@johnculviner au fait, est-ce que ça marche quand vous essayez de récupérer IMEI ? parce que j'ai essayé d'utiliser react-native-device-info et que cela ne fonctionne pas, j'ai essayé d'utiliser react-native-Imei qui est obsolète depuis RN 0.47 me donne l'erreur de ne pas remplacer ou de ne pas implémenter la méthode, avez-vous une solution à mon problème ?

@koswarabilly Je suis à peu près sûr que l'autorisation ci-dessus est l'une des exigences pour IMEI, ce qui est certainement une chose assez élevée à demander étant donné qu'elle identifie le téléphone de manière unique pour toujours

@johnculviner je sais que l'autorisation me donne accès aux informations de l'appareil, j'ai essayé d'obtenir l'imei via le package react-native-imei mais lorsque je lance Android, il m'invite à dire que l'erreur remplace ou méthode non implémentée, avez-vous déjà réussi à obtenir Numéro IMEI de votre appareil
Ou quelqu'un a-t-il réussi à récupérer le numéro imei ici ? Parce que je crois que c'est une tâche possible

J'utilise React Native v0.44.0 et j'ai essayé de passer au SDK 26, mais le système Android ne permet plus d'utiliser SYSTEM_ALERT_WINDOW, même en mode débogage. SYSTEM_ALERT_WINDOW ne peut être utilisé que par les applications au niveau du système dans Oreo. Des idées sur la façon dont je peux faire ce travail?

Pour tous ceux qui essaient de résoudre ce problème, dans cet article, le gars utilise la solution répertoriée ici mais très bien expliquée.
https://medium.com/@applification/fixing -react-native-android-permissions-9e78996e9865

@mikelambert Merci, votre solution fonctionne parfaitement

La solution pour moi était de modifier le
./android/app/src/main/AndroidManifest.xml

j'ai du rajouter les lignes suivantes

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
// Added this
    xmlns:tools="http://schemas.android.com/tools"
    package="de.democracydeutschland.app"
    android:versionCode="1"
    android:versionName="1.0">

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>
// Added tools:node="remove"
    <uses-permission android:name="android.permission.READ_PHONE_STATE" tools:node="remove"/>
// Added READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE both with tools:node="remove"
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" tools:node="remove" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" tools:node="remove" />

    <uses-sdk
        android:minSdkVersion="16"
        android:targetSdkVersion="22" />

    ...

À des fins de débogage : ./android/app/build/outputs/logs/manifest-merger-***-report.txt

Rel : https://github.com/demokratie-live/democracy-client/blob/master/android/app/src/main/AndroidManifest.xml

Cela supprime la boîte de dialogue App-Permission lors de l'installation via PlayStore

La seule chose que je ne comprends pas :

Pourquoi dois-je ajouter des droits pour les supprimer alors que l'application elle-même ne nécessite même pas d'autorisation ?

Grüße Ulf

<3

La "correction" sera ajoutée dans une prochaine version de React-native ?

Notre application a plusieurs types de build (4 à ce jour) et nous voulions supprimer les autorisations SYSTEM_ALERT_WINDOW de tous SAUF debug .
Je ne voulais pas pirater les noms d'autorisation via des espaces réservés de manifeste, ni créer 3 AndroidManifests supplémentaires avec un contenu égal.
Donc, à la fin, je supprime l'autorisation dans main/AndroidManifest.xm l en utilisant :

<manifest xmlns:tools="http://schemas.android.com/tools" ...>
<uses-permission tools:node="remove" android:name="android.permission.SYSTEM_ALERT_WINDOW" />
...

puis dans un debug/AndroidManifest.xml séparé , je le rajoute :

<manifest xmlns:tools="http://schemas.android.com/tools" ...>
<uses-permission tools:node="merge" android:name="android.permission.SYSTEM_ALERT_WINDOW" />
...

Étant donné que le debug AndroidManifest a une priorité plus élevée que le main (voir Merge Priorities ), il remplacera la suppression et ajoutera l'autorisation.

Cela semble étrange, mais semble bien fonctionner (à en juger par la sortie de aapt d permissions <apk file> ).

Le Congrès aurait dû demander à Zuck ce qui se passe avec ces autorisations.

Je pense que la solution est de créer un autre android/app/src/release/AndroidManifest.xml comme ceci :

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.facebook.react.demo">

    <uses-permission
        android:name="android.permission.SYSTEM_ALERT_WINDOW"
        tools:node="remove" />

    <uses-permission
        android:name="android.permission.READ_PHONE_STATE"
        tools:node="remove" />

    <application>

    </application>

</manifest>

Et éditez android/app/build.gradle comme ceci :

android {
    ...
    sourceSets.release {
        manifest.srcFile 'release/AndroidManifest.xml'
    }
}

https://code.videolan.org/videolan/vlc-android/blob/923bbada6687ecab31addc1dfd3f90619976ccdf/vlc-android/build.gradle#L169

Fermeture de ce problème, car les autorisations inutiles sont supprimées. Veuillez consulter https://github.com/facebook/react-native/blob/master/local-cli/templates/HelloWorld/android/app/src/main/AndroidManifest.xml

@dulmandakh Cela n'a aucun rapport avec le problème. Les autorisations sont ajoutées au manifeste lors de la création d'un APK, elles ne sont pas présentes dans le modèle par défaut (comme mentionné dans le numéro d'origine et dans https://github.com/facebook/react-native/issues/5886#issuecomment-200862582 ). Pouvez-vous s'il vous plaît rouvrir le problème?

@dulmandakh cela n'aurait pas dû être fermé. Les autorisations sont ajoutées au moment de la construction, sans rapport avec votre fichier lié

Cela semble être le guide officiel sur la suppression des autorisations par défaut :
http://facebook.github.io/react-native/docs/removing-default-permissions

Je ne sais pas si c'est lié à ce forum ou pas.

donc parce que le changement récent des règles d'autorisation de la console Google Play. Google vérifiera notre manifeste pour voir les autorisations Android que nous avons utilisées.

bien que j'aie utilisé ' tools:node= "remove"' dans toutes les autorisations inutilisées et dans les applications de publication, l'autorisation n'est pas affichée. Google ne me permet toujours pas de publier mes applications dans la console Google Play.

quelqu'un a un problème comme ça ? j'ai eu ce problème 27-01-2019.

En guise de suivi, notre manifeste actuellement utilisé :

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="de.democracydeutschland.app">

    <uses-permission android:name="android.permission.INTERNET" />

    <!-- Default permissions which are added silently and not needed by us - hence we remove them -->
    <uses-permission android:name="android.permission.READ_PHONE_STATE" tools:node="remove" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" tools:node="remove" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" tools:node="remove" />

    <!-- This needs to be added in dev mode but removed in all others
         since this config is used for production aswell we need to remove it here -->
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" tools:node="remove" />

    <!-- included from rn-fetch-blob - implications of removal are unknown -->
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" tools:node="remove" />

    ...
</manifest>

Manifeste principal

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="de.democracydeutschland.app">

    <!-- This needs to be added in dev mode but removed in all others -->
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" tools:node="replace" />

</manifest>

Manifeste des saveurs des développeurs

Les autorisations mentionnées ci-dessus sont implicitement ajoutées par Android SDK car l'ancien JSC ou JavaScriptCore ciblait le SDK 4. Dans le maître, nous avons un nouveau JSC et seront utilisés par défaut dans 0.59. Nous ne pouvons donc rien y faire. Veuillez consulter https://developer.android.com/studio/build/manifest-merge

Attention, le seul moyen de supprimer SYSTEM_ALERT_WINDOW est de suivre les instructions de réaction officielles sur la création d'un nouveau fichier manifeste pour publication.

Peut-être que cela fonctionnait en utilisant manifestPlaceholders, mais il doit y avoir eu un changement ou des versions d'outils de construction qui le cassent.

@hammadzz merci de nous avoir rappelé l'autorisation inutilisée, et j'ai créé un PR pour résoudre ce problème https://github.com/facebook/react-native/pull/23504. J'espère qu'il débarquera bientôt dans le master et cerise cueillie pour 0,59.