Use AndroidFuture instead
This CL replaces our inhouse utility classes in favor of an existing
alternative AndroidFuture, which allows us to remove 8 files in total.
Several downsides are:
* We lose compile-time type checking in the remote end, because AIDL
does not support generics.
* AndroidFuture<T> does not support any raw Binder interfaces. For
instance, AndroidFuture<IInputContentUriToken> would crash due to
java.lang.ClassCastException at run time. You must use IBinder
instead and manually create a stub object in the receiver side.
* Data transfer would be a bit slower for primitive types and much
more slower for Parcelable types, because AndroidFuture internally
uses Parcel.{read,write}Value(), which is known to be around 4x
slower than Parcel.{read,write}TypedObject() for Parcelable
objects [1][2].
* When you find an AndroidFuture<T> on a code, you have to figure
out whether the code is running on the source side or remote side.
If you are on the source side, what you see on that object is an
aggregation of the computations on both the source and remote
ends, which is probably easy to understand. If you are on the
remote side, however, you will never observe any computation
result in the source side. What you can observe in the remote
side remains to be your local data that is specific to your remote
process.
Other than above, there should be no observable semantic change in
this CL.
[1]: https://developer.android.com/reference/android/os/Parcel
[2]: I29548ce6c2e5886f0e90a5dc70d8e9ecc0fb25a8
b293d933e0297dc9a5b8b0c7f8ca939bd8f53267
Bug: 192412909
Bug: 195699814
Test: presubmit
Change-Id: I74657826a99b11ca1f86932f8f41cca6e449cc8a
14 files changed