Archives For Qt for Work

Before debugging and running a work APP on your managed Android device from Qt Creator

  • your device must be activated as Android for Work device
  • your must have sent a release build to your Admin and this APP must be published to Google Play for Work
  • you must have installed the work APP on your managed device

Deploy to Device

Build and deploy your APP as usual from Qt Creator to your (managed) Android device.

If all works well, the APP (named PegelMeter) will appear twice on your device.

This is expected behavior – read more here – topic “Testing on managed profiles – tips and tricks“.

Run the work APP

Unfortunately you’ll notice that Qt Creator runs the private version of the APP and not the work version.

This is because Qt Creator doesn’t know that we want to run a work app. Private and Work apps are bound to the user.

Work User vs Private User (managed Android Device)

Default user is user 0, where the work user normally is user 10. You can list your users from Terminal:

adb shell pm list users

you’ll get something like this:

Users:
    UserInfo{0:1799924875:13} running
    UserInfo{10:141078676:30} running

User 0 –> default (private) user

User 10 –> work user

Run as Work App

You can run the APP from Terminal as Work APP:

adb shell am start --user 10 -n org.ekkescorner.xxx.pegelmeter.dev/org.qtproject.qt5.android.bindings.QtActivity

QtCreator starts the APP without –user which always will use the default one (0)

I’ll open a bug report and request to add a Variable USER_ID so this can be placed inside .pro and added to adb start command by Qt build process.

Starting the work APP from Terminal you’re loosing the log output inside QT Creator. Workaround could be to log from adb or to use an extra tool.

This will give you the logs using adb:

adb -d logcat libpegelMeter_x.so:D *:S

A special tool gives you some more comfort filtering the logs. For OSX I can recommend LogRabbit. It’s easy to filter out the logs from your APP.

External Tool

As we have seen, Build and Run the APP starts the private APP.  So you have to stop and close the private APP and then start the work APP from Terminal.

To make this easier I added this to External Tools in Qt Creator:

I checked Output: Show in Pane – but nothing is printed. Probably I forgot something to tell External Tools that APP output should be visible in Application Output Pane. As long as this doesn’t work I’m using LogRabbit (see above)

External Tools ‘start_pegelmeter_work.sh’ executes this script:

#!/bin/sh
cd <path-to->/platform-tools
./adb shell pm clear --user 0 org.ekkescorner.xxx.pegelmeter.dev
./adb shell am start --user 10 -n org.ekkescorner.xxx.pegelmeter.dev/org.qtproject.qt5.android.bindings.QtActivity

Now it’s easier:

  • Build and Run APP
  • ExternalTools – Kill running private APP and Start Work APP

I would like to use a variable for User Id and also for APP Name and APP Package. (see QTCREATORBUG-17863)

and here’s the request to add USER_ID to be placed inside .pro: QTCREATORBUG-17862


← Back (Deploy Android Work App to Google Play)

→ Next Article (…work in progress…)

⇐ Home (Overview / Topics)


Publish to Google Play Store for Work

Your BlackBerry UEM Admin must publish your APP to Google Play Store for Work.

The APP must not be uploaded to Google Play but will be registered.

The workflow is similar to publishing a ‘normal’ APP to Google Play, so you need screenshots, artwork, description, …

Here’s a guide what the Admin has to do:

This guide is from 2016 – but the workflow still is the same. All described for BES12 will work using UEM 12.6

As soon as Google has approved the APP the Admin can configure on which devices / users / user-groups the APP should be installed.

Developer Policies

The Admin typically will create Policy profiles matching the rights a user-group should have for work APPs.

Attention: To be able to deploy debug builds from QtCreator to your device the Admin must add these extra policies to developers:

  • Apps
    • Allow installation of non Google Play apps
    • Allow developer options

If you cannot deploy and run work apps from QtCreator ask your Admin if these policies are set for your device.


← Back (Activate Android Device for Work)

→ Next Article (Debug and Run managed Qt Android App | QtCreator)

⇐ Home (Overview / Topics)


There are different ways to activate a Device:

  • Managed Accounts
  • Google Domains

My example and sceenshots are based on ‘Managed Accounts’, which is the easiest way. If you’re using Google Domains then it’s much more complex and for each User you need a dedicated Work Google Play Account. The newest BlackBerry UEM 12.6 supports ‘Managed Accounts’.

To activate a Android device for work (‘Managed Account’), you’ll receive an eMail from the Admin (email address, password)

BlackBerry UEM Client

Please download the BlackBerry UEM Client APP from Google Play

Open the UEM Client and enter email address and password.

Configure your profile.

Device will be activated:

Play Store for Work

Automatically some work apps will be added. Here you see the Play Store for Work (left) and the usual private Play Store:

Please open the Play Store for Work. If you don’t have used a Google Mail address (different from your personal Goofle Mail address) for activation, it can happen that you get an error:

try to switch off / on the airplane-mode or restart the device to see your work apps.

Your Work APPs

in this case there’s one app available – the app you sent to the admin:

Two APPs (Work, Private)

Install the APP as usual and you’ll get 2 APPs: one as private, one as work app:

we only need this app as work APP, so you can delete the private one.

Now as your APP exists as a work APP you can deploy updates from Qt Creator and use the work profile.

Android for Work Statusbar

Open your work APP and take a look at Android statusbar:

you’ll always see if the current APP is a work app and you’ll also see if currently there’s a secure connection to server (VPN)

Secure Connection

All your Work APPs will use the secure connection. There’s also a second Browser: Chrome for Work. Opening sites from Chrome for Work or accessing URLs from your Work APP always goes thru the secure connection – this means those URLs will be opened behind the firewall same way as if you’re sitting in your office using the Intranet. Data used by Work APPs is encrypted and secure out of the box on transport and also on your device.

Secure Boot

Using BlackBerry Android Devices there’s some extra security built into the hardware. Those devices cannot be rooted.

Read more here and here.

BlackBerry and Android Devices ? You have read that there will be no more Devices built by BlackBerry ?

Yes – BlackBerry finished transition from hardware to software. BlackBerry licensed Devices to partners, but verifies security. First new device was presented by TCL at Mobile World Congress in Barcelona: keyONE with Android Nougat 7.1 – three more new devices will follow. BlackBerry Android Devices always get the monthly security updates for Android – per ex. Security Patches from march 2017.

It’s up to you or your customers how many levels of security they need. Android for Work is the first step, using devices with secure boot the next one.

Samsung does something similar with Samsung KNOX and Samsung devices, but fails with monthly security updates.


← Back (Overview managed Android Devices)

→ Next Article (Deploy Android Work App to Google Play)

⇐ Home (Overview / Topics)


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:

  • BlackBerry
  • Mobileiron
  • VMware AirWatch

BlackBerry UEM 12.6

My examples are based on BlackBerry UEM 12.6 (formely known as BES 12)

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.

EMM Admin manages users, user groups, devices, policies and apps. Here you can download the policies for BlackBerry UEM. Get an overview of BlackBerry UEM here.

Development Stages (Dev, Test, Production)

Developing a new app there are typically 3 stages:

  1. develop UI with MockUp data (no access to servers needed)
  2. test against test environment
  3. release for production environment

Stage 1 I’m using GooglePlay 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 environemts 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 GooglePlay 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:


← Back (EclipseCON Europe)

→ Next Article (Activate Android Device for Work)

⇐ Home (Overview / Topics)