通过Intent传输图片导致广播消息异常的问题根因分析（通过分析Android源码反向推理）

Music应用负责音乐的播放，如果某音乐还有图片，也需要把图片显示出来；

当Music应用播放的音乐发生切换后，需要通过广播消息，将正在播放的音乐的名称、图片等通过广播消息通知给B应用。

如果播放的是歌曲1，应用B可以正常收到歌曲1的名称、图片等；但如果切换到歌曲2，应用B无法收到广播消息。

 

Music应用中发送广播消息的代码如下：

            System.out.println("play " + "send intent, musicTitle="                    + getTrackName() + " musicAlbum" + getAlbumName());            Intent intent = new Intent();            intent.setAction("com.zhao3546.ACTION_MUSIC_DETAIL");            intent.putExtra("musicTitle", getTrackName());            intent.putExtra("musicAlbum", getAlbumName());            Bitmap bmp = MusicUtils.getArtwork(this.getApplicationContext(),                    getAudioId(),                    getAlbumId());            intent.putExtra("musicImage", bmp);                        System.out.println("bmp.getByteCount() = " + bmp.getByteCount());                        sendBroadcast(intent);

B应用中动态注册接收广播消息的代码如下：

        IntentFilter intentFilter = new IntentFilter();        intentFilter.addAction("com.zhao3546.ACTION_MUSIC_DETAIL");        registerReceiver(mReceiver, intentFilter);

    private class MusicDetailReceiver extends BroadcastReceiver    {        @Override        public void onReceive(Context context, Intent intent)        {            final String title = intent.getStringExtra("musicTitle");            final String album = intent.getStringExtra("musicAlbum");                        System.out.println("MusicDetailReceiver.onReceiver" + " title="                    + title + " album=" + album);                        final Bitmap bmp = (Bitmap) intent.getParcelableExtra("musicImage");

播放歌曲1，输出的日志如下：

09-11 16:12:16.732: I/System.out(14177): play send intent, musicTitle=最近超级火热的变形金刚简单机械短信息音效 musicAlbumwww.mozhao.net09-11 16:12:16.776: I/System.out(14177): bmp.getByteCount() = 36723609-11 16:12:16.802: I/System.out(13265): MusicDetailReceiver.onReceiver title=最近超级火热的变形金刚简单机械短信息音效 album=www.mozhao.net

播放歌曲2，输出的日志如下：

09-11 16:12:25.266: I/System.out(14177): play send intent, musicTitle=Bach-Goldberg Variations 1 2 3 musicAlbumClassical 109-11 16:12:25.329: I/System.out(14177): bmp.getByteCount() = 524288

在使用歌曲1测试时，和使用歌曲2测试时，中间我还修改过一些代码，一开始一起以为修改代码引入的问题；

但后来使用歌曲1测试发现最新的代码也是好使的，再仔细分析日志，发现在 bmp.getByteCount() = 524288 这行日志有一个错误日志，见红色字体：

09-11 16:12:25.266: I/System.out(14177): play send intent, musicTitle=Bach-Goldberg Variations 1 2 3 musicAlbumClassical 1
09-11 16:12:25.329: I/System.out(14177): bmp.getByteCount() = 524288
09-11 16:12:25.342: E/JavaBinder(9985): !!! FAILED BINDER TRANSACTION !!!

 

手头有Android 4.2.2完整的源码，根据“FAILED BINDER TRANSACTION” 搜索了一下代码，发现是在 android_util_Binder.cpp 这个类的signalExceptionForError中输出的：

void signalExceptionForError(JNIEnv* env, jobject obj, status_t err,        bool canThrowRemoteException){    switch (err) {        ...                case FAILED_TRANSACTION:            ALOGE("!!! FAILED BINDER TRANSACTION !!!");            // TransactionTooLargeException is a checked exception, only throw from certain methods.            // FIXME: Transaction too large is the most common reason for FAILED_TRANSACTION            //        but it is not the only one.  The Binder driver can return BR_FAILED_REPLY            //        for other reasons also, such as if the transaction is malformed or            //        refers to an FD that has been closed.  We should change the driver            //        to enable us to distinguish these cases in the future.            jniThrowException(env, canThrowRemoteException                    ? "android/os/TransactionTooLargeException"                            : "java/lang/RuntimeException", NULL);            break;        ...

再根据 “FAILED_TRANSACTION” 这个关键字，进一步搜索，在IPCThreadState.cpp的waitForResponse()方法中，有如下代码：

从这个问题出现的所在的函数，我们可以知道，说明这个广播消息已经传输给Binder驱动层了，正在等待Binder驱动层回应答。

为什么？这是一个相当长的话题，如果你不知道，看一下《Android框架揭秘》，或者老罗的Blog：《Android进程间通信（IPC）机制Binder简要介绍和学习计划》。

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult){    int32_t cmd;    int32_t err;    while (1) {        if ((err=talkWithDriver()) < NO_ERROR) break;        err = mIn.errorCheck();        if (err < NO_ERROR) break;        if (mIn.dataAvail() == 0) continue;                cmd = mIn.readInt32();                IF_LOG_COMMANDS() {            alog << "Processing waitForResponse Command: "                << getReturnString(cmd) << endl;        }        switch (cmd) {        ...        case BR_FAILED_REPLY:            err = FAILED_TRANSACTION;            goto finish;                ...        }    }finish:    if (err != NO_ERROR) {        if (acquireResult) *acquireResult = err;        if (reply) reply->setError(err);        mLastError = err;    }        return err;}

IPCThreadState::waitForResponse() 将 BR_FAILED_REPLY这个错误码，转成了FAILED_TRANSACTION抛给了上层，

再看看BR_FAILED_REPLY这个错误码是在哪里生成的，进一步搜索了一下，发现这个错误码是在binder.c（Binder的驱动源码中）大量出现：

Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;Binder.c (e:\git\android4.2.2源码\driver\binder):return_error = BR_FAILED_REPLY;

binder.c 这个类通过正常方式下载的Android全量源码中是不包含的，如何下载可以参考我的另一个blog：《Android Binder驱动源码下载地址》。

再进一步分析一下之前的日志：

正常传输的图片大小 ：    09-11 16:12:16.776: I/System.out(14177): bmp.getByteCount() = 367236

无法正常传输的图片大小 ：    09-11 16:12:25.329: I/System.out(14177): bmp.getByteCount() = 524288

异常的那个图片，比正常的图片要大42%左右，再反向去推测，既然是图片过大，那这个问题可能出现在哪里？

出现BR_FAILED_REPLY关键字的地方，我都过了一下，如下地方我个人觉得最像，由于图片大小过大，导致分配buffer出现了问题：

static void binder_transaction(struct binder_proc *proc,       struct binder_thread *thread,       struct binder_transaction_data *tr, int reply){...t->buffer = binder_alloc_buf(target_proc, tr->data_size,tr->offsets_size, !reply && (t->flags & TF_ONE_WAY));if (t->buffer == NULL) {return_error = BR_FAILED_REPLY;goto err_binder_alloc_buf_failed;}

当然，仅是推测，没有进一步验证。

大概分析出了问题根因，那怎么解决，其实就比较简单了：

1、将图片保存到sd卡，将路径传给应用B，让应用B自己去从sd卡加载；

2、将图片进行压缩后再传输；

 

搞Android，有一个好处，就是遇到问题，你可以通过全部的源码去进一步分析找到问题根因；通过解决某个问题，反过来又可以加深对Android的整体的了解。