Al encender el teléfono, se le solicita de forma predeterminada que ingrese el SIM-PIN, que es una buena medida de seguridad para evitar que "extraños" le causen costos. Ahora se aplica lo mismo al regresar del modo avión: uno tiene que ingresar el SIM-PIN nuevamente. Lo que hace que ciertos ahorradores de energía sean inútiles: si una aplicación, por ejemplo, ingresa al modo avión en caso de pérdida de señal (consulte: ¿Qué es el modo de espera de la celda y cómo puedo evitar que consuma mi batería? ), no podría volver a la operación normal sin la interacción del usuario .
Estoy buscando una manera de deshabilitar esto de manera selectiva : tenga la solicitud de PIN activa cuando encienda el dispositivo, pero no se le solicite el PIN de SIM cuando regrese del modo avión.
No confunda esto con "keyguard": no estoy preguntando sobre el bloqueo de pantalla (PIN/patrón/contraseña). Aquí conozco mi camino, ya que hay una API para que las aplicaciones la usen (por lo que puedo, por ejemplo, desactivarla temporalmente con Tasker ).
Sé que esto funciona con dispositivos Samsung, pero preferiblemente quiero una solución independiente del dispositivo que funcione para todos los fabricantes.
DESCARGO DE RESPONSABILIDAD
SOLUCIÓN ALTERNA
Encontré una solución para el problema que funciona maravillosamente en un Samsung Galaxy S2 con Cyanogenmod 10.2 y Dorimanx Kernel 9.41 instalados. Los pasos necesarios son los siguientes:
Asegúreses de que su dispositivo esté hackeado.
Descargue e instale el instalador de Xposed Framework .
Cuando Xposed solicite rootear en cualquier lugar en un futuro cercano, concédelo .
Abra la aplicación y haga clic en Framework-Tab.
Haga clic en Install/Update.
reiniciar _
Descargue e instale Jelly Bean 4.x Airplane Mode Helper .
Abra Xposed Framework Installer-App de nuevo y seleccione Modules.
Marque (establecer activo) Jelly Bean 4.x Airplane Mode Helper.
reiniciar _
abierto Jelly Bean 4.x Airplane Mode Helper_
Marque (establecer activo) Habilitado .
reiniciar _
¡Eso es! El modo avión debería volver a funcionar como en las versiones anteriores de Android y ya no solicita el PIN de la SIM cuando se apaga. Sin embargo, todavía lo hace al inicio, lo que mantiene su tarjeta SIM algo segura. Configuré un procedimiento automatizado de ahorro de batería con perfiles de ubicación de Llama similar al que se describe aquí (Muchas gracias, Izzy) y funciona perfectamente.
¡Buena suerte, amigos!
La respuesta está en la fuente... parece ser que la propiedad para solicitar el bloqueo de pines está integrada en build.propo default.prop.
Eche un vistazo a la referencia que se encuentra en la fuente de TelephonyManager , entre las líneas 735 y 755. Para abreviar,
public int getSimState() {
String prop = SystemProperties.get(TelephonyProperties.PROPERTY_SIM_STATE);
if ("ABSENT".equals(prop)) {
return SIM_STATE_ABSENT;
}
else if ("PIN_REQUIRED".equals(prop)) {
return SIM_STATE_PIN_REQUIRED;
}
else if ("PUK_REQUIRED".equals(prop)) {
return SIM_STATE_PUK_REQUIRED;
}
else if ("NETWORK_LOCKED".equals(prop)) {
return SIM_STATE_NETWORK_LOCKED;
}
else if ("READY".equals(prop)) {
return SIM_STATE_READY;
}
else {
return SIM_STATE_UNKNOWN;
}
}
La clave es TelephonyProperties.PROPERTY_SIM_STATEla que se menciona en otra parte , entre las líneas 94 y 98.
//****** SIM Card
/**
* One of <code>"UNKNOWN"</code> <code>"ABSENT"</code> <code>"PIN_REQUIRED"</code>
* <code>"PUK_REQUIRED"</code> <code>"NETWORK_LOCKED"</code> or <code>"READY"</code>
*/
static String PROPERTY_SIM_STATE = "gsm.sim.state";
Después de buscar en el código fuente aquí en mi máquina, le daré una idea de la frecuencia con la que getSimStatese llama a este método, observe los nombres de la fuente de Java para tener una idea de cómo está integrado en Android, no solo en la capa de Telefonía sino en otra parte.
services/java/com/android/server/am/BatteryStatsService.java 219: int simState = TelephonyManager.getDefault().getSimState();
telephony/java/android/telephony/TelephonyManager.java 523: public int getSimState() { 551: * @see #getSimState 562: * @see getSimState
policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.java 478: public IccCard.State getSimState() {
policy/src/com/android/internal/policy/impl/KeyguardViewMediator.java 545: final IccCard.State state = mUpdateMonitor.getSimState();
policy/src/com/android/internal/policy/impl/LockPatternKeyguardViewProperties.java 57: final IccCard.State simState = mUpdateMonitor.getSimState();
policy/src/com/android/internal/policy/impl/LockScreen.java 273: mStatus = getCurrentStatus(updateMonitor.getSimState());
policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java 173: && (mUpdateMonitor.getSimState() == IccCard.State.ABSENT); 217: final IccCard.State simState = mUpdateMonitor.getSimState(); 469: && (mUpdateMonitor.getSimState() != IccCard.State.PUK_REQUIRED)) { 512: secure = mUpdateMonitor.getSimState() == IccCard.State.PIN_REQUIRED 513: || mUpdateMonitor.getSimState() == IccCard.State.PUK_REQUIRED; 643: final IccCard.State simState = mUpdateMonitor.getSimState(); 662: final IccCard.State simState
= mUpdateMonitor.getSimState();
policy/tests/src/com/android/internal/policy/impl/LockPatternKeyguardViewTest.java 49: public IccCard.State getSimState() {
¿Esos nombres de archivo dan una pista, sí, en la pantalla de bloqueo...
Esto requiere raíz en este punto, invocando adb shelly llamando getpropy setproppara hacer esto, la única parte es esta, invocando
adb shell getpropobtendrá la información pertinente como se muestra a continuación
sh-4.1# getprop
[gsm.sim.state]: [READY]
Esta propiedad sutil parece persistir dinámicamente en una tienda de propiedad de respaldo, desde el momento del encendido y se ajusta en consecuencia, en función de la cantidad de cosas, el servicio y sin mencionar la caída accidental del teléfono, lo que puede dañar la tarjeta SIM. su lector que cambiaría el estado de la tarjeta a " no lista " o " desconocido ". ( ref: system/core/include/cutils/properties.h y system/core/toolbox/ [ getprop | setprop ].c)
Ahora, en este punto, teóricamente, al invocar setprop antes de bloquear la pantalla, podría eludirse temporalmente, pero, de nuevo, ¡eso podría restablecerse mediante la capa de telefonía! ¡No he probado eso! Lo que lleva a esto...
La única forma en que esto se puede desactivar es deshabilitar efectivamente la solicitud de bloqueo de PIN en la tarjeta SIM real . Ahí es donde se almacena el indicador de bits "mágico", en el que la capa RIL de la telefonía lo lee a través de la biblioteca patentada de htc/samsung/qualcomm, y eso evitaría la propagación de la persistencia de la propiedad "PIN_REQUIRED" hasta las capas de Android.
Esto requeriría piratear y volver a compilar la fuente. Para el modo avión, al entrar en ese modo y salir del modo avión, la propiedad podría dividirse en dos, gsm.sim.state puede dejarse como está, pero diseñe otra propiedad, algo como esto, gsm.sim.state. avión.modo y asigne un valor a lo largo de las líneas de SIM_STATE_PIN_NOT_REQUIRED, y modifique la verificación del modo avión, para leer esa propiedad y, si se establece en eso, no muestre el cuadro de diálogo pin, de lo contrario, como lo hace normalmente, pídale.
No estoy seguro de que necesites hacer lo que estás tratando de hacer.
En su lugar, podría:
Taskertareas para activar/desactivar todo lo que Airplanehace el modo de activación/desactivación.Airplanemodo. Usa tus Taskertareas.Es posible que deba ver si alguna aplicación está habilitada para encender automáticamente una radio de hardware. Mire para ver si una aplicación intenta sincronizar en segundo plano o lo que sea, podrían intentar activar las radios deshabilitadas. Si es así, deshabilite la capacidad de esa aplicación para encender automáticamente su WiFi, por ejemplo. Digo esto porque Airplaneel modo ciertamente detuvo las conexiones WiFi inesperadas antes, pero ya no, si prueba esta respuesta.
También puede configurar Taskerpara que siempre entre en Airplanemodo al apagar. De esa manera, vería el bloqueo de PIN en el momento del arranque.
izzy