2012-09-19 24 views
9

Mi aplicación tiene información de usuario sensible y debemos implementar una pantalla de código de acceso para mostrarla cada vez que el usuario abre la aplicación. Aquí están los dos enfoques que intenté después de leer this post.Implementar bloqueo de contraseña para la aplicación Android

  1. utilizar una variable estática y restablecerla en onStop() de cada actividad y comprobar de nuevo en el onStart() de cada actividad y mostrar la pantalla de código de acceso si el tiempo cruzó un umbral mínimo decir 1-2 segundos. El problema con este enfoque es que mi aplicación también utiliza intenciones para llamar a escáneres de cámaras y códigos de barras y los usuarios pueden pasar períodos más largos en estas aplicaciones externas. Puedo aumentar el umbral en este caso pero complica los cálculos y no es una solución muy buena.

  2. Probé la otra aproximación utilizando este método.

    protected boolean isAppOnForeground(final Context context) { 
    List<RunningAppProcessInfo> appProcesses = ((ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE)).getRunningAppProcesses(); 
    
        if (appProcesses == null) { 
         return false; 
        } 
    
        final String packageName = context.getPackageName(); 
    
        for (RunningAppProcessInfo appProcess : appProcesses) { 
         if ((appProcess.importance == RunningAppProcessInfo.IMPORTANCE_FOREGROUND) && 
          appProcess.processName.equals(packageName)) { 
          return true; 
         } 
        } 
        return false; 
    } 
    

Pero esto siempre devolverá cierto cuando puedo comprobar que en el método onStart de cada actividad ya que el proceso ya iniciado por el tiempo que está en onStart

¿Hay algún otro enfoque que ¿Puedo mostrar una contraseña cuando el usuario abre la aplicación? Debería mostrarse incluso cuando el usuario haga clic en la pantalla de inicio para salir de la aplicación y luego vuelva a la aplicación desde aplicaciones recientes.

+0

no estoy seguro, pero si puede hacer un servicio y cada uno dice 1 o 2 segundos llame antes, y cambie una variable a verdadero/falso, y en actividad en hoja de vida, simplemente verifique verdadero/falso – Amit

+0

Para # 1, qué sobre una cadena de tipo de cookie/sesión UNIFORMIZADA y almacenada almacenada en una * SharedPreference * privada - puede establecer el tiempo de espera por unos minutos y esto podría permitir a los usuarios salir y regresar a su aplicación. – pjco

+0

Otra posible solución es convertirse en administrador del dispositivo para utilizar el bloqueo del dispositivo en lugar de un bloqueo de pin personalizado de la aplicación. esto puede ser mejor o peor dependiendo de cómo lo mires. si tiene muchas aplicaciones que requieren seguridad, se trata de un bloqueo único para todas las aplicaciones. si solo tiene una aplicación, los usuarios se molestan porque su aplicación les obliga a tener una pantalla de bloqueo. –

Respuesta

4

he implementado esta característica exacta. esencialmente hice tu # 1, pero de una manera un poco más limpia.

lo que hice fue escribir una subclase abstracta de Activity, y anular onResume(). allí, decide si necesitas mostrar la pantalla de bloqueo de pin. si lo hace, termínese y comience la actividad de bloqueo de pin. Haga que todas sus actividades amplíen esta actividad.

para recordar dónde se encontraba, puede agregar un "intento de inicio" adicional a la intención utilizada para iniciar la actividad de bloqueo de pin. cuando la aplicación está desbloqueada, la actividad de bloqueo de pin puede usar ese extra para poner al usuario de nuevo donde estaban.

si su aplicación estaba basada en fragmentos, esto sería simple. siempre que se reanude la actividad que alberga todos los fragmentos, se muestra el fragmento de bloqueo de pin. eso es todo.

el problema con una aplicación que consiste en un conjunto de actividades es que no hay un momento definitorio claro para "iniciar" la aplicación. el concepto no existe este es esencialmente el problema que encontraste con tu solución # 1. onResume() parece una buena opción, pero eso se puede llamar por muchas razones. por ejemplo, el usuario inicia la actividad A, que inicia la actividad B. ahora presionan hacia atrás. mostrar el bloqueo de pin, o no?

Cualquier solución que utilice un subproceso que compruebe los procesos en primer plano es una idea terrible debido al impacto de la batería.

Finalmente, es posible que desee cuestionar el requisito de tener un bloqueo de pin cada vez que la aplicación se pone en primer plano. parece excesivo si salgo para leer un mensaje de texto y vuelvo 10s más tarde, me veo obligado a volver a ingresar un pin. basado en el tiempo parece más apropiado.

+0

La única diferencia con 'onResume()' vs 'onStart()' es que 'onResume()' se puede llamar después de que se haya cerrado un diálogo. Eso podría ser una ventaja o una desventaja, supongo. – pjco

+0

@pjco, creo que 'onStart/Stop()' es probablemente una mejor opción por el motivo que identificó. –

+0

@Jeff: Gracias. De hecho, estaba haciendo una actividad base desde la cual se subclasificaron casi todas mis actividades e implemento la verificación de código en los métodos onStart y onStop. No me importa eso cuando los usuarios abren diálogos porque ya están en la aplicación. Estoy totalmente de acuerdo con el impacto de la batería y definitivamente no tomaría el enfoque de servicio en segundo plano solo para este control. Y en cuanto a requerir un código de acceso, sí, es muy importante para mi aplicación. Los usuarios realmente lo demandan y dan un voto negativo ya que no lo tengo. Por supuesto, lo haré opcional para quien lo desee. – achie

Cuestiones relacionadas