java - unbound - service onbind

Permiso de denegación de servicio remoto en enlace

Question

Tengo un servicio remoto, al que se pueden enlazar aplicaciones externas. Hay situaciones en las que me gustaría rechazar el enlace. Según la documentación ,

Devuelva el canal de comunicación al servicio. Puede devolver nulo si los clientes no pueden vincularse al servicio.

@Override
public IBinder onBind(final Intent intent) {
    return null;
}

El hecho de devolver un IBinder nulo no devuelve un objeto IBinder y, por lo tanto, impide la conexión, sin embargo, la aplicación que realiza la llamada no recibe correctamente esta "información".

boolean bound = context.bindService(intent, serviceConnection, flagsHere);

Ya sea que devuelva el valor nulo o no del Servicio, ¿esto siempre devuelve verdadero?

Según la documentación ,

Devoluciones: si se ha vinculado con éxito al servicio, se devuelve true; se devuelve falso si no se realiza la conexión, por lo que no recibirá el objeto de servicio

Había asumido que devolver null desde onBind hubiera causado que bindService devolviera falso. Los supuestos nunca son una buena idea ...

Sin embargo, devolver un valor nulo impide que se invoque la instancia de ServiceConnection , pero una consecuencia de esto no sería una opción para verificar si el onServiceConnected es de hecho nulo en onServiceConnected .

Entonces, mi pregunta: ¿Cómo puede ''saber'' una aplicación si la solicitud vinculante ha sido denegada?

Además, si decido sobre la marcha que se onRebind una solicitud de onRebind (después de haber devuelto true de onUnbind ), parece que no puedo anular el comportamiento para evitar esto:

@Override
public void onRebind(final Intent intent) {

    if (shouldAllowRebind(intent)) {
        super.onRebind(intent);
    } else {
        // ?
    }
}

Espero que alguien pueda arrojar algo de luz para mí. Gracias por adelantado.

Answer 1

Probablemente tengas que crear una solución. Veo dos opciones aquí:

• Devuelva un Binder sin ninguna funcionalidad si la solicitud debe ser denegada. El cliente entonces tiene que verificar si la funcionalidad deseada está ahí.
• Siempre devuelva el mismo Binder , pero deje que cada método lance una Exception (por ejemplo, SecurityException ) si la llamada no está permitida. (Esto también fue sugerido por @CommonsWare en los comentarios)

Personalmente preferiría el segundo enfoque, ya que es más flexible. (por ejemplo, permite el permiso / rechazo por llamada, resuelve el problema de negar cosas después de una revinculación, etc.)