Cargando…
Acción antes del 1 de febrero de 2027Google bloquea nuevas releases en Play Store para apps que no soportan tamaños de página de memoria de 16 KB.
Arreglar mi appDesde el 1 de febrero de 2027, Google Play bloquea nuevas releases para apps que apuntan a Android 15+ y no soportan tamaños de página de memoria de 16 KB. AllsWeb actualiza tu cadena de build, recompila el AAB contra ABI de 16 KB, re-firma con tu keystore actual y publica la release en Play Console para que desaparezca el warning y puedas volver a lanzar updates.
Mejor precio cuando compartes el código fuente más reciente de instalación. ¿No tienes source? Aun podemos recompilar desde el AAB publicado, cotizado por caso para evitar sorpresas.
Play Console · Estado de política
Problema: la app debe soportar tamaños de página de memoria de 16 KB
Lo que dice Google: “Para asegurar que tu app funcione correctamente en las últimas versiones de Android, Google Play requiere que todas las apps que apunten a Android 15+ soporten tamaños de página de memoria de 16 KB.”
Fecha límite: 1 February 2027, las apps que no soporten páginas de 16 KB ya no podrán publicar actualizaciones.
Estado: tu última release en producción no soporta tamaños de página de memoria de 16 KB.
AllsWeb lo soluciona por ti
Rebuild contra ABI de 16 KB · re-firma · re-envío
La política en lenguaje claro
Traducimos el aviso de Play Console en un alcance claro, fecha límite real y precio fijo.
Google Play exige que las apps dirigidas a Android 15+ soporten tamaños de página de memoria de 16 KB. Si no lo hacen, se bloquea la publicación de nuevas releases.
Desde el 1 de febrero de 2027, si tus updates no soportan tamaños de página de memoria de 16 KB, Google no permitirá publicar esas actualizaciones, incluso parches críticos de seguridad.
Play Console muestra el banner “Policy status -> Issue details”: “Your latest production release does not support 16 KB memory page sizes.” Ese warning es exactamente el que corregimos.
Precios transparentes
Nunca ocultamos variables: tiempo, complejidad y trabajo de recuperación necesario. Siempre te mostramos primero el nivel más económico si aplica a tu app.
Compartes el source code más reciente de instalación (nuestro o de otra agencia). Hacemos rebuild contra NDK alineado a 16 KB, re-firmamos con tu keystore actual y subimos la nueva release.
¿No tienes source a mano? Extraemos el último APK / AAB desde Play Console, descompilamos, identificamos librerías nativas alineadas a 4 KB, actualizamos toolchain y recompilamos. Re-firma con tu keystore actual.
Confirmamos el precio exacto en menos de 24 horas desde tu consulta. Nunca empezamos trabajo sin tu aprobación de alcance y tarifa.
Qué necesitamos de tu lado
Te enviamos checklist de una página + nombres exactos de roles en Play Console para que mantengas el control. Nada sale de tu cuenta sin tu aprobación.
Invítanos con permisos “View app information”, “Manage testing tracks” y “Release manager” en tu app para verificar el warning, subir el nuevo bundle y publicar la release.
El mismo .jks/.keystore + key alias + passwords con el que publicaste tu release actual. Sin eso no podemos publicar en el mismo listing: Play no permite re-keying.
El .zip o repo de la instalación más reciente. Si no lo tienes, comparte quién instaló la app por última vez y te ayudamos a recuperarlo.
Cómo se ve este fix en la práctica
Nos conectamos a Play Console, confirmamos el banner de política de 16 KB, extraemos el AAB actual y listamos cada librería .so que requiere rebuild para 16 KB (propia y transitiva).
Subimos NDK r27+, Android Gradle Plugin, AGP 8+, CMake y versiones de dependencias al mínimo necesario para emitir binarios ELF alineados a 16 KB. Sin cambios de código fuera de lo estrictamente necesario.
Recompilamos el AAB release con el nuevo toolchain, hacemos regresión en Android 14, Android 15 y emuladores Android 15 de 16-page, y verificamos con `zipalign -c -p 16` y `readelf -lW`.
Re-firmamos con tu keystore actual, subimos a Play Console en el track elegido (internal -> closed -> production). El aviso de política desaparece en la siguiente revisión.
Alcance claro
Auditoría + diff de tu AAB actual
Listado de cada librería nativa alineada a 4 KB y dependencia que activa la infracción.
Upgrade de NDK / Gradle / dependencias
Subimos toolchain al mínimo que cumple ABI de 16 KB sin romper el resto de la app.
Rebuild del AAB de release
Bundle de calidad producción con verificación `zipalign -p 16` y `-c 16`.
Re-firma con tu keystore
Mismo Package ID, misma firma de datos: tus usuarios mantienen datos y credenciales.
Subida a Play Console
Nueva release en track interno, cerrado o producción, según elijas.
Smoke test de regresión pre-release
Validamos login, pagos, mapas, push e imágenes en Android 14 + emuladores Android 15 con páginas de 16 KB.
Sign-off de senior engineer
Un humano revisa y aprueba la release antes del envío, nunca una release solo de modelo.
Soporte de por vida para este fix
Si Play vuelve a marcar la misma política, re-investigamos y re-publicamos bajo soporte, sin factura extra.
Todo lo de la derecha también se puede cotizar, pero como servicio separado para que el fix 16 KB siga predecible.
Funciona para cualquier stack Android
El requisito ABI de 16 KB aplica a cualquier app respaldada por NDK, no solo Flutter ni solo CodeCanyon. Ya entregamos fixes en todos estos stacks.
Cómo funciona
Envía el enlace de Play Store, captura del warning en Play Console, stack técnico y si tienes source code.
Nos invitas a Play Console (te enviamos nombres exactos de roles). Verificamos el warning, confirmamos alcance y cerramos tarifa fija en menos de 24 horas.
Actualizamos NDK + Gradle + deps, hacemos rebuild del AAB y regresión en emuladores Android 15 con 16 KB. Te compartimos el log de verificación.
Subimos la release en Play Console con tu keystore actual. El banner de política se limpia en la siguiente revisión de Play.
Reseñas reales · clientes reales
Los mismos engineers que trabajan el resto de AllsWeb hacen también este rebuild de 16 KB. Todas las reseñas mostradas están verificadas en su plataforma original.
This is the second time I have ordered from this team. They are very professional and have excellent communication skills to understand the problem. I had some issues before, and they helped me solve them.
AllsWeb respondió: Thank you, it was nice working with you.
Verificado en Fiverr
I am very happy to find this developer to work at a very high level.
AllsWeb respondió: Thank you! I am glad to have met your expectations and look forward to future projects.
Verificado en Fiverr
Wow! Best job ever. The Allsweb gig was done quick and made professionally. I will be back soon. Thank you so much — me and my family are so happy 😀Verificado en Fiverr
I am satisfied with the excellent work. I will surely order from them again. I like how prompt, communicative and supportive he is.
AllsWeb respondió: Thank you so much for your kind words! I am really glad you are satisfied with the work.
Verificado en Fiverr
Kevin is so best to me and made my life unforgettable with his app development support. Because of his excellency I am here with you all.Verificado en Google
NiceVerificado en Google
FAQ
Android 15 (API 35+) introdujo soporte para tamaños de página de memoria de 16 KB en hardware nuevo como mejora de rendimiento sobre el tradicional de 4 KB. Las apps con librerías nativas (NDK) compiladas solo para 4 KB pueden fallar en dispositivos de 16 KB. Por eso Google Play lo convirtió en requisito de publicación: desde el 1 de febrero de 2027, las apps dirigidas a Android 15+ que no soporten páginas de 16 KB ya no pueden publicar nuevas releases.
Muy urgente. Ese banner significa que Google te dio una ventana de gracia fija. Después de esa fecha, Google bloquea cualquier nueva release de tu app (incluidos hotfixes, parches de seguridad y updates estacionales) hasta que publiques un build compatible con 16 KB. Tu release actual sigue en Play, pero no podrás actualizarla. Recomendamos resolverlo al menos 2-3 semanas antes de la fecha límite.
Por dos razones: (1) para confirmar el warning real de bloqueo en tu listing, ya que la política puede variar por app y por track; y (2) para subir el AAB reconstruido en tu listing actual con tu keystore actual, sin afectar usuarios instalados. Te enviamos una guía de una página para agregarnos con los permisos mínimos.
Porque primero hay trabajo de recuperación. Con source code solo actualizamos NDK + Gradle, recompilamos y re-testamos (normalmente 1-3 días hábiles). Sin source code, extraemos el AAB de Play Console, descompilamos, identificamos librerías nativas alineadas a 4 KB, actualizamos toolchain y recompilamos. Ese trabajo extra añade tiempo y riesgo, por eso se cotiza por caso. Siempre te damos primero el precio más bajo si aplica.
No. Mientras re-firmemos con tu keystore actual (mismo .jks/.keystore + key alias + passwords) y publiquemos con el mismo Package ID, la actualización se instala sobre la app existente: mismo login, mismos pedidos, mismas preferencias y mismo push token. Google Play no permite cambiar keystore ni Package ID de una app ya publicada.
Perder el keystore es el único bloqueo que no se puede saltar directamente: Google Play no permite re-keying de un listing existente. Si usas Play App Signing, Google gestiona upload key y puede resetearse desde Play Console (te guiamos). Si firmaste fuera de Play App Signing y se perdió de forma permanente, la única opción es una app nueva con Package ID nuevo, que cotizamos como proyecto separado.
No. Cualquier app Android que incluya librerías nativas necesita el fix de 16 KB: Flutter, Kotlin native, Java native, React Native, Cordova / Ionic, Unity y apps internas personalizadas. Los scripts de CodeCanyon (6ammart, StackFood, 6Valley, eFood, Demandium, DriveMond, HexaCom, GroFresh) son comunes porque incorporan varios SDKs que requieren rebuild.
1-3 días hábiles si tienes source code y keystore y el acceso a Play Console está aprobado. 3-7 días hábiles cuando hay que recuperar desde el AAB publicado. El contador se pausa si estamos esperando accesos o archivos de tu lado; verás el timer en vivo en la página del proyecto.
No. Este servicio es específico para Android + Play Store. iOS App Store tiene su propio track de cumplimiento (Apple notarisation, privacy manifests) y lo gestionamos por separado. Si también necesitas iOS, lo cotizamos en la misma consulta.
Las apps nuevas que apunten a Android 15+ deben nacer con soporte 16 KB desde el inicio, y eso ya forma parte de nuestro servicio estándar de envío de apps a Google Play. Esta página es para apps existentes que se construyeron antes de que 16 KB fuera requisito obligatorio.
Cuéntanos tu app, comparte acceso a Play Console y te cerramos cotización fija en menos de 24 horas. La mayoría de fixes se entregan en 1-3 días hábiles cuando hay source code.