binder机制导致的异常

• 概述
• 异常分析
• • can't deliver broadcast
  • FAILED BINDER TRANSACTION
  • • DeadObjectException
    • TransactionTooLargeException
  • DeadSystemException

  在平常程序运行过程中，可能碰到最多跟binder相关的异常是RemoteException，但本文只分析跟binder机制相关的异常，而RemoteException是server端逻辑导致的其它异常在client端的表现。
  跟binder机制相关的异常有：android.app.RemoteServiceException: can’t deliver broadcast，JavaBinder: !!! FAILED BINDER TRANSACTION !!!，TransactionTooLargeException，DeadSystemException，DeadObjectException；有没有似曾相识的异常。
  这些异常都跟上一遍文章 Android进程间通信之binder - 几个重要数字 中的数字有扯不清的关系。
  Android进程间通信之binder - 实战
  Android进程间通信之binder - 几个重要数字
  Android进程间通信之binder - debug transaction
  Android进程间通信之binder - 重要工具aidl
  Android进程间通信之binder - 上层协议IPCThreadState
  Android进程间通信之binder - 工具类Parcel

  can’t deliver broadcast

  Fatal Exception: android.app.RemoteServiceException: can't deliver broadcast
     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1813)
     at android.os.Handler.dispatchMessage(Handler.java:102)
     at android.os.Looper.loop(Looper.java:154)
     at android.app.ActivityThread.main(ActivityThread.java:6776)
     at java.lang.reflect.Method.invoke(Method.java)
     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1520)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1410)
  第一眼看到这个堆栈是不是觉得这是系统问题，跟app没有关系，其实我第一次看见也是这么判断的，还执着的认为BroadcastQueue肯定是出问题了。
   分析这个问题就带看源码？首先确定这个异常抛出的前后代码逻辑，我们一起看代码（本文代码都来自于aospxref.com android11）：
   
      void performReceiveLocked(ProcessRecord app, IIntentReceiver receiver,
              Intent intent, int resultCode, String data, Bundle extras,
              boolean ordered, boolean sticky, int sendingUser)
              throws RemoteException {
          // Send the intent to the receiver asynchronously using one-way binder calls.
          if (app != null) {
              if (app.thread != null) {
                  // If we have an app thread, do the call through that so it is
                  // correctly ordered with other one-way calls.
                  try {
                      app.thread.scheduleRegisteredReceiver(receiver, intent, resultCode,
                              data, extras, ordered, sticky, sendingUser, app.getReportedProcState());
                  // TODO: Uncomment this when (b/28322359) is fixed and we aren't getting
                  // DeadObjectException when the process isn't actually dead.
                  //} catch (DeadObjectException ex) {
                  // Failed to call into the process.  It's dying so just let it die and move on.
                  //    throw ex;
                  } catch (RemoteException ex) {
                      // Failed to call into the process. It's either dying or wedged. Kill it gently.
                      synchronized (mService) {
                          Slog.w(TAG, "Can't deliver broadcast to " + app.processName
                                  + " (pid " + app.pid + "). Crashing it.");
                          app.scheduleCrash("can't deliver broadcast");
                      throw ex;
              } else {
                  // Application has died. Receiver doesn't exist.
                  throw new RemoteException("app.thread must not be null");
          } else {
              receiver.performReceive(intent, resultCode, data, extras, ordered,
                      sticky, sendingUser);
   
  这个异常是执行scheduleRegisteredReceiver函数时抛出的RemoteException，是app.thread binder调用到server端时发生了异常，这儿的server不是system_server进程，这儿的server是指binder的server，在这儿server是app程序，（这儿衍生一个问题：这个ibinder对象是从什么地方赋值的？）既然是binder调用，肯定有一个aidl接口，找到接口描述；
   
  frameworks/base/core/java/android/app/IApplicationThread.aidl
  aidl中方法是一个正常的描述接口，第一眼看，这是一个在正常不过的binder同步调用，然而它却是一个异步调用，oneway关键字它写到哪儿了？
      void scheduleRegisteredReceiver(IIntentReceiver receiver, in Intent intent,
              int resultCode, in String data, in Bundle extras, boolean ordered,
              boolean sticky, int sendingUser, int processState);
  它的整个aidl接口统一定义为异步调用；
  oneway interface IApplicationThread {
  ...
  IApplicationThread接口中的函数都是oneway调用；
  这里需要去了解binder async调用执行流程：
   
   在这里衍生一个知识点，oneway binder在server端只有一个线程在执行，具体的可以看驱动代码；我们在后面的原理文章中会仔细去分析它。
   这个接口的参数加起来也不是很大，但是怎么就超出512k了，其实就是之前的binder调用把空间给占了，同步binder和异步空间使用同一片区域。所以说这个问题还待看到底之前的binder调用是谁，传输了多少size。是不是执行耗时。
   
  FAILED BINDER TRANSACTION
   
  DeadObjectException
   
  上面分析了原理，当前这个failed binder transaction也是binder 内存空间的问题。
   
  E/JavaBinder: !!! FAILED BINDER TRANSACTION !!!  (parcel size = 40084)                                            
  W/System.err: android.os.DeadObjectException: Transaction failed on small parcel; remote process probably died    
  W/System.err:     at android.os.BinderProxy.transactNative(Native Method)                                         
  W/System.err:     at android.os.BinderProxy.transact(Binder.java:764)                                             
  W/System.err:     at c.t.myapplication.IMyAidlInterface$Stub$Proxy.failedBinderError(IMyAidlInterface.java:149)   
  W/System.err:     at c.t.myapplication.MainActivity$2.run(MainActivity.java:47)                                   
  W/System.err:     at java.lang.Thread.run(Thread.java:764)   
  产生这个异常的代码
  
  
  
  
      
   
          //client端调用代码
          int i = 0;
          int[] val = new int[10000];
          while (i<30) {
              i++;
              new Thread(new Runnable() {
                  @Override
                  public void run() {
                      try {
                          binder.failedBinderError(val);
                      } catch (RemoteException e) {
                          e.printStackTrace();
              }).start();
          //service端执行代码，用sleep模拟了一个耗时操作
          @Override
          public void failedBinderError(int[] val) throws RemoteException {
              try {
                  Thread.sleep(1000000);  //Simulated long time operation
              } catch (InterruptedException e) {
                  e.printStackTrace();
  TransactionTooLargeException
   
   W/System.err: android.os.TransactionTooLargeException: data parcel size 1200084 bytes                               
   W/System.err:     at android.os.BinderProxy.transactNative(Native Method)                                           
   W/System.err:     at android.os.BinderProxy.transact(Binder.java:764)                                               
   W/System.err:     at c.t.myapplication.IMyAidlInterface$Stub$Proxy.failedBinderError(IMyAidlInterface.java:149)     
   W/System.err:     at c.t.myapplication.MainActivity$2.run(MainActivity.java:47)                                     
   W/System.err:     at java.lang.Thread.run(Thread.java:764)     
  为了方便对比，我把产生这个异常的代码也贴出来
   
  		//client调用代码
          int i = 0;
          int[] val = new int[300000];
          while (i<30) {
              i++;
              new Thread(new Runnable() {
                  @Override
                  public void run() {
                      try {
                          binder.failedBinderError(val);
                      } catch (RemoteException e) {
                          e.printStackTrace();
              }).start();
          //service端代码跟上面是同一个函数
  产生这两个异常的代码几乎一致，都是启动30个线程同时去调用binder方法，而同步调用的binder却是一个耗时方法，只要成功调用一次，binder service端的内存就会被占用，当重复到一定次数，内存耗尽后，在某一次调用中，binder调用返回失败； 大家还记得当前这个实例中，binder调用占用service的内存大小是多少吗？忘了可以回过头看看上一篇文章，binder的几个重要数字。 
   之所以产生了两个不同的异常，测试代码唯一不同的地方就是int 数组 val new的size不同；当前binder传输失败如果size小于200k就是第一个异常，如果当前传输大于200k，就抛出第二个异常。
   直接看代码：
   在binder调用失败后，执行此函数signalExceptionForError，针对具体error抛出相应的异常；本文只关心FAILED_TRANSACTION；
   
  void signalExceptionForError(JNIEnv* env, jobject obj, status_t err,
          bool canThrowRemoteException, int parcelSize)
      switch (err) {
          case UNKNOWN_ERROR:
              jniThrowException(env, "java/lang/RuntimeException", "Unknown error");
              break;
          case NO_MEMORY:
              jniThrowException(env, "java/lang/OutOfMemoryError", NULL);
              break;
          case INVALID_OPERATION:
              jniThrowException(env, "java/lang/UnsupportedOperationException", NULL);
              break;
          case BAD_VALUE:
              jniThrowException(env, "java/lang/IllegalArgumentException", NULL);
              break;
          case BAD_INDEX:
              jniThrowException(env, "java/lang/IndexOutOfBoundsException", NULL);
              break;
          case BAD_TYPE:
              jniThrowException(env, "java/lang/IllegalArgumentException", NULL);
              break;
          case NAME_NOT_FOUND:
              jniThrowException(env, "java/util/NoSuchElementException", NULL);
              break;
          case PERMISSION_DENIED:
              jniThrowException(env, "java/lang/SecurityException", NULL);
              break;
          case NOT_ENOUGH_DATA:
              jniThrowException(env, "android/os/ParcelFormatException", "Not enough data");
              break;
          case NO_INIT:
              jniThrowException(env, "java/lang/RuntimeException", "Not initialized");
              break;
          case ALREADY_EXISTS:
              jniThrowException(env, "java/lang/RuntimeException", "Item already exists");
              break;
          case DEAD_OBJECT:
              // DeadObjectException is a checked exception, only throw from certain methods.
              jniThrowException(env, canThrowRemoteException
                      ? "android/os/DeadObjectException"
                              : "java/lang/RuntimeException", NULL);
              break;
          case UNKNOWN_TRANSACTION:
              jniThrowException(env, "java/lang/RuntimeException", "Unknown transaction code");
              break;
          case FAILED_TRANSACTION: {
              ALOGE("!!! FAILED BINDER TRANSACTION !!!  (parcel size = %d)", parcelSize);
              const char* exceptionToThrow;
              char msg[128];
              // 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.
              if (canThrowRemoteException && parcelSize > 200*1024) {
                  // bona fide large payload
                  exceptionToThrow = "android/os/TransactionTooLargeException";
                  snprintf(msg, sizeof(msg)-1, "data parcel size %d bytes", parcelSize);
              } else {
                  // Heuristic: a payload smaller than this threshold "shouldn't" be too
                  // big, so it's probably some other, more subtle problem.  In practice
                  // it seems to always mean that the remote process died while the binder
                  // transaction was already in flight.
                  exceptionToThrow = (canThrowRemoteException)
                          ? "android/os/DeadObjectException"
                          : "java/lang/RuntimeException";
                  snprintf(msg, sizeof(msg)-1,
                          "Transaction failed on small parcel; remote process probably died");
              jniThrowException(env, exceptionToThrow, msg);
          } break;
          case FDS_NOT_ALLOWED:
              jniThrowException(env, "java/lang/RuntimeException",
                      "Not allowed to write file descriptors here");
              break;
          case UNEXPECTED_NULL:
              jniThrowNullPointerException(env, NULL);
              break;
          case -EBADF:
              jniThrowException(env, "java/lang/RuntimeException",
                      "Bad file descriptor");
              break;
          case -ENFILE:
              jniThrowException(env, "java/lang/RuntimeException",
                      "File table overflow");
              break;
          case -EMFILE:
              jniThrowException(env, "java/lang/RuntimeException",
                      "Too many open files");
              break;
          case -EFBIG:
              jniThrowException(env, "java/lang/RuntimeException",
                      "File too large");
              break;
          case -ENOSPC:
              jniThrowException(env, "java/lang/RuntimeException",
                      "No space left on device");
              break;
          case -ESPIPE:
              jniThrowException(env, "java/lang/RuntimeException",
                      "Illegal seek");
              break;
          case -EROFS:
              jniThrowException(env, "java/lang/RuntimeException",
                      "Read-only file system");
              break;
          case -EMLINK:
              jniThrowException(env, "java/lang/RuntimeException",
                      "Too many links");
              break;
          default:
              ALOGE("Unknown binder error code. 0x%" PRIx32, err);
              String8 msg;
              msg.appendFormat("Unknown binder error code. 0x%" PRIx32, err);
              // RemoteException is a checked exception, only throw from certain methods.
              jniThrowException(env, canThrowRemoteException
                      ? "android/os/RemoteException" : "java/lang/RuntimeException", msg.string());
              break;
  这代码是不是不需要解释了，全是关键字，只需要将异常msg组织起来，调用jni给vm抛出异常。
  
  
  
  
      
   
  DeadSystemException
   
       * Rethrow this exception when we know it came from the system server. This
       * gives us an opportunity to throw a nice clean
       * {@link DeadSystemException} signal to avoid spamming logs with
       * misleading stack traces.
       * Apps making calls into the system server may end up persisting internal
       * state or making security decisions based on the perceived success or
       * failure of a call, or any default values returned. For this reason, we
       * want to strongly throw when there was trouble with the transaction.
       * @throws RuntimeException
      @NonNull
      public RuntimeException rethrowFromSystemServer() {
          if (this instanceof DeadObjectException) {
              throw new RuntimeException(new DeadSystemException());
          } else {
              throw new RuntimeException(this);
  在整个app的执行过程中，生命周期，显示view等都需要跟system_server提供的service（activity，window，package）通信，如果系统binder调用出现问题，你在分析log是可能纳闷，system_server从log看运行的很正常，但是app居然给你报告system已经death。
   
  到这儿binder几个常见异常已经算是告一段落。接下来，我们聊聊，在遇到binder问题是如何去调试问题；找到问题root cause。
   
  都看到这儿了，辛苦一下，给点个赞呗。。。。
                      在平常程序运行过程中，可能碰到最多跟binder相关的异常是RemoteException，但本文只分析跟binder机制相关的异常，而RemoteException是server端逻辑导致的其它异常在client端的表现。跟binder机制相关的异常有：android.app.RemoteServiceException: can't deliver broadcast，JavaBinder: !!! FAILED BINDER TRANSACTION !!!，TransactionTooLargeEx
  				
  Binder是一种进程间通信机制，基于开源的OpenBinder实现；OpenBinder起初由BeInc.开发，后由PlamInc.接手。从字面上来解释Binder有胶水、粘合剂的意思，顾名思义就是粘和不同的进程，使之实现通信。一般Android应用开发很少直接用到跨进程信通信（IPC），但如果你想知道：1.App是如何启动并初始化的？2.Activity的启动过程是怎样的？3.进程间是如何通信的？4.AIDL的具体原理是什么？5.众多插件化框架的设计原理等等这些问题的背后都与Binder有莫大的关系，要弄懂上面这些问题理解Bidner通信机制是必须的。我们知道Android应用程序是由Ac
  发现app出现crash，具体看到堆栈：
  android.app.RemoteServiceException: can't deliver broadcast
  	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2047)
  	at android.os.Handler.dispatchMessage(Handler.java:106)
  	at android.os.Looper.loop(Looper.java:2
  				
  碰到一个异常，具有随机性：
      android.os.DeadObjectException: Transaction failed on small parcel; remote process probably died
          at android.os.BinderProxy.transactNative(Native Method)
          at android.o...
  				
  Binder机制是android中实现的进程间通信的架构，它采用的是c/s架构，client通过代理完成对server的调用。既然这里提到了server，那么我们有必要先了解下在android中是怎么来管理server的。先来看一个重要的Native进程：ServiceManager，从名字可以看出来，这个是用来管理所有server的。在init进程启动之后，会启动另外两个重要的进程，一个是我们上一篇讲的Zygote进程，另外一个就是这个ServiceManager进程了，这两个进程启动之后就建立了android的运行环境和server的管理环境。ServiceManager进程启动之后其他s
  				
  Talking Kotlin Android App
  Hi there! This is an android app for TalkingKotlin.com, a podcast about all the Kotlin things.
  Goodies
  Kotlin
  MVPVM
  Android Architecture Components (LiveData, ViewModel, etc.)
  Deep linking to directly access episodes from urls
  Feature Wish List
  Add extra data posted on the website of talkingkotlin but can't be added through SoundCloud
  Make the app more social (shares, likes, etc.) 
  A detail screen for each episode
  Mea culpa
  Not enough tests (WIP)
  No DI (Dagger2? 
  				
  RemoteServiceException: Bad notification posted from package *
  过去有一个奇异的Crash，出现概率比较低，后来Huawei 8.0机器出来后突然暴增，统计了一下大概5%左右的概率会出现
  首先确定这不是因为Notification数据填充问题(使用了非@RemoteView修饰的View……)
  这个Crash有如下特征
  Huawei 8.0高频出现 (以往系统版本也会出现，但概率很小，系统实现机制存在这种概率)
  只在更新后一段时间内出现
  06-23 11:02:35.482 E/AndroidRuntime(19470): FATAL EXCEPTION: main
  06-23 11:02:35.482 E/AndroidRuntime(19470): Process: com.tencent.android.qqdown
  				
  DeadObjectException:
  Binder 为CS架构，我们无法确保Client端的生命周期,如被forcestop或被卸载等等。如果server端提供了接口回调的方式，一旦Client被停用，那么就会出现DeadObjectException的异常，原因是在Server进行Callback时，Client端已经死亡。
  安卓本身提供了一些检测方法,拿com.android.se
  				
  Android进程间通信（Inter-process Communication, IPC）是指在不同进程之间进行数据交互和通信的方法。Android提供了多种方式实现进程间通信，以下是常用的几种方式：
  1. Binder机制：Binder是一种跨进程通信技术，它基于Linux内核提供的Binder驱动。通过Binder，我们可以将一个Service注册为Binder服务，其他进程可以通过Binder进行远程调用，实现进程间的通信。
  2. 文件共享：进程可以通过共享文件的方式实现通信。一个进程将数据写入文件，其他进程读取该文件数据，从而实现进程间的信息传递。
  3. Socket通信：可以使用Socket套接字进行进程间通信。一个进程作为服务器，另一个进程作为客户端，通过Socket建立连接进行数据交互。
  4. ContentProvider：ContentProvider是Android中用于实现进程间共享数据的一种组件。通过ContentProvider，一个进程可以提供数据给其他进程进行读写操作。
  5. BroadcastReceiver：广播是一种常见的进程间通信方式。一个进程发送广播消息，其他进程通过注册相应的广播接收器来接收并处理广播消息。
  6. Messenger：Messenger是一种轻量级的进程间通信方式。通过Messenger，一个进程可以发送消息给另一个进程，实现进程间的通信。
  以上是常用的几种Android进程间通信方式，开发者可以根据具体需求选择合适的方式来实现进程间通信。
  353    if (mDriverFD >= 0) {
  354        // mmap the binder, providing a chunk of virtual address space to receive transactions.
  355        mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);   //BINDER_VM_SIZE设置buffer size；
  45#define BINDER_VM_SIZE ((1*1024*1024) - (4096 *2)) //具体大小
  46#define DEFAULT_MAX_BINDER_THREADS 15
  可以在aospxref.com这个网站在线查看Android源码