title: android AIDL interface, parcelables and backwards compatibility
body: <p>We expose an AIDL service to third party developers. We'd like to return parcelable objects from this service, but we have concerns about backwards compatibility. By this, I mean clients compiled against version N of the parcelable, and a service compiled against version N+1 must work together.</p>
  <p>From my tests, for simple flat objects (simple type fields only), backwards compatibility is possible, as long as new fields are parceled at the end of stream ... e.g.,</p>
  <pre><code>in.writeInt(field1);
  in.writeInt(field2); // new field
  </code></pre>
  <p>however, when it comes to complex objects, things blow up. for example,</p>
  <pre><code>class D implements Parcelable {
    int field1;
  }
  
  class C implements Parcelable {
    List&lt;D&gt; ds;
  }
  </code></pre>
  <p>if a second field is added to class <code>D</code>,</p>
  <pre><code>class D implements Parcelable {
    int field1;
    int field2; // new field
  }
  </code></pre>
  <p>unmarshalling of class <code>C</code>s fail (i tried using <code>Parcel.writeList()</code> and <code>Parcel.writeParcelableArray()</code>).</p>
  <p>This seems almost inconceivable that this case can't be handled. Sure, we can leave the old binder interface as-is, and create a new binder interface that returns objects of the new class with the additional fields, but for a service that returns oft-changing classes, this will result in a convoluted mess. For example, interface 1.0 returns a <code>Person</code>. now we add a field, and we have a new binder interface 2.0 that returns <code>Person2</code> objects, and so on.</p>
  <p>This leaves us to using some more forgiving format, like JSON, to pass IPC data.</p>
  <p>Any suggestions?</p>