parse - java.lang.numberformatexception: for input string:
Integer.parseInt y NumberFormatException en Android (4)
Ejecuté el siguiente código en mi aplicación de Android
Integer.parseInt("+91");
En Android 5.0 (Lollipop), no lanzó ninguna excepción ya que +91
es un número entero. Pero en Android 4.4.x (KitKat) y versiones inferiores lanza:
NumberFormatException: Int no válido: "+91"
¿Cómo está la versión de Android causando esta diferencia?
Este comportamiento es en realidad parte de Java 7, como indican los docs :
Analiza el argumento de cadena como un entero decimal firmado. Todos los caracteres de la cadena deben ser dígitos decimales, excepto que el primer carácter puede ser un signo menos ASCII ''-'' (''/ u002D'') para indicar un valor negativo o un signo más ASCII ''+'' (''/ u002B'') para indicar un valor positivo.
Sin embargo , en Java 6 solo se aceptó el símbolo -
.
El Android SDK 21+ tiene dependencias de JDK7, que es probablemente la razón por la que está experimentando este comportamiento.
Funciona después de Java 7.
Android 5 presenta la nueva característica parseInt como la versión Java 7: la respuesta de Martin Nordholts apunta exactamente a la revisión
Entonces, esto significa que su Lollipop usa un sdk más nuevo basado en Java 7 que tiene el método parseInt con la parte de manejo de signos también.
KitKat introdujo algunas características de java 7 en el sdk 19 de Android, pero no el nuevo parseInt. Las versiones más bajas utilizan una implementación anterior de parseInt (versión de Java 6) por lo que obviamente también fallarán.
La diferencia entre las implementaciones de parseInt: documentación de Java 6 parseInt vs documentación de Java 7 parseInt
Se agregó soporte para explícito +
en este compromiso :
Support explicit + in Byte, Short, Integer, Long.
Bug: 5239391
Change-Id: I2b25228815d70d570d537db0ed9b5b759f25b5a3
que se ha incluido a partir de android-5.0.0_r1
. Si ha recuperado el repositorio Git, puede verificar con:
git tag --contains 6b40837ee3a023bba698c38fd6d6e46ae0065a55
lo que te da
android-5.0.0_r1
android-5.0.0_r2
android-5.0.0_r3
...
Aunque la documentación puede dar una idea de por qué se realizó el cambio (para lograr el comportamiento de Java 7 como lo señalan otras respuestas), el análisis del historial del código fuente brinda la respuesta más precisa cuando cambió el comportamiento, ya que la documentación no coincide necesariamente con la implementación .