¿Por qué Android limita los tipos de archivos aceptables tan estrictamente mientras se recibe a través de Bluetooth OPP?

Question

Saludos stackoverflow.

Recientemente estoy rastreando el mecanismo operativo Bluetooth en el marco de Android. Me he dado cuenta de que hay una limitación de tipo de archivo que se realiza por this patch mientras se reciben archivos a través de OPP.

en el paquete com.android.bluetooth.opp, hay una lista blanca fija en Constants.java

/** 
* The MIME type(s) of we could accept from other device. 
* This is in essence a "white list" of acceptable types. 
* Today, restricted to images, audio, video and certain text types. 
*/ 
public static final String[] ACCEPTABLE_SHARE_INBOUND_TYPES = new String[] { 
    /* ... some types such as images and music ... */ 
}; 

que limita los tipos de archivos aceptables en BluetoothOppObexServerSession.java

 // Reject policy: anything outside the "white list" plus unspecified 
     // MIME Types. 
     if (!pre_reject 
      && (mimeType == null || (!Constants.mimeTypeMatches(mimeType, 
        Constants.ACCEPTABLE_SHARE_INBOUND_TYPES)))) { 
     if (D) Log.w(TAG, "mimeType is null or in unacceptable list, reject the transfer"); 
     pre_reject = true; 
     obexResponse = ResponseCodes.OBEX_HTTP_UNSUPPORTED_TYPE; 

Lo que nos hace preocupación por el tipo MIME en ¿esta situación? En mi conocimiento, podemos bloquear los archivos ejecutables (es decir, * .apk, * .so) ya que esos archivos pueden dañar nuestro dispositivo. Si el bloqueo de algunos tipos específicos es la razón por la que establecemos una lista aquí, ¿por qué usaríamos una lista blanca en lugar de una lista negra justo antes de este parche? ¿Existe alguna limitación similar cuando transmitimos archivos a través de otro protocolo que no es Bluetooth, como HTTP?

Answer 1

He votado su pregunta y la he marcado como no constructiva al mismo tiempo. La pregunta es excelente, pero se formula en el lugar equivocado: debe presentar su reclamo como un error/sugerencia en el rastreador de errores de Android.

Para responder a su pregunta, es una tendencia a no permitir que el usuario se pegue un tiro en el pie al restringir su acceso a un arma y un pie. Tal vez ROM personalizados están libres de esta limitación.

Answer 2

Se espera que el perfil OBEX alcance interoperabilidad a nivel de aplicación para los formatos de contenido intercambiados. Por ejemplo, si se empuja/tira una tarjeta de visita, la aplicación local debe comprender el formato de la tarjeta de visita para poder mostrarla en la ubicación adecuada (por ejemplo, la ubicación de los contactos) y debe comprender el formato para mostrarla en su aplicación de contactos local. . OPP especifica formatos de contenido para guías telefónicas (vCards), calendario, mensajería, notas, etc. Por lo tanto, el servidor debe admitir el formato de objeto particular que el cliente intenta enviar para poder tomar las medidas adecuadas con el objeto recibido.

Para una transferencia/intercambio más genérico de archivos, se puede usar el perfil de FTP.