The ScopedLogSeverity was added to observe APCT failures, which turned
out to be a compiler optimization error.
Bug: 62429763
Test: None
Change-Id: Ibb45d018d8eaf4b29cb417da80ae5f0b000dda8e
APCT log shows that we got FUSE request unique=0 and replying to such
request causes a EINVAL.
The possible reasons of getting unique=0 here are:
* /dev/fuse actually submits such requests. In this case, not replying
to such request probabbly safe as the kernel cannot wait corresponding
response without a unique number. We can observing the kernel code to
find out what unique=0 actually means.
* Memory corruption happens and unique number are cleared with zero.
In this case, if we skip unique=0 request, libappfuse does not reply
to the kernel request and APCT result will become timeout .
To see which case happens, the CL ScopedLogSeverity to output
verbose logs and lets FuseBridgeLoop skip a request from /dev/fuse if unique=0.
Bug: 62429763
Test: libappfuse_tests
Change-Id: I8c4d532564b690d55573b92260170b0cd68150ab
The CL turns StartFuseBridgeLoop function into FuseBridgeLoop class, and
adds a method adding new appfuse mount to the loop.
After doing this, one FuseBridgeLoop can process FUSE commands from
multiple AppFuse mounts.
Bug: 34903085
Test: libappfuse_test
Change-Id: I54f11f54bc26c551281b9c32e9bb91f8f043774c
The CL changes FuseBridgeLoop so that it exits when all files opened on
the AppFuse mount point are closed. Note that the client code will
unmount the FUSE mount point after the loop exits.
Bug: 32260320
Test: libappfuse_test
Change-Id: I4965fbb48de8a280c6306e70757a07376b1956a7
The class is used at the app side (StorageManager) to parse FUSE
commands.
Bug: 32260320
Test: libappfuse_test
Change-Id: I1ae2904d3290a041f1efbf8fc10ba032eda5449c
The CL adds FuseBridgeLoop class to libappfuse, which is used in the
system service to proxy fuse commands to applications.
Bug: 29970149
Test: libappfuse_test
Change-Id: I0708f608b3868721ab16ba4028fd2c17a6735af7
