SingularityNET Service Integration into Android Apps — Opening the AI Marketplace to 2.5 Billion Customers

The SingularityNET platform and decentralized AI marketplace enable AI developers to publish their models and solutions as services and monetize them without the need for developing end-user applications or full-fledged software systems. At the same time, software developers can utilize these contemporary AI services in their products without the need for digging into complex specifics.

Recently we released a Java SDK available on our Developer Portal, which allows developers to create a SingularityNET service client in the Java programming language.

We’re tremendously happy to announce that with this SDK it is now possible to connect Android mobile apps to the SingularityNET platform, enabling AI services to be accessed by apps found on the Google Play Store and over 2.5 billion Android devices.

The SongSplitter App

To showcase the power of the Java SDK, we are introducing the SongSplitter app, an AI-driven SingularityNET powered application for splitting vocals from a music track, available to download now on the Google Play Store.

This application constitutes a real-world demonstration of how Android app developers can quickly and easily integrate services found on our platform and leverage the power of decentralized AI. This illustrates the viability of the SingularityNET blockchain-based AI protocol and marketplace as a means of disseminating and monetizing AI tools and products beyond the desktop and server and into the mobile arena.

SongSplitter will be the first in a long series of mobile apps leveraging SingularityNET AI agents to deliver intelligent services to users.

The SongSplitter app is in its first release and allows a user to separate vocal and accompaniment from the input audio. The app saves the split results locally and retains the ability to play all previously split results directly from within the included multi-track player, users can play the original audio or vocal and accompaniment tracks separately.

Below we will briefly describe the process of the integration of the SingularityNET service with an Android app considering our SongSplitter app as an example.

SingularityNET Service integration using the Java SDK

You can create mobile apps utilizing advanced AI services available on the SingularityNET platform. A user prepares input data using a mobile application, sends this to the SingularityNET platform, calling a specified service via a proxy server, and then receiving a response after the Service has processed the data.

The diagram below illustrates a common pipeline of interaction between a mobile app and the SingularityNET platform

The diagram encapsulates the overall process and consists of a mobile device app, a payment proxy server and a SingularityNET service.

The mobile app provides a rich UI and obtains inputs, it then presents the output using a SingularityNET service. The payment proxy server is required to manage Ethereum private keys safely because the SingularityNET platform is a Decentralised Blockchain-based project and utilises a native ERC20 token known as AGI. Both the mobile app and payment proxy server are parts of the SingularityNET client application.

The final component is the SingularityNET service which does the main AI-related work. For example, our team developed the SongSplitter app that connects to SingularityNET and calls the “sound-spleeter” service.

Handling Client-Side App Payment

We thought a lot about ways of integrating mobile apps and a SingularityNET payment system and finally ended up with the following options:

1. A mobile app directly utilizes a user’s Ethereum wallet and AGI tokens to pay for a service. In this case, a user should allow a mobile app accessing his Ethereum wallet. Thus, a user deals directly with SingularityNET payments and may choose different options e.g. recurring payment, one-time payment or individual usage pricing.

2. A mobile app publisher monetizes an app in general (for example using ads or setting a price for an app installation) and pays for a service using its own Ethereum wallet. In such a case, mobile app developers deal directly with SingularityNET payments and mobile app users are isolated from this.

3. A mobile app charges a fee to each user individually (i.e. each app user may pay for a subscription or pay for a call) and the app translates those payments into SingularityNET payments. This option is a kind of hybrid of the two previous options where a mobile app may generate an Ethereum wallet for a user, store AGI tokens and convert user’s payments into tokens for payment of a service.

For our Songsplitter app, we chose option 2 because of its simplicity from a technical perspective, allowing you to make SingularityNET AI-powered apps available to mainstream users by having blockchain developers manage AGI transactions in bulk in the back-end. In this case, the mobile app developer would still need to pay for the SingularityNET AI service in tokens by setting up a payment channel to the service on our platform.

SingularityNET Payment Models

At the time of writing this article, the SingularityNET platform supports two different payment models: free call and price per call, additional payment models such as service subscriptions and tiered pricing will be available in the future.

The free call model allows a restricted number of free payments to test service API, whereas the price per call model allows an unlimited number of calls to the service to be made, therefore the price per call model is the best option to use for service integration unless the developer wishes to only allow app users to use the service a limited number of times.

In the price per call model, each service call must be paid with tokens. To make a payment, the SDK needs to open a payment channel using a user-provided private key. All payments in the channel should be signed by that key. For a mobile app there are two different ways of working with private keys:

1. Create a separate private key for each user and keep it on the user device. Key is generated by the application itself or entered by the user. This approach is preferable in situations when each mobile app user has their own payment channel because it allows calling service directly without additional network hop.
2. Store private keys on your own proxy server. This approach allows to provide a service for all users using the same payment channel, and it is the way utilized in the Songsplitter application.

The second option means that you don’t need to use the SingularityNET SDK in the mobile app’s code. You still need the SingularityNET Gradle plugin to get the service API from the registry, only after getting and compiling the API as an app module you can do the common gRPC calls to your proxy service.

The proxy service is a component which obtains mobile app calls, forwards them using the SingularityNET SDK, adding the payment data and then returning a response to the app. In the future, we plan to publish a universal proxy service to make it easier to work with applications, but for now, you can take the Songsplitter proxy service code as an example.

Calling a Service

In order to call a SingularityNET service from the client side one needs to do three things:

• Open a service channel;
• Use this channel to call the service via gRPC
• Close the channel after work is finished.

Following this, a Protobuf request to the service needs to be built and decoded. Below is a diagram illustrating a typical app’s working pipeline including these three main parts.

The detailed description of calling services from the SingularityNET platform can be found in the “Invoking a Service using Java SDK” tutorial on our developer portal. Here we’ll focus on some moments specific for integration into an Android app.

In order to use the SingularityNET Gradle plugin in the top-level build.gradle file you should add the Jitpack Maven repo into the list of repositories and add the plugin into the list of dependencies:

dependencies {
   …
   classpath 
"com.github.singnet.snet-sdk-java:snet-sdk-gradle-plugin:0.3.2"
}

You need to apply the plugin in the app’s module build.gradle file:

apply plugin: 'io.singularitynet.sdk'

In order to use the gRPC in an Android mobile app you should also add grpc related dependencies (see gRPC Android example). But it is enough to add grpc-http and the SingularityNET SDK. The other necessary dependencies will be added automatically:

dependencies {
    …
    implementation "io.grpc:grpc-okhttp:1.28.0"
    implementation "com.github.singnet.snet-sdk-java:snet-sdk-java:0.3.2"
}

Don’t forget to add Jitpack Maven repo to the list of repositories of the corresponding module.

The last step of the Gradle build setup is importing the SingularityNET service API using plugin and compiling it. Add the following task into modules build.gradle file. This task will download and unpack the protobuf API of the service into local build/proto folder:

tasks.register('getServiceApi', io.singularitynet.sdk.gradle.GetSingularityNetServiceApi) {
    orgId = 'snet'
    serviceId = 'sound-spleeter'
    outputDir = file("$buildDir/proto")
    javaPackage = 'io.singularitynet.service.soundspleeter'
    ethereumJsonRpcEndpoint = new URL('https://mainnet.infura.io/v3/<infura-project-id>)
}

Then you need to add a task to compile this API using the protobuf compiler. You can find example code for this in the SingularityNet SDK tutorial or gRPC examples.

If your application is complex and includes several different services then we recommend creating a separate Gradle module for each kind of service API. Such setup allows to compile their protobuf files using separate protobuf compiler calls and eliminates possible protobuf package conflicts.

Here is a code to open a gRPC channel and create the gRPC stub. You need to do that once during an application lifecycle:

ManagedChannel chanel = OkHttpChannelBuilder
           .forAddress(<proxy address>, <proxy port>)
           .useTransportSecurity()
           .build();
SoundSpleeterBlockingStub stub = SoundSpleeterGrpc.newBlockingStub(channel);

The process of opening a channel can take some time, besides one can’t do network operations on the main GUI thread, so the only way to perform this operation is in a separate thread.

Finally here is a code to call a service. You can see it is a common gRPC call, nothing special:

SoundSpleeterOuterClass.Input request = SoundSpleeterOuterClass.Input.newBuilder()
       .setAudio(<audio file bytes>)
       .build();
SoundSpleeterOuterClass.Output response = stub.spleeter(request);

Don’t forget to shutdown your payment channel by calling channel.shutdown() when a user is going to exit the app.

Call Multiple AI Services and the Road to AGI

Right now, the Songsplitter app uses only one SingularityNET service. However, the strength of the platform is in the possibility to combine different services provided by different developers, for example, our app could make good use of a vocal recognition service, and we do plan to extend the features of the SongSplitter app as new relevant services become available.

Connecting multiple AI services together in a synergetic way is not limited to front-ends and in fact, all AI services on the SingularityNET platform can interact with others, opening up great prospects for near-endless applications where the strengths of each individual AI algorithm is added to and accessible by the entire network.

With each new service published on the SingularityNET platform brings us one step closer to a decentralised ecosystemic implementation of artificial general intelligence, enriching the world by being accessible to everyone globally and not owned or controlled by any single organization or entity.

Join Us

We thank each and everyone one of our community members for their continuous support. SingularityNET plans to reinforce and expand its collaborations to shape the coming AI Singularity into a positive one, for all. To read more about our other partners, click here.

SingularityNET has a passionate and talented community which you can connect with by visiting our Community Forum. For any additional information, please refer to our roadmaps and subscribe to our newsletter to stay informed about all of our developments.