By: BlackBerry Elite, Ekke Gentz / originally posted here on Mar.15, 2017.
If you’re developing mobile business apps sooner or later customers will request to debug, build and run on managed devices. This blog post is focused on Google for Work | Android (aka Android for Work).
Google for Work | Android
There are different ways to run work applications: devices may only contain work apps or private and work apps are installed together. From my experiences in most cases there are private and work apps together on devices. Read more about EMM (Enterprise Mobile Management) and different scenarios here.
There are some EMM solution providers:
- VMware AirWatch
BlackBerry UEM 12.6
My examples are based on BlackBerry UEM 12.6 (formerly known as BES12)
You can try out UEM for 30 days (Cloud version) or 60 days (on-premises) for free.
Using a managed device is like working behind the firewall via VPN, but all is transparently managed by the EMM solution provider.
Development Stages (Dev, Test, Production)
Developing a new app there are typically 3 stages:
- develop UI with MockUp data (no access to servers needed)
- test against test environment
- release for production environment
Stage 1 I’m using Google Play Closed Beta Test to deploy the apps to beta testers from customer. Adding testers only gMail address is needed.
For stages 2 and 3 your device must be activated as Android for Work device or you should request a device to test on from your customer. This is the only way to get access to data servers behind the firewall – in most cases there will be no URL you can use from outside. One device can only be activated as work device for one server (BlackBerry UEM).
It’s highly recommended to test your APP as Work APP – the admin can forbid features (Bluetooth, NFC, Camera, …)
To manage apps your customer has to use a Google developer account to be able to publish apps through Google Play for Work.
Multi Android Package Names in Manifest
Attention: you must change the Android package name to enable your customer publishing the app to Google Play for work because the package name from stage 1 is already connected to your own Google developer account from Beta testing.
Also your Enterprise Customers can have different environments for dev, test, production with different Google Developer Accounts to get a specific Play Store for Work for each environment. This means you must build releases for up to three or more different package names. Changing the package name manually in Android Manifest is not so comfortable. You can have a dynamic way following this blog article.
Best would be Qt Creator supports this directly using variables in .pro. see QTCREATORBUG-17863
Develop – Test – Release Workflow for Work APPs
Here’s an example workflow:
- add your APP to Google Play Closed Beta Test (Android package name: my.example.beta)
- deploy updates to beta testers until stage 1 finished
- build release (Android package name: my.example.test) and send APK to your customer
- your customer publishes APP to Google Play for Work
- your customer creates user and profile for you and adds the APP to your user or user group
- your customer sends an email to activate a device
- you activate your device and install the APP from Google Play for Work on your device
- now you can develop, build and run your APP from Qt Creator
- build update releases and send to your customer
- your customer publishes update to Google Play for Work so others can test your update
Hint: you can only build and run your app as work app if customer has published your app once to Google Play for Work and you installed it once !
Following pages will explain the steps in more detail: