For consistency with APKs, signature verification is performed
in the system_server. This includes checking that the signature of
an updated install matches the signature of the active package that
it updates. For this, it requires search access to /data/apex and
read access to the files under that directory.

Test: m
Change-Id: Ia073adb8892886e4767fa5529e95c110b9cbff1b

Test: basic workflow between apexd and PackageManager tested with
changes being developed.
Bug: 118865310
Change-Id: I1ae866f33e9b22493585e108c4fd45400493c7ac

To configure read-ahead on loop devices, eg.
/sys/devices/virtual/block/loop0/queue/read_ahead_kb

Bug: 120776455
Test: configuring read-ahead on loop devices works from apexd
Change-Id: Ib25372358e8ca62fa634daf286e4b64e635fac58

To work around a kernel bug where pages that are read before changing
the loop device offset are not invalidated correctly.

Bug: 120853401
Test: apexd mounts APEX files on gphone_sdk_x86_64
Change-Id: I89f23f8f9d472e599f053553b73cc0618dcb3747

Currently, when an APEX is staged, apexd moves the file from
/data/app/vmdl*.tmp directory to /data/apex. However, the original file
is labeled with apk_tmp_file and is not readable from apexd.

We plan to resolve this issue by moving the file content via file
descriptor in between the package manager and apexd.

However, until the plan is implemented, temporarily allow apexd to
relabel the file to apex_data_file that is readable to it. This unblocks
the end-to-end test for APEX.

Bug: 112669193
Test: adb install --apex system/apex/apexd/apexd_testdata/test.apex
adb reboot; adb root; adb shell; cmd apexservice getActivePackages
The test APEX is activated

Change-Id: Ib9d4f5c699261f1fa1e6d557731767ee4d7168f9

To configure readahead for APEX dm-verity devices.

Bug: 117823094
Test: apexd can change readahead
Change-Id: Ie0396d59ef758ad55f499f65957697d26a48aae9

In earlier kernel versions (<4.0), the loopback driver issues
requests from a kernel thread. Therefore, the kernel needs access
to APEX file descriptors and data files (which are loopback
mounted).

Bug: 119220815
Test: mounting works on sailfish
Change-Id: I75b2bade41c64cf6fa6040d9c2f5489a206e04c6

apexd is using following additional ioctl cmds to mount the mini
filesystem inside APEXs:

 LOOP_SET_STATUS64
 LOOP_SET_FD
 LOOP_SET_BLOCK_SIZE
 LOOP_SET_DIRECT_IO
 LOOP_CLR_FD

Test: m; m apex.test; adb push <the_built_apex> /data/apex; adb reboot

/apex/com.android.example.apex exists

Change-Id: I68388cc4f323e4fcff370c8cdc0958cbd827e9cc

Start enforcing the use of ioctl restrictions on all Android block
devices. Domains which perform ioctls on block devices must be explicit
about what ioctls they issue. The only ioctls allowed by default are
BLKGETSIZE64, BLKSSZGET, FIOCLEX, and FIONCLEX.

Test: device boots and no problems.
Change-Id: I1195756b20cf2b50bede1eb04a48145a97a35867

apexd uses realpath(3) to ensure that the public key file that will use
is under /system/etc/security/apex directory. In order to support it,
allow apexd to getattr on apex_key_files.

The canonicalization is required because the key name from APEX might be
wrong. For example, if the key name from an APEX is '../../some/path'
then apexd will use '/system/etc/security/apex/../../some/path' as the
public key file, which is incorrect.

Bug: 115721587
Test: m apex.test; m
/apex/com.android.example.apex@1 exists

Change-Id: I6dc5efa0de369f8497e4f6526e0164e2de589c67

Bug: 115710947
Test: on device
Change-Id: Ie712689d80fb829f16de70e865cac4f0ff4e9b35

apexd is a new daemon for managing APEX packages installed
on the device. It hosts a single binder service, "apexservice".

Bug: 112455435
Test: builds, binder service can be registered,
      apexes can be accessed, verified and mounted
Change-Id: I634ad100f10b2edcd9a9c0df0d33896fa5d4ed97