[Android Execution] Home Edge Orchestration

[suresh-lc]

We are thinking of supporting execution of Home Edge Orchestration in Android platform. Hence in this regard we did basic study of how this can be taken ahead. Following are some of the approaches :

[suresh-lc]

This is further to the method we had proposed for Android execution during the TSC call, wanted to keep posted the progress. We are following the "gomobile" way of building the APK or AAR as mentioned in below link,

https://pkg.go.dev/golang.org/x/mobile/cmd/gomobile

We started with sample 'Hello-World' in go to build apk out of the same. Tried the same in Linux and as well Window's machine. After resolving many errors in setup and environment setting, could make APK in Linux machine. We would install the same in Android-Emulator or on device and check once. In Window's machine still we get some error and trying to resolve. Since its Android support, we are trying in Window's machine also. Will check the Linux APK and get back how it works.

If the APK works as intended, we will next follow the same steps and build APK(AAR) out of Home-Edge Orchestration next. Upon the successfull build, will install on device to check the features which work and so.

[nitu-s-gupta]

Hello All,
We have analysed the gomobile library and observed the following facts,

1. The Go code can be used on Android in two ways
   a. Creating a AAR file and using it in Android Application to call the APIs
   b. Converting the Gocode in apk and installation of apk in the android devices
   We started with step b and took sample code to convert it into gomobile after the necessary step. The converted APK was successfully installed and worked fine in android emulators/devices. The initial analysis of sample code of the APK defines the following requirement
2. The Go code that has to be converted should import the package golang.org/x/mobile/app. All the Go Apps should use this package to initialize the app, manage its lifecycle, and receive events.
3. "golang.org/x/mobile/event/lifecycle" is also necessary to manage the lifecycle of the apps for Android
   So simply the code cannot be converted to the APK and code changes would be necessary for further analysis of effect /side effects of importing the above mentioned packages. We will keep you posted with the further steps of analysis
   Please provide your valuable suggestions for the same

[tiokim]

@nitu-s-gupta Thanks for the valuable analysis. Does b mean that javaapi.go build an apk file for android service instead of current the aar file?

[nitu-s-gupta]

No, currently as per my analysis its the entire code that gets converted to apk. the javaapi.go file is converted to aar which is option a. But to convert the go code few more imports to manage the lifecycle of the Android are required. So I will be trying initially the same chaanges on simple hellowworld application to understand the GUI that shall be created and also the level of changes required to take the decision of taking option 'b' or dropping it

[tiokim]

Is b possible to run in the background as Android Service and to open other android applications to access? If it's right, it seems good.

[nitu-s-gupta]

Will check on this and get back to you!

[suresh-lc]

Thought of sharing the current progress.

1. Built APK from https://pkg.go.dev/golang.org/x/mobile/example/basic and was able to install in Android emulator. The app also executed as expected.
2. Next tried creating a aar file from the sample @https://pkg.go.dev/golang.org/x/mobile/example/bind using command
   gomobile bind -target=android ./hello
   and hello.aar got created.
3. Tried similar steps for sample helloworld.go , but getting some errors even though there is not much functional logic. Trying to check the issue.

[suresh-lc]

Successful in creating the aar for sample helloworld.go. Two files helloworld.aar and helloworld-sources.jar got created. The point to be remembered is that the files should be in the same directory as "go" has been installed.

[nitu-s-gupta]

Few things I observed from my analysis,

1. if the apk has to be made,it should run as service as UI will not be created from the gocode that we have currently. But this needs to be checked how can it be made as service since currently by default it launchs as an app
2. Another option is using as an aar and this aar can be made available to the third party service application/developers who can then use the aar in their android application as library to call the functionalities. We are though creating a aar currently of the javaapi file and used in android. But that also required many other factore like root permission, tun interface etc. Hence this wwill require thorough analysis to understand how a aar can be created that reduces the overhead of the developer.

[tiokim]

@nitu-s-gupta Thanks for the valuable analysis!

Few things I observed from my analysis,

1. if the apk has to be made,it should run as service as UI will not be created from the gocode that we have currently. But this needs to be checked how can it be made as service since currently by default it launchs as an app

I believe android developers develop application with JAVA, C, C++, and Kotlin because The Go Mobile project is experimental. Use this at your own risk. While we are working hard to improve it, neither Google nor the Go team can provide end-user support.. From this point of view, I don't want to force developers to make an Android application written in Golang. However I think providing an Android service apk file that other apps can acceess and use edge-orchestration features is not bad.

2. Another option is using as an aar and this aar can be made available to the third party service application/developers who can then use the aar in their android application as library to call the functionalities. We are though creating a aar currently of the javaapi file and used in android. But that also required many other factore like root permission, tun interface etc. Hence this wwill require thorough analysis to understand how a aar can be created that reduces the overhead of the developer.

This is my preference. We don't need to support all edge-orchestration features in Android. We may investigate what features are working or not in the android platform.

[suresh-lc]

AAR file creation has been successful. We are trying a build an APK and check for orchestration init and basic features. As mentioned we will now need to investigate what features work and what not.

[nitu-s-gupta]

Aar has been created sucessfully for edge orchestration to test the basic feature of orchestration. Now, Creating a basic App to import the aar and check for functionality. Getting error in importing the aar. Checking for the few links to resolve the issue. will update once the issue resolves

[tiokim]

Netlink is enabled on all Linux systems, including Android. Netlink is used to enumerate network interfaces and routes as well as get notification when the system's network interfaces change. Unfortunately it looks like Google intends to remove the ability of native code to do any of those things.

Please check this in time. If edge-home-orchestration-go cannot run on Android, we should drop android code in this repository.

[tiokim]

Also, we have to think about changing to the approach 1 with minimal features.

[nitu-s-gupta]

https://www.androidbugfix.com/2021/10/cannot-bind-netlink-socket-when.html is one more link which also states netlink cannot be used in AndroidAPI>=24. Though it states of using ifaddrs but notsure for the changes required in the go code for the same.

[MoonkiHong]

@suresh-lc @nitu-s-gupta Thank you for your elaborate investigation. Since it seems to me that this is a deadlock, I would like to suggest you to take a look at this approach:

Suggestion: Based on the simple scenario of Baobab release, what about implementing a library written in Kotlin for Android?

0. Run an application with Edge Orchestration library at Android.
1. The app requests an offloading via internal REST API of edge-orchstration library.
2. The edge-orchstration library gets and compares the scores from the other Edge Orchestration Devices.
3. The app requests Service Execution to the device that has the highest score.
   • If the device itself has 0 score.

This is a kind of Approach 1, but it would be also good to hear your opinion on this suggestion at this moment. Please feel free to share your thought here. 🙏

[MoonkiHong]

@tdrozdovsky Also would like to get your opinion on my suggestion. 🙏

[suresh-lc]

We all concur on new development in Kotlin with minimal features of discovery and offloading as the possible approach. The development part is clear for now. Few thought which came to mind before we start the implementation,

1. The Android support shouldn't go as another feature addition. How well can we advocate this Android support to make it useful for product/service developers
2. Interaction scenario between an Android device supporting vB and Linux/Rpi on vD(or higher). Linux would support DS or Cloud Sync but Android wouldn't.
   If we go ahead with the feature, we should analyze and design in a way it would be easier for other developers to use.

[tiokim]

2. Interaction scenario between an Android device supporting vB and Linux/Rpi on vD(or higher). Linux would support DS or Cloud Sync but Android wouldn't.

I think that the features of vB are sufficient for Android at the moment.
Reason 1. edgexfoundry doesn't support Android, so Android can't use datastorage anyway.
Reason 2. CloudSync is required when it is a background application for other applications of the device. An android application with the home edge library written in kotlin can communicate with the broker using android MQTT library.

[suresh-lc]

Feature definition is fine for the moment and a plan can be made based on it. Android version would remain in vB and Linux can have latest updates. How do we take this Android support, for that matter Home Edge itself for product teams is question.

[MoonkiHong]

Your view point is also valid, @suresh-lc. My suggestion at this moment is to approach this task as an incremental basis. After releasing a set of experimental examples for the Android support based on vB, we could even encourage those developers outside to jump into our community to participate in filling in the features for vC, vD and beyond. What do you think? At this moment, the prioritized item might be to support the Android operation for the basic function of "edge-home-orchestration", which could offload the processing/service into connected other Home Edge in the same local network. Thoughts? 😁 🙏