Greetings stackoverflow.
Recently, I'm tracing the Bluetooth operating mechanism in Android framework. I've notice that there's some file type limitation which is made by this patch while receiving files via OPP.
in package com.android.bluetooth.opp , there's a fixed white list in 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 ... */
};
which limits the acceptable file types in 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;
What makes us concern about the MIME type in this situation? In my knowledge, we may like to block the executable files (i.e. *.apk, *.so) since those files may harm our device. If blocking some specific types is the reason we set a list here, why would we use a white list instead of a black list just before this patch? Is there some similar limitation when we transmit files via other non-bluetooth protocol such as HTTP?
I voted your question up and marked it as non-constructive at the same time. The question is great but it's asked in the wrong place: you need to file your complaint as a bug/suggestion in android bug tracker.
To answer your question - it's a tendency of not letting the user shoot himself in the foot by restricting his access to a both a gun and a his own foot. Maybe custom ROMs are free from this limitation.