Add Trusty code and build files for binderRpcTestService
so we can run the binderRpcTest tests on Android against
a Trusty service.

Bug: 230135749
Test: build Trusty
Test: mmm tests
Change-Id: Id4dbe453229c1f1b93da2811cec265c0e331edfe

This patch changes the file format for RecordedTransactions towards
stable and extensibility. Warnings about stability are retained so that
the TransactionHeader may be more easily changed to serve our needs for
a "version 1".

Test: `atest binderUnitTest`

Change-Id: If8d63304815a227a8ee2bb8f7bfaa1ab33bd6e0f

AParcel_create was used incorrectly in fuzzer. Using NdkParcelAdapter
instead of AParcel_create
Bug: 264659127
Test: m SANITIZE_HOST=address binder_parcel_fuzzer

Change-Id: I25e47ea095b6119a32af308b5000a9508d71e465

Adding both APIs to binder_parcel_fuzzer

Test: m binder_parcel_fuzzer &&
	out/host/linux-x86/fuzz/x86_64/binder_parcel_fuzzer/binder_parcel_fuzzer
Bug: 264550130
Change-Id: I107525f168c5c446adc758498905c1b4ceaaff9b

The control sockets a service inherits when spawned from init cannot
have O_CLOEXEC set, or they wouldn't be inherited.

But we don't want them to be further inherited when we are running an
RPC binder server on them, so set the flag.

This showed up in authfs_service, which inherits a socket and spawns
an authfs process, leading to a denial like this (since authfs doesn't
have the SELinux permission to access the socket):

avc: denied { read write } for pid=207 comm="authfs"
path="socket:[6436]" dev="sockfs" ino=6436 scontext=u:r:authfs:s0
tcontext=u:r:authfs_service:s0 tclass=unix_stream_socket permissive=0

The denial is harmless, but it can easily be interpreted as a sign of
a real problem.

Bug: 264496291
Test: composd_cmd --test-compile; denial no longer seen
Change-Id: I516eb07776eb78db046bc4155315cb8267cfe456

Fixes: 264514421
Test: binderAllocationLimits (32-bit and 64-bit passes)
Change-Id: Iaad3c643fc4cb80f40e22f9976c754da6b45cef5

Test: `atest binderUnitTest`

Change-Id: I015fc6ccc640ec8d2db70c8edf0a20dc381230cc

Asserting while trying to read the parcel received from another process
is causing crashes in fuzzer. Since, there is no gurantee that received
parcel may have exact data which is being read, this assert should not
exist.

Test: m libbinder_rs
Bug: 261827787
Change-Id: I8a96ef05e65ff8250644accd7d237a486ec16cff

If a service doesn't specify any capabilities in it's definition in the
.rc file, then it will inherit all the capabilities from the init.
Although whether a process can use capabilities is actually controlled
by selinux (so inheriting all the init capabilities is not actually a
security vulnerability), it's better for defense-in-depth and just
bookkeeping to explicitly specify the capabilities that dumpstate needs.

The list of capabilities that dumpstate is allowed to use was obtained via:
```
$ adb pull /sys/fs/selinux/policy /tmp/selinux.policy
$ sesearch --allow -s dumpstate -c capability,capability2 /tmp/selinux.policy
allow dumpstate dumpstate:capability { chown dac_override dac_read_search fowner fsetid kill net_admin net_raw setgid setuid sys_ptrace sys_resource };
allow dumpstate dumpstate:capability2 { block_suspend syslog };
```

Note: dumpstate can transfer in several other domains, but all of them
either don't need any capabilities:
```
$ sesearch --allow -s vdc -c capability,capability2 /tmp/selinux.policy
$ sesearch --allow -s perfetto -c capability,capability2 /tmp/selinux.policy
$ sesearch --allow -s derive_sdk -c capability,capability2 /tmp/selinux.policy
```

Bug: 249796710
Test: atest BugreportManagerTestCases
Test: presubmit
Change-Id: I6f03675b60d69063c3d944b370f4a8d325cfa7f9

If a service doesn't specify any capabilities in it's definition in the
.rc file, then it will inherit all the capabilities from the init.
Although whether a process can use capabilities is actually controlled
by selinux (so inheriting all the init capabilities is not actually a
security vulnerability), it's better for defense-in-depth and just
bookkeeping to explicitly specify the capabilities that installd needs.

The list of capabilities that installd is allowed to use was obtained via:
```
$ adb pull /sys/fs/selinux/policy /tmp/selinux.policy
$ sesearch --allow -s installd -c capability,capability2 /tmp/selinux.policy
allow installd installd:capability { chown dac_override dac_read_search fowner fsetid kill setgid setuid sys_admin };
```

Note: installd can transfer in several other domains, but all of them
either don't need any capabilities, or need a subset of installd
capabilities:
```
sesearch --allow -s dex2oat -c capability,capability2 /tmp/selinux.policy
sesearch --allow -s dexoptanalyzer -c capability,capability2 /tmp/selinux.policy
sesearch --allow -s viewcompiler -c capability,capability2 /tmp/selinux.policy
sesearch --allow -s profman -c capability,capability2 /tmp/selinux.policy
sesearch --allow -s idmap -c capability,capability2 /tmp/selinux.policy
sesearch --allow -s migrate_legacy_obb_data -c capability,capability2 /tmp/selinux.policy
allow migrate_legacy_obb_data migrate_legacy_obb_data:capability { chown dac_override dac_read_search fowner fsetid };
```

Bug: 249796710
Test: presubmit
Change-Id: I98d54ab08707e406b54968974ba8ea457499fcde

Bug: N/A
Test: N/A
Change-Id: Ia4ea41938dfff18a8c6727b4cdd05bc4e08c7281

For common issue around cookie lifetimes.

Change-Id: Ia1cb8c4278d783acf2af874651bd0d459261a9cf
Fixes: 254939515
Test: N/A

This test fails 0.01% of the time, likely due to
scheduler interactions. We can make the test more robust
by using a secondary connection to the service, but
limiting noise from this case for now.

Fixes: 263370125
Test: binderRpcTest
Change-Id: I73fdbc9e232fc39ce579957fef32e94af606e56d

Unbounded connections will exhaust resources.

Fixes: 260736889
Test: w/ reproducer
Change-Id: Ic21a1b4aab1127fbf4b9d3d943d0b27f423b84ea

Avoid private dirty cost for loading these shared libs.

Bug: N/A
Test: N/A
Change-Id: I7ea4c37a4bc58830440fe16d7ce760f202c3ad36

* changes:
  libbinder_ndk: ABpBinder linkern'space muliplicity
  libbinder_ndk: remove associateClassInternal

This adds a few additional bytes of .ro data to store the warning
message in the String, but worrying about re-fetching the interface
descriptor when it is empty (which happens less often in native
code after BBinder has a default descriptor, but still happens in
Java, or in custom implementations) adds complexity to other code.
Since we guarantee to always cache the descriptor, we don't need
to think about this case as much.

One alternative implementation would be to drop BpBinder mObitsSent
and use both !mAlive and an empty obituary list to represent the
obituaries being sent. However, due to sendObituary using mObitsSent
in order to avoid taking a lock in some cases (something that
should have never been done, because it's optimizing a fast path
and the way it does it means that certain races will take a lock
part of the time - which is flake prone), I couldn't find a way to
remove this variable without introducing the possibility that
we take an extra lock after linkToDeath fires, which could prevent
system recovery and cause a deadlock. Moving this variable would
have to be done more carefully.

For now, we can avoid repeated binder calls for an empty interface
descriptor. This is intended to help justify (perhaps overly so)
other changes being made in the bug, but I'm submitting it for
review entirely independently, because it's not strictly necessary
for correctness assuming that the corresponding Bn implementation
of getInterfaceDescriptor is correct. If the implementation of this
function is adverserial, it could lead to a deadlock in some
situations, but a far easier way to cause this same deadlock would
be to not return from getInterfaceDescriptor at all, which is
well-known.

Bug: 262463798
Test: binderAllocationLimits
Change-Id: I07aee55f6092b52189ad2fadbbcd0880e2e3cbf4

Previously, if the same process loaded the same class in two different
linker namespaces, you could not have an ABpBinder which pointed to the
same service in both of them.

I kind of did this intentionally, because at the time I was still
figuring out a lot of this stuff, and I didn't want to make the
implementation unnecessarily complicated. I also wanted a chance to
investigate these issues. In some cases, this may mean that an ODR
issue is less noticeable (however - the way we should fix these is
by having the build system and linkers detect when we overwrite a
symbol which is not binary identical - a very difficult a noisy
task, but a neglected and unfortunate one). Anyway, we have other
checks for ODR issues now in the AIDL build system. It's okay.

Anyway - it turns out the stability mechanism in AIDL is really
awesome and enables some awesome usecases, so we need this support
now. Well.

Fixes: 262463798
Test: libbinder_ndk_unit_test
Change-Id: Idce05e13768cd4ad10c64873f393535d74cd4d3e

The code here was pretty difficult to understand.

Bug: 262463798
Test: atest CtsNdkBinderTestCases
Change-Id: Ie9920192a685149d3d5723e83246d59aa8ef50f4

* changes:
  The ahb changes necessary for
  swapchain: Don't call native_window_get_wide_color_support