Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit e839388a authored by Steven Moreland's avatar Steven Moreland
Browse files

BpBinder: hide 'handle' API

The 'handle' API represents an internal 'address' for use with the
kernel, and it shouldn't be exported from libbinder (currenlty it is
used in Parcel). If any clients are using this API (they really
shouldn't be), then this CL should expose them. This way, when/if binder
supports communications over sockets, the format of this data can be
changed without having to worry about changing this API (we're worrying
about changing that API now).

Possible solutions here:

1. Parcel should not read/write binder objects. Instead, these objects
should implement Parcelable. This certainly sounds like an elegant
solution. However, because of the way that flattenBinder/unflattenBinder
interact with Parcel internal details ('objects') rather than being
composed of other Parcel primitives, having Parcel expose 'handle' is
probably the lesser of the two evils (not to mention, the
sizeof(IBinder) and its virtual address table is frozen).

2. Use 'friend' (and this is the route this CL goes). However, in order
to avoid exposing unnecessary internal details of BpBinder, this CL
creates a header-only access function which limits the ability of Parcel
to inspect BpBinder, and it makes the contract/relationship explicit.

Assuming this CL lands, I want to change other uses of 'friend' here to
use a similar accessor pattern.

Bug: 167966510
Test: boot, aidl_lazy_test
Change-Id: I5b21d15989f7ce7c45e44b33ed3bde45a63347a5
parent d95f8b18
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment