React-native: [Android] Eliminación de permisos no utilizados agregados en el momento de la compilación

¡Hola lucidrains, gracias por informar de este problema!

React Native, como probablemente hayas escuchado, se está volviendo realmente popular y la verdad es que estamos un poco abrumados por la actividad que lo rodea. Hay demasiados problemas para que podamos gestionarlos correctamente.

• Si no sabe cómo hacer algo o algo no funciona como espera, pero no está seguro de que sea un error , pregunte en StackOverflow con la etiqueta react-native o para más interacciones en tiempo real, pregunte en Discord en el # canal nativo de reacción.
• Si se trata de una solicitud de función o un error que le gustaría corregir, infórmelo en Product Pains . Tiene una función de clasificación que nos permite centrarnos en los problemas más importantes que está experimentando la comunidad.
• Damos la bienvenida a asuntos claros y RP que estén listos para una discusión en profundidad. Proporcione capturas de pantalla cuando corresponda y siempre mencione la versión de React Native que está utilizando. ¡Gracias por sus aportaciones!

Simplemente elimínelos de su AndroidManifest.xml si no los necesita. Creo que estos son por AsyncStorage .

Hay un lugar increíble para publicar código / hacer preguntas antes de presentar un problema: StackOverflow . Es el mejor sistema para preguntas y respuestas. Muchas personas de la comunidad pasan el rato allí y podrán ver y responder su pregunta. Esto nos permite usar el rastreador de errores de github para detectar errores.

Estoy publicando esto aquí porque los problemas de github no nos han funcionado muy bien y porque StackOverflow es mucho mejor. ¡Gracias por leer! :)

@mkonicek ¿no se agregaron en el momento de la compilación? En ese caso, no es fácil eliminarlos.

+1

Incluso cuando no tiene los permisos LEER y ESCRIBIR en su AndroidManifest, todavía aparecen en la compilación. ¿Solo tienes que eliminar AsyncStorage por completo?

Tengo un problema similar cuando generé la versión apk.

Antes de la instalación, solicitó permisos:

• Fotos / Medios / Archivos
• ID del dispositivo e información de llamada

pero confirmé que eliminé AsyncStorage por completo y solo tengo

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

en mi AndroidManifest

@mkonicek @ satya164 @bestander ¿Podría volver a abrir este problema, por favor? Investigué un poco, no pude encontrar dónde se agregaron esos permisos. Hasta ahora hay:

<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"/>

Lo cual no estoy seguro de lo que hacen, pero no creo que realmente se usen porque no funcionaría en Android 6. + (permisos de tiempo de ejecución). También parece extraño forzar permisos para usar un módulo ya que en NetInfoModule en Android, React-native requiere que USTED agregue el permiso necesario a su manifiesto (Ver NetInfoModule.java # L38 ).
De todos modos, no es por AsyncStorage ya que usa una base de datos SQLite debajo del capó , que no requiere ningún permiso. Incluso si usó otro método de almacenamiento como SharedPreferences o el almacenamiento interno para almacenar archivos, no debería requerir ningún permiso (consulte Opciones de almacenamiento ).

Estoy seguro de que esto proviene de React-native, probé un proyecto nuevo sin otro permiso, y aquí estaba una vez que se generó el APK. También miré todas las aplicaciones de Android en el escaparate y todas las aplicaciones tienen esos permisos, excepto una que no tiene READ_PHONE_STATE al menos: Administrador de anuncios de Facebook (Ver _Permisos: Ver detalles_ en la parte inferior).

Tampoco está completamente relacionado, pero este también es un permiso:

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

Este permiso (Dibujar sobre otras aplicaciones) es necesario en el modo de depuración para mostrar el cuadro rojo de error, pero aún está presente
en modo de lanzamiento, lo que da bastante miedo al usuario (aunque no se utilice). Probablemente podría enviar un PR para eso (tengo 2 manifiestos diferentes para depurar y publicar, solo usa el permiso en el de depuración).

Perdón por la publicación tan larga, pero mi empresa está en proceso de lanzar nuestra nueva aplicación para Android, y realmente nos gustaría distribuirla sin permisos innecesarios, ya que no es algo que le guste a la comunidad de Android.

Gracias por tu atención.

¿Quizás Gradle hace eso?
No puedo encontrar ninguna cadena con READ_PHONE_STATE en el código.
No me importa volver a abrir esto, pero ¿podrías ayudarnos a investigarlo?

@ facebook-github-bot reabrir

De acuerdo, reabriendo este número.

@bestander Sí, creo que Android / gradle lo agrega automáticamente, ya que no pude encontrar ninguna mención de ellos en el código, pero realmente no estoy seguro de por qué. Intentaré investigar rápidamente y responderle / enviar un PR tan pronto como encuentre algo.

Olvidé revisar el registro de fusión del

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

Debido a que android-jsc no proporciona un targetSdkVersion , la fusión de manifiesto agregó los permisos por varias razones (consulte Permisos implícitos ). Aparentemente, @astuetz ya solucionó esto en https://github.com/facebook/android-jsc/pull/12 pero la nueva versión de android-jsc no se publicó o no se usa en React-native actualmente. Si puede ponerse en contacto con los encargados de mantenimiento de android-jsc para resolver esto, ¡sería fantástico!

@brentvatne ping, ¿es posible publicar un nuevo android-jsc?

@Bhullnatik, lo que estamos haciendo hasta que se

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

@astuetz Estaba viendo la fusión del manifiesto sobre cómo solucionar esto hasta que se resuelva, gracias por el aviso 😄

@bestander : seguro que puedo hacer eso, ¿también podríamos querer actualizar a r189384 también @kmagiera?

@astuetz gracias, me ayudó, solo para agregar a esta información tuve que declarar el atributo de herramientas en

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

De forma predeterminada, solo hay xmlns: android , no xmlns: tools

@bestander @brentvatne ¡Hola! ¿Algún avance en esto?

👍 +1 para esto.

Siento que la eliminación de SYSTEM_ALERT_WINDOW de las versiones de lanzamiento es mucho más crítica que los otros permisos que se están discutiendo.

@marcshilling En mi opinión, es igualmente importante eliminarlos, pero este es un poco más complicado. La forma más fácil de eliminarlo es eliminarlo en la versión AndroidManifest.xml , pero la configuración es un poco pesada para incluirla en cada proyecto de React Native.
La otra forma sería eliminar el uso, por lo que ya no necesitaría el permiso. Para eso, no estoy seguro de dónde / para qué se usa, pero no vi ninguna necesidad en particular que no pudiera satisfacerse con otra cosa. Aunque podría estar equivocado.

Para aquellos que desean excluir SYSTEM_ALERT_WINDOW de las versiones de lanzamiento sin archivos de manifiesto separados:

En tu manifiesto:

<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"]
        }
    }

Parece funcionar bien.

@marcshilling ¡Perfecto! ¡Gracias! Ha sido un poco vergonzoso tener que explicárselo a los usuarios porque no pude averiguar cómo eliminarlo. 😕

Hola, un usuario de una de mis aplicaciones me ha alertado sobre READ_PHONE_STATE.

Recibo el mismo motivo en el registro de compilación

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

Con suerte, se resuelve en una versión futura.

Por el momento, estoy usando las soluciones alternativas para la eliminación de permisos que se mencionan aquí.
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

Además de agregar el espacio de nombres como lo explica mouneyrac (https://github.com/facebook/react-native/issues/5886#issuecomment-209218936)

Entonces, no pude eliminar SYSTEM_ALERT_WINDOW con la solución anterior.

Tuve que recurrir a un truco (después de mucho pinchar y pinchar).

en AndroidManifest.xml

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

en la aplicación / build.gradle

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

En modo de depuración, elimino ACCESS_FINE_LOCATION, ya que no uso (ni en dev ni en prod). Se podría utilizar cualquier otro permiso no esencial (BIND_TV_INPUT?).

En el modo de lanzamiento, elimino SYSTEM_ALERT_WINDOW. Si no lo quita a la fuerza, se fusionará.

Hacky, pero efectivo 😂

Si usa esta solución https://github.com/facebook/react-native/issues/5886#issuecomment -224397883, no olvide agregar xmlns:tools como se describe aquí: https://github.com / facebook / react-native / issues / 5886 # issuecomment -209218936

@marcshilling Creo que esto es algo que podemos tener en la plantilla del generador de forma predeterminada.

@marcshilling Tu solución no funcionó para mí también, pero la de @jbrodriguez sí.

Una cosa que noté fue que en lugar de usar un permiso real que se eliminará, también puede usar un nombre de permiso no existente como REMOVE_ME .

Comentario rápido: después de actualizar de 0.30 a 0.32 parece react-native ahora de repente agrega el permiso com.google.android.c2dm.permission.RECEIVE He visto esto en dos aplicaciones ahora. Dudo que tampoco necesite este nuevo permiso.

El uso de tools:remove de @marcshilling tampoco me funciona.

Mi solución para evitar permisos innecesarios (una combinación de los anteriores) es:
En el app/src/main/AndroidManifest.xml , agregué:

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

Y en un app/src/release/AndroidManifest.xml recién creado, pongo:

<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 sustitución variable dentro de un tools:node no funciona para mí, por lo que algo como tools:node="${someManifestPlaceholder}" no funcionaría. Por lo tanto, el enfoque anterior de varios archivos AndroidManifest.xml que se fusionan parece un mejor método para agregar / eliminar ciertos permisos sobre una base de debug vs release (o el valor predeterminado main ).

@marcshilling tu solución no funcionó para mí, así que usé la combinación de @jbrodriguez con la de @astuetz .

¿Ustedes creen que vale la pena crear un script para automatizar esto?

¿tal vez crear un paquete npm que haga esto en la instalación y luego se elimine?
Nunca hice algo así, aunque creo que es posible.

@mikelambert , con respecto a su enfoque , ¿se necesita algo más para que funcione?

¿Gradle fusiona automáticamente app/src/release/AndroidManifest.xml en app/src/main/AndroidManifest.xml ?

Eso me parece el enfoque más limpio

¡Se agradecen los pensamientos y comentarios! :)

Sí, fusiona automáticamente los archivos AndroidManifest.xml . Creo que es todo lo necesario para que funcione para mí, ¡pero avíseme si me he perdido algo!

@mikelambert también funcionó para mí. Sin embargo, tengo varios tipos de compilación de lanzamiento, por lo que necesitaba release{X}/AndroidManifest.xml para cada tipo de compilación para que funcione.

No estoy seguro de cómo capturar algo así en un paquete npm ..

La solución adecuada (IMO) sería configurar esto como parte del proyecto cuando se ejecuta react-native init . es decir, algo similar a cómo se usa esto en la configuración inicial del proyecto:
https://github.com/facebook/react-native/blob/master/local-cli/templates/HelloWorld/android/app/src/main/AndroidManifest.xml

@freakinruben todo lo que haces manualmente se puede hacer en un script;)
la primera versión del script sería básica y solo admitiría versiones de lanzamiento / depuración

más tarde podemos solicitar al usuario más configuraciones

@mikelambert seguro hombre, todos estamos pirateando esto aquí hasta que el equipo react-native

<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"/>

Hola a todos,

Tenga cuidado al permitir que RN agregue este permiso por usted android.permission.READ_PHONE_STATE . Si intenta publicar una aplicación en la tienda Google Play con dicho permiso (entre otros), le advertirá con:

Su aplicación tiene un apk con el código de versión X que solicita los siguientes permisos: android.permission.READ_PHONE_STATE. Las aplicaciones que usan estos permisos en un APK deben tener una política de privacidad establecida.

Más información: https://play.google.com/intl/en-US_ALL/about/privacy-security/additional-requirements/. Así que sí, tenga cuidado y asegúrese de eliminar este permiso si no lo necesita hasta que se solucione en RN. Siento que esto debería estar documentado en algún lugar por ahora solo para que las personas con intenciones de liberación estén al tanto.

La solución de

@mikelambert Gracias por la mejor solución.

@ferrannp, en realidad fue la razón por la que llegué aquí. :) y las soluciones funcionaron bien.

Se acerca un pequeño resumen desde el 15 de marzo:

@mmazzarolo ¿qué pasa el 15 de marzo (mañana)?

@antoinerousseau : La nueva regla de política de privacidad de Google Play entra en vigencia el 15 de marzo , y READ_PHONE_STATE es uno de los permisos que lo obligará a publicar un documento de políticas de privacidad tanto en Play Store como en la aplicación.

build.gradle

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

Siguiendo las reglas de la 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 solución es eliminar:

tools:node="remove

@iegik , no estoy seguro de qué solución / código estaba probando, pero agregar un permiso SYSTEM_ALERT_WINDOW para lanzar compilaciones no es una solución que recomendaría a otros.

Pruebe mi sugerencia anterior, si no desea requerir ese permiso en sus versiones de lanzamiento.

@ a-koka ya se ha explicado anteriormente varias veces

@mikelambert Tengo que solicitar el permiso SYSTEM_ALERT_WINDOW de los usuarios, porque nuestra aplicación falla en algún lugar al obtener permisos :(

@iegik Por lo que tengo entendido, las aplicaciones en modo de lanzamiento normales no deberían necesitar SYSTEM_ALERT_WINDOW , y solo es útil para las aplicaciones en modo de desarrollo. ¿Tiene un registro de dicho accidente, que muestre dónde está este "lugar"?

Por supuesto, puede hacerlo si se adapta a sus necesidades y no vale la pena depurarlo ... Simplemente no quería que los futuros lectores de este hilo pensaran que también deben solicitar ese permiso, ya que este hilo trata sobre cómo no solicitar permisos innecesarios. :)

Agregar esta línea hace que mi aplicación se bloquee.
<uses-permission android:name="android.permission.READ_PHONE_STATE" tools:node="remove" />

@npaez , eso es correcto

eso no es lo que está haciendo node = "remove". Se quita el permiso del manifiesto generado, porque otras bibliotecas, por ejemplo, pueden agregar permisos. Esto asegura que el permiso definitivamente no estará allí.
- Heron en Discord

El método de @marcshilling funcionó. (y)

Esto no debe cerrarse ya que RN aún está agregando este permiso implícitamente:

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

lo cual es súper desagradable. Tengo tu número de teléfono e IMEI si instalas mi aplicación, tipo de permiso. No quisiera instalar ninguna aplicación que solicite esto ...

@johnculviner por cierto, ¿funciona cuando intentas recuperar IMEI? porque intenté usar react-native-device-info y no funciona, intenté usar react-native-Imei, que ha sido obsoleto desde RN 0.47, me da un error de no anular o implementar el método, ¿tiene alguna solución para mi problema? ?

@koswarabilly Estoy bastante seguro de que el permiso anterior es uno de los requisitos para IMEI, que definitivamente es algo bastante elevado de solicitar dado que identifica de manera única el teléfono para siempre.

@johnculviner sé que el permiso me da acceso a la información del dispositivo, he intentado obtener el imei a través del paquete react-native-imei pero cuando ejecuto-android me pide que diga anulación de error o método no implementado, ¿alguna vez lo consiguió con éxito? Número IMEI de su dispositivo
¿O alguien ha recuperado exitosamente el número imei aquí? Porque creo que es una tarea posible

Estoy usando React Native v0.44.0 e intenté actualizar a SDK 26, pero el sistema Android ya no permite que SYSTEM_ALERT_WINDOW se use más, incluso en modo de depuración. SYSTEM_ALERT_WINDOW solo puede ser utilizado por aplicaciones de nivel de sistema en Oreo. ¿Alguna idea sobre cómo puedo hacer que esto funcione?

Para cualquiera que intente resolver esto, en esta publicación el tipo usa la solución que se enumera aquí pero muy bien explicada.
https://medium.com/@applification/fixing -react-native-android-permissions-9e78996e9865

@mikelambert Gracias, tu solución funciona perfectamente

La solución para mí fue modificar el
./android/app/src/main/AndroidManifest.xml

Tuve que agregar las siguientes líneas

<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" />

    ...

Para fines de depuración: ./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

Esto elimina el cuadro de diálogo de permisos de la aplicación cuando se instala a través de PlayStore

Lo único que no entiendo:

¿Por qué tengo que agregar derechos para eliminarlos mientras la aplicación en sí ni siquiera requiere permiso?

Grüße Ulf

<3

¿La "corrección" se agregará en cualquier próxima versión de React-native?

Nuestra aplicación tiene varios tipos de compilación (4 a partir de ahora) y queríamos eliminar los permisos SYSTEM_ALERT_WINDOW de todos ellos EXCEPTO debug .
No quería piratear nombres de permisos a través de marcadores de posición de manifiesto, ni crear 3 Manifiestos de Android adicionales con el mismo contenido.
Entonces, al final elimino el permiso en main / AndroidManifest.xm l usando:

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

y luego en un debug / AndroidManifest.xml separado, lo agrego de nuevo :

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

Debido a que el debug AndroidManifest tiene una prioridad más alta que el main one (ver Fusionar prioridades ), anulará la eliminación y agregará el permiso.

Suena extraño, pero parece funcionar bien (a juzgar por el resultado de aapt d permissions <apk file> ).

El Congreso debería haberle preguntado a Zuck qué pasa con estos permisos.

Creo que la solución es crear otro android/app/src/release/AndroidManifest.xml como este:

<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>

Y edite android/app/build.gradle así:

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

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

Cerrando este problema, porque se eliminan los permisos innecesarios. Consulte https://github.com/facebook/react-native/blob/master/local-cli/templates/HelloWorld/android/app/src/main/AndroidManifest.xml

@dulmandakh Esto no es relevante para el tema en absoluto. Los permisos se agregan al manifiesto al compilar un APK, no están presentes en la plantilla predeterminada (como se menciona en el problema original y en https://github.com/facebook/react-native/issues/5886#issuecomment-200862582 ). ¿Puede volver a abrir el problema?

@dulmandakh esto no debería haberse cerrado. Los permisos se agregan en el momento de la compilación, sin relación con su archivo vinculado

Esta parece ser la guía oficial sobre cómo eliminar los permisos predeterminados:
http://facebook.github.io/react-native/docs/removing-default-permissions

No sé si esto está relacionado con este foro o no.

así que debido al reciente cambio de las reglas de permisos de la consola de Google Play. Google verificará nuestro manifiesto para ver los permisos de Android que usamos.

aunque he usado ' tools: node = "remove"' en todos los permisos no utilizados y en las aplicaciones de lanzamiento, el permiso no se muestra. Google todavía no me permite publicar mis aplicaciones en la consola de Google Play.

¿Alguien tiene algún problema como este? Tengo este problema 27-01-2019.

Como seguimiento de este nuestro manifiesto utilizado actualmente:

<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>

Manifiesto 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>

Manifiesto de sabor de los desarrolladores

Los permisos mencionados anteriormente son agregados implícitamente por Android SDK porque el JSC antiguo o JavaScriptCore apuntaba al SDK 4. En el maestro tenemos un nuevo JSC y se usará por defecto en 0.59. Entonces no hay nada que podamos hacer al respecto. Consulte https://developer.android.com/studio/build/manifest-merge

Cabe señalar que la única forma de eliminar SYSTEM_ALERT_WINDOW es seguir las instrucciones oficiales de reacción sobre la creación de un nuevo archivo de manifiesto para su lanzamiento.

Quizás solía funcionar mediante el uso de manifestPlaceholders, pero debe haber habido un cambio o versiones de herramientas de compilación que lo están rompiendo.

@hammadzz gracias por recordarnos sobre el permiso no utilizado, y creé un PR para arreglar esto https://github.com/facebook/react-native/pull/23504. Espero que aterrice pronto en el master y cherry pick por 0,59.