Comunicación de Android entre dos servicios
Sé que una actividad puede comunicarse con un servicio local usando la interfaz de IBinder; Estoy tratando de encontrar una forma de comunicación entre dos servicios.
Específicamente, tengo mi servicio principal iniciando un IntentService para manejar las subidas de archivos. Quiero que este IntentService informe de nuevo al servicio principal una vez que se termine de cargar, y antes de que muera.
- El servicio de Android que se estaba ejecutando cuando se apagó el teléfono se inicia automáticamente cuando se inicia el teléfono
- ¿Cuántas maneras de un servicio android para comunicarse con otros componentes dentro de la misma aplicación?
- Usar SharedPreferences en modo multiproceso
- StopSelf () vs stopSelf (int) vs stopService (Intención)
- StopSelf no detiene mi servicio
¿Alguna idea acerca de cómo esto sucedería?
- Uso del servicio para ejecutar fondo y crear notificaciones
- Hacer que la actividad se ejecute en segundo plano
- Servicios de Android: Bind on demand vs. Bind on #onCreate ()
- El sistema Android eliminó mi servicio cuando borro todas las aplicaciones recientes
- OnServiceConnected a veces no se llama después de bindService en algunos dispositivos
- No se puede iniciar el temporizador en un servicio en android
- Vinculación / desvinculación a un servicio en una aplicación
- Cómo manejar onServiceConnected después onPause?
Usted tiene que utilizar BroadcastReceiver para recibir intenciones, y cuando usted quiere comunicarse simplemente hace un intento con los valores apropiados.
De esta manera usted debe ser capaz de hacer una comunicación bidireccional entre cualquier componente.
En Android, hay una forma especial de completar tareas como la tuya. Mira AIDL (no está bien documentado en documentos oficiales, pero hay algunas fuentes adicionales en la web). Esta es una forma de implementar la comunicación bidireccional entre cualquier componente colocado en procesos separados. En comparación con BroadcastReceivers, usando esto obtendrían llamadas directas y callbacks, que estarían menos sucias que confiar en algo que vendría de algún lugar en BroadcastReceiver.
Para alcanzar el efecto necesario, tendrá que definir una interfaz para una devolución de llamada y una interfaz para realizar acciones (con una devolución de llamada suministrada o métodos de registro / anulación de registro). Después de recibir algún comando utilizando la segunda interfaz, debe realizar el trabajo y devolver el resultado a través de la devolución de llamada. Para llegar a la conclusión asíncrona, agregue una clave de trabajo "oneway" antes de la firma del método (tipo de retorno). Para separar los parámetros de entrada y salida (si es necesario), utilice las palabras clave "in", "out" y "inout" cerca de los parámetros.
Como se trata de restricciones, sólo primitivas, matrices y parcelables (y matrices parcelables) pueden ser transferidos entre procesos.
Para controlar el ciclo de vida de las devoluciones de llamada y la atomicidad de las operaciones, utilice RemoteCallbacksList para almacenar devoluciones de llamada registradas y notificar a los destinatarios utilizando el duplicado de su lista obtenido de beginBroadcast.
Si tienes algún problema, puedes preguntar aquí.