Writing offset will trigger the kernel-side code to transform the flat
binder object into the handle form, which (in my understanding) is not
a valid operation for a NULL binder object. Meanwhile, the receiving
side will create a corresponding Binder object from such handle,
tripping the stability check as it will no longer accept UNDECLARED.
OTOH, if the offset is not written, then the receiving side will receive
the flat binder object as-is, with type BINDER and pointer NULL, which
will be interpreted as NULL binder. This is also what Android's
Parcel.cpp does [1][2].
IMO, this is sort of a hack. Binder kernel driver should handle the NULL
binder internally, and not relying on the sender doing the correct
thing. Meanwhile, the receiver should always reject a flat binder object
of type BINDER. But that's how Android work, so... 🤷
[1]: https://github.com/LineageOS/android_frameworks_native/blob/lineage-19.1/libs/binder/Parcel.cpp#L1327-L1332
[2]: https://github.com/LineageOS/android_frameworks_native/blob/lineage-19.1/libs/binder/Parcel.cpp#L2023-L2029
Origin: vendor
Forwarded: https://github.com/mer-hybris/libgbinder/pull/135
Nikita (@NotKit) noticed that the change in commit f227ae4291
("[gbinder] All binder objects need stability field in Android 11.
JB#58951") has made the aidl4 servicemanager variant redundant. In fact,
using aidl4 variant will cause an extra stability field to be sent on
the wire (luckily it has not caused any problem).
I've tried using aidl3 variant on Volla Phone X23 which runs Halium 12
(API level 32), and service registration still work, which seems to
validate this theory. Thus, stop using aidl4 servicemanager variant on
any of the API level-based config, as it no longer correspond to any of
Android versions.
Note that this commit doesn't outright remove aidl4 variant, as doing so
would break configurations which explicitly request its use. This commit
doesn't doesn't alias the aidl4 variant to aidl3 variant either.
Manually requesting a certain variant could mean some unusual setup;
aliasing aidl4 to aidl3 could break such setup.
Origin: vendor
Forwarded: https://github.com/mer-hybris/libgbinder/pull/133
On Android 12, the wire format of stability field is changed to also
include so-called "Binder wire format version", which starts at 1 [1].
A 32-bit-sized struct is re-interpreted into a 32-bit integer, with a
layout which makes it incompatible with the old version. Interestingly,
they reverted this idea in Android 13 [2], which makes the wire format
of the stability field the same as Android 11 again (as far as I know).
Add a new RPC protocol variant 'aidl4' to account for this difference.
Use this protocol on API level 31 through 32 and use 'aidl3' from API
level 33 onwards. The only difference from 'aidl3' is `finish_flatten_
binder()` function.
Interestingly, there is also a 16-bit-sized struct variant of the field
too [3]. However, to the best of my knowledge, this version is not used
in any of the released Android versions.
[1]: 89ddfc5f8c
[2]: 16a4106cb7
[3]: 14e4cfae36
Origin: vendor
Forwarded: https://github.com/mer-hybris/libgbinder/pull/133
AIDL HALs require stability field value to be set to VINTF as
opposed to the default SYSTEM, so expose a way to let the caller
set the value to used by finish_flatten_binder per local object.
Allow the build system to override the way make is invoked.
Cannot use make_install equally as that does not allow to pass
additional arguments to make.
Data race condition detected by Coverity (CID 444481, CID 444483).
According to Slava the effect of this particular optimization is
negligible, so let's simply drop it to make Coverity happy.
Recognized by Coverity (CID 444485) that this is the single call to
gbinder_driver_write out of the total of 9, where the return value is
not checked.
This change is implemented just to make Coverity happy. The compiler
does not complain.
Previously this always returned 1. Drop the first comparison so status
can be negative and errors will return 0.
Signed-off-by: Tomi Leppänen <tomi.leppanen@jolla.com>
In UTF-16, code points U+010000 to U+10FFFF are encoded using 'surrogate
pairs' where 32 bits are actually used. If a string is mostly emojis,
that can end up larger than the len*2 bytes assumed padded_len.
Convert the string to UTF-16 before allocating the extra buffer size so
it will be correct.
Previously to cross-compile one would need to add a pkg-config
executable in $PATH wrapping all the search paths required; now one can
e.g.
make PKG_CONFIG=foreign-arch-target-pkg-config
with the wrapper executable being separate and allowing programs for
host to also be built if needed for example.
