Implement Android Oak client

[tiziano88]

Something like

oak/oak/client/application_client.h

Line 47 in 39838c8

class ApplicationClient {

but usable by Android applications.

I am not sure whether this means it should be implemented natively in Java, or have a thin Java wrapper around the C++ client, or whether we can just offer the C++ version and assume that Android applications will wrap it.

In any case, it requires establishing a channel using EKEP.

I note though that there is already a separate Android gRPC stack, but it does not seem to be as flexible as the regular gRPC stack. In particular, I am not sure it offers any way of using different channel credentials.

@ipetr0v could you start looking into it, and seeing what else is missing? e.g., can we use bazel with a different configuration to check whether some of our targets can be built for Android?

cc @annasapek @KeithMoyer

[ipetr0v]

Android uses a Java version of gRPC - https://grpc.io/docs/tutorials/basic/android/
But Asylo already uses a C++ version. Will it be okay to compile a C++ version of gRPC into *.so file, that is used by Asylo and Oak, which are used by Android through a Java/C++ interface?
Considering there is a dedicated Java version of gRPC, which will be cheaper to use grpc/grpc-java#3815 (or not https://groups.google.com/g/grpc-io/c/a_VntDs0s2w).

[ipetr0v]

It looks, that it's not possible to just convert existing grpc::Channel from C++ to Java: https://stackoverflow.com/questions/59239502/convert-grpc-channel-from-c-to-java

And, since we allow users/clients to use raw gRPC channels, this may require using a Java version of channels inside Asylo.

[ipetr0v]

I'm trying to create a hello-world android application in our Docker image.
But it looks like, android-sdk only supports Java 8: flutter/flutter#16025 (comment)

And our docker image is based on the Debian 10, that doesn't have Java 8 (only Java 11, that is not supported by the Android SDK).
There are different repositories with Java backports: https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/
But it also seems like adoptopenjdk-8-hotspot also doesn't work for Android:

/opt/android-sdk# ./tools/bin/sdkmanager --upgrade
Error: Could not find or load main class java.se.ee

[tiziano88]

Even using bazel, would we need to install Java 8 manually on the Docker image?

[ipetr0v]

Bazel requires the following command in the WORKSPACE:

load("@rules_android//android:rules.bzl", "android_sdk_repository")
android_sdk_repository(name = "androidsdk")

Not sure if it can reference Java that is loaded by Bazel.

[ipetr0v]

Compiling with Android Native Development Kit (NDK), and got an interesting error:

ERROR: /usr/local/google/home/ivanpetrov/.cache/bazel/_bazel_ivanpetrov/8772cf28264fce63c397d94b96d607b4/external/com_google_asylo/asylo/identity/null_identity/BUILD:58:1: C++ compilation of rule '@com_google_asylo//asylo/identity/null_identity:null_assertion_verifier' failed (Exit 1) clang failed: error executing command external/androidndk/ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang '-D__ANDROID_API__=28' -isystemexternal/androidndk/ndk/sysroot/usr/include/arm-linux-androideabi -target ... (remaining 74 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
In file included from external/com_google_asylo/asylo/identity/null_identity/null_assertion_verifier.cc:19:
In file included from external/com_google_asylo/asylo/identity/null_identity/null_assertion_verifier.h:25:
In file included from external/com_google_asylo/asylo/identity/enclave_assertion_verifier.h:24:
In file included from external/com_google_asylo/asylo/identity/enclave_assertion_authority.h:24:
In file included from external/com_google_asylo/asylo/crypto/util/byte_container_util.h:24:
external/com_google_asylo/asylo/crypto/util/byte_container_util_internal.h:45:2: error: "Only supported on x86_64 architecture"
#error "Only supported on x86_64 architecture"
 ^
1 error generated.

[annasapek]

@ipetr0v, The byte_container_util_internal library currently makes assumptions about platform endianness, but I think we can rewrite it so that it works on non-x86 platforms as well.

[tiziano88]

Thanks @annasapek , it seems that that would indeed be necessary if we plan to target Android as a possible client for Asylo / Oak. Unless Asylo is going to separately provide a Java / Android native way of creating Asylo (EKEP) channel credentials.

[ipetr0v]

@annasapek That would be awesome!
Created an issue/request on Asylo github google/asylo#55

[ipetr0v]

Compiling an application for x86:

bazel build //examples/hello_world/client/android:client_app --fat_apk_cpu=x86_64

and get the following error:

ERROR: /root/.cache/bazel/_bazel_root/b6bc0828d5b43c7085b650e0698bf388/external/com_github_cares_cares/BUILD.bazel:109:1: C++ compilation of rule '@com_github_cares_cares//:ares' failed (Exit 1) clang failed: error executing command external/androidndk/ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -gcc-toolchain external/androidndk/ndk/toolchains/x86_64-4.9/prebuilt/linux-x86_64 -target x86_64-none-linux-android -fPIC ... (remaining 42 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
external/com_github_cares_cares/ares_library_init.c:34:10: fatal error: 'ares_android.h' file not found
#include "ares_android.h"
         ^~~~~~~~~~~~~~~~
1 error generated.

but this file is loaded by Bazel in the execution root:

/opt/my-project# ls $(bazel info execution_root)/external/com_github_cares_cares/ares_android.h -l
-rw-rw-r-- 1 root root 1014 Oct 23  2018 /root/.cache/bazel/_bazel_root/b6bc0828d5b43c7085b650e0698bf388/execroot/oak/external/com_github_cares_cares/ares_android.h

[ipetr0v]

So, gRPC does not include ares_android.h in their custom file for Ares.
Submitted an issue to gRPC: grpc/grpc#21437