AeroGear Android 3.0

So it has been a while, but AeroGear Android 3.0 is out. As fitting a major number release we have a few breaking changes, lots of bug fixes, and a few new features. The full changelist can be viewed on our JIRA page


Breaking Changes

New Features

  • aerogear-android-push now uses GCM 3 including GcmListener, InstanceID, and GCM Topics.
  • Android 23 support
  • Material design in cookbooks

Minor Changes

  • JUnit 4 based automated tests
  • Updates to all required libraries (Android SDK, Android Maven Plugin)

How to get it

In Android Studio just declare our dependencies in your build.gradle file. Feel free to mix and match as necessary.

    compile 'org.jboss.aerogear:aerogear-android-core:3.0.0'
    compile 'org.jboss.aerogear:aerogear-android-security:3.0.0'
    compile 'org.jboss.aerogear:aerogear-android-store:3.0.0'
    compile 'org.jboss.aerogear:aerogear-android-pipe:3.0.0'
    compile 'org.jboss.aerogear:aerogear-android-auth:3.0.0'
    compile 'org.jboss.aerogear:aerogear-android-authz:3.0.0'
    compile 'org.jboss.aerogear:aerogear-android-push:3.0.1'

Also, feel free to take our cookbook samples for a spin!

How to get involved

Feel free to join us at #aerogear on IRC, follow us @aerogears on Twitter, or also join our aerogear-dev and aerogear-users mailing lists. For more details please check out our Community Page.

Android N – Security with Self Signed Certificates

If you are a good developer you are securing your services with SSL encryption. Unless you have put in a lot of effort, local testing still uses the good old fashioned self signed certificate and just click through the warning window of shame.

Screenshot from 2016-05-04 13-04-42

This is great until you are writing a RESTful service to be consumed by something which isn’t a browser. If you are an Android developer you have probably come across blog posts (or the official Android docs) encouraging you to make your own Trust Manager to accept your certificate or, worse, disable certificate checking altogether! However, Android N has come to the rescue with new security configuration features.

Using Self Signed Certificates with Android N

To use a self signed certificate you need to

  1. Add a meta-data tag to your AndroidManifest.xml which points to a security configuration xml file
  2. Add to your xml resources directory the security configuration file
  3. Download your self signed certificate to your project

Edit AndroidManifest.xml

I’ve added in my projects the following code to Android Manifest’s application element
[code lang=”xml”]
<meta-data android:name=""
android:resource="@xml/network_security_config" />

This code just informs Android that the configuration file is found in res/xml/network_security_config.xml.

Creating the Network Security Config

The full documentation for the network security files covers a lot more than our use case for a self signed certificate. It is well worth a read to understand what is being done.

Here is my XML file to load my certificate from the raw directory. I have it named server_aerogear_dev, but the file name is irrelevant. What matters is that the common name in the certificate file matches the domain name of the server. I am pretty sure that this also works with IP addresses, but I haven’t tested it.
[code lang=”xml”]
<?xml version="1.0" encoding="utf-8"?>
<certificates src="@raw/server_aergear_dev"/>

Downloading the certificate

You can download the certificate to the raw directory in your source using your web browser or using the command line.

cd app/src/main/res/raw;
echo -n | openssl s_client -connect | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > server_aerogear_dev
// Credit to SO :

Replace the name of the server and the port with configuration appropriate to you.

Final Notes

This is a very simple example of a new feature from Android N. This may change or go out of date. However, this gives us a simple was to manage security and it ALSO works within Android’s build flavor system. Take a look, and stay safe.

RHMAP and Google Accounts in Android

The Red Hat Mobile Application Platform (RHMAP) has strong authentication and authorization mechanisms baked into its Auth Policy system. Android has deep integration with Google’s ecosystem which provides many easy mechanisms for authorizing services to act on a user’s behalf. Out of the box RHMAP allows for connecting to a Google account using OAuth and a web view, but a better user experience is using Google’s Android account picker. To enable this integration in RHMAP we have to use a MBaaS Auth Policy.


This post should be informative to anybody who wishes to learn more about RHMAP; however, you will have the most benefit if you have access to a RHMAP instance and have read through the Getting Started documentation. If you do not have access to a instance of RHMAP, you may sign up for a free one at

Additionally you will need a Google account and Android emulator or device with Google’s APIs set up.


You can view an example of this integration in my FehBot video. The Android portion of this post will refer to the code in the application.

Creating an MBaaS Auth Policy

Create a blank MBaaS Service

Select “Services & APIs” from the top navigation. Click “Provision MBaaS Services/API”


Select “Choose” next to the item “New mBaaS Service”.


Name the service, click “Next”, ensure you are using the “Development” environment, and finally click “Deploy”. The service should deploy and you should have a green bar.


You are now ready to set up the Auth Policy.

Setup the Auth Policy

Select “Admin” from the top navigation and then “Auth Policies” from the 6 boxes which appear. Create_auth_policy_1

Click “Create” on the next screen to begin setting up an Auth Policy.

Name the Policy and select “MBaaS Service” as the “Type” under “Authentication. From the “Service” drop down select the service you created in the previous step. For “Endpoint” our MBaaS service will use “/auth/init”. Finally select for your “Default Environment” the value “Development.

Scroll down to the bottom of the page and click “Create Auth Policy”.

Implementing the MBaaS

I have created a MBaaS Service for us to use. It implements the server side token validation that Google recommends in its documentation. You should be able to copy this project into your MBaaS’s source and redeploy it.

You may wish to limit which Cloud applications can access your MBaaS services in the “Service Settings” section of the MBaaS “Details” page.



The /auth/init route will consume tokens from the Android device and set up user accounts in RHMAP. The code should be easy ish to follow along. The most important part is that we return a userId value in the json which we can use to look up the user’s session informaiton.


The route /list/:session can be used by Cloud applications to fetch a user’s account information which is created and saved after a call to “/auth/init”.

Android Integration

In order to integrate with Android, please follow Google’s Guide for instructions on how to setup an Android account and get an IdToken from a sign in. The FehBot Android client contains a working example.

Once you have a IdToken you can use FH.buildAuthRequest to perform the sign-in with RHMAP. For the three parameters us the Auth Policy name you assigned during “Setup the Auth Policy”, the IdToken you retrived from Google, and an empty string for the final parameter. Here is an example from the FeHBot app.


As per the RHMAP Authentication API if you use this you will have to manually verify your sessions in your application yourself. The built in verification methods will not work.


As you can see, it is easy to add a third party authentication mechanism to RHMAP. The principles in this post can be applied to many other authentication providers and client platforms.

Realtime sync with AeroGear on Android

AeroGear 1.2.0 included support for AeroGear Unified Push. Part of the technology underpinning that feature on Android are the Registrar APIs. These APIs make it very easy to create a message generating or message consuming Object and integrate it with your applications in Android. In my own time I have experimented with a MQTT PushRegistrar and a WebSocket PushRegistrar. Using the my WebSocket Push Registrar I created a very simple text sync demo.

As a quick bit of background, I also wrote the server component of the demo. It runs on vert.x and persists data to MongoDB. I implemented Neil Fraser’s Differential Synchronization process on both the client and server side. This algorithm handles merging the documents various states across devices. It is also very well written and easy to follow.

In this demo a user loads a document (using a RESTful Pipe). In the callback, the Activity registers itself as a MessageHandler with the Registrar API, creates a configuration object which describes a WebSocketPushRegisrar and passes this configuration into the Registrations class which creates a new Web Socket and connects it to the server. Now when the document is changed by a different application, a diff is received on the WebSocket and its contents are given to the Activity. If the Activity edits the document it creates a diff and saves it to the server. The server is in charge of synchronizing diffs across the different devices.

CRUD operations are performed using two Pipes. A Pad Pipe which is responsible for creating documents, getting lists of documents, and getting an individual document. The second Pipe is a PadDiff Pipe. Its job is to send diffs to the server.

[source lang=”java”]
//Create a Pad Pipe
PipeConfig padConfig = new PipeConfig(URL, Pad.class);
pipeline.pipe(Pad.class, padConfig);

//Use the Pad Pipe
//By passing in the padListFragment to Pipeline#get we are telling Aerogear to
//wrap the Pipe in a Loader.

public void getPads(GetPadsListFragment getPadsListFragment, PadCallback padCallback) {
pipeline.get("pad", getPadsListFragment, this).read(padCallback);

//Create a PadDiff pipe. PadDiff pipes are 1:1 with the "Session" which is a identifier for the web socket.
//In this app a session is killed with the fragment is put into the background. Thus I decided
//to make a PadDiff Pipe 1:1 with the fragment.
public Pipe<PadDiff> padDiff(PadFragment padFragment, String sessionId) {
PipeConfig config = new PipeConfig(URL, PadDiff.class);
config.setEndpoint("/padDiff/" + sessionId);
pipeline.pipe(PadDiff.class, config);
return pipeline.get("padDiff", padFragment, this);

From the devices POV the documents are fetched using the following code:

[source lang=”java”]
ReadFilter filter = new ReadFilter();
//Currently the way to get an element by ID is to use the LinkUri.
//This is scheduled to be fixed in a future version of Aerogear
filter.setLinkUri(URI.create("/" + padId));
pipeline.get("pad", fragment, this).read(filter, new PadCallback(padId));

In `PadCallback` the Pad is loaded and a WebSocket is created. When the websocket creation is finished, the server sends a message to the Activity with a session_id object. This message is received on the onMessage method of the Activity. This method is also responsible for handling error messages and handling diff messages which are updates from other clients.

First we handle the response from getting the pad:

[source lang=”java”]
//Called from PadCallback#onSuccess
public void handlePads(List<Pad> pads) {
pad = pads.get(0);
PushConfig pushConfig = new PushConfig();
pushConfig.setPushServerURI(URI.create("ws://" + pad.getId()));

//This will open the web socket.
((AeropadApplication) getActivity().getApplication()).register(pushConfig);

Then the Activity receives a callback from the WSPushRegistrar with a session id. The server will send different messages depending on what information it is sending to the client. In AeroGear a MessageHandler(in this case our Activity) receives a message from the WSPushRegisrar and extracts the content based on if there is a “diff”, “session_id”, or “error” object in the response. These keys are specific to this server but the general principle can be applied to any application.

[source lang=”java”]
public void onMessage(Context context, Bundle message) {
try {
String json = message.getString(WebsocketMessageReceiver.PAYLOAD);
JSONObject object = new JSONObject(json);
if (object.has("diff")) {
} else if (object.has("session_id")) {
//Create a PadDiff Pipe
diffPipe = ((AeropadApplication)getActivity().getApplication()).padDiff(this, object.getString("session_id"));
} else if (object.has("error")) {
Log.e("ERROR", json);
Toast.makeText(getActivity(), json, Toast.LENGTH_LONG).show();
} else {
Toast.makeText(getActivity(), json, Toast.LENGTH_LONG).show();
} catch (JSONException e) {
Log.e("MESSAGE", e.getMessage(), e);

The full source code for the Android application can be found at my Github. It is build using the aar branch on the official AeroGear Android repository.