Flutter: Admite paquetes de aplicaciones con binarios de 32 y 64 bits dentro de ellos

Creado en 1 may. 2019  ·  194Comentarios  ·  Fuente: flutter/flutter

Advertencia

Esta versión no cumple con el requisito de Play 64 bits.

Los siguientes APK o paquetes de aplicaciones están disponibles para dispositivos de 64 bits, pero solo tienen código nativo de 32 bits: {código de versión}.

A partir del 1 de agosto de 2019, todas las versiones deben cumplir con el requisito de Play 64 bits.

Incluya código nativo de 64 bits además del código nativo de 32 bits en su aplicación. Utilice el formato de publicación de Android App Bundle para asegurarse de que la arquitectura de cada dispositivo reciba solo el código nativo que necesita. Aprende más

Esta advertencia aparece al intentar publicar un aab creado por flutter build appbundle en Play Store desde hoy .

¿Es esto algo de lo que debo preocuparme o Flutter lo resolverá automáticamente, es decir, ya está planeado que se resuelva a tiempo?

crowd engine waiting for PR to land (fixed)

Comentario más útil

Hola equipo de Flutter,
Me gustaría hacer hincapié en el estado de este tema. Desde mi punto de vista, hay dos problemas graves:

  • La versión actual de flutter estable 1.7.8+hotfix.3 no crea apks estables - al menos split-per-abi no funciona como debería - arm32 tiene un problema de regresión y no se puede ejecutar en algunos dispositivos arm32 . Aún no está claro cuándo se solucionará esto;
  • Fecha límite del 1 de agosto: en aproximadamente una semana, nosotros, como desarrolladores, no podremos actualizar ni lanzar nuevas aplicaciones de flutter en Google Play Store, tan simple como eso. Teniendo en cuenta el problema de la versión actual de Flutter (como se mencionó anteriormente) y el tiempo restante, no creo que sea factible esperar tener la solución en un canal

Teniendo en cuenta los dos problemas anteriores, me gustaría sugerir el siguiente plan de contingencia, que OMI nos serviría mejor como desarrolladores:

  • Revertir el canal estable de flutter a su versión anterior al hotfix.2
  • Posponga la fecha límite del 1 de agosto por un par de meses; entiendo que esto requerirá una escalada del problema, pero espero que comprendan el impacto serio que podría tener si los desarrolladores no pueden lanzar una aplicación de flutter

Solo puedo hablar en mi nombre, pero tengo clientes con contratos y decidí pasar de React Native a Flutter, ya que creía que Google brindaría un mejor soporte para sus propios productos. Tengo proyectos en curso y aplicaciones para apoyar.
Ahora me encuentro en un caso absurdo, cuando Google me obliga a lanzar la versión apk de 64 bits y al mismo tiempo Google no me proporciona la herramienta para hacerlo (y sí, sé que el equipo de Flutter no es lo mismo que Google Play equipo, pero desde donde yo me paro, usted es la misma entidad comercial).
Si Google no entrega a tiempo, esto dará lugar a un fuerte rechazo de Flutter, ya que cada día después del 1 de agosto reducirá la credibilidad del framework.
Pido disculpas si mis palabras suenan un poco más fuertes, solo espero que puedas ponerte en mi lugar por el momento.

Cualquiera, por favor vote sobre esto, ¡y esperamos que se escuche nuestra voz!

Todos 194 comentarios

no

Tuve la misma advertencia. ¿A alguien del equipo de Flutter le importaría comentar o explicar lo mismo, y qué podemos hacer para asegurarnos de que el paquete de aplicaciones generado con flutter build appbundle --release también tenga el código de 64 bits? @zoechi ¿Puedes contarnos algo al respecto?

También estoy viendo esto. Aquí hay una captura de pantalla:
Screen Shot 2019-05-02 at 12 25 57 PM

Y la documentación "más información" está aquí: https://developer.android.com/distribute/best-practices/develop/64-bit

Espero una respuesta del equipo de Flutter.

Hoy también recibí este mensaje de advertencia.

El mismo problema aquí.

Yo también

Yo también

¿Existe ya una solución para esto?

Mire esto: https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

Funcionó para mí.

el botón [iniciar lanzamiento a prueba interna] está deshabilitado en la página de versiones de la aplicación de Google Play Console (la pantalla donde aparece el mensaje de advertencia de 64 bits anterior)

El requisito del paquete de 64 bits es ahora un obstáculo para los proyectos de flutter.

/ cc @mklim @cbracken

Parece que Play Store ha comenzado a emitir una advertencia que se activa si se utilizan las instrucciones de lanzamiento predeterminadas de Flutter.
https://flutter.dev/docs/deployment/android

Es posible enviar APK para ARM de 32 y 64 bits con Flutter, actualmente solo requiere un par de pasos adicionales. Varios enfoques para resolver tales problemas se discuten en:
https://github.com/flutter/flutter/issues/18494#issuecomment -477502287

También estamos buscando en este momento para ver cuál es la mejor manera de actualizar la plantilla / herramientas / pasos de lanzamiento predeterminados para evitar esta advertencia.

Gracias por su paciencia.

@eseidelGoogle Corrígeme si me equivoco, sin embargo, pensé que el objetivo de un paquete de aplicaciones era empaquetar todo en un solo archivo y dejar que Play Store solo envíe la apk necesaria a cada usuario.

Como señalé en mi pregunta original, estoy usando flutter build appbundle . En este caso, la solución que propuso no se aplicaría, ¿verdad?

Ayer probamos el paquete de aplicaciones de compilación de flutter y recibimos mensajes de error de la tienda de juegos de que era una compilación de depuración ...

por supuesto, también debe funcionar en escenarios de add2app donde no se usan las instrucciones de flutter.dev, sino que se usa la compilación de estudio de Android-> Generar APK firmado

Gracias por etiquetarlo como crítico

Hablamos de esto en persona. @tvolkert va a encontrar a alguien que lo ayude a cerrar esto.

También recibo esta advertencia, ¿hay alguna manera de establecer de forma predeterminada 64 bits?

Una pequeña modificación a build.gradle puede forzar la inclusión de bibliotecas nativas de 64 bits en la versión apk y aab; eche un vistazo aquí para encontrar una solución alternativa

Por el bien de Google, indíquenos cuántos teléfonos todavía utilizan 32 bits.
Si agrega bibliotecas de 64 bits y 32 bits, aumenta el tamaño final de la apk.

Tengo un proyecto sin aleteo, donde divido el APK por ABI, por lo que tengo apks separados para 32 bits y 64 bits para reducir el tamaño. Ahora, este paso parece obligarme a aumentar el tamaño de la apk en el futuro.
Pero por qué ?

No tengo estadísticas sobre cuántos teléfonos solo de 32 bits hay en India / África ... Estoy seguro de que no es casi nada en Europa, los EE. UU. Y partes de Asia.
¿Qué pasa con x86 / x86_64 vs armeabi / arm64-v8a? ¿Necesitamos agregar libflutter.so para las 4 ABI en el apk de producción final?
.. también mips ... ¿hay algún teléfono que todavía use mips? Solo google lo sabe.

@VarolOkan Use AAB y deje que Google genere APK para todas las combinaciones de ppp de pantalla y ABI que necesite.

el botón [iniciar lanzamiento a prueba interna] está deshabilitado en la página de versiones de la aplicación de Google Play Console (la pantalla donde aparece el mensaje de advertencia de 64 bits anterior)

El requisito del paquete de 64 bits es ahora un obstáculo para los proyectos de flutter.

@eseidelGoogle o cualquiera: ¿alguien puede confirmar si esto es
a) un tapón de espectáculo
o b) una advertencia hasta agosto
ver: https://forums.expo.io/t/warning-with-the-google-play-64-bit-requirement/22305
Él indica que hay algunas casillas a la izquierda para marcar para que funcione, y si la advertencia dice agosto, parece un gran problema si en realidad es a principios de mayo.

Además, es muy útil saber si, de hecho, no hay aproximadamente máquinas de 32 bits y el uso de un abiFilter de una sola línea para el brazo de 64 bits es una opción viable para admitir el 99,5% de los usuarios o algo así; Vi a alguien limpiando hace un año completo "todos los teléfonos en el mercado" eran de 64 bits ... ¿quizás eso significa que hay muchos teléfonos viejos?

Tengo entendido que esto no es un impedimento, sino una advertencia común. Le hemos pedido a @blasten que eche un vistazo a lo que podemos hacer aquí para que la configuración predeterminada de Flutter evite esta advertencia. Espero que tengamos algunas actualizaciones en los próximos días.

Como dijo @eseidelGoogle , me https://github.com/flutter/flutter/issues/18494#issuecomment -489807239?

¿Esto ya no es un problema? https://github.com/flutter/flutter/issues/18494#issuecomment -482795450

No es espectacular. Recibí la advertencia, pero pude lanzar mi aplicación para
la tienda de juegos.

Kr Morten

El martes, 7 de mayo de 2019 a las 17.46, Audrius Karosevicius [email protected]
escribió:

¿Esto ya no es un problema? # 18494 (comentario)
https://github.com/flutter/flutter/issues/18494#issuecomment-482795450

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/flutter/flutter/issues/31922#issuecomment-490135779 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA4B4J5BY3BJVIELNEPC4N3PUGP7BANCNFSM4HJU7TZA
.

>

;-)
/ Morten

Web: http://buildsucceeded.dk
Móvil: 51 21 90 79

Para resumir:

1) A principios de este año, Play comunicó a los desarrolladores que requerirá que las aplicaciones cargadas en la tienda proporcionen versiones de 64 bits a partir de agosto (https://android-developers.googleblog.com/2019/01/get-your-apps-ready -para-64-bit.html). Esta semana, Play Store ha comenzado a mostrar un mensaje informativo para las aplicaciones cargadas para proporcionar una advertencia sobre el próximo requisito. Sin embargo, los requisitos de Play Store no han cambiado en este momento.

2) El requisito de APK de 64 bits con las referencias de advertencia es posible cumplir ahora con un pequeño esfuerzo manual para modificar los archivos gradle en el proyecto Flutter: https://github.com/flutter/flutter/issues/18494#issuecomment - 489807239 para un ejemplo de cómo.

3) Estamos trabajando para que el comportamiento predeterminado de Flutter cumpla con las próximas actualizaciones de las pautas de Play en torno al soporte de 64 bits sin ningún esfuerzo adicional por parte de los usuarios. Espero que el trabajo se complete en los próximos días / semanas, mucho antes de las fechas límite de agosto.

Si me he perdido algo de lo anterior, no dude en comentar o comunicarse. Disculpas por no haberlo actualizado antes de que Play activara la advertencia. ¡Gracias a todos por su ayuda y comentarios!

@eseidelGoogle

  1. No puedo publicar la aplicación creada por flutter build apk . Play Store no acepta compilaciones de solo 32 bits en mi perfil.
  2. La solución de # 18494 (comentario) falla en dispositivos de 32 bits como OnePlus One.

En mi opinión, es espectacular.

@eseidelGoogle

  1. Resuelto. Google Play no acepta compilaciones si la clasificación y los países no están configurados. Solo el mensaje es engañoso.

El requisito de APK de 64 bits con las referencias de advertencia es posible cumplir ahora con un pequeño esfuerzo manual para modificar los archivos gradle en el proyecto Flutter: # 18494 (comentario) para un ejemplo de cómo.

después de unas pocas horas de prueba y error, no pude __no__ producir un apk firmado ni un paquete de aplicaciones que contenga un libflutter.so de 64 bits

el único libflutter.so incluido en el paquete es el
armeabi-v7a (32 bits)
, cuando usas
Android Studio 3.4
Compilación # AI-183.5429.30.34.5452501, creada el 10 de abril de 2019

menú: Generar> Generar paquete / APK firmado


flutter build apk --release --target-platform=android-arm64 -v
flutter build appbundle --release --target-platform=android-arm64 -v

ambos fallan @> Task: app: validateSigningRelease FAILED

@ciez Esto produjo 64 bits solo apk para mí:

$ flutter build apk --release --target-platform=android-arm64
Initializing gradle...                                              1.1s
Resolving dependencies...                                           1.8s
Running Gradle task 'assembleRelease'...                                
Running Gradle task 'assembleRelease'... Done                       9.0s
Built build/app/outputs/apk/release/app-release.apk (7.5MB).

@adriank
Si, funciona.
descubrió cuál era el problema: "~" en la ruta al almacén de claves.jks necesitaba ser reemplazado por / home / user

perdón por la falsa alarma.

¿Parece que cada paquete construido de esta manera puede apuntar solo a 1 arco como máximo?

Esperando la actualización de Flutter ya que la solución simplemente rompió mis compilaciones.

@mulderpf ¿Qué solución aplicó y cómo se rompió su compilación?

Consulte este comentario para conocer la última actualización del equipo de Flutter.

Recibí una actualización: ¡tengo esto funcionando en mi sucursal!
La sugerencia es usar flutter build appbundle --release --target-platform=android-arm-all (recomendado para obtener el APK separado de la caja) o flutter build apk --release --target-platform=android-arm-all en una versión futura.

¿Alguien en la zona horaria PST está dispuesto a probarlo? Si es así, comuníquese con Gitter o Slack :)

@blasten Lamentablemente, no pude producir un paquete con tu rama. Gradle falla en app:properties alguna manera, pero mirando el código parece prometedor.
¿Ha logrado verificar que flutter/engine cargará instantáneas AOT del directorio ./lib/ ? Mirando el código del motor, usa activos en todas partes ... Si esto funciona, resolverá el problema general de los paquetes de aplicaciones, ya que por ahora carecen del soporte de la orientación del directorio de activos por ABI.

@SPodjasek correcto, también necesitaría una compilación local del motor, por lo que las clases en el APK buscan las nuevas instantáneas.

@blasten Me las arreglé para arreglar mi árbol de compilación y ahora puedo compilar con éxito el paquete de aplicaciones que contiene instantáneas de AOT en base/lib/${abi}/

  4649616  2019-05-13 20:52   base/lib/arm64-v8a/isolate_snapshot_data.so
  6296768  2019-05-13 20:52   base/lib/arm64-v8a/isolate_snapshot_instr.so
  8472736  2019-05-13 20:52   base/lib/arm64-v8a/libflutter.so
    32352  2019-05-13 20:52   base/lib/arm64-v8a/vm_snapshot_data.so
    19200  2019-05-13 20:52   base/lib/arm64-v8a/vm_snapshot_instr.so
  3700504  2019-05-13 20:52   base/lib/armeabi-v7a/isolate_snapshot_data.so
  6019680  2019-05-13 20:52   base/lib/armeabi-v7a/isolate_snapshot_instr.so
  6036116  2019-05-13 20:52   base/lib/armeabi-v7a/libflutter.so
    23520  2019-05-13 20:52   base/lib/armeabi-v7a/vm_snapshot_data.so
    12640  2019-05-13 20:52   base/lib/armeabi-v7a/vm_snapshot_instr.so

Y me pregunto si sería suficiente modificar esto ...

https://github.com/flutter/engine/blob/1b649a57d18a8c41ae017d79cf9bdb999a2276ac/shell/platform/android/io/flutter/view/FlutterMain.java#L334 -L336

a algo como:

getContext().getApplicationInfo().nativeLibraryDir;

Por supuesto, no sería tan simple, pero para tener una idea general ...

Aquí se explica cómo probar flutter build appbundle con soporte de 32 y 64 bits:

  1. Descargue flutter.jar de https://drive.google.com/open?id=1yAkfhPKfhdd8MwW39qfkZDePc66SMA_z y colóquelo debajo de {flutterInstallationPath}/bin/cache/artifacts/engine/android-arm-release . Para verificar la ruta de instalación de Flutter, use which flutter

Si desea ver los cambios en FlutterMain.java, consulte: https://github.com/blasten/engine/commit/b3ab9def28a414ffa53bf10ad6a3249f31ed00e3

  1. Consulte el parche de esta rama:
$ cd {flutterInstallationPath}
$ git remote add arm-all https://github.com/blasten/flutter
$ git fetch arm-all apk_defaults
$ git checkout apk_defaults

$ git build appbundle --release --target-platform=android-arm-all

Déjame saber lo que encuentres.

+1

@danysz En lugar de escribir +1, si hubiera votado a favor de este problema, habría tenido más sentido (sin sentimientos duros para usted). Para otros, si leen este mensaje, por favor no escriban "yo también", "lo mismo aquí", "+1", en su lugar, voten a favor de este problema.

¡Gracias!

@blasten Las aplicaciones no se inician:

05-14 10:50:35.979  3445 28828 I ActivityManager: Start proc 30019:xxx/u0a262 for activity xxx/com.example.flutterapp.MainActivity
05-14 10:50:36.067 30019 30019 I FirebaseInitProvider: FirebaseApp initialization successful
05-14 10:50:36.108 30019 30019 E flutter : [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings.
05-14 10:50:36.108 30019 30019 E flutter : [ERROR:flutter/runtime/dart_vm.cc(241)] Could not setup VM data to bootstrap the VM from.
05-14 10:50:36.108 30019 30019 E flutter : [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance.
05-14 10:50:36.108 30019 30019 F flutter : [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.
05-14 10:50:36.108 30019 30019 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 30019 (xxx), pid 30019 (xxx)

Esto va a mi dispositivo físico y al dispositivo 9/10 Test Lab; tenemos un resultado inconsistente para Pixel-Q-beta.

@danysz En lugar de escribir +1, si hubiera votado a favor de este problema, habría tenido más sentido (sin sentimientos duros para usted). Para otros, si leen este mensaje, por favor no escriban "yo también", "lo mismo aquí", "+1", en su lugar, voten a favor de este problema.

¡Gracias!

hecho

@blasten Al AndroidManifest.xml

diff --git a/packages/flutter_tools/templates/app/android.tmpl/app/src/main/AndroidManifest.xml.tmpl b/packages/flutter_tools/templates/
app/android.tmpl/app/src/main/AndroidManifest.xml.tmpl
index 4778a2080..f3492835e 100644
--- a/packages/flutter_tools/templates/app/android.tmpl/app/src/main/AndroidManifest.xml.tmpl
+++ b/packages/flutter_tools/templates/app/android.tmpl/app/src/main/AndroidManifest.xml.tmpl
@@ -24,6 +24,11 @@
             <meta-data
                 android:name="io.flutter.app.android.SplashScreenUntilFirstFrame"
                 android:value="true" />
+            <!-- If true, the snapshots are read from lib instead of the assets 
+                 directory in the APK. -->
+            <meta-data
+                android:name="io.flutter.view.FlutterMain.snapshot-in-lib"
+                android:value="${snapshotInLib}" />
             <intent-filter>
                 <action android:name="android.intent.action.MAIN"/>
                 <category android:name="android.intent.category.LAUNCHER"/>

Sin embargo, todavía falla ...

@blasten

git build
$ git build appbundle --release --target-platform=android-arm-all
"git build" or "flutter build" ? :-)

Lamentablemente, no pude producir un paquete con sus instrucciones. Gradle falla en la aplicación: propiedades de alguna manera (después de una "Herramienta de aleteo de construcción ..." y algunas descargas de android-arm - * ....).

Parece que el proceso de descarga sobrescribió a flutter.jar

@MoacirSchmidt Tuve problemas similares, pero limpiar flutter clean ) y cachés gradle ( ~/.gradle/caches & ${projectRoot}/android/.gradle ) ayudó

Para las personas que tienen problemas para crear una apk de 64 bits.
Esta configuración funcionó para mí.

build.gradle

ejecutar flutter build apk --release --target-platform=android-arm

Incrementar versionCode

ejecutar flutter build apk --release --target-platform=android-arm64

flutter build appbundle ahora está en master, ¿alguna persona voluntaria quiere intentarlo?

Para las personas, como yo, que tienen miedo de cambiar los archivos gradle, si solo quieren la versión de 64 bits, flutter build apk --release --target-platform=android-arm64 funciona incluso sin modificar build.gradle.

@blasten Probé flutter build appbundle en el canal beta . Cuando intento subirlo a Play Store, todavía obtengo el error 32/64.

Sé que dijiste master pero tengo algunos errores en los que todavía estoy trabajando en esa rama. ¡Solo quería darte esa información!

¡También recibo esta advertencia!

¿Existe alguna forma de crear un paquete de aplicaciones para todas las arquitecturas?

¿Alguna actualización sobre cómo solucionarlo?

Estoy cerrando este error ya que se refiere a paquetes de aplicaciones. Si cambia a la rama principal, puede usar flutter build appbundle para generar paquetes de aplicaciones que admitan arquitecturas de CPU de 32 y 64 bits. Si prefiere o no puede usar paquetes de aplicaciones, siga este hilo para obtener soporte adicional a través de APK grandes.

@blasten : ¿podría proporcionar algún tipo de instrucciones sobre cómo usarlo desde Android Studio?
Aquí está mi configuración actual de flutter:

Resumen del médico (para ver todos los detalles, ejecute flutter doctor -v):
[√] Flutter (Canal estable, v1.2.1, en Microsoft Windows [Versión 10.0.17763.503], configuración regional en-US)
[√] Cadena de herramientas de Android: desarrollo para dispositivos Android (SDK de Android versión 28.0.3)
[√] Android Studio (versión 3.4)

¿Cuándo este cambio irá a la sucursal stable ?

@blasten, ¿funciona con Add2App?

@blasten ¿cómo firmar el paquete de aplicaciones creado por flutter build appbundle?

@blasten ¿ es una buena forma de utilizar la rama maestra para aplicaciones de producción?

@dblokhin puede usar flutter channel master para cambiar al canal maestro. Tenga en cuenta que ahora también está disponible en el canal de desarrollo.

@tvolkert : ¿algún período de tiempo en el que se fusionará con la rama stable ?

@ angel1st Lo

@truongsinh - considerando que el 1 de agosto es aproximadamente en dos meses a partir de ahora, esperaría una adopción mucho más rápida, en realidad ...

¡@ angel1st ya está en estable! Descubriré más ...

¡@ angel1st ya está en estable!

¿Estás seguro de eso? El estable actual es 1.5.4-hotfix 2 y no genera paquetes con 32 y 64. ¿O me falta algo?

@shinayser aún no lo es, lo siento. Descubriré más y actualizaré el hilo. Como mencionó Todd, el canal master es la única opción en este momento.

Probé el paquete. Tenía la versión 1.6.1-pre de Flutter en el maestro
canal.

La salida del paquete fue de alrededor de 12 MB, lo que no generó la advertencia.
y los tamaños de APK individuales eran alrededor de 7. Hasta ahora todo está bien.

Pero cuando abrí la aplicación después de actualizar a través de Play Store, mi aplicación se
atascado en la pantalla de bienvenida.

No tuve opción de volver a flutter build apk que funcionó bien, no sé cómo
y por qué.

Así que no creo que este problema esté cerrado todavía, porque aunque la advertencia
se ha ido con el appbundle, al igual que la propia aplicación. El paquete es
haciendo que la aplicación sea inútil ya que está atascada en la pantalla de inicio.

En ese caso, no dude en comunicarse conmigo directamente en Gitter: https://gitter.im/flutter/flutter. Si es posible, será útil si puede enviar el archivo .aab que generó la herramienta.

Creo que necesitamos documentar el uso de una forma u otra. También creo que tener esto combinado con stable antes de finales de junio es vital si el equipo de Flutter quiere mantener a los desarrolladores cerca.

@ angel1st estamos trabajando arduamente para que este trabajo sea promovido a stable para fines de junio.

Algunas actualizaciones:

Pudimos reproducir aplicaciones que se atascan en la pantalla de inicio después de implementar un APK desde un paquete de aplicaciones (generado usando flutter build appbundle desde el canal maestro).

Esto parece deberse a nuestra ubicación de las instantáneas de AOT ( vm-snapshot-data , vm-snapshot-instr , isolate-snapshot-data , isolate-snapshot-instr ) como bibliotecas dentro de /lib/{abi}/lib_{snapshot}.so para obtener la división ABI para paquetes de aplicaciones.

EDITAR : La causa raíz resultó ser que el código en el incrustador de Android espera un directorio llamado flutter_assets en esta línea , pero mi cambio reciente para admitir paquetes de aplicaciones deshabilitó la creación de dicho directorio, lo que hizo que la aplicación nunca se iniciara. Esta confirmación de @ jason-simmons https://github.com/flutter/engine/compare/7f4f52f95294...e8db5dfd52ee soluciona el problema.

Conclusión

El plan actual es permitir que la herramienta Flutter genere bibliotecas compartidas ELF en lugar de instantáneas AOT. Esta función se acaba de agregar al SDK de Dart en https://github.com/dart-lang/sdk/commit/af93ebcf4cb55ae5f0f39a183ad2d42ca13ae51f.

Lo que esto significa es que obtendremos ABI dividido para paquetes de aplicaciones y APK gruesos utilizando bibliotecas reales.

Actualizaré este error y https://github.com/flutter/flutter/issues/18494 una vez que se solucione el problema. Mientras tanto, pasar --target-platform a build appbundle le permitirá crear paquetes de aplicaciones sin mover las instantáneas de AOT a lib/ .

Algunas actualizaciones:

Pudimos reproducir aplicaciones que se atascan en la pantalla de inicio después de implementar un APK desde un paquete de aplicaciones (generado usando flutter build appbundle desde el canal maestro).

Esto parece deberse a nuestra ubicación de las instantáneas de AOT ( vm-snapshot-data , vm-snapshot-instr , isolate-snapshot-data , isolate-snapshot-instr ) como bibliotecas dentro de /lib/{abi}/lib_{snapshot}.so para obtener la división ABI para paquetes de aplicaciones. Después de todo, las instantáneas no son bibliotecas reales y nuestro truco para obtener este comportamiento no funcionó.

El plan actual es permitir que la herramienta Flutter genere bibliotecas compartidas ELF en lugar de instantáneas AOT. Esta función se acaba de agregar al SDK de Dart en dart-lang / sdk @ af93ebc .

Lo que esto significa es que obtendremos ABI dividido para paquetes de aplicaciones y APK gruesos utilizando bibliotecas reales.

Actualizaré este error y # 18494 una vez que se solucione el problema. Mientras tanto, pasar --target-platform a build appbundle le permitirá crear paquetes de aplicaciones sin mover las instantáneas de AOT a lib/ .

@blasten, ¿esto funcionará correctamente cuando tenga otras bibliotecas que también .so cuando estamos construyendo el APK.

Sí, puede usar otras bibliotecas de código nativo dentro de su APK.

En el nuevo formato de empaquetado, una aplicación Flutter incluirá la biblioteca del motor libflutter.so junto con otro .so contiene los datos de la instantánea AOT compilados a partir del código Dart de su aplicación. La aplicación puede agregar otras bibliotecas .so no relacionadas con Flutter si es necesario.

Para su información, la solución al problema de quedarse atascado en la pantalla de inicio debería estar en la versión del canal de desarrollo 1.7.0 (próximamente) (https://github.com/flutter/flutter/wiki/Bad-Builds#v161--- v167)

Hola a todos. La solución al problema de quedarse atascado en la pantalla de inicio ha llegado al canal de desarrollo; debería verlo si flutter upgrade a v1.7.0. Pruébelo y avísenos si tiene problemas con flutter build appbundle .

@tvolkert No me funcionó antes y no me funciona ahora. Ni en el canal dev (1.7.0) ni en el canal maestro (1.7.1). La compilación de la aplicación con flutter build appbundle bloquea después de publicarla a través de Play Store y ejecutarla en un dispositivo real.
Editar: ahora funciona en el canal dev (1.7.0) después de eliminar la aplicación del dispositivo y reinstalarla desde Play Store.
Edit2: NO funciona. Play Store fue un poco más lento de lo normal mientras distribuía la versión correcta. ¿Qué puedo hacer para ayudar a reproducir?

@masewo ¿puedes recolectar la lápida del dispositivo, junto con qué versión de Flutter se estaba ejecutando en ese momento?

@ jason-simmons @blasten ¿Algo más que le gustaría ayudar a rastrear esto?

@tvolkert

lápida sepulcral:

2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: Build fingerprint: 'samsung/crownltexx/crownlte:9/PPR1.180610.011/N960FXXS2CSDJ:user/release-keys'
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: Revision: '28'
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: ABI: 'arm64'
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: pid: 8261, tid: 8261, name: asewo.myfirstapp  >>> net.masewo.myfirstapp <<<
2019-06-04 08:32:44.375 8326-8326/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG: Abort message: '[FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm. Must be able to initialize the VM.
    '
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x0  0000000000000000  x1  0000000000002045  x2  0000000000000006  x3  0000000000000008
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x4  0000000000000000  x5  0000000000000000  x6  0000000000000000  x7  0080000000000000
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x8  0000000000000083  x9  000000767c1f9890  x10 fffffff87ffffbdf  x11 0000000000000001
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x12 00000075ded1c000  x13 0000000000000008  x14 ffffffffffffffff  x15 0000402003ff3b02
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x16 000000767c2302b0  x17 000000767c16f958  x18 0000007fdd2251da  x19 0000000000002045
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x20 0000000000002045  x21 0000000000000083  x22 00000075edde02e0  x23 00000075dec79fc0
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x24 00000075de3a6150  x25 0000000000000000  x26 00000075f7614ca0  x27 0000000000000003
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     x28 0000000000000000  x29 0000007fdd225b00
2019-06-04 08:32:44.376 8326-8326/? A/DEBUG:     sp  0000007fdd225ac0  lr  000000767c162da0  pc  000000767c162dcc
2019-06-04 08:32:44.377 8326-8326/? A/DEBUG: backtrace:
2019-06-04 08:32:44.377 8326-8326/? A/DEBUG:     #00 pc 0000000000021dcc  /system/lib64/libc.so (abort+124)
2019-06-04 08:32:44.377 8326-8326/? A/DEBUG:     #01 pc 0000000000e4a6a0  /data/app/net.masewo.myfirstapp-J4PFXKn_O2diLnKpCeu2eg==/split_config.arm64_v8a.apk (offset 0xe2d000)

aleteo:

D:\Programme\Android\flutter\bin\flutter.bat doctor --verbose
[√] Flutter (Channel dev, v1.7.0, on Microsoft Windows [Version 10.0.18362.145], locale de-DE)
    • Flutter version 1.7.0 at D:\Programme\Android\flutter
    • Framework revision f36a35d20a (3 days ago), 2019-05-31 15:27:56 -0400
    • Engine revision a32df2c928
    • Dart version 2.3.2 (build 2.3.2-dev.0.0 445a23a9bc)

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at D:\Programme\Android\sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: D:\Programme\Android\Android Studio Dev\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)
    • All Android licenses accepted.

[√] Android Studio (version 3.5)
    • Android Studio at D:\Programme\Android\Android Studio Beta
    • Flutter plugin version 36.0.7
    • Dart plugin version 191.7221
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b02)

[√] Connected device (1 available)
    • SM N960F • xxxxxxxxxxxxxxxx • android-arm64 • Android 9 (API 28)

@ jason-simmons @blasten es esta afirmación la que está causando el colapso en el caso de @masewo

@masewo , no podemos reproducir el bloqueo de nuestro lado sin aplicaciones; ¿estaría dispuesto a crear un archivo .aab sin firmar de la versión 1.7.1 que demuestre este comportamiento y enviármelo por correo electrónico (tvolkert @ google .com)? Si es así, ¡sería de gran ayuda!

Para su información, el siguiente anuncio se envió a [email protected] con respecto a nuestro soporte de 64 bits.

https://groups.google.com/forum/#!topic/flutter -announce / oIzwT9EDczc

@tvolkert, ¿el equipo también está trabajando para hacer que https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps sea compatible con todos los puntos que estaba enumerando?

  1. Proporcione una forma (de forma predeterminada) de crear un paquete de aplicaciones que admita tanto 32 bits como 64 bits. (ya disponible para probar en el canal de desarrollo)

  2. Proporcione una forma (de forma predeterminada) de crear un APK que admita tanto 32 bits como 64 bits. (en curso)

@truongsinh Sí, vea este comentario en el PR pendiente: https://github.com/flutter/flutter/pull/33696#issuecomment -498934359

@masewo y todos los demás: pudimos replicar el bloqueo descrito en https://github.com/flutter/flutter/issues/31922#issuecomment -498541765 y lo estamos rastreando.

tldr: espera, estamos en eso 🙂

Hola a todos,

TLDR:

Hemos identificado el problema con los bloqueos cuando se descargan de Play Store y estamos trabajando en una solución, que se entregará dentro del mismo período de tiempo que se describe anteriormente en https://github.com/flutter/flutter/issues/31922#issuecomment -498880614

Explicación de alto nivel

Para aquellos interesados, la explicación un tanto larga es que con dispositivos que ejecutan Android Marshmallow o posterior, Play Store detectará aplicaciones empaquetadas como App Bundles que contienen múltiples ABI, e instalará esas aplicaciones en el dispositivo en forma de "split APK ". Cuando hace esto, los archivos .so que contiene no se extraen del archivo zip APK, que es diferente al comportamiento de los APK no divididos. Dado que el mecanismo actual del motor Flutter

La solución es solo dlopen las bibliotecas, y Android abstrae dónde están ubicadas las bibliotecas (es decir, dentro de un archivo o no). Sin embargo, los archivos .so necesarios nunca fueron bibliotecas verdaderas para empezar, eran solo blobs binarios de datos que cargamos en la máquina virtual Dart. Entonces, como parte de esto, las estamos convirtiendo en bibliotecas ELF (por ejemplo, https://github.com/dart-lang/sdk/commit/6d608fb52bc1926a73d986d73ab228b77cfb7ca2 y https://github.com/flutter/flutter/pull/33696).

Hola a todos,

Creemos que todas las correcciones han aterrizado en la punta del árbol en el canal master . Si desea probarlos, siga estos pasos:

  • flutter build appbundle

    De forma predeterminada, el paquete de aplicaciones contiene su código de Dart y el tiempo de ejecución de Flutter compilado para armeabi-v7a (32 bits) y arm64-v8a (64 bits)

  • flutter build apk --split-per-abi

    Este comando dará como resultado dos APK:

    build/app/outputs/apk/release/app-armeabi-v7a-release.apk
    build/app/outputs/apk/release/app-arm64-v8a-release.apk

  • flutter build apk

    Esto dará como resultado un APK grueso que contiene su código compilado para todas las ABI de destino. Dichos APK serán de mayor tamaño que sus contrapartes divididas, lo que hará que el usuario descargue binarios nativos que no son aplicables a la arquitectura de su dispositivo.

flutter build appbundle ahora me está funcionando. ¡Gracias @tvolkert !

Puede confirmar que esto está funcionando (después de cambiar a maestro) en varios dispositivos Android. Qué salvavidas, gracias.

¡Excelente! Gracias a @blasten , @ jason-simmons y @ rmacnak-google; solo soy el mensajero 🙂

Gracias a todo el equipo de Flutter y a los colaboradores por una respuesta tan rápida. Con suerte, este llegará al canal beta dentro de 1,5 meses :)

@tomaszpolanski, el plan es llevarlo a la versión beta a fines de junio y estabilizarse a principios de julio 🙂

@tvolkert ¿hay un indicador de comando flutter build appbundle que podamos pasar para incluir también x86?

@athornz no está en modo de liberación atm. Ver: https://github.com/flutter/flutter/issues/9253. Sin embargo, será posible agregar instantáneas de AOT por x86_64 en un futuro próximo.

Cambiar a la rama maestra me da el siguiente error. Compilaciones estables, pero no incluye 64 bits en el paquete de lanzamiento.

Running flutter doctor...
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, v1.7.4-pre.108, on Mac OS X 10.14.5 18F132, locale nl-NL)
[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
[✓] iOS tools - develop for iOS devices
[✓] Android Studio (version 3.4)
[✓] IntelliJ IDEA Community Edition (version 2018.2.7)
[✓] Connected device (1 available)

• No issues found!
MacBook-Pro-van-Wendel:zaira wendel$ flutter build appbundle --build-name=1.0.6 --build-number=6 -t lib/main_prod.dart --flavor=prod
Initializing gradle...                                              0,9s
Resolving dependencies...                                           2,2s
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
Running Gradle task 'bundleProdRelease'...                              
Running Gradle task 'bundleProdRelease'... Done                    78,6s
Gradle task bundleProdRelease failed with exit code 1

@xinoxapps , ¿puedes enviar el resultado completo de flutter build appbundle -v (como un enlace a gist.github.com, para facilitar la lectura de este hilo 🙂)?

@xinoxapps , no pude reproducir este problema localmente. Ahora, mirando las advertencias que está recibiendo, parece que hay una lógica de configuración personalizada build.gradle , que puede o no estar causando el problema. ¿Sería posible llegar a un caso de reproducción mínima? por ejemplo, intente eliminar parte de esa configuración personalizada de Gradle hasta que funcione, luego comparta qué causó exactamente el problema. Así es como definí el sabor:

android {
  flavorDimensions "version"
    productFlavors {
        prod { }
    }
}

Hola a todos,

Estas correcciones ahora están disponibles en el canal dev , en la versión v1.7.4 o posterior.

Cambié a paquetes de aplicaciones y pasé a Play Store, y la mayoría de los usuarios parecen felices. Sin embargo, tengo dos informes de que la aplicación no se inicia en absoluto en un dispositivo x86 que admite la emulación ARM, el Asus ZenFone 2 ZE551ML: https://www.gsmarena.com/asus_zenfone_2_ze551ml-6917.php. Desafortunadamente, los usuarios no han podido proporcionar la salida de adb logcat. ¿Está previsto que el nuevo formato ELF funcione en estos dispositivos?

Screen Shot 2019-06-16 at 11 55 54 PM

Cambiar a los canales master y dev me da este error con flutter build appbundle :

* What went wrong:
Execution failed for task ':app:transformNativeLibsWithMergeJniLibsForProductionRelease'.
> More than one file was found with OS independent path 'lib/armeabi-v7a/libapp.so'

@darioielardi ¿puedes incluir enlaces a gist.google.com con la salida de flutter build appbundle -v , así como el contenido de tus archivos android/build.gradle y android/app/build.gradle ?

Cambié a paquetes de aplicaciones y pasé a Play Store, y la mayoría de los usuarios parecen felices. Sin embargo, tengo dos informes de que la aplicación no se inicia en absoluto en un dispositivo x86 que admite la emulación ARM, el Asus ZenFone 2 ZE551ML: https://www.gsmarena.com/asus_zenfone_2_ze551ml-6917.php. Desafortunadamente, los usuarios no han podido proporcionar la salida de adb logcat. ¿Está previsto que el nuevo formato ELF funcione en estos dispositivos?

Screen Shot 2019-06-16 at 11 55 54 PM

sí, tengo el mismo problema. Funciona con el paquete de aplicaciones Flutter Build y la mayoría de los dispositivos ejecutan bien mis aplicaciones. pero no por este asus

@blasten Sí, entiendo que x86 nativo no es compatible, pero creo que el problema aquí es que Google Play está instalando los paquetes de aplicaciones ARM / ARM64 en dispositivos x86 que anuncian soporte para ARM a través de la traducción, pero los nuevos paquetes de aplicaciones de alguna manera no lo hacen. funcionan correctamente en tales dispositivos (quizás porque los nuevos formatos ELF confunden al traductor ARM). Sin embargo, los APK de ARM (no ARM64) originales parecen funcionar en ellos, como se confirma al volver a una rama maestra de dos semanas de antigüedad (e1a784ae para ser específico) y observar que los dos usuarios que estaban viendo problemas ahora tienen mi aplicación ejecutándose de nuevo en sus dispositivos ZenFone 2. Esto evitará que actualice a v1.7.4.

@xinoxapps , ¿puedes enviar el resultado completo de flutter build appbundle -v (como un enlace a gist.github.com, para facilitar la lectura de este hilo 🙂)?

Me funciona ahora en el canal de desarrollo. ¿Aún necesitas información?

@xinoxapps no , me alegra saber que está funcionando para usted.

@darioielardi, el problema está solucionado en el maestro ahora. Ejecute flutter upgrade en el canal maestro.

@darioielardi, el problema está solucionado en el maestro ahora. Ejecute flutter upgrade en el canal maestro.

@blasten Cambié a maestro y obtuve este error al ejecutar flutter build appbundle
Execution failed for task ':app:transformClassesAndResourcesWithProguardForRelease'.

este es mi gradle y salida completa https://gist.github.com/julindra/80cd2e588cf11bdd0df3f34239b07409

Hola a todos,

Nuestro objetivo es obtener algunas correcciones de errores más para agregar a la aplicación y sabores, y eliminar una versión de v1.7.5 dev. Como tal, estamos postergando la promoción a beta para recoger esas correcciones. Todavía esperamos que esto sea estable a principios de julio.

flutter build appbundle funcionó para mí. Muchas gracias @tvolkert .

@julindra al agregar -ignorewarnings a 'proguard-rules.pro soluciona ese problema. Actualmente no incluimos el paquete android.arch. *. Otra opción es editar su android/app/build.gradle y agregar lo siguiente:

.gradle dependencies { implementation "android.arch.lifecycle:common-java8:1.1.1" implementation 'android.arch.lifecycle:extensions:1.1.1' }

cc @ matthew-carroll

Subí el paquete app.aab a Play Store. La advertencia por falta de 64 bits desapareció, pero la aplicación se bloqueó al iniciarse después de instalarla desde Play Store. ¿Alguna sugerencia?

Además, ¿es seguro usar flutter build appbundle para lanzar en producción?

@sulaysumaria ¿puedes publicar el resultado de ejecutar flutter doctor ?

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.5.4-hotfix.2, on Mac OS X 10.14.5 18F132, locale en-IN)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✗] iOS toolchain - develop for iOS devices
    ✗ Xcode installation is incomplete; a full installation is necessary for iOS development.
      Download at: https://developer.apple.com/xcode/download/
      Or install Xcode via the App Store.
      Once installed, run:
        sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
    ✗ libimobiledevice and ideviceinstaller are not installed. To install with Brew, run:
        brew update
        brew install --HEAD usbmuxd
        brew link usbmuxd
        brew install --HEAD libimobiledevice
        brew install ideviceinstaller
    ✗ ios-deploy not installed. To install:
        brew install ios-deploy
    ✗ CocoaPods not installed.
        CocoaPods is used to retrieve the iOS platform side's plugin code that responds to your plugin usage on the Dart side.
        Without resolving iOS dependencies with CocoaPods, plugins will not work on iOS.
        For more info, see https://flutter.dev/platform-plugins
      To install:
        brew install cocoapods
        pod setup
[!] Android Studio (version 3.4)
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
[✓] VS Code (version 1.35.1)
[✓] Connected device (1 available)

! Doctor found issues in 2 categories.

@truongsinh

También intenté generar apk desde el paquete de aplicaciones e instalarlo. También se bloquea al iniciarse.

$ bundletool build-apks --bundle=build/app/outputs/bundle/app.aab --output=app.apks
$ bundletool install-apks --apks app.apks

Intente cambiar al canal dev y verifique.

Intenté construir en el canal dev pero rompí una de mis dependencias. Intentaré comentarlo y compilarlo para ver si la aplicación funciona.

Además, ¿es seguro utilizar el canal dev para el lanzamiento de producción?

Ups, lo siento. Tendría más cuidado si fuera por producción.

Voy a construir APK por ahora. Aunque Google sugiere cargar paquetes en lugar de apks, será bueno si esto se corrige en la próxima versión en la rama estable.

Encontré esto usando adb logcat:

[FATAL:flutter/runtime/dart_vm.cc(389)] Error while initializing the Dart VM: Snapshot not compatible with the current VM configuration: the snapshot requires 'product use_bare_instructions no-"asserts" causal_async_stacks no-bytecode arm-eabi softfp' but the VM has 'product use_bare_instructions no-"asserts" causal_async_stacks no-bytecode arm64-sysv'

Estoy en el canal stable .

La solución de https://github.com/flutter/flutter/issues/19865 funcionó.

También tuve que eliminar la sección splits de build.gradle.

La aplicación funciona bien ahora cuando se instala a través de bundletool. Intentaré subirlo a PlayStore y comprobar si todo va bien.

@sulaysumaria, la solución solo está disponible en la rama maestra todavía. Si está estable, como se indica en su salida flutter doctor

[✓] Flutter (Channel stable, v1.5.4-hotfix.2, on Mac OS X 10.14.5 18F132, locale en-IN)

la corrección no se aplica. Debe esperar hasta que la solución sea estable si desea compilar con estable. Parece que está en algún lugar alrededor de 1.7.x hasta entonces, debe cargar las apk por separado.

Ohh ... Gracias @pythoneer . ¿Sabes cuándo estará disponible en el canal estable?

@sulaysumaria no hay problema. Se menciona varias veces en este hilo.

Todavía esperamos que esto sea estable a principios de julio.

Funcionó en el canal dev . Usé flutter build appbundle --target-platform android-arm,android-arm64 y cargué el paquete en Play Store y funcionó perfectamente.

@sulaysumaria : debe usar las instrucciones ya preparadas con el canal maestro o dev .

@julindra al agregar -ignorewarnings a 'proguard-rules.pro soluciona ese problema. Actualmente no incluimos el paquete android.arch. *. Otra opción es editar su android/app/build.gradle y agregar lo siguiente:

dependencies {
  implementation "android.arch.lifecycle:common-java8:1.1.1"
  implementation 'android.arch.lifecycle:extensions:1.1.1'
}

cc @ matthew-carroll

Gracias. Solo uso el canal de desarrollo y agrego -ignorewarnings , funciona perfecto.

funcionó para mí con flutter build appbundle
https://github.com/flutter/flutter/issues/18494#issuecomment -489807239

@blasten, ¿ se puede cerrar en este momento o queda trabajo por hacer?

@cbracken , creo que esto se puede cerrar ahora o después de la próxima versión estable.

¿Todavía planea abordar el problema de incompatibilidad con el dispositivo ZenFone 2 y dispositivos x86 similares que permiten la instalación de aplicaciones ARM desde Play Store y usan libhoudini para ejecutarlas?

Intenté construir en el canal dev pero rompí una de mis dependencias. Intentaré comentarlo y compilarlo para ver si la aplicación funciona.

Además, ¿es seguro utilizar el canal dev para el lanzamiento de producción?

Nunca he usado ninguna rama en lugar de dev y mis aplicaciones funcionan a la perfección. Así que confíe en la sucursal que nunca decepciona. @sulaysumaria

@matthewlloyd escuchamos del equipo de Play Store que es mejor agregar un binario x86 explícito que intentar hacer que nuestros binarios existentes funcionen bien con el traductor arm-> x86. - Sin embargo, el equipo recientemente mejoró el código que genera el compilador de Dart, y me pregunto si eso quizás hizo que la traducción funcionara. Inténtalo y cuéntame. De lo contrario, dependiendo de la situación, es posible que deba compilar la versión JIT para x86, que generalmente se usa para depurar / generar perfiles en emuladores.

@blasten Gracias por la información. Me pone en un pequeño aprieto porque no tengo uno de estos dispositivos, solo dos reseñas anónimas de Play Store de usuarios descontentos de ZenFone 2, por lo que no tengo forma de probar. El riesgo de romper cosas es demasiado grande para lanzar otra compilación de paquete de aplicaciones hasta que alguien confirme que el código mejorado realmente funciona en esos dispositivos. A menos que haya una manera de decirle a Play Store que excluya dichos dispositivos, continuaré lanzando compilaciones creadas con una versión anterior de Flutter (y APK de 32 bits), hasta que Google lo pruebe y confirme que lo ha arreglado, o que ya no se confirme como un asunto. Supongo que no será así hasta que se envíen más aplicaciones a la tienda con el nuevo formato appbundle / .so. Voy a esperar...

para aquellos que todavía buscan, aquí estaba la solución que funcionó para mí:

Flutter build apk --split-per-abi
no funcionó, incluso después de editar build gradle
de https://flutter.dev/docs/deployment/android#build -an-apk

en su lugar, use:

  1. appbundle de compilación de aleteo
  2. y luego cargue app.aab

problema solucionado para 32 y 64 bits, y el lanzamiento de la alerta no cumple con el requisito de Play 64 bits ".

Gracias @ juliengit2 , flutter build appbundle funciona.

Vale la pena mencionar también la versión Flutter, porque tenía la v1.5.0 hasta ahora y no funcionó.
Tuve que actualizar (actualmente a v1.7.9) para que funcione.

@PerechicK , ¿por último te

Canal DEV, como aparece hoy aquí: https://flutter.dev/docs/development/tools/sdk/releases?tab=windows

Todavía no sé desde qué versión se solucionó este problema.

Cuando uso cualquier otra cosa que no sea la rama estable, me encuentro con uno de mis complementos que arroja el error "Los métodos marcados con @UiThread deben ejecutarse en el hilo principal", que se introdujo con este flutter sdk commit https: // github. com / flutter / engine / commit / 2c9e37c34e79475bbde7c8163eb5e56cdb9662a1.

¿Hay alguna forma de compilar el paquete de aplicaciones de 64 bits mientras se usa la rama estable 1.5.4-hotfix.2?

@uj este problema https://github.com/flutter/flutter/issues/33562 podría estar relacionado con su error si usa firebase_database .

y no se introdujo 64 bits en 1.7.4+ según Flutter Docs

No, no es firebase_database, en realidad es OneSignal, pero su única solución es "usar la rama estable de Flutter"

¿Hay alguna forma de compilar el paquete de aplicaciones de 64 bits mientras se usa la rama estable 1.5.4-hotfix.2?

@uj aunque no puede compilar un paquete de aplicaciones de 64 bits con 1.5.4-hotfix.2 , puede compilar 2 apks, uno con 32 bits y otro con 64 bits, cargue ambos apks en Google Store para resolver la advertencia.

El paquete de aplicaciones Flutter 1.5.4-hotfix.2 actualmente se dirige a android-arm, que crea solo código nativo de 32 bits ( flutter build appbundle -h ). Para cambiar esto, ejecute flutter build appbundle --target-platform=android-arm64 para cambiar el objetivo predeterminado.

Esto ahora está en vivo en el canal beta, en la versión v1.7.8+hotfix.2

@tvolkert - excelentes noticias, gracias. ¿Sería más específico cuándo podríamos esperar que la solución viva en estable , por ejemplo, una fecha en la que esto sucederá?

@ angel1st https://en.wikipedia.org/wiki/Forward-looking_statement 🙂

(estamos trabajando para que suceda lo antes posible)

@tvolkert : teniendo en cuenta el hecho de que estamos a unas tres semanas de la fecha límite de Google para las aplicaciones de 64 bits, también esperaría una fecha límite de su parte. Además, nosotros, como desarrolladores, necesitaremos un tiempo de amortiguación entre su lanzamiento y la fecha límite mencionada anteriormente para que podamos construir, probar y lanzar nuestras aplicaciones sin molestar a nuestros clientes.
Aparte de eso, realmente aprecio los esfuerzos y los resultados de los últimos meses, pero espero que pueda ponerse en nuestro lugar y ver cómo se ven las cosas desde esa perspectiva. ¡Gracias por la comprensión y todos sus esfuerzos hasta ahora!

@ angel1st absolutamente. Según el anuncio anterior , nuestro objetivo es que esto se estabilice a principios de julio (muy pronto); simplemente no puedo predecir la fecha exacta.

Tengo este problema en la unidad 2017.4.20 o 2019.1.2, ¿cómo puedo resolverlo? esta
está en el enlace de golpe: https://stackoverflow.com/questions/56687339/what-is-this-error-in-build-adroid-and-build-app-bundle-in-unity-2017-4-17 por favor ayuda yo Porque estoy en este problema durante 2 meses gracias

Espero ver esto resuelto lo antes posible. La fecha límite es ajustada

@DoubleHub puedes cambiar al canal beta para resolverlo.
O espere a lanzar la versión estable el 8 de julio.

@ abc873693 Lo leí, creo que esperaré la versión estable. ¡Estoy feliz de que este problema finalmente se resuelva oficialmente!

@ abc873693 Experimenté problemas al intentar publicar aplicaciones de Android en Play Store usando el canal _beta_. Los informes previos al lanzamiento mostraban advertencias de accesibilidad. Parece que la aplicación no pasó de la pantalla de bienvenida. Todas las capturas de pantalla de todos los dispositivos permanecieron en la pantalla de inicio.

La solución para mí fue simplemente cambiar al canal STABLE y compilar el paquete de aplicaciones usando la marca --target-platform.

Hola a todos,

v1.7.8+hotfix.2 se ha lanzado al canal estable, por lo que esta corrección ahora está disponible en todos los canales. ¡Gracias a todos por su paciencia y ayuda en el camino!

@tvolkert ¡ Gracias! ¡Acabo de confirmar que la observación que mencioné aquí ya no existe con el canal estable!

@tvolkert ¿cómo aplicar este v1.7.8+hotfix.2 en un proyecto existente? ¿Necesito recrear todo de nuevo?

@jaasaria, este problema está relacionado con la creación de su aplicación para su lanzamiento. si estás estable, necesitarás actualizar tu instalación de flutter. el problema que se informa aquí se relaciona con la creación de un paquete de aplicaciones según este enlace

@jaasaria acaba de ejecutar: $ flutter channel stable && flutter upgrade

@MaikuB Creé mi archivo src hace un mes y cada vez que construyo mi proyecto necesito ejecutar el comando flutter build appbundle --target-platform=android-arm64 lugar de flutter build appbundle para evitar el error de Play Store x64.

@dblokhin Acabo de actualizar y, afortunadamente, mi proyecto no se rompió. :) gracias

Gracias @ juliengit2 , flutter build appbundle funciona.

Vale la pena mencionar también la versión Flutter, porque tenía la v1.5.0 hasta ahora y no funcionó.
Tuve que actualizar (actualmente a v1.7.9) para que funcione.

¡Gracias por la advertencia!

Tengo flutter versión 1.7.8 + hotfix.3 ¿resultará "flutter build appbundle" con app.aab con 32 y 64 bits ambos?

extraño, probé con 1.7.8 + hotfix.3 con canal estable y recibo nuevamente la advertencia de Play Store:

"Esta versión no cumple con el requisito de 64 bits de Google Play ..."

al cargar un paquete después de: _flutter build appbundle_

Intenté también actualizar flutter pero el mismo resultado.
y con una nueva instalación de Flutter: mismo resultado

Aquí está mi conf:
m

¿¿Alguna idea??

@ juliengit2 Abra el .aab como un zip normal, vaya a la carpeta base/lib y compruebe si hay carpetas armeabi-v7a y arm64-v8a

Intenté hacerlo con mi aplicación "flutter build appbundle". La carpeta lib contiene tanto v8a como v7a. ¿Puedo enviar la actualización ahora? No quiero que llegue otra advertencia al correo electrónico de mi cabeza.

Otro caso similar de un APK lejano que recibe una advertencia https://github.com/flutter/flutter/issues/18494#issuecomment -509937209

para aquellos con el mismo problema, eliminé en build.gradle:

ndk {
    abiFilters "armeabi-v7a", "x86", "armeabi", "mips"
}

y la advertencia desapareció.

(si conserva los abifilters, aún obtendrá "la versión no es compatible" incluso con _flutter build appbundle_

Hola, construí mi appbundle con éxito, pero cuando intento subirlo a Play Store recibí este error ...
Para cargar un paquete de aplicaciones de Android, debe estar inscrito en la firma de aplicaciones de Google Play.
Exporta tu clave desde Android Studio. En el menú Generar, seleccione Generar paquete / APK firmado. Seleccione la opción Paquete y presione Siguiente. Seleccione Exportar la clave cifrada y presione Siguiente.

Intento exportar la clave cifrada de esa manera, directamente desde el módulo de Android, pero no pude terminar el proceso porque aparece este error.

Proceso 'comando' / Usuarios / oaacelasu / Documentos / flutter / bin / flutter '' terminado con un valor de salida 1 distinto de cero

bref supongo que no es la forma correcta ... ¿Existe otra solución para obtener la clave cifrada para inscribir la aplicación directamente desde el comando flutter build appbundle?

Traté de usar appbundle en playstore,
pero en android 6.0 arm 64, se bloqueó en el inicio debido a libflutter.so no se pudo encontrar, y después de verificar libflutter.so se incluyó en aab arm 64

@matthewlloyd , he reproducido esto con un Chromebook local (aunque ese Chromebook podría estar saliendo de viaje durante tres semanas el lunes. Tengo que comprobarlo). Creo que _debería_ reproducirse en la mayoría de los Chromebooks x86; creo que es probable que haya más de estos que de teléfonos x86.

el equipo recientemente mejoró el código que genera el compilador de Dart, y me pregunto si eso quizás hizo que la traducción funcionara. Inténtalo y cuéntame. De lo contrario, dependiendo de la situación, es posible que deba compilar la versión JIT para x86, que generalmente se usa para depurar / generar perfiles en emuladores.

@blasten , ¿hay alguna versión particular de Dart en la que estabas pensando? Reproduje con 2.3.1 (con flutter 1.7.8 + hotfix.2) ¿Debo probar con 2.4.0?

Además, reproduje cuando lanzamos una versión alfa. Todavía necesito ver cómo probar un paquete de aplicaciones sin pasar por Play Store.

@wreppun Gracias por

@matthewlloyd Esto es lo que apareció en el registro de

java.lang.UnsatisfiedLinkError: 
  at java.lang.Runtime.loadLibrary0 (Runtime.java:984)
  at java.lang.System.loadLibrary (System.java:1530)
  at io.flutter.view.FlutterMain.startInitialization (FlutterMain.java:122)
  at io.flutter.view.FlutterMain.startInitialization (FlutterMain.java:99)
  at io.flutter.app.FlutterApplication.onCreate (FlutterApplication.java:22)
  at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1024)
  at android.app.ActivityThread.handleBindApplication (ActivityThread.java:5549)
  at android.app.ActivityThread.-wrap2 (ActivityThread.java)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1595)
  at android.os.Handler.dispatchMessage (Handler.java:102)
  at android.os.Looper.loop (Looper.java:154)
  at android.app.ActivityThread.main (ActivityThread.java:6320)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:891)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:781)

Eso podría aparecer en algunos de sus (antiguos) registros de fallos si alguno de sus usuarios optaba por compartir estadísticas.

El dispositivo era un HP Chromebook x360.

Lamento que esto no funcione en el 100% de las configuraciones. Estamos trabajando para obtener una mejor cobertura de prueba en una variedad de SDK y dispositivos. Mientras tanto, voy a configurar algunas pruebas en el laboratorio de pruebas de Firebase.

En este punto, creo que la forma más eficaz de solucionar todos estos problemas es, probablemente, presentar nuevos problemas y vincularlos a este. @tvolkert y yo nos aseguraremos de que cada uno sea

Es muy posible que necesitemos hacer pequeños ajustes al compilador de Dart, lo que teníamos en el pasado para CPU o emuladores que tienen peculiaridades de procesador específicas. Sin probar yo mismo en un Chromebook x86 (que aún no he hecho), no puedo decirlo con certeza.

¿Quienes experimentan problemas, por favor, nos ayudarían a resolver los problemas restantes presentando nuevos problemas para cada uno? Eso sería de gran ayuda para asegurarnos de abordar cada uno de ellos. ¡Gracias!

@wreppun Gracias -

@blasten No te preocupes, eso es genial. Si alguien puede mostrar que los nuevos paquetes funcionan en un dispositivo Asus ZenFone 2, eso sería suficiente para que avance. Lamentablemente, no tengo acceso a uno, pero espero que los laboratorios de pruebas móviles de Google sí lo tengan.

@matthewlloyd no "Asus ZenFone" en el laboratorio de pruebas de Firebase. ¿Qué versión de SDK? La mayoría de las veces, el problema se puede reproducir simplemente ejecutando una versión específica del SDK de Android.

¿Qué versión de SDK? La mayoría de las veces, el problema se puede reproducir simplemente ejecutando una versión específica del SDK de Android.

😂

Hola equipo de Flutter,
Me gustaría hacer hincapié en el estado de este tema. Desde mi punto de vista, hay dos problemas graves:

  • La versión actual de flutter estable 1.7.8+hotfix.3 no crea apks estables - al menos split-per-abi no funciona como debería - arm32 tiene un problema de regresión y no se puede ejecutar en algunos dispositivos arm32 . Aún no está claro cuándo se solucionará esto;
  • Fecha límite del 1 de agosto: en aproximadamente una semana, nosotros, como desarrolladores, no podremos actualizar ni lanzar nuevas aplicaciones de flutter en Google Play Store, tan simple como eso. Teniendo en cuenta el problema de la versión actual de Flutter (como se mencionó anteriormente) y el tiempo restante, no creo que sea factible esperar tener la solución en un canal

Teniendo en cuenta los dos problemas anteriores, me gustaría sugerir el siguiente plan de contingencia, que OMI nos serviría mejor como desarrolladores:

  • Revertir el canal estable de flutter a su versión anterior al hotfix.2
  • Posponga la fecha límite del 1 de agosto por un par de meses; entiendo que esto requerirá una escalada del problema, pero espero que comprendan el impacto serio que podría tener si los desarrolladores no pueden lanzar una aplicación de flutter

Solo puedo hablar en mi nombre, pero tengo clientes con contratos y decidí pasar de React Native a Flutter, ya que creía que Google brindaría un mejor soporte para sus propios productos. Tengo proyectos en curso y aplicaciones para apoyar.
Ahora me encuentro en un caso absurdo, cuando Google me obliga a lanzar la versión apk de 64 bits y al mismo tiempo Google no me proporciona la herramienta para hacerlo (y sí, sé que el equipo de Flutter no es lo mismo que Google Play equipo, pero desde donde yo me paro, usted es la misma entidad comercial).
Si Google no entrega a tiempo, esto dará lugar a un fuerte rechazo de Flutter, ya que cada día después del 1 de agosto reducirá la credibilidad del framework.
Pido disculpas si mis palabras suenan un poco más fuertes, solo espero que puedas ponerte en mi lugar por el momento.

Cualquiera, por favor vote sobre esto, ¡y esperamos que se escuche nuestra voz!

También estoy de acuerdo con esto ... Pero como plan de contingencia, sugeriría no retroceder a la versión anterior, sino cambiar al canal dev ...

Desde mi experiencia personal, tampoco me sentía cómodo usando dev canal i inicialmente. Pensé en quedarme con el canal stable , porque ya sabes, ¡es estable! ... Pero ahora he estado usando el canal dev y lanzando aplicaciones usando paquetes de aplicaciones en Play Store sin ningún problema ... ..

La situación es algo que no debería ocurrir ya que ambos son productos de Google ...

Lo que presenté es solo una solución alternativa más simple, porque puede comenzar a enviar actualizaciones usando aab s y no apk s, que es sugerido por Google ...

@ angel1st mismo problema, mismos problemas, mismos zapatos
@sulaysumaria si cambiamos al canal de desarrollo, ¿se resolverá el problema de libapp.so?
Porque ni el canal maestro parece funcionar

Lo que presenté es solo una solución alternativa más simple, porque puede comenzar a enviar actualizaciones usando aabs y no apks, que es sugerido por Google ...

@sulaysumaria - no es tan simple como parece, créeme ... También re cambiar a dev canal parece conducir a algunas complicaciones con los paquetes de plugins de terceros y que dará lugar a un conjunto diferente de problemas.

@campioncino Creo que sí porque nunca me he enfrentado a ese problema ... Simplemente construyo el paquete de aplicación de lanzamiento y lo subo a Play Store ... Nunca muestra ninguna advertencia ... y la aplicación funciona bien cuando se instala desde Play Store ( al menos lo que mi cliente está usando hasta ahora ...)

@ angel1st , puedo entender ... en ese caso, retroceder es la única opción ... Pero esas dependencias deben actualizarse o, de lo contrario, nunca podrá actualizar a una versión más nueva ... También enfrenté ese tipo de problema con un complemento Estaba usando, afortunadamente lanzaron una versión más nueva en beta para admitir la versión más nueva de flutter ... Tal vez si el complemento no se mantiene, no deberíamos usarlo ...

@sulaysumaria Nunca me he enfrentado a este problema también ... hasta la última compilación.
Lo intentaré, pero no es tan fácil de probar, porque solo ocurre en algunos dispositivos.

Por ejemplo, en Samsung Galaxy Tab 2 7.0 P3110, Android 4.2.2 y en alguna otra tableta antigua con Android 4.1.2

Ohhh ... Mi aplicación no es para tabletas, eso es seguro ... Sería mejor si la probaras una vez ...

Hola a todos,

Aquí está el estado actual:

  1. Hay indicios de que https://github.com/flutter/flutter/issues/35838 afecta a Android 4.2 y versiones anteriores, lo que significa que afecta aproximadamente al 3% de los teléfonos Android . Estamos trabajando con las personas afectadas en ese error para identificar el alcance de la solución y rastrear posibles problemas auxiliares que probablemente solo afecten a algunas aplicaciones (como un posible error no relacionado en la máquina virtual Dart que no se manifiesta en todas las aplicaciones). Basándonos en esa investigación y su conclusión, decidiremos si es mejor parchear la versión estable actual o impulsar una nueva versión a través de los canales a estable.

  2. Si alguien prefiere compilar a partir de una versión anterior de Flutter y compilar manualmente APK de 32 y 64 bits, puede hacerlo descargando una versión anterior de Flutter aquí . Revertir nuestra versión estable no es una opción; hacerlo causaría muchos más problemas de los que resolvería.

  3. Si alguien tiene problemas para compilar para Android _que no sea https://github.com/flutter/flutter/issues/35838 , presente un problema por separado y envíeme una copia, ya que queremos rastrear dichos problemas.

  4. Por separado, estamos trabajando activamente para aumentar nuestra matriz de prueba para detectar mejor los problemas en una variedad más amplia de dispositivos / versiones de Android al principio del proceso (para que los informes de errores no sean nuestra primera línea de defensa).

@tvolkert - gracias por los comentarios. Solo para asegurarnos de que estamos en la misma página: volver a la versión anterior de Flutter no tiene sentido hasta que se posponga la fecha límite del 1 de agosto , ya que Google Play no me permitirá cargar la versión 32 de la aplicación solo después del 1 de agosto.

@ angel1st ¿Esta opción sería adecuada para su caso?

  1. Revertir el SDK de flutter a v1.5.4-hotfix.2 ( flutter version v1.5.4-hotfix.2 )
  2. Cree 2 APK separados (uno en 32 bits flutter build apk --target-platform android-arm y otro en 64 bits flutter build apk --target-platform android-arm64 )
  3. Sube ambos APK en Google Play Store

Sé que es una solución, pero al menos resuelve tanto el problema de estabilidad como el de "advertencia".

@truongsinh - gracias por la sugerencia - vale la pena considerarlo. ¿Sería tan amable de confirmar que el paso 2 de su sugerencia anterior no requerirá cambios como en la sugerencia anterior, por ejemplo, app gradle enmiendas?

@ angel1st siempre que tenga toda la aplicación en flutter (es decir, no https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps), y no haya modificado nada en Gradle archivos (es decir, archivos vanilla de flutter create ), creo que no tenemos que hacer nada.

Puede hacer la verificación rápida usted mismo (asumiendo la versión "3.4.5", siguiendo https://github.com/flutter/flutter/issues/31922#issuecomment-512292798, mi elección personal de formato para "número de compilación" es bbxxyyzz , en el que bb es solo para identificar 32 o 64 bits, xx es mayor, yy es menor, zz es parche, pero también hay otros formatos recomendados, consulte https://developer.android.com/google/play/publishing/multiple-apks#using-a-version-code-scheme):

  • flutter create hello_world
  • flutter build apk --target-platform android-arm --build-number 32030405 --build-name=3.4.5
  • mv build/app/outputs/apk/release/app-release.apk build/app/outputs/apk/release/app-release-32.apk
  • flutter build apk --target-platform android-arm64 --build-number 64030405 --build-name=3.4.5
  • mv build/app/outputs/apk/release/app-release.apk build/app/outputs/apk/release/app-release-64.apk

Incluyo los 2 APK aquí. Funcionan con mi Pixel 2. También mirando el análisis de APK, podemos ver claramente que cada APK tiene diferentes archivos libflutter.so y 4 instantáneas / aot

Screen Shot 2019-07-17 at 1855 27

app-release-32.apk.zip
app-release-64.apk.zip

Solo una nota para cuando cargue dos apks ... Google no permite cargar varios archivos que tengan el mismo número de compilación, por lo que es posible que desee cambiar el número de compilación antes de crear una apk para 64 bits.

Solo una nota para cuando cargue dos apks ... Google no permite cargar varios archivos que tengan el mismo número de compilación, por lo que es posible que desee cambiar el número de compilación antes de crear una apk para 64 bits.

Ah, es cierto que (ref https://developer.android.com/google/play/publishing/multiple-apks#Rules). Solo asegúrese de que para cada versión, el número de compilación de 64 bits sea superior a 32 bits (actualicé mi ejemplo anterior https://github.com/flutter/flutter/issues/31922#issuecomment-512223030).

Oye, recibo un mensaje de error cuando intento compilar con appbundle . flutter build apk funciona bien pero quiero publicar una nueva versión en Play Store. ¿Alguien puede ayudarme cuál podría ser la razón?

El resultado de ejecutar flutter build appbundle --target-platform android-arm,android-arm64 --flavor my_flavor --release -t "bin/main.dart es el siguiente:

Initializing gradle...                                              0,6s
Resolving dependencies...                                           2,0s
Running Gradle task 'bundleMy_AppRelease'...                   
Running Gradle task 'bundleMy_AppRelease'... Done          1,9s
Gradle build failed to produce an Android bundle package.

Lamentablemente, el mensaje de error no es realmente útil. También la salida de flutter doctor:

[✓] Flutter (Channel stable, v1.7.8+hotfix.3, on Mac OS X 10.14.5 18F132, locale de-DE)
    • Flutter version 1.7.8+hotfix.3 at /Users/tom/development/flutter
    • Framework revision b712a172f9 (2 weeks ago), 2019-07-09 13:14:38 -0700
    • Engine revision 54ad777fd2
    • Dart version 2.4.0

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Users/tom/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.3, Build version 10G8
    • CocoaPods version 1.6.1

[✓] iOS tools - develop for iOS devices
    • ios-deploy 1.9.4

[✓] Android Studio (version 3.4)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 36.1.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[✓] Connected device (1 available)
    • iPhone Xʀ • 095B1A07-E138-4A80-9783-8CA36DC8049A • ios • com.apple.CoreSimulator.SimRuntime.iOS-12-4 (simulator)

• No issues found!

Editar
Si trato de usar --split-per abi el edificio también falla con flutter build apk .

@wreppun Gracias -

@blasten No te preocupes, eso es genial. Si alguien puede mostrar que los nuevos paquetes funcionan en un dispositivo Asus ZenFone 2, eso sería suficiente para que avance. Lamentablemente, no tengo acceso a uno, pero espero que los laboratorios de pruebas móviles de Google sí lo tengan.

Incluso estoy enfrentando problemas con Asus Zenfone. Cuando estoy usando flutter build apk la aplicación se ejecuta en el teléfono. Pero cuando lo subo a la App Store usando appbundle, no se adelanta a la pantalla de inicio.

Alguna solución ??

Intenté compilar y lanzar una nueva versión de una de mi aplicación (app) en "Play Store", pero tuve algunos problemas.

1-) Cuando subo 32 y 64 bits, el sitio se recusa, debido a la versión de 32 bits.

2-) Cuando subo solo 32 bits, el sitio se recusa, porque necesito los 64 bits.

3-) Cuando subo solo 64 bits, el sitio funciona, pero mis clientes tal vez no tengan el Android de 64 bits. En mi teléfono celular, por ejemplo, uso esta misma aplicación, pero en mi teléfono celular simplemente funciona cuando uso el apk de 32 bits. Cuando instalo el apk de 64 bits en mi teléfono celular, se detiene en la pantalla de inicio.

¿Cómo debo hacer ahora para liberar?

Tigerclaw1980 usa la opción de paquete de aleteo

Tigerclaw1980 usa la opción de paquete de aplicaciones Flutter

Usé Delphi Beta para hacer archivos apk de 32 y 64 bits. No sé si esta opción está disponible

Intenté compilar y lanzar una nueva versión de una de mi aplicación (app) en "Play Store", pero tuve algunos problemas.

1-) Cuando subo 32 y 64 bits, el sitio se recusa, debido a la versión de 32 bits.

2-) Cuando subo solo 32 bits, el sitio se recusa, porque necesito los 64 bits.

3-) Cuando subo solo 64 bits, el sitio funciona, pero mis clientes tal vez no tengan el Android de 64 bits. En mi teléfono celular, por ejemplo, uso esta misma aplicación, pero en mi teléfono celular simplemente funciona cuando uso el apk de 32 bits. Cuando instalo el apk de 64 bits en mi teléfono celular, se detiene en la pantalla de inicio.

¿Cómo debo hacer ahora para liberar?

@ Tigerclaw1980 , ¿solucionaste este error?

¿Fue útil esta página
0 / 5 - 0 calificaciones