Cómo restringir los intentos de Android o agregar seguridad

He añadido un filtro de intenciones a una actividad en mi aplicación para que otras aplicaciones puedan acceder a determinados datos (desde la nube) a través de mi aplicación. Sin embargo, algunos usuarios pueden tener preocupaciones sobre la privacidad y pueden no estar muy contentos con los datos que usan. Sin embargo, otras aplicaciones pueden conectarse a la mía, para realizar copias de seguridad de sus configuraciones, etc. en la nube.

Ahora, necesito algún tipo de mecanismo de seguridad para restringir las aplicaciones que pueden acceder a la mía para que pueda desautorizar las aplicaciones maliciosas, etc. Aunque es imposible identificar una aplicación malintencionada, me gustaría algún tipo de control de acceso al permitir sólo ciertos ' Nombres de paquetes Sin embargo, no puedo encontrar cómo hacerlo.

La otra opción es agregar un requisito de permiso, pero esto puede ser pasado por alto por más usuarios. Mientras que sería la culpa de los usuarios (y sería mi culpa si no agrego el permiso), recientemente las aplicaciones han tomado un montón de flak para exponer el contenido del usuario.

La tercera opción es solicitar al usuario cada vez que una aplicación acceda a la mía. Sin embargo, no tengo el nombre de paquete, así que no puedo decir de dónde vino la intención. Además, mi aplicación automatiza ciertas transferencias desde la nube, por lo que el usuario puede "configurar y olvidar" la intención.

Confío en sólo intentos para transferir algunos comandos entre dos aplicaciones diferentes. Veo que tendré que implementar las salvaguardas yo mismo, pero no quiero reinventar la rueda si Google ya tiene algunos flujos en su lugar. Si no, tendré que implementar mi propio flujo de autenticación o algo así.

EDIT: Soy un noob así que uso términos demasiado libremente. Intenté hacer la pregunta mejor.

Un poco más sobre la aplicación. Automatiza las descargas / subidas desde / hacia un servicio en la nube. Al enviar una intención, otra aplicación puede especificar un archivo para descargar o subir. No quiero que esto suceda sin que el usuario sepa, así que le pediría que cuando el intento llega y acepto los datos. Pero también, la aplicación puede configurar transferencias periódicas. Mientras que el usuario ahora ha sido solicitado dos veces (una vez en los permisos, y una vez que la intención viene) no tiene derecho a quejarse. Pero, ¿es esta práctica aceptable o necesito salvaguardarlo de alguna manera?

Creo que usted debe mirar las funciones Binder.getCallingUid para obtener UID del proceso de llamada (y, a continuación, su nombre de paquete) o Binder.getCallingPid para obtener PID del proceso de llamada y de este pid descubrir packageName del proceso de llamada. Tenga cuidado, varios paquetes pueden usar el mismo UID (si están firmados con el mismo certificado solamente) y varios paquetes pueden compartir un proceso (pero también deben tener el mismo UID).

He añadido un filtro de intenciones en mi aplicación

No, no lo tiene. Ha agregado un <intent-filter> a una <activity> , oa un <service> , oa un <provider> , pero no a una <application> .

Ahora, necesito algún tipo de mecanismo de seguridad para restringir qué aplicaciones pueden acceder a la mía para que pueda rechazar aplicaciones malintencionadas, etc.

¿Cómo, precisamente, tiene la intención de identificar una "aplicación maliciosa"?

Mi opción preferida sería que puedo permitir intentos de ciertos "proveedores de confianza" mediante el filtrado de la intención con el nombre del paquete. Sin embargo, no puedo encontrar cómo hacerlo.

Eso no es compatible.

La otra opción es agregar un requisito de permiso, pero esto puede ser pasado por alto por más usuarios.

Si un usuario "pasa por alto" un requisito de permiso, no tienen motivos para quejarse con respecto a "preocupaciones de privacidad".

Sin embargo, no tengo el nombre de paquete, así que no puedo decir de dónde vino la intención.

En algunos casos, la recomendación de Yury funcionará.

¿Cuáles son mis opciones de seguridad cuando se trata de intentos

No existe tal concepto en Android. Intent s no tienen "seguridad", más que enteros tienen "seguridad". Las actividades, servicios y receptores de difusión representan su código y su código puede implementar medidas de seguridad para proteger dicho código.

O es este el método incorrecto para IPC?

Puesto que usted no ha indicado lo que está haciendo para IPC (aparte de que implica objetos de Intent , al parecer), es imposible responder a esta pregunta.

Si las únicas aplicaciones que están permitidas para enviar intentos a su aplicación son aplicaciones que también controla, puede crear un <permission> para su aplicación y establecer su nivel de seguridad en "firma". Esto restringiría el acceso a las aplicaciones que se firmaron con la misma clave de firma.

 <manifest ...> ... <permission name="com.thedesolatesoul.myapp.MY_ACCESS" android:permissionLevel="signature" android:label="@string/my_access_label" android:description="@string/my_access_description" /> </manifest> 

Entonces, las únicas aplicaciones que pueden enviar intenciones a su aplicación son aquellas que tienen la entrada apropiada <uses-permission> en su manifiesto y están firmadas por la misma clave.

  • Cifrado del dispositivo Android ICS
  • Poste HTTP seguro en Android
  • SecurityException: no se permite realizar OP_READ_PHONE_STATE
  • ¿Qué tan seguras son las API de GeoLocation en dispositivos móviles?
  • ¿Hay alguna forma de comprobar si la firma de una aplicación está depurada o publicada?
  • XmlHttpRequest problema de publicación doble en Android
  • SecurityException - Nombre del paquete de llamadas desconocido -Android 6.0.1
  • ¿Hay análogos javax.smartcardio en Android?
  • Comprobar si el sistema de archivos Android está encriptado
  • RSA PKCS1-OAEP padding es compatible con bouncycastle?
  • ¿Es seguro almacenar nombre de usuario y contraseñas en un SQLite local db en Android?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.