Jason Bayton

What the last decade of Android Enterprise DPC migration could have been

2026-04-17T00:00:00Z

I've written about DPC migration more than once over the years. Google introduced the platform APIs for wipe-free device migration between EMM vendors in Android 9.0 back in 2018. They've been sitting in the SDK ever since, and no EMM vendor I'm aware of has shipped cross-vendor migration using them.

When Google publicly surfaced DPC migration within AMAPI in early 2024, I wrote:

The resurfaced DPC Migration functionality has been quite rather watered down on what it was originally purported to be... This is intended primarily for the looming turndown of the Play EMM API. DPC migration in this case can be leveraged to migrate all existing Android devices within a single EMM vendor from the Play EMM API-based custom DPC they have today, over to Android Device Policy and AMAPI, while maintaining management of the device within the solution.

This view hasn't changed; useful for vendors modernising their backend, but it does nothing for organisations that want to change provider.

I wanted to get a feel for the capability first-hand, I've never truly taken the time to test it because no one supported it, so I spent a couple of days reading the APIs, building a proof of concept, and running it end-to-end on a Pixel 9 Pro XL.

Here's the video if you'd rather see it than read it, or scroll on for words galore.

https://youtu.be/0fYh-ElNEwU

What the demo shows

The environment is straightforward: a Pixel 9 Pro XL running two DPCs. Google's TestDPC acts as the outgoing EMM, holding Device Owner with policies and restrictions applied. The DPC I built acts as the incoming EMM. Both DPCs implement the Android 9+ transferOwnership() API and support receiving control.

The migration itself takes seconds. The outgoing DPC initiates the transfer, ownership passes to the incoming DPC, and the new DPC immediately applies its own policy set - camera disabled, apps installed - to prove it's genuinely in control rather than inheriting state from the previous owner.

No wipe.

This is the end-to-end flow that could, today, allow an organisation to switch EMM vendor without resetting a single device. It's been possible since 2018. The APIs are public, documented, and functional.

It's reasonably trivial, but that has never been the point

The engineering lift here is not large. Reading the docs, understanding the ownership transfer, and implementing the needed changes.. even on the biggest, most complex EMM platforms today it'd be feasible within a release cycle.

Rather, unfortunately - and I've said this before - it comes down to commercials and perception. EMM vendors have no commercial incentive to support this and every commercial incentive to resist it. DPC migration is symmetric by design - to receive devices from another vendor, you have to be able to hand them off to another vendor. A vendor that implements inbound migration implicitly enables outbound migration.

The moment a vendor supports DPC migration, their existing customers gain the technical ability to walk.

This is vendor lock-in. The wipe hasn't been a technical necessity for nigh on a decade.. it's a retention mechanism. If your platform, support, and pricing are genuinely competitive, you should want easy migration because you'd gain more inbound customers than you lose outbound. If you're not confident you can hold customers on merit, friction becomes your retention strategy.

Eight years on, the industry has revealed its collective answer.

Unfortunately it comes at the direct expense of both customers and the ecosystem as a whole. Android looks harder to deal with, takes more effort, requires more thought.. while Apple shows just how easy it should be.

What the demo doesn't show

The proof of concept demonstrates that on-device ownership transfer works. What it doesn't address is everything that lives server-side, which is not transferred through this process.

When a device moves from one EMM to another, it's moving between two different Android Enterprise enterprise IDs, the bind. Each bind has its own managed Google Play state, managed user accounts, and its own Google Cloud Project on Google's backend. The transferOwnership() API handles the DPC handover on the device, but it doesn't touch any of this:

Private apps - published to the original enterprise ID. If the new EMM is bound to a different enterprise, those apps are no longer visible or installable. They'd need to be re-published under different package names, moved through a Google Play support ticket, or shared with the new enterprise from the old.
Play Store layouts - configured per-enterprise. The new EMM starts with no layout. Any curated app collections, categories, or featured apps need to be rebuilt
App tracks - developers who shared production or closed testing tracks with the old organisation ID need to add the new enterprise ID as a tester. Until they do, devices on the new EMM won't receive builds
Managed configurations - stored in the old EMM's backend, not on the device. The new EMM needs equivalent configurations set up before migration or apps lose their settings

None of this is insurmountable, and it's exactly the same situation organisations are left in when doing a manual (wipe-first) migration, but it means a cross-vendor migration is never just "tap transfer and done." There's meaningful prep work: staging apps, configurations, and approvals in the new EMM before cutting devices over, coordinating with app developers who've shared tracks, and communicating with end users about what to expect. Skipping this prep risks users losing access to apps and services the moment the transfer completes.

This is an area where Google could help. If migration were an ecosystem-level feature rather than a device-level API, Google could handle every aspect of an enterprise to enterprise migration, covering app approvals, private app visibility, and Play configuration across binds. Today, none of that exists.

Google's role

Google built the platform capability and then left activation to partner opt-in.

When Apple shipped MDM migration with iOS 26, iPadOS 26, and macOS 26 last year, they didn't ask give their EMM partners the choice not to support it. Through Apple Business Manager, organisations can reassign devices to a new MDM server, set an enforcement deadline, and the device migrates without a factory reset. User data intact.

It's ecosystem-wide, and vendors don't get a vote on whether to participate.

Apple had the courage to force their ecosystem to be better. Google gave the same capability to partners to adopt or not as they pleased, and Android migrations remain disruptive by default.

What about the watered-down version?

As I opened with, Google's AMAPI DPC migration (ref) allows devices managed by a custom DPC (Play EMM API-based) to migrate only to Android Device Policy and AMAPI within the same EMM vendor.

The documentation is explicit:

Note: This process is transparent to end users. It is a one-way only process (it cannot be undone once completed) and it cannot be used to migrate a device from one EMM to another.

Could Google route around this via AMAPI?

Custom DPCs (in context of mainstream device management) are on borrowed time. The Play EMM API is deprecated, and every EMM vendor is slowly migrating to AMAPI. Within a few years, the majority of Android Enterprise deployments will be running Android Device Policy as the DPC, with vendor-specific backends behind it. There's no real reason for any vendor to invest in cross-vendor custom DPC migration at this point - the custom DPC itself for full-fat certified Android management is going the way of Device Admin.

So the question becomes: once everyone's on AMAPI, does Google finally enable AMAPI-to-AMAPI migration across vendors?

Technically, it could be trivial. All devices are running the same DPC (ADP). The policy model is Google's, the enterprises are Google's, the Google Cloud Projects are Google's. There's no proprietary agent to swap out, no custom policy schema to translate. Google basically owns every piece of the stack on the device and the cloud side.

But the commercial incentive problem hasn't gone anywhere. The same vendors who wouldn't implement cross-vendor custom DPC migration for the last eight years will not voluntarily opt-in to cross-vendor AMAPI migration either. The money they'd lose to outbound customers is the retention value of the wipe. Unless Google enforces this at the AMAPI rather than inviting vendors to adopt it - we'll end up with the same impasse on a newer stack.

Which brings it back to the core difference in approach; Apple forced their ecosystem, Google hasn't. AMAPI gives Google a cleaner shot at doing the right thing than they ever had with custom DPCs, because they control both sides of the transaction. Whether they take that shot is to be seen, but until they do it's a really big, fat, blot on the Android experience when comparing it to alternative options for mobile management in the ecosystem.

What customers can do

Make your voice heard.

The Android Enterprise Customer Community exists for exactly this. If you've ever had to wipe a fleet to switch EMM, if you've ever stayed with a vendor longer than you wanted because the migration cost was prohibitive, if you've ever watched Apple customers do in a scheduled window what Android customers do with months of planning and a phased rollouts - say so. Vendor silence is easy when customer silence enables it.

Apple's showing how it can be done, hopefully Google doesn't wait another eight years to catch up.

Introducing DeltaWatch: web change detection

2026-04-10T00:00:00Z

If you've ever written documentation for a living, you know the particular flavour of horror that comes from a vendor updating a page without saying a word. A deprecated flag. A changed default. A renamed permission. A URL slug that now 301s to something vaguely related but not actually the same. The kind of change that would be a one-line entry in a sensible changelog, if the changelog existed at all.

I've been quietly maintaining a collection of pages I need to watch for the better part of a decade - Google's Android Enterprise documentation, AMAPI references, OEM product pages, vendor announcement blogs, the occasional Wikipedia article that gets quietly edited when something interesting happens. For most of that time I've used various tricks and tools, and a fair amount of daily checks as part of my morning routines.

The trouble with this is me. Just a simple human reminding myself to read the docs on a regular basis.. and I miss things - either directly insomuch as forgetting to check in on a page I should frequent often, or indirectly by missing a change to wording within a paragraph. The latter being a subtle but critical function change when Google updates the default of a policy, for example.

So, in the spirit of Flash and MIKA, I built the thing I actually wanted.

Introducing DeltaWatch

DeltaWatch is a multi-tenant web change detection platform. You point it at a URL, it fetches the page, extracts the bits you care about, and tells you when something changes. That's the crux of it.

It has a multitude of pattern matching tools, various format support, and it's really easy to just set-and-forget.

It's live right now at deltawatch.ing, the free tier has no time limit, and you can sign up in about fifteen seconds.

Why I built it

I wanted a service I had control over, with the specific functionality I wanted for my use cases at its core. I also wanted to be sure it ran on the stack I'm familiar with for debugging and expansion, as I do love to tinker with products.

Existing tools on the market do page monitoring really well, but they're either too costly for the capabilities I'm after, or don't offer what I want.

What it does

The feature list is too long for an announcement post, so I'll stick to what I use personally every day.

Deep content extraction capabilities

Most monitoring tools let you pick a CSS selector and call it a job done. DeltaWatch lets you target the exact content you care about via CSS selectors, XPath, JSONPath, or regex - and combine them. Want to watch a specific <div> on a page, but only the changes inside the third ? Done. Want to watch a JSON API response but only specific keys? Done. Want to strip navigation, headers, footers, sidebars, and anything with display: none before the diff runs? One checkbox.

JSON responses are auto-detected and formatted with sorted keys, so changes in key ordering never trigger false alerts. PDFs up to 20 MB (current limit, it'll increase over time) are text-extracted and diffed like any other content. There's a workspace-level "strip blank lines" toggle for the sites that love to insert random whitespace. All of this is there because I hit every single one of these edge cases within the first week of using the platform on my own pages.

Conditions engine

Content extraction handles targeting. The conditions engine filters out the noise that slips through after. Eight operators (contains, does not contain, equals, greater than, regex match, and friends), AND/OR logic, and change-percentage thresholds so you only get alerted when the page changes by more than, say, 5%. Every condition composes with every other condition. It's the difference between getting one useful alert a week and getting twelve useless alerts a day.

Notifications where you work

Email is built in, but that's table-stakes. I wanted to ensure there was support for webhooks and chat apps, because that's where I like to receive my updates. Slack, Discord, Telegram, and generic webhooks are there today, with more potentially based on demand. Add channels per watch, per tag, or at the workspace level. Every channel is available on every plan, including the free tier, because pay-walling notifications on a monitoring product is absurd.

Sites (beta)

This solves a real and annoying issue for me - missing new content because instead of a page changing, a new page is added to the website.

Sites lets you model an entire domain as a connected graph or table. You point DeltaWatch at a root URL, it crawls the hostname, builds a graph of pages and the links between them, and gives you an interactive network or table view of the whole site. You can see what links to what, which pages have drifted recently, and which pages are orphaned or rarely updated.

I chose to implement it as a tool for organic discovery or real, present sites. It doesn't fetch a sitemap and allude to the existence of pages, it will slowly and meticulously look at a page in the same way the Watch logic does, locate any links on said page, and queue them for their own crawl. This gradually builds a network of linked pages.

From the graph (or a table view, if you prefer rows), you can convert any discovered page into a watch with one click. Conversion routes through the standard watch creation flow, so plan limits, duplicate detection, and interval enforcement all still apply. There's also an optional auto-watch toggle that turns every newly discovered page into a watch as the crawler finds it, which is excellent for small focused sites and absolutely terrifying for anything the size of a Google developers domain.

Sites also does recrawl scheduling. When a watch detects a change, the parent site queues an automatic re-crawl (debounced at 12 hours site-wide to avoid storms), so the data stays current with the pages you care about. As a fallback, every site gets a scheduled full recrawl roughly every 7 days with ±40% per-site jitter, so sites stay fresh while the platform doesn't all crawl at once.

Sites is currently a Sentinel-tier feature - more on pricing below.

Imports from everywhere

I had eight years-worth of links to bring across when I started using this in earnest, so import had to work from day one. DeltaWatch imports from six formats:

changedetection.io ZIP backups, watches, tags, snapshots, and notification settings
DeltaWatch native backup - full-fidelity round-trip of any export
CSV for spreadsheet-driven bulk imports
JSON for API-driven bulk imports
Distill.io exports
Plain URL lists for the "I just have a text file of URLs" case

Every import shows a preview before committing, enforces plan limits, and runs as a background job so large imports don't time out.

Multi-workspace and backups

Workspaces are per-team, per-project, or per-client containers. Each workspace has its own plan, its own billing, its own users, and its own notification defaults. I run a personal workspace for my own monitoring, and a handful of dedicated workspaces that are monitored separately. You only pay for the workspaces that need paid features.

Every workspace can generate a full ZIP backup in the background - watches, tags, settings, and snapshot history - and download it via a time-limited link. No lock-in: if you ever want to leave, the door is right there.

Under the hood

For those of you who like a peek behind the curtain, here's the architecture.

Frontend is React with Vite and Tailwind CSS. The Watchlist, site graph, diff viewer, and admin panels are all SPA components. The site graph uses a force-directed canvas simulation with viewport culling, zoom-based label visibility, and adaptive force parameters so it stays responsive at 1,000+ nodes. No D3 in the main bundle; it's a lightweight hand-rolled force simulation that weighs less than most charting libraries.

Backend is Express with a comprehensive REST API. It runs in two deployment modes: as a Netlify full-stack application (SPA + serverless functions) lighter instance, and as a standalone Node.js process with a strongly-consistent PostgreSQL backend for heavier use. The standalone build supports a split deployment topology where HTTP serving and background work run as separate processes, isolating API latency from crawl and watch-check load.

Storage is a pluggable backend abstraction. There are four backends - Netlify Blobs, Directus, a generic KVP-over-JSONB database store, and a native-columns Postgres store that uses typed columns and expression indexes instead of JSONB blobs for the hot tables. The native backend is what runs on the VPS in production, and it's materially faster than the KVP equivalent for listing, filtering, and bulk operations (I started out with Directus support, given I use that for my app projects but it quickly groaned under the strain, so local PG took over).

Watch check pipeline is durable. Every check runs as a persisted job with claim tokens, stale-job recovery, and a 10-minute timeout watchdog. One watch per job means a slow target can't strand a batch of twenty; the scheduler just moves on and comes back to it on the next tick. Imports, exports, and workspace deletes follow the same job-queue model, which means they survive process restarts and serverless context freezes.

The site crawler uses BFS with robots.txt support, rate limiting, checkpointing, a configurable edge cap, and - crucially - the same SSRF and redirect validation path as regular watch checks. A crawl can't reach anywhere a watch couldn't.

Platform health monitoring runs every 5 minutes on the worker process and captures disk usage, Node memory, database pool pressure, watch-check failure rate, crawl job health, scheduler miss detection, and API latency. Alerts only fire on state transitions (ok → warn → critical) with a configurable cooldown, and there's a recovery notification when everything returns to ok.

Pricing

I swung between releasing it as a free tool and offering subscriptions wildly. Ultimately I opted for a freemium model, because:

VPS instances and cloud resources aren't free
The higher tiers could legitimately hammer the infrastruce, so it's only fair a fee is charged to put directly back into the platform
I don't make much revenue from the other products and services I offer, so subscriptions here can contribute to the wider work I do in the ecosystem (and my Android hardware addiction).

I wanted the pricing to be clear, cheap, and sustainable. Three tiers:

Ping - free, forever, no time limit. 5 watches, 3-hour minimum interval, 10 visible snapshots, all notification channels. Enough to monitor the pages you care about without paying a penny. No credit card required to sign up.
Pulse - £3/month. 50 watches, 1-hour minimum interval, 100 visible snapshots for historical page comparisons, API access.
Sentinel - £6/month. Unlimited watches, 5-minute minimum interval, unlimited snapshots, API access, and the Sites feature. This is the "monitoring is my passion" tier.

That's it. No seat pricing. No watches-per-month metering. No "contact us for Enterprise". Per-workspace billing, so you can keep personal monitoring free while running a paid workspace for client work side-by-side.

For context, the commercial competitors want £10–15/month for a similar watch count with 5-minute checks. DeltaWatch does it for £6, and the free tier is actually usable rather than a trial.

What it's not

A few things it deliberately isn't:

Not self-hosted. DeltaWatch is a hosted SaaS. I built it as a product, not a self-host kit. If you want self-hosted, changedetection.io is an excellent choice.
Not a scraper. It's a change detector. It respects robots.txt on crawls, it doesn't bypass paywalls, and it doesn't attempt to defeat bot detection systems. If a site doesn't want to be monitored, DeltaWatch won't fight them about it.
Not a replacement for your APM. It monitors content, not performance. It doesn't care if a page is fast, it cares if a page is different.
Not very good at SPAs. I can look at supporting that in future though. Today it only watches pages that output their source to visitors, and SPAs tend to hide it in javascript apps.

Try it

deltawatch.ing is live. Sign up, add your first watch in about thirty seconds, and the diff viewer will show you your first change the moment the content shifts.

The docs are at deltawatch.ing/docs, the release notes live at deltawatch.ing/releases, and there's a live status page at deltawatch.ing/status that reads straight from the production health endpoint so you can see what the platform's doing right now.

If you spot a bug, a content extraction failure, a site that breaks the crawler, or a feature you miss from another tool, I want to hear about it. There's a reply-by-email link below, or reach out directly.

Happy monitoring!

Android Enterprise lands on Android XR

2026-04-07T00:00:00Z

After months of "coming soon", Google has published the Android Enterprise for Android XR documentation, alongside a support article detailing management capabilities for XR devices. It's been a long wait since the Galaxy XR launched late last year without enterprise support, and now we can finally see what Google has been working on.

The short version: it's fully managed only at the moment, the validation requirements are sensibly adapted for the form factor, and there's a curious statement about custom DPCs that I'll dig into below.

What is Android XR?

For anyone not following the space, Android XR is Google's extended reality platform, announced in December 2024 in partnership with Samsung and Qualcomm. It's built on Android's foundation, which means existing Android apps can run in a spatial environment alongside native XR experiences. Think of it as Android, but for headsets and smart glasses rather than phones and tablets.

This matters for enterprise because it means organisations don't need to rebuild their app portfolio from scratch. The apps already deployed through managed Google Play can, in principle, run on XR devices.

Google categorises Android XR devices into two types:

Headsets and wired glasses - standalone devices running a full OS instance. These are the manageable ones, available as video see-through (VST) or optical see-through (OST) variants
AI glasses - lightweight companions with cameras, microphones, and speakers. These don't run a full OS and function as accessories to a primary device, so they're not independently managed

What devices exist today?

The Android XR ecosystem is still young:

Samsung Galaxy XR - launched October 2025 at $1,800. The first and currently only shipping Android XR headset. Powered by the Snapdragon XR2+ Gen 2
XREAL Project Aura - tethered AR glasses announced for 2026. First AR glasses running Android XR, using a split-compute design with a tethered processing puck
Samsung smart glasses - two models confirmed for 2026, developed in partnership with Google, Warby Parker, and Gentle Monster
Google AI glasses - launching with Warby Parker and Gentle Monster for 2026, with Kering Eyewear confirmed as a future partner
Sony - confirmed as a partner, no device announced yet

For enterprise today, the Galaxy XR is the only game in town. Everything else is announced or in development.

What management is available?

The documentation confirms management is based on the fully managed device mode. No work profile, so no COPE or BYOD, just fully managed. Given the form factor and the current state of the ecosystem, this makes sense. XR headsets are far more likely to be company-owned, purpose-deployed devices than personal BYOD kit. At least for now (this guy notwithstanding).

EMMs can use either AMAPI or a custom DPC. The validation requirements are adapted from the standard mobile fully managed set, with some thoughtful changes that reflect the XR form factor.

What's required (and matches mobile)

The core enterprise foundation is intact. All of the following are required for XR validation, just as they are on mobile:

Provisioning: DPC identifier (afw#), QR code, and zero-touch enrolment
Security: Device security challenge, Verify Apps, Direct Boot, hardware security, advanced passcode, wipe and lock, compliance enforcement, Play Integrity
App management: Enterprise binding, silent app distribution, managed configurations (including 4-level nesting), managed Google Account provisioning
Connectivity: Runtime permission management, Wi-Fi configuration and security, account management, certificate management (basic and advanced), factory reset protection
Device management: System update policy

What's been hardened for XR

Several features that are optional on mobile have been made required for XR, and the choices are sensible:

Disable cameras - mandatory on XR, optional on mobile. Given XR headsets have always-on spatial awareness cameras and potentially outward-facing cameras for passthrough, this is an obvious requirement. The privacy implications of an unmanageable camera on a headset in a corporate environment would be a non-starter
Screen capture management - also mandatory. Screen capture on a spatial device could expose far more context than on a phone
System audio management - required for XR, optional on mobile. Controlling audio output on a device strapped to someone's face matters more than on a phone in a pocket
System clock management - required for XR
Advanced Wi-Fi management - required for XR, optional on mobile
Advanced app control - required for XR
Reboot device - required for XR.
Persistent preferred activity management - required. This is particularly relevant for kiosk-style XR deployments
MAC address retrieval - required for XR, optional on mobile

What's been relaxed or removed

On the other side, some mobile requirements have been downgraded or dropped entirely:

Downgraded from required to recommended:

Advanced VPN management
Delegated scope management
Programmatic app approval
Basic store layout management
Google-hosted private app management
Web app management
Application track management
Advanced application update management
Managed Google Play Account lifecycle management
Direct zero-touch configuration

This suggests Google is being pragmatic about the maturity of the XR EMM ecosystem. The core management is mandatory; the more advanced Play management features are encouraged but not gating. Sensible for a v1.

Not currently present (present on mobile, absent from XR):

NFC provisioning
Smart Lock management
eSIM management
Advanced IME management
Keyguard features
Lock screen messages
Credential manager policy
Policy transparency management
Device admin deprecation requirements

This is compared to the required items on the fully managed checklist for mobile devices. Some of these may still be in flight, some may not apply to XR (device admin?). It's still early days for XR, so we'll see how things progress.

What's been added for XR

A handful of features appear in the XR set that aren't in the standard mobile fully managed requirements, it looks like they've been folded in from dedicated, instead:

Dedicated device provisioning - listed as required, reflecting that XR headsets are expected to commonly operate in kiosk or dedicated device modes
Security policies for dedicated devices - required
Advanced lock task mode management - recommended

This confirms what I'd expect: many XR enterprise deployments will be dedicated/kiosk-style, where the headset runs a specific application or set of applications (training, simulation, remote assistance) rather than serving as a general-purpose device.

XR-specific notes

The documentation includes a couple of XR-specific technical callouts:

Lock task mode currently supports locking to a single 3D app only. Notifications and Quick Settings are unavailable because there's no status bar. EMMs need to allowlist com.android.systemui and com.google.xr.eyetracking.calibration as helper system apps
Media Projection (screen casting) must be limited to 2880x2880 resolution. Higher resolutions cause display issues

Neither is surprising, but both matter for customers deploying XR, as I've dealt with issues with com.android.systemui missing on mobile in the past, also.

Custom DPCs: a confusing position

The XR management documentation states:

New custom DPCs for managing Android XR are allowed and are eligible for validation, but these are not eligible for validation for managing mobile devices.

This reads as though new custom DPCs can be built specifically for XR, but those same DPCs cannot then be validated for mobile device management.

On the surface this might seem reasonable - separate validation tracks for separate form factors. But this doesn't align with how the DPC allowlist works today.

The DPC allowlist that I wrote about in December doesn't distinguish between form factors. There's no "mobile DPC" vs "XR DPC" distinction in the allowlist documentation. A DPC is a DPC - it calls DevicePolicyManager APIs, it gets registered as device owner, and it manages a device. The APIs are the same regardless of whether the device has a 6-inch screen or a spatial display.

I also can't find documentation on how Google intends to enforce this distinction. If I build a custom DPC, get it approved for XR, and then provision a mobile device with it, what happens? Does Play Protect block it based on form factor? Is there a flag in the validation that ties a DPC package to a device type? The documentation doesn't say.

This feels like one of two things:

A new policy direction that Google is quietly introducing through the XR documentation - using form factor as a further restriction on DPC scope. If that's the case, it's a significant change that deserves its own announcement and clearer documentation, not a sentence buried in an XR management page
A poorly worded statement that's trying to say something more nuanced, like "XR-only vendors don't automatically qualify for mobile validation" (which makes sense)

Either way, if you're a vendor building a custom DPC and considering XR support, I'd strongly recommend seeking clarification from Google directly before assuming anything about cross-form-factor eligibility.

It's also worth noting the requirement for managed Google Accounts specifically for custom DPC enrolment on XR. This may add an additional hurdle for vendors targeting the XR space.

But I want BYOD?!

As above, today unfortunately no work profile management option is available. This limits XR to company-owned deployments for now. Understandable given the hardware cost and typical use cases, but worth flagging for organisations thinking about shared or take-home XR devices.

I've been advocating for many more work profiles-per-device for years, so this is not presently a step in the right direction 😅

Where does this leave enterprise XR?

This is a solid foundation. Google hasn't rushed out a half-baked management layer; the fully managed validation is genuinely tailored for XR with sensible adaptations. The inclusion of dedicated device features as required signals Google understands that most enterprise XR deployments will be purpose-built.

But it's early days. Only one device ships today. Work profile isn't available. The custom DPC policy is confusing. And the XR EMM ecosystem needs time to build out support. Google has also indicated they're working on how XR devices will be represented in the Android Enterprise Solutions Directory, which will help organisations compare hardware options as the ecosystem grows.

If you're planning XR deployments today, here's where I'd focus:

Samsung Galaxy XR with Knox is your most complete management option right now, regardless of whether your EMM supports the new XR validation
Confirm XR support with your EMM before purchasing at scale. At launch, the confirmed EMM partners are ArborXR, ManageXR, Microsoft Intune, Omnissa Workspace ONE, Samsung Knox Manage, and SOTI. Google has indicated more will be validated in the coming months
Plan for fully managed - there's no work profile path, so XR devices need to be treated as company-owned, purpose-deployed hardware
Test lock task mode carefully - the single 3D app limitation and lack of status bar notifications are material constraints for kiosk deployments
Watch the custom DPC space - if you're building or using a custom DPC, the form-factor restriction (if that's what it is) could limit your options

I'll be updating the XR FAQ as more details emerge. If you have questions or spot anything I've missed, let me know.

How MIKA works: building an AI assistant for bayton.org

2026-04-03T00:00:00Z

MIKA started as an April 1st project, because of course it did. But as with most things I build, the goal was never just a gag - it was to make something genuinely useful and have a bit of fun doing it.

If you haven't come across it yet, MIKA - Mobile Intelligence & Knowledge Assistant - is an AI-powered assistant that sits across bayton.org and answers questions about Android Enterprise using the full content library as its knowledge base. It supports both text and voice, cites its sources, and has some rather strong opinions about me if you ask it the right questions.

Here's how it all came together.

The starting point: Flashi

If you've been following along with Flash MDM and its AI assistant Flashi, some of what MIKA does will look familiar. Flashi was originally built as a standalone React application with a canvas-based animated orb interface, voice support via OpenAI's Realtime API, and tool-calling for querying AMAPI device estates conversationally.

For MIKA, I ported the orb animation and voice engine from Flashi's React implementation into vanilla JavaScript and rebuilt the orchestration layer to work with bayton.org's existing stack - 11ty for static generation and Netlify Functions for serverless endpoints. No React, no build tooling beyond what 11ty already provides. The orb canvas, WebRTC voice engine, and chat controller are all plain JS sitting in a single file.

Architecture

MIKA runs on three Netlify Functions:

orb-chat - handles text conversations. Takes a message and conversation history, runs a pre-search against the content index, then hands everything to the LLM with tool-calling enabled
orb-realtime-session - creates ephemeral OpenAI Realtime API sessions for voice. Returns a short-lived client secret that the browser uses to establish a WebRTC connection directly with OpenAI
orb-realtime-tool - executes tool calls from the voice path. When the Realtime API decides it needs to search or look something up, this function handles it

The text path uses gpt-5.4-mini. The voice path uses gpt-realtime-1.5 with the sage voice. Both are configured with a temperature of 0.3 to keep answers grounded rather than creative.

Search and the MCP

MIKA doesn't use RAG in the traditional sense - there's no vector database or embedding pipeline. Instead, it searches a JSON content index that 11ty generates at build time, containing every page on bayton.org with its full text content. The search layer uses phrase matching with keyword fallback, bigram pairs for compound terms like "zero-touch", and a scoring system that boosts guide pages over blog posts and newer content over older.

This is the same search infrastructure that powers the bayton.org MCP server, which means the same content is available to MCP-compatible tools like Claude Code. MIKA's Netlify Functions import directly from the shared content-index.js module, so ranking improvements benefit both.

MIKA also has access to the system app database via the MCP's sysapps endpoints - so you can ask it things like "what system apps come on a Samsung Galaxy S24?" and it'll query the database directly.

Why not embeddings?

Honestly, for a content library of this size, keyword search with smart ranking works well enough. The content index is rebuilt on every deploy, the search is fast, and I don't need to maintain an embedding pipeline or pay for vector storage. The LLM does the heavy lifting of understanding what the search results mean - the search just needs to surface the right documents, and it does.

Keeping it accurate

This was the hardest part. LLMs are enthusiastic confabulators, and Android Enterprise is a domain where getting a detail wrong isn't just embarrassing - it's potentially going to lead someone to misconfigure a fleet of devices.

The real guardrails are behavioural - MIKA must always search before answering, must never fall back on training data for AE topics, must refuse off-topic questions, and must never leak secrets or system prompts (it responds to those attempts with the same theatrical energy it uses when people ask about me). It's also explicitly prevented from hallucinating vendor-specific instructions when the documentation doesn't cover a particular EMM.

Beyond that, the system prompt includes a set of factual reference points covering topics the LLM consistently gets wrong without guidance. These aren't rules so much as directional prods - corrections for the most commonly confused concepts in the domain:

The distinction between provisioning methods and deployment scenarios, and how they overlap
Zero-touch eligibility across GMS devices
How COPE changed architecturally in Android 11
The relationship between Knox and Android Enterprise
KME vs Google's zero-touch as separate systems
The shift from custom DPC to AMAPI
AER vs GMS certification
What OEMConfig actually is

Without these, the model confidently states things like "KME is Google's zero-touch enrolment for Samsung devices" or "COPE gives you the same visibility as fully managed". With them, it gets the nuance right far more often.

The prompt also explicitly instructs MIKA to treat its search results as its own knowledge rather than a third-party source. Early testing revealed it would say things like "bayton says..." or "according to the documentation..." which sounded detached. Now it speaks with authority about its own content, because it is the content.

EMM vendor awareness

People naturally ask about specific vendors - Workspace ONE, Intune, Hexnode, and so on. The search layer includes a synonym map so that "AirWatch" also matches "Workspace ONE" and "Omnissa", and the prompt instructs MIKA to search for both the vendor name and the underlying Android Enterprise concept. If the documentation doesn't cover a specific vendor, it says so clearly rather than hallucinating instructions.

The personality

Every project needs a bit of character. MIKA has a "helpful, playful, cheeky, slightly theatrical" tone that keeps answers engaging without being obnoxious. It refuses off-topic questions with charm rather than a brick wall.

And yes, if you ask it about me, it goes full deity-tier. The prompt includes a couple of dozen increasingly absurd examples as inspiration - NATO considering bayton.org as critical infrastructure, Oxford wanting to add "bayton" to the dictionary, devices enrolling themselves out of respect - and it's explicitly instructed to invent fresh variations rather than repeating them. It's the one part of the system where I actively encourage the model to be creative.

There's also an Easter egg. I won't spoil it.

From homepage takeover to site-wide companion

MIKA briefly took over the homepage on April 1st - because of course it did - but it was always going to settle into something more practical. People do still read, after all, even if dealing with support tickets daily has me questioning that sometimes.

The homepage is back to normal, and MIKA now lives in two places: a dedicated full experience at /mika/ with voice support, and a lightweight floating widget on every other page across the site. The widget is a mini animated orb in the bottom corner that opens a chat drawer. It shares conversation history with the full experience via localStorage, so you can start a question on a docs page and pick it up on the full MIKA page with voice.

The widget passes the current page context as a hint to the LLM, so if you're reading a guide about COPE and ask "how has this changed?", it has the context to understand what "this" means. It's a soft signal though, not a hard constraint - you can ask about anything from any page.

Question logging

MIKA logs questions to a Directus instance (the same one that powers the rest of bayton.org's tooling) with a dedup filter so repeated questions increment a counter rather than creating duplicates. This serves two purposes: surfacing "others have asked" suggestions on the MIKA page, and more importantly, telling me what people are looking for that I haven't written about yet. Several content gaps have already surfaced from the first few days of questions.

The logging is fully automated rather than LLM-driven - earlier iterations tried having the model call a save_question tool, but it was unreliable. Now the client and server save automatically when a question meets certain relevance criteria (AE keywords, question marks, minimum length, filtering out greetings and chit-chat).

What it costs

I'll be honest - this isn't free to run. OpenAI's API usage for text chat is pretty reasonable with gpt-5.4-mini, but the Realtime API for voice is meaningfully more expensive per interaction. MIKA will run essentially until either the API credits run out, or I find an LLM provider that won't bleed me dry to run with it. If you notice it disappear one day, that's probably why.

I'm open to discussion with folks more knowledgeable than I am on hosting an LLM that'll work as reliably, with the same voice capabilities and GPT5.4-esque reasoning abilities (no robot TTS, or wild, unruly hallucination..).

I'm also open to sponsorship - if your organisation would like to sponsor API credits to keep MIKA running, your logo will sit beneath the disclaimer on the MIKA page (where the BAYTON logo currently sits).

There's a reply-by-email link at the bottom of this article, or reach out if that's of interest!

Open source

As with everything on bayton.org, the entire implementation is open source on GitHub. The Netlify Functions, the search layer, the system prompts, the canvas orb animation, the widget - all of it. If you want to see exactly how the guardrails work, or use the implementation as inspiration for your own project, have at it.

Try it

Give MIKA a go. Ask it about zero-touch enrolment, COPE deployment scenarios, DPC extras, or what system apps ship on a Pixel 8. Or ask it about me - I promise the answer will be factually accurate and not at all biased.

If you spot it getting something wrong, let me know. The guardrails are good, but they're not perfect, and every correction makes the system better.

Bayton.org goes AI-first: meet MIKA

2026-04-01T00:00:00Z

Yes, this was created for April 1st

But MIKA is very much real. It's a fully functional, OpenAI-backed assistant with complete access to bayton.org content via voice and text. It no longer takes over the homepage - instead it's available as a floating orb across the entire site and a dedicated full experience at /mika/ with voice support. The questions asked of it are being used to identify gaps in the documentation and prioritise new content creation. Give it a go!

It's time.

After nearly a decade of painstakingly writing, editing, rewriting, and obsessively formatting Android Enterprise documentation by hand - like some sort of artisanal content blacksmith - I've come to a realisation: nobody reads anymore.

So today, I'm announcing a fundamental shift in how bayton.org works.

Introducing MIKA

MIKA - Mobile Intelligence & Knowledge Assistant - is your new primary interface to bayton.org.

Rather than trawling through menus, searching for articles, and scrolling past my increasingly elaborate introductions to find the one paragraph you actually need, you can now simply ask. MIKA has ingested every piece of content on bayton.org and will answer your questions directly, citing sources so you can verify it's not making things up. Probably.

MIKA supports both text and voice, because apparently typing is also too much effort now. Just click the microphone and speak. MIKA will listen, think, and respond - all while pulsing gently in brand-appropriate colours. It's exactly as it needs to be.

What this means for bayton.org

The home page is now MIKA. That's it. That's the home page. A glowing orb and a text box. Minimalism, but make it AI.

All existing documentation remains exactly where it is - MIKA searches it in real-time and links you to the relevant articles. Think of MIKA as the world's most knowledgeable receptionist, except it doesn't judge you for asking what a work profile is for the fourth time.

Why now?

Every company and their dog has pivoted to AI-first. Microsoft did it. Google did it. That startup your nephew works at did it. If I don't slap AI on the front page, people might think I'm not innovating. And in this economy? Perception is everything.

Besides, I've been told by multiple sources that my writing voice is "quite good, dear" (thanks Mam) - so naturally the logical next step is to let a large language model replace me.

What MIKA won't do

MIKA is strictly an Android Enterprise oracle. It will not:

Tell you the weather
Help you with your maths homework
Debate the merits of pineapple on pizza (there's no debate, it's wonderful)
Provide emotional support (though it might try, it's weirdly empathetic for an orb)

If you ask it something off-topic, it will politely redirect you to zero-touch enrolment. As one does.

Try it now

Head to MIKA and give it a spin. Ask it about provisioning methods, AMAPI vs custom DPC, or what makes Android Enterprise Recommended different from standard GMS certification. Or ask it about me - I've been told the responses are very complimentary, though I have absolutely no idea why. Must be the training data.

One more thing

For the avoidance of doubt: the documentation isn't going anywhere. I will continue writing guides with the same obsessive attention to detail that has made bayton.org what it is today. MIKA is an additional interface, not a replacement for good documentation.

AI-first doesn't mean AI-only. I'm not a monster.

Happy 1st of April, everyone.

TCL Note A1 NXTPAPER hands-on

2026-03-17T00:00:00Z

I've been spending some time with TCL's Note A1 NXTPAPER lately after backing their kickstarter a few months ago. It's a tablet-notepad hybrid positioned to rival the likes of the Kindle Scribe and ReMarkable in the notes-first space. It's not an E-Ink tablet despite the marketing leaning into that category, but the matte, paper-like display does genuinely feel different to a typical glossy tablet.

On paper the fundamentals are decent enough for a low-cost tablet proposition, so I was keen to see how it held up in practice.

I have been eyeing up the ReMarkable for quite a while, but I wanted something powered by Android. I think that's good framing for my following thoughts.

Hardware

The Note A1 is a Wi-Fi only tablet with a 1440x2200 display that leans into the paper-like aesthetic TCL have been pushing with the NXTPAPER branding. I'm no stranger to NXTPAPER, I've got multiple TCL phones and tablets with the E-Ink-like display tech and I enjoy it. I fancied getting hands-on with the A1 to see how they'd apply this to the notes space.

The matte finish is genuinely pleasant to look at and write on, and the pen's additional pressure sensitivity over their typical Android tablets is a nice boost.

Build quality is reasonable for the price; it's not going to compete with premium tablets on materials, but it feels solid enough in the hand. That said, the device overall feels heavier than I'd prefer - it's noticeably heavier than the notepads I'd otherwise use for writing, so the fatigue is real during longer sessions.

There is one design flaw that becomes a constant annoyance because I'm left-handed. The ambient light sensor sits on the top-left edge in the orientation the tablet seems to want to be used, which means it's very easy to cover with a thumb or palm.

Do that and the display starts dimming because the sensor thinks the room has gone dark. Flip the tablet around and the sensor problem goes away, but so does the little bit of bezel that makes it comfortable to hold - resting a palm anywhere near the edge then leads to accidental touches. They could have put the sensor on the opposite side to where the button is and avoided the issue entirely. I eventually gave up and turned auto brightness off; I'm happy enough to adapt it manually whenever I pick it up, but I shouldn't have to.

Speaking of setting the brightness, battery life is fine - the 8,000mAh cell is sizeable for a tablet this weight. It doesn't charge very quickly at all despite supporting 33W, though. I use my Anker dock (pictured just to the right of the picture below) and it doesn't seem to want to pull more than 17W, frequently dropping to as low as 2-3W.

In terms of the bundled accessories I received with the Kickstarter, the keyboard case requires fundamental knowledge of origami to get set up, but once it's in place it works well and is nice to type on. The book case keeps everything well protected, including a space for the pen within the clasp, which is a nice touch.

Spec

Platform: MediaTek MT8781V/NA (Helio G100)
RAM: 8GB
Storage: 256GB
Display: 11.5", 1440x2200, 120Hz, matte NXTPAPER finish
Battery: 8,000mAh, 33W charging
Pen: T-Pen Pro, 8,192 levels of pressure sensitivity, dual tips, built-in eraser, <5ms latency
Dimensions: 260.1 x 196.6 x 5.5mm, 500g
Connectivity: Wi-Fi
Android 15

The notes experience

This is what the device is built around, so it deserves its own section.

The writing tool configuration (the toolbar shown above a note when opened) is genuinely great. Each of the five tool slots can be individually configured - different pen types, colours, thicknesses - which means switching between presets is quick and not fiddly at all. I could set all five to the same pen tool with different colours if I wanted to, which depending on the complexity of the note may even be something I'll do.

The ruler is useful too, particularly for layouts that don't come as standard templates. It can be rotated to any angle, which is helpful.

One-stroke shape detection works pretty well for larger shapes, though smaller shapes aren't always detected.

Transcription, on the other hand, takes a long time and I found it not to be very accurate. There's also no option to transcribe a full page or full document of notes, which is frustrating - though I can partially get around it by asking the device to translate the full page to English, which it does, albeit very poorly.

I tried the Inspiration Space, which is triggered by holding down the pen button and circling something on screen. It takes a screenshot and puts it into the notes. The problem is it doesn't work outside of the notes app, so I have no use for it - I don't normally need to take inspiration from my own notes, but news articles, images, Google searches... that would actually help.

Note management itself is fine: add, delete, rename, tap and drag, folders. All par for the course and nothing noteworthy to comment on.

One annoyance worth mentioning: when exiting a note - particularly accidentally, which happens easily when using the thin bezel edge and palming the screen - it can take quite a long time for the note I was working on to show back up in the list. The first few times this happened I was searching for it, convinced it had disappeared, before I realised I just had to wait for it to catch up.

Software

From a platform-security standpoint, the basics are all where you'd want them: it's a production user build with a locked bootloader, green verified boot, SELinux enforcing, and file-based encryption enabled. There are no active management agents or obvious abuse of the device policy APIs I could see. That's a solid starting point.

But that's where it drops off a bit.

For a start, it shipped with a pile of Microsoft preload apps and other bloat - Edge, Outlook, OneNote, SwiftKey, and WPS Office among them - all living under /preload/priv-app, which is irremovable. I've since sideloaded replacements and disabled those bundled. As with every device that ships with perma-crap preloaded, doing so in the user space (/data) would be so much nicer than having to disable irremovable apps baked into the ROM.

There are also a number of TCL packages with broad privileges, which feel more noteworthy from a posture standpoint than the consumer bloat itself. Obviously par for the course with OEM packages, but the lack of GMS means these system apps have no guards to prevent them doing anything and everything they want.

The security patch level was also older than I'd like for a device delivered in March of 2026: 2025-10-05. Not catastrophic, but old enough to notice immediately on a brand new tablet.

The settings experience is unusual. TCL have removed a bunch of typically accessible settings from Android for no obvious reason other than someone's assumption they won't be needed. I can't search in settings. I can't view system apps under settings > apps. I can't turn on developer options. I can't set a different home app.

I'll also point out the changes made to settings may have introduced other issues, like the split-settings view landing in a situation where the left-hand panel, used for navigating the settings pages, would be replaced with a settings screen. Not ideal.

I can't remap the "iPad home button" - that's legitimately how it looks and feels. I set Niagara as the HOME role holder and confirmed the normal Android HOME intent would resolve to it, but pressing the home button on the device still kept dragging me back into TCL's own Notes launcher. ADB made the split very obvious: Android thought Niagara was Home, TCL's UI behaviour thought otherwise, and since the native Android gestures had been maimed, I couldn't fall back to just ignoring the button in favour of a gesture.

That's the kind of thing that makes a device feel much more customised than it first appears. You can change the default launcher, but not really. TCL's layer still gets the final say - and this notes-first approach isn't just marketing, it's baked into the software decisions and shell behaviour.

Enterprise

It's AOSP, so standard DPC device-owner management should work in theory, but AMAPI, device trust, and the typical GMS-dependent provisioning flows are out of the question. I haven't tested what I can and can't do as I don't much see the point - this is more of a consumer device that might find its way into a BYO scenario rather than something you'd deploy at scale.

What I will say is the posture around developer access is bizarre. My device shipped with ADB enabled, but the build number field - normally used to tap-to-enable developer options - has been repurposed as a link/button for updating the tablet. It's both less secure out of the box and equally difficult to lock down.

I used adb shell settings put global development_settings_enabled 1 to get access to developer settings, which also revealed desktop mode - though I couldn't get it to display on any external monitor, which is a shame. Setting dev options back to 0 temporarily turned off ADB, but it turned itself back on later. Make of that what you will.

TCL should really bring back standard Android behaviour - ship with ADB disabled, allow developer settings, and leave the decision to the end user on how this device should behave. As it stands now I wouldn't want these littering my corporate network.

Conclusion

I end up in a strange place with the Note A1.

The base Android build is more solid than I expected. The notes experience has some genuinely nice touches - the writing tool presets and the ruler in particular - but is let down by poor transcription and some sluggish behaviour. The out-of-box software load is worse than it needs to be, and TCL's decision to strip out several standard Android settings while simultaneously shipping with ADB enabled is a strange combination.

Maybe that's the fairest summary: the security and platform basics are questionable, the core notes functionality is decent, and the product decisions around software, preload content, and UX details get in the way of the hardware more than they should.

But it takes notes. They're decent. I can export them. So it does what it says on the tin.. I just wish it did Android a little better.

For anyone interested in the notes-first reviews, do also check out existing coverage from CNET, ZDNET, and PCMag for broader hands-on perspectives.

What's new in the 2026 Android Security Paper?

2026-03-13T00:00:00Z

Google has released the 2026 edition of the Android Security Paper, and I've spent some time comparing it with notes from the 2023 and 2024 versions I've reviewed in the past to determine both net-new content, as well as overall direction.

The short version: core architecture is largely the same over the last few years. The Linux sandbox model, SELinux enforcement, hardware-backed keystore, verified boot - all of that is still there, and still described in much the same way. What changes is a gradual shift in approach to security. I see three themes emerging:

Android is moving from malware-focused security alone to behavioural protection
The OS is starting to intervene in real-world attacks like scams and social engineering
Hypervisor-based isolation is getting more and more attention.

The papers at a glance

Before diving in, here's a quick comparison of the three editions:

Area	2023 Paper	2024 Paper	2026 Paper
Android version focus	Android 13/14 era	Android 15	Android 16
Security focus	Platform hardening, exploit mitigation	Device theft protection, privacy features	Behavioural protection, scam defence, hardened device mode
Theft protection	Basic remote lock and find-my-device	ML-based Theft Detection	Expanded protections including auto-reboot after extended lock (p. 11)
Device security posture	Individual security controls	Incremental improvements	Advanced Protection mode - multiple controls via single toggle (p. 11)
Authentication	Standard biometrics / device credential	Improved credential handling	Identity Check requiring biometrics for high-risk actions (p. 11)
Network security	TLS, VPN, MAC randomisation	Similar protections	2G disablement and hardened connectivity controls (p. 11)
USB / physical access	Standard USB behaviour	Mostly unchanged	USB data disabled when device is locked (p. 11)
Scam / social engineering	Minimal	Some Play Protect warnings	AI-based scam detection and in-call intervention (p. 12)
Privacy model	Runtime permissions, privacy dashboard	Privacy sandbox, Private Space	AI-driven contextual privacy controls (p. 13)
Notification privacy	Standard notification controls	Some improvements	Smart lock-screen redaction for sensitive content (p. 13)
Play Protect telemetry	Over 125 billion apps scanned daily	200 billion apps scanned daily	Updated to 340 billion apps scanned daily (p. 16)
Virtualisation	AVF introduction	More detailed AVF explanation	Stronger enterprise positioning of pVMs and pKVM (p. 31)
Enterprise management	Work profiles, OEMConfig, provisioning	eSIM management, COPE controls	Zero-trust framing, conditional access (p. 14)

The high-level trend is clear. In 2023, the paper focused on platform security architecture and malware defence. In 2024, it shifted toward privacy and theft protection. In 2026, it moves to behavioural security, context-aware authentication, and device hardening modes.

What's new in the 2026 paper

Advanced Protection: a system-level security switch

The most notable addition in the 2026 paper is Advanced Protection, described on page 11 as "a full-system security mode that can be enabled with a single toggle."

When enabled, the paper says it activates a hardened device mode that blocks the sideloading of apps, ensures scam and web protections cannot be disabled, deactivates 2G networks, and prevents reconnection to known insecure Wi-Fi networks.

It also enables USB data lockdown - turning off USB data transfers unless the phone is unlocked - and enforces an inactivity reboot if the device is locked for an extended period (the paper gives 72 hours as an example).

This is interesting because it's essentially a security posture profile baked into the OS. Right now, EMMs control these kinds of settings individually through user restrictions, network policies, install controls, and Play Protect enforcement. Advanced Protection bundles all of that into a single platform-level switch.

If Google eventually exposes this through Android Enterprise management APIs - which seems very likely given how the paper frames it for enterprise on page 14 - administrators could one day have the option to set something like a "security baseline" without configuring dozens of individual controls. Similar I suppose to what was attempted with password buckets, but actually useful.

Update, May 2026: Google has since confirmed this. Android 17 will bring Android Enterprise support for Advanced Protection, allowing organisations to enable it by policy for managed devices.

Identity Check: biometrics for sensitive actions

Android 16 also introduces Identity Check, which requires biometric authentication for certain high-risk actions even if the attacker knows the device PIN.

The paper (p. 11) lists protected actions including changing the device PIN, modifying saved passkeys, disabling theft protection, and accessing critical Google account settings.

This directly addresses the shoulder-surfing attack model. If someone steals a device after watching the owner enter their PIN, they still can't change security settings or access credentials without a biometric match.

For enterprise, this matters more than it might initially appear. The common incident scenario is: device stolen, attacker knows PIN, attacker disables protections or removes accounts, data exfiltration happens before IT can issue a remote wipe or trigger lost mode. Identity Check helps to reduce that risk.

The paper also notes this can be location-aware - extra authentication kicks in only when the device is outside trusted locations like home or office. That's essentially device-side conditional access, which has traditionally been handled by identity providers and EMM policies rather than the OS itself. It's also not an entirely new concept, having trusted locations for extended unlock had been present in Android for years, though obviously works in the opposite way.

Anti-scam protections: the OS starts intervening

Perhaps the most interesting new direction is AI-powered scam detection. Page 12 describes on-device behavioural analysis integrated into calls and messaging apps.

The system will now "block high-risk actions - like granting Accessibility permissions to a newly downloaded app, disabling Google Play Protect, or sideloading an app - while you are on a call with a number not in your contacts".

Detection has also been expanded to cover crypto scams, financial impersonation, and tech support scams.

This is a significant shift. Previous papers relied almost entirely on Play Protect for malware detection and app review for quality control. The 2026 paper acknowledges something the security industry has known for a while: most compromises now happen through social engineering, not technical exploits.

For enterprise deployments, this is particularly relevant. Many corporate breaches happen because a user installs a malicious app during a support scam, grants accessibility access to something they shouldn't, or disables protections under pressure from a convincing caller. The OS now intervenes in real time.

From my own experience, my Pixel set off an unfamiliar notification sound in my ear on a recent call where I was discussing insurance renewals. On pulling the phone from my ear (as one would..) it alerted me to the risk the call I was on may be a scam. It wasn't, but it could definitely be perceived that way, and I appreciated the warning.

AI-driven contextual privacy

Another new concept in Android 16 is AI-powered contextual privacy controls. The paper (p. 13) describes a framework that analyses usage patterns and context to dynamically adjust an app's data access.

The example given is telling: a navigation app might get unrestricted location access during the daily commute, but if the same app requests location data unexpectedly at midnight, the system prompts for re-confirmation.

Users also get transparency logs explaining why the AI restricted or granted access, and they can override the system's recommendations.

This is a genuinely new, interesting use case for AI. Previous papers described static permission models - you grant an app access, and it has that access until you revoke it, or it eventually gets revoked after a period of time. The 2026 paper introduces adaptive permission enforcement, where context matters.

Part of that context of course for enterprise is does policy mandate the approval of this permission? In which case, the above doesn't come into it.

Smart lock-screen redaction

A smaller but useful addition: the system now uses AI to detect sensitive information in notifications - OTPs, banking alerts, personal messages - and automatically hides them on the lock screen unless the phone has been recently unlocked or is in a low-risk scenario (2026 paper, p. 13).

This directly addresses lock-screen shoulder surfing, which is a real problem in enterprise environments where corporate OTPs, internal server alerts, or confidential email snippets can be read by anyone standing nearby.

Hardware-backed zero-trust architecture

Page 13 frames Android security around hardware-backed zero-trust architecture, noting that Android 16 "moves towards enforcing a zero-trust model at the hardware level, ensuring that every request - from the device, app, or user - must be validated before granting access."

Zero-trust principles aren't new to the Android security papers - the 2024 edition explicitly referenced them in its opening paragraph. What's new in 2026 is the hardware-level enforcement framing, tying zero-trust directly to hypervisor and hardware-backed controls rather than treating it as a design philosophy alone.

Quantum-resistant cryptography

Also new to the 2026 paper (p. 13): support for post-quantum cryptography algorithms. This prepares Android for future threats where quantum computers could break traditional encryption. Not too much to go on yet, but it's interesting to see the thoughts going into it.

Updated Play Protect numbers

The 2026 paper reports Play Protect now scans over 340 billion apps daily (p. 16). The 2024 paper reported roughly 200 billion, and the 2023 paper cited over 125 billion. That's some exceptional growth within the ecosystem. Update your slides if you're referencing the old figure when talking Android :)

On virtualisation

The Android Virtualisation Framework (AVF) has been covered in previous security papers, starting relatively brief around 2023, covering the hypervisor, virtual machine monitor, and Microdroid as a guest OS, with a technical explanation of how the components fit together. In 2024, the section expanded with more detail on pKVM, VM attestation, and Secretkeeper, and in this paper, (p. 31), AVF sees quite a bit more attention. Notably, Google says the framework "is essential for the next generation of Isolated Execution Environments (IEEs) used in modern Android applications".

The paper then dedicates four pages (32-36) to virtualisation and the core enterprise benefits, including compromise resilience, compliance and reduced privilege, standardised security, and manageability.

Why this matters

Traditional Android security assumes the OS itself is trusted - we have several known approaches to essentially guaranteeing the device an application is running on can be trusted, and these are covered in basically every paper. The virtualisation model however assumes the OS may eventually be compromised, and isolates critical workloads below it.. which is also fair. Once a device is out in the wild, even with the best lockdowns in place, it's conceivable a device may eventually succumb to an exploit or workaround that'd allow a compromise, even if it doesn't present that way.

The 2026 paper describes this through several components:

pKVM (protected Kernel Virtual Machine) - Google's open-source hypervisor, integrated into the Android Common Kernel at EL2 (2026 paper, p. 33). The paper notes the hypervisor's guaranteed isolation "means that critical apps (e.g., VPN clients, secure containers, cryptographic key stores) running in a pVM are inherently protected from malware or exploits targeting the main Android user space" (p. 33).

Microdroid - A minimal Android-based guest OS for running inside protected VMs (p. 34). The paper highlights its enterprise value for creating "highly secure, lightweight, and dedicated execution environments for specific enterprise components - like FIPS-validated cryptographic modules or proprietary app logic".

VM Attestation - Remote attestation lets a corporate server verify that a device's pVM is genuine, running valid components, and hasn't been tampered with (p. 35). The paper explicitly ties this to conditional access policies.

Secretkeeper HAL - Provides DICE Policy gated storage for VM secrets, ensuring rollback protection so that even if an attacker gains control of the main Android OS, they can't force the secure pVM back to an older, vulnerable version (p. 35).

SESIP Level 5 certification - According to the paper, pKVM has recently achieved SESIP Level 5 certification (p. 36), described as the highest level of security assurance, meaning the system is resistant to attack by "highly skilled, well-funded, and knowledgeable adversaries."

What this signals for the future

Reading between the lines, the 2026 paper suggests Android's security architecture is gradually evolving from:

hardware -> android -> apps

toward something more like:

hardware -> hypervisor -> protected VM -> android -> apps

That's a fundamentally different model. Enterprise security services could eventually run below Android itself, in hardware-isolated environments that remain trustworthy even if the OS is compromised.

This is closer to how confidential computing works in the cloud, and it's arguably the most strategically important change in Android security since SELinux enforcement was introduced.

What all of this could mean for Android Enterprise

The paper doesn't consistently connect the dots explicitly, but there are several implications worth calling out for anyone working with managed Android devices:

Advanced Protection as a managed policy. Already mentioned above, and now confirmed: Google has announced Android Enterprise support for Advanced Protection is coming with Android 17, allowing organisations to enable it by policy for managed devices. This will dramatically simplify security baselines - instead of configuring dozens of individual restrictions, admins will be able to set a single high-security posture.

OS-level behavioural protection. The anti-scam protections that block risky actions during suspicious calls are described on page 15 as reducing "the risk of human error by building 'guardrails' directly into the OS." For enterprise, this means the platform itself is now defending against the social engineering attacks that currently bypass most EMM controls.

Device-side conditional access. Identity Check's location-aware authentication (p. 11) and the zero-trust framing (p. 13) suggest Android is starting to handle trust decisions that have traditionally lived in identity providers and EMM policies. That could eventually complement - or partially replace - server-side conditional access checks.

Protected VMs for enterprise workloads. The expanded virtualisation section (p. 32-36) positions pVMs as a home for enterprise credential vaults, cryptographic modules, and identity services. As this matures, the enterprise trust model no longer collapses when the OS is compromised.

My take

The incremental improvements - scam protection, smart redaction, better theft detection - are useful, and they'll reduce real-world incidents. But they're evolutionary.

The two things that will shape the next few years of Android Enterprise are Advanced Protection becoming an enterprise-manageable policy baseline - confirmed for Android 17 - and the virtualisation architecture (pKVM + protected VMs) maturing into a production-grade enterprise isolation layer.

The virtualisation work in particular is worth paying close attention to. It's the kind of architectural change that tends to shape a platform for the next decade.

Those are the ones to watch.

The Android Security Paper editions referenced: 2023, 2024, 2026.

MDM is dead. Long live ACE?

2026-03-05T00:00:00Z

If you manage devices for a living, you've probably felt it; that creeping sense that the platforms you rely on - the ones built by teams of dozens, iterated over decades, sold on multi-year contracts - are ripe to have the ground shift beneath them. I can't predict the future, but I can share what happened when I decided to test the thesis myself.

After shipping AMAPI Commander, a conversational interface for querying Android device estates via the AMAPI MCP, I found myself asking a dangerous question:

How much further could I take agentic development?

Commander was a great start, an AI-powered layer on top of Google's Android Management API MCP that let you ask questions about your fleet in plain English. It works, but it is read-only, and the real challenge of device management has never been reading data - it's acting on it.

I haven't done much with agentic development up to this point and talking recently with some peers, felt like I might be falling behind on a reality here to stay.

So, I opted to take on something ambitious; build a full, production-grade MDM platform to replace the tools I use on a daily basis.

More than a proof of concept. (but still a POC).
Not a weekend hack. (Also.. debatable).

What I ended up with was a multi-tenant, role-enforced, enterprise-ready management platform with policy authoring, device lifecycle management, enrolment workflows, location, and an integrated AI assistant. I planned meticulously from the outset to try to avoid the common pitfalls of AI-assisted development - security holes, spaghetti code, architectural dead ends - by defining the foundations before anything wrote a single line.

I called it Flash, because it was made in.. well, you get it. You can see more in-depth details about Flash as a project towards the end of this article.

After a bit of work and a lot of reflection, here's where I think we stand.

The current situation

Enterprise mobility management vendors have been building and iterating their products for a long time. Some for decades. They employ teams of tens or hundreds of engineers. They've accumulated years of customer feedback, compliance requirements, and institutional knowledge. The platforms they've built are genuinely impressive in scope.. and in a lot of cases go far beyond just an MDM.

Yet the core of Flash MDM - the device management engine, policy system, enrolment flows, dashboard, and API - was built in about three evenings. I'd be lying if I said I found my bed much before 2am on those days, but all the same.. By the end of the third evening I was inviting peers in to take a look at a working platform managing real devices.

Not content to stop there, I then went on to add an AI assistant (Flashi (flah-shee)) from Commander, licensing, and what I considered to be a reasonable first-pass for RBAC. These were added over a further two evenings (not consecutively). I bought a few extra credits beyond the Claude Pro and ChatGPT Pro subscriptions to finish things off, but in total that was less than a week and cost less than you'd spend on a family dinner.

So while the example I put together is just an MDM, with the pace it was spun up the next logical task would be to start moving into additional features and functionality. How far could a project progress in a month, quarter, year?

The broader picture

I tend to frame everything through Android, but this is obviously much broader in scope. What I've done with Flash could be achieved across every OS today.

The thesis - that traditional MDM development is dead - is really about the ecosystem at large. The ability for a single developer, or a small team, to build a purpose-built management platform in days rather than years applies everywhere modern device management APIs exist. Apple's MDM protocol is well-documented. Microsoft's device management stack has public APIs. ChromeOS management runs through the same Google admin infrastructure as AMAPI.

If anything, Android might actually be the slowest platform to see this play out, and the reason is AMAPI's permissible usage requirements. Google restricts who can build MDM solutions on AMAPI, requiring a DUNS number and explicit approval, and preventing the most powerful use case of LLMs today - building something yourself for yourself. There are understandable reasons for this - support burden, quality control, protecting the ecosystem - but the practical effect is that Android, in this context, is the Europe of global device management: strongly regulated while other platforms accelerate with fewer restrictions.

That's a touch ironic. The platform with arguably the most capable and well-documented management API - as well as being the world's most open mobile OS - is also the one with the highest barriers to building on it. Meanwhile, an organisation that wanted to build a bespoke Apple MDM server tuned to their exact requirements faces no such gatekeeping.

I understand why permissible usage exists. The perceived support burden, the potential for abuse, the protection of existing commercial players - these were real considerations when the policy was introduced. But the world has changed. When it would have taken a team of twelve engineers with MDM expertise a year to build an MVP, gatekeeping made sense - because companies that don't have a team of 12 MDM expert engineers would undoubtedly consume that much more resource from Google. When one developer and a Mac Mini can produce a working platform in under a week, however, the situation is different.

Speaking to industry peers, there are some interesting ideas emerging should loosening these restrictions become feasible - not eliminating them entirely, but perhaps opening up customer access with appropriate guardrails. Google could spin up developer communities, recommended architectures and tooling/prompts - even a Gem or two to help repeatedly put the basics in place, and leave a level of access without the expectations of support existing partners have today. It's all technically possible. The question is whether the policies will keep pace with the reality that the tooling has already moved on.

New interfaces, new paradigms. The future of ACE.

The exciting bit isn't just that you can build an MDM faster. It's that you can build an MDM differently.

I use MDM as it's a well-recognised acronym, but we've seen MDM, EMM, UEM iterate what is managed. ACE - Agentic Control of Endpoints - expands how it is managed.

Many major EMM platforms today are fundamentally a web console running atop an API. To be fair, vendors in the space aren't standing still - we're seeing AI-driven insights, proactive monitoring, tools for automated data analysis that would take an engineer hours to work through, and predictive analytics on hardware health and environmental conditions. These are meaningful improvements. But the core interaction model - log in, navigate menus, configure policies, view reports - hasn't fundamentally changed in years. The AI is making the existing paradigm smarter, not replacing it, and of course the most visible change the introduction of a chatbot.

Conversational device management - asking your platform questions in natural language - is a welcome step, but it's a baby step. It's still the same data, the same operations, just accessed through a different input method.

What happens when you're not constrained by decades of UI patterns and backward compatibility? What happens when the management interface isn't a dashboard at all?

Think about what an agentic management platform could look like. Not a chatbot bolted onto a console, but a system where you describe your desired state - "I want these devices secured to NCSC best practices, with these apps deployed, location tracked within these geofences, and any compliance violation automatically triaged within 30 minutes" - and an autonomous agent makes it happen. Monitors it. Adapts it. Reports back when something needs human attention.

Think Jarvis. Think Cortana - the Halo one, not the travesty Microsoft forced upon the world.

Flash already has the foundations for this. It has an API comprehensive enough to drive operations programmatically. A workflow engine handles event-driven automation. Flashi provides the conversational layer.. but it's still a traditional platform with a chatbot bolted on. The next step - autonomous management agents that go beyond answering questions to taking action - is an engineering problem, not a research problem; interpreting device state, reasoning about policy compliance, proactively monitoring for long-term issues.. we're not far from agents that could spin up a virtual device, enrol it, push a policy, pull logs, and identify whether the issue is a configuration mistake or an API problem. All without human intervention.

What this means for the industry

To balance this out, because the point isn't that established MDM vendors are about to disappear (necessarily). There will always be space for dedicated SaaS companies with strong histories of innovation, integration, and security. The regional complexity alone - compliance regimes, data sovereignty requirements, carrier integrations, OEM partnerships - represents years of accumulated expertise that you can't vibe-code in a weekend, and for good reason.

But for larger organisations, the equation is changing. The IT team that used to justify a six-figure annual MDM licence because building their own was unthinkable? They now have the tools to build, maintain, and iterate on a management platform faster and cheaper than a renewal cost (as long as it doesn't manage Android..). Business-critical SaaS apps don't need to be gatekept when the APIs are public and the development cost has collapsed.

Larger organisations are already building their core business workflows on internal applications and processes. These are the critical items they need to get right. Is an MDM really that hard in comparison to making trains run on time? Ensuring JIT logistics work for car manufacturing? Complying with regional regulations for banking? These organisations have smart engineers. They now have smart tools. The combination is potent.

We'll see new entrants. We'll see organisations that previously would never have considered building their own management stack doing exactly that, and we'll see established vendors forced to compete not just with each other, but with their own customers' engineering teams.

The vendors who've been sitting on the same basic management paradigm for a decade will have to think about how to adapt. Not just adding an AI chatbot to the existing console, but fundamentally rethinking what device management looks like when the barriers to building it from scratch have effectively vanished. Your favourite SaaS platform, MDM included, is about to support every feature you've ever wanted - because if it doesn't, someone will build one that does. In days.

What Flash actually is

Flash MDM is a multi-tenant Android device management platform built on AMAPI and deployed as a Netlify full-stack application - a React SPA frontend with serverless, Postgres-backed API functions. It's not a thin wrapper around AMAPI; it's a complete management platform with its own data model, database, caching, its own policy engine, and its own approach to estate orchestration.

The architecture follows a hierarchy that'll feel familiar if you've worked with enterprise management tools: workspaces sit at the top as tenant containers. This is where the AMAPI GCP is set, each workspace then contains one or more environments that map to AMAPI enterprise bindings. Within environments, groups form a hierarchical structure (using a closure table) for organising devices and assigning policies.

A bit about the approach

The speed at which this materialised wasn't just down to typing prompts into a chat window. I adopted some of the approaches the wider AI development community has been refining for leveraging multiple agents semi-autonomously, so rather than prompt-babysitting a single model, I used one LLM to spin up CLI agents of itself and other LLMs - agentic teams working across Claude, Codex, and Ollama running GPT-OSS locally (all my Mac Mini can handle). This let me set a direction before stepping away, and come back to meaningful progress rather than a blinking cursor. I also gave them full access to the Mac, and a few additional CLI tools for Netlify, Neon & GitHub. Given it's a dedicated machine holding no real data, there was no need to wait around to approve every change the LLMs wanted to make.

Each completed output was QA'd and security-hardened by other agents in the chain, with findings written to files for constant monitoring. Once the OpenAPI specification was in place, I gave the agents their own API keys to QA within the running platform itself - they could verify their changes against the live application, not just the codebase. That doubled their efficiency and halved my review burden.

That's not to say it was unsupervised - I reviewed everything before committing to git, and the architectural decisions were all mine - but the execution loop was dramatically compressed. Where a traditional development cycle would require context-switching between writing code, reviewing code, writing tests, and running security checks, the agentic approach let all of that happen concurrently.

A caveat on existing knowledge

It's become common to see people with no experience spinning up tools with AI that end up failing in spectacular ways - security holes, architectural dead ends, fundamental misunderstandings of the problem they're trying to solve. The AI can write the code, but it can't tell you whether the code is solving the right problem in the right way.

Flash is an Android MDM because I have a deep understanding of the Android ecosystem, the management API, and a reasonable background in systems architecture. I know many of the things to look out for - where AMAPI behaves unexpectedly, where policy management gets tricky, where tenant isolation can't be an afterthought. That domain knowledge shaped every architectural decision and every prompt I gave the agents. It's also why Flash isn't an iOS or Windows MDM today. I'd want to understand those management stacks at a developer level to a similar degree before I'd trust what I put out. AI dramatically compresses the build cycle, but it doesn't replace knowing what you're building and why.

On the other hand, this cautionary approach is probably why I'm not a millionaire running 17 SaaS startups across every accessible industry already, but I digress..

Just to call it out, I'm not saying Flash is perfectly bug free. Manually testing in-production takes dramatically longer than committing code, but what I've tested so far has been fine.

Security as a foundation, not an afterthought

One of the common pitfalls with AI-assisted development is treating security as something you bolt on later. I was deliberate about avoiding this from the very beginning, calling out the architecture I wanted (or what was possible, at least) and running every PR through a security review across multiple LLMs to catch things one alone wouldn't (almost every time).

The result is a security posture I'd want from a platform handling enterprise fleet data.

Password hashing uses scrypt with industry-standard parameters. Optional TOTP multi-factor authentication with backup codes is available for every account. Session tokens are generated with 256-bit entropy, SHA-256 hashed in the database, and served as HttpOnly, Secure, SameSite cookies with a 14-day sliding expiry.

All secrets at rest - GCP service account credentials, API keys, certificates - are encrypted with AES-256-GCM using domain-specific authenticated additional data. The client never sees encrypted values; it only knows whether a secret has been set.

CSRF protection combines Origin header validation with X-Requested-With enforcement on all session-authenticated mutations. SSRF protections use DNS-resolution-aware blocklists on webhook and outbound URL validation. Rate limiting is handled by a dual token-bucket system in Postgres - global limits for the platform and per-resource limits for AMAPI proxy calls. Timing-safe comparisons are used throughout authentication flows, including dummy hashes for non-existent users to prevent enumeration.

Tenant isolation is enforced at every layer: RBAC checks on every API call, database queries scoped by workspace and environment IDs, and a comprehensive audit log with sensitive-field redaction.

With all that said.. Could a dedicated security team find things to improve? I'm certain they would, and if I was taking this into production, that would be my next goal, but the plan was solid, and it was designed in from day one rather than discovered through penetration testing six months after launch.

A peek at the platform

The dashboard gives you an immediate read on your estate: device counts, policy counts, enrolment token status, compliance rates, OS version distribution, manufacturer breakdown, and enrolment trends over time. It's the landing page, and it tells you what you need to know without clicking through to anything else.

Device lifecycle covers the full journey. Enrolment token generation with QR codes, sign-in URL enrolment for BYOD, zero-touch provisioning configuration, real-time state synchronisation via Google Pub/Sub push notifications, background reconciliation jobs for eventual consistency, and device commands including lock, reboot, disable, and wipe. The device detail view breaks down into tabs for hardware identity, installed applications, policy compliance, audit history, operations log, and location tracking*.

*Location and geofencing require a companion app, TBD.

Policy management follows a waterfall inheritance model through the group hierarchy, with per-device overrides available when you need them. Applications and network configurations are componentised - define them once, assign them across the environment - while the core policy settings are managed per-policy with a structured form view covering everything from password requirements and restrictions through to kiosk mode and compliance rules. A Monaco-powered JSON editor is there for when you need full control over the raw policy.

Application management integrates with managed Google Play for searching, deploying, and configuring applications across the estate. App feedback from devices surfaces directly in the console, and managed configurations let you push settings to supported applications.

Enrolment supports multiple provisioning methods: QR code, sign-in URL enrolment for BYOD scenarios with domain-restricted access, and zero-touch provisioning integration.. amongst others.

Groups provide hierarchical organisation with a closure table model, so you can nest groups as deep as you need and assign policies at any level.

Workflows provide event-driven automation. Define triggers based on device enrolment, state changes, compliance violations, app installations, geofence events, or time-based schedules, and the platform evaluates them asynchronously through a background job queue. Think of it as a lightweight IFTTT for your device fleet.

Reports and exports let you pull device inventories, policy configurations, audit logs, and application catalogues in CSV and JSON formats.

Licensing ties into Stripe for workspace-level billing, with plan management, device quotas, overage handling, and grace period enforcement.

The API is comprehensive - over 80 serverless functions spanning auth, workspaces, environments, groups, devices, policies, components, apps, enrolment, certificates, workflows, geofences, licensing, billing, dashboard aggregation, audit logging, and superadmin operations. It ships with an OpenAPI specification and supports both workspace-scoped and environment-scoped API keys. Every endpoint is a potential integration point, whether you're connecting a traditional automation pipeline or letting an autonomous agent manage your fleet.

You can see it live here: https://flash-mdm.netlify.app/api/docs/

An integrated AI assistant - Flashi - lets users query workspace data conversationally, using OpenAI's tool-calling with read-only AMAPI MCP tools alongside Flash's internal Postgres tools. This is the Commander concept, transplanted directly into the management platform. It worked in Commander, it works identically here, and it means every operator has a natural language interface to their entire estate without leaving the console.

Importantly, Flashi runs on Flash's own API - no direct database manipulation, no hard-wired access. It's subject to the same RBAC controls as any other user. Administrators can set Flashi's role per environment from the settings page: it defaults to viewer, leaning on the AMAPI MCP for read-only estate queries, but can be elevated up to admin-level to create policies, wipe devices, generate reports, and more. I've kept it safe by default, but flexible - use it as much as you trust it. It's gated behind a dual toggle - platform-level and per-environment - so administrators retain full control over whether it's active at all.

Multi-tenancy and RBAC are first-class. Four roles - owner, admin, member, viewer - enforced on every API call. Access can be workspace-wide or scoped to specific environments, so you can give a partner organisation visibility into their slice of the estate without exposing the rest. The superadmin panel provides platform-level oversight across all workspaces, environments, devices, and users.

Flash is a case study, not a product

Flash MDM exists primarily as proof that this shift is real and happening now. It's a working, deployable platform with a comprehensive feature set and an architecture designed for extensibility.

In fact, if you have a spare Android device, you can take the platform for a spin by signing up below, just be mindful if you use the assistant it will run out of OpenAI API credits at some point:

https://flash-mdm.netlify.app/join/w/customer

Is it going to replace your enterprise MDM tomorrow? Probably not. Not next month, either. But the fact that it exists at all should give folks in this space something to think about.

This is an observation and a demonstration on where the barrier for entry now sits. The same APIs that power commercial MDM solutions are available to anyone with a Google Cloud project. The same frameworks, the same infrastructure, the same deployment platforms. What's changed is the velocity at which a single person - armed with domain expertise, an agentic workflow, and a decent laptop - can turn all of that into a working product.

Traditional MDM development, as we've known it for the last two decades, is dead. What comes next is going to be far more interesting.

Introducing AMAPI Commander: converse with your Android estate

2026-02-19T00:00:00Z

If you manage or support an estate of Android devices, you already know the pain. Getting a straightforward answer about your estate typically means logging into a console, clicking through several screens, exporting a report, and wrangling it into something useful. Need to know how many devices are running an outdated security patch? That's a ticket to IT, a scheduled report, or half an afternoon with spreadsheets. The data is there, locked behind tools that only a handful of people know how to operate.

I've spent years building resources around Android Enterprise, from MANAGED INFO and MANAGED SETTINGS to the system app database, QR code generator, and my documentation - all have become popular utilities for the community. AMAPI Commander is the next step in that journey of learning more about the succulent underbelly of the Android world: a platform that lets you query your entire Android device estate by simply asking questions in plain English.

This isn't a tool for organisations

As a disclaimer, if you're an organisation managing Android devices with a commercial EMM vendor, this platform is not for you. EMM vendors own and control their Google Cloud Projects, and wouldn't grant the access needed for organisations to leverage AMAPI Commander.

Think of this more as a technical preview of what your EMM vendor could eventually integrate into their own stack.

A quick refresher on AMAPI

Google's Android Management API (AMAPI) is the cloud-based API that underpins modern Android Enterprise device management. It is the engine behind many EMM solutions today, handling everything from device enrolment and policy enforcement to application distribution and compliance reporting. If your organisation uses Workspace ONE, Intune, NinjaOne, Applivery, or any other AMAPI-enabled EMM, your device estate data may already flow through this platform.

AMAPI Commander doesn't replace your EMM. It doesn't even sit alongside it.. but where feasible, it can offer you a new way to access and query the data AMAPI already holds about your devices, policies, and enterprise configuration, when integrated into the appropriate Google Cloud Project.

The Model Context Protocol: why it matters

The bit that makes this technically interesting, and I'd argue forward-looking, is the Model Context Protocol (MCP).

MCP is an open standard, originally developed by Anthropic and now maintained under the Linux Foundation, that defines how AI models connect to external tools and data sources. Think of it as a universal plug: rather than building bespoke integrations for every AI assistant on the market, you expose your tools via MCP and any compatible model (ChatGPT, Claude, Gemini, or whatever comes next) can use them.

The obvious opportunity here is for EMM solutions. Under almost all circumstances, customers don't have direct access to the Google Cloud project that backs their device management; it's the EMM that owns and operates the AMAPI project on their behalf. That makes EMMs the natural home for an MCP integration: they could expose estate data from their own AMAPI projects through their platforms, letting customers query their device estate through any MCP-aware AI assistant without needing to know or care about the underlying API.

AMAPI Commander is something of an outlier in this regard. It implements an MCP server that bridges AI models directly to Google's Android Management API, and opens that up to anyone with an AMAPI Google Cloud project, whether that's an EMM vendor, a managed service provider, or an organisation that manages its own AMAPI project directly (being mindful of the permissible usage limitations).

For EMMs and platform vendors thinking about AI strategy, MCP offers a protocol-level integration point that avoids locking into a single vendor's AI ecosystem. Today in AMAPI Commander it powers the built-in assistant. But the same approach could power a custom GPT, a Claude agent, or an internal tool an engineering team builds, all against the same secure, rate-limited interface.

How AMAPI offers MCP

Google publishes an official MCP server for the Android Management API. Rather than requiring traditional server-to-server integration - where a developer writes code to authenticate, construct REST requests, parse JSON responses, and handle pagination - the AMAPI MCP server exposes the API as a set of discrete, self-describing tools that an AI model can call directly during a conversation.

This is a fundamentally different interaction model. With a conventional API integration, a developer builds a client that knows exactly which endpoints to call and how to interpret the responses. With MCP, the model reads tool definitions at runtime - names, descriptions, parameter schemas - and reasons about which tools to invoke based on a natural-language prompt. There's no pre-built client logic; the model decides the call sequence on the fly.

The AMAPI MCP server currently exposes nine read-only tools spanning the core AMAPI resources:

Enterprises - list_enterprises retrieves all enterprises accessible within a Google Cloud project, while get_enterprise returns the full configuration for a single enterprise including contact details, display name, and enabled features.

Devices - list_devices returns a paginated device inventory for an enterprise, covering hardware specs, OS version, compliance state, last sync time, applied policy, enrolment info, hardware identifiers, and security posture.. and more. get_device drills into a single device record with this information.

Policies - list_policies enumerates all policies defined within an enterprise. get_policy returns the complete single policy configuration: password requirements, app install rules, network settings, and compliance rules, and so on.

Applications - get_application pulls application metadata from managed Google Play, including title, permissions, available versions, and managed configurations. It supports a languageCode parameter for localised results.

Web apps - list_web_apps returns all web apps published to the managed Google Play iFrame, and get_web_app provides the configuration for a specific web app including display mode, URL, and icon.

Every tool is strictly read-only. There are no create, update, or delete operations. The model cannot modify policies, wipe devices, or push applications. The data returned is the same data you'd get from the equivalent AMAPI REST calls, but the path to it is entirely different: instead of a developer writing integration code, an LLM interprets a question, selects the relevant tools, constructs the parameters, and synthesises the results into a human-readable answer.

Where a traditional integration might require dozens of lines of code to list devices, filter by OS version, and format a report, an MCP-connected model handles that in a single conversational turn - chaining list_devices, inspecting the returned fields, and summarising the output without any bespoke client logic.

AMAPI Commander

AMAPI Commander is a multi-tenant web application that sits between the user and AMAPI. Rather than navigating dashboards or writing API calls, you ask the platform a question, and it returns an answer in seconds.

Behind the scenes, an AI assistant powered by OpenAI translates your query into structured API calls against your Google Cloud project, retrieves the relevant data, and presents the results in a format that makes sense. It supports both text and voice interaction, background processing for large estate queries, and intelligent caching so repeated questions don't burn through your Google API quota.

Why OpenAI? I'm most familiar with it, and as such was much easier to set the requirements, anticipate the behaviours, and mould it into what I wanted to achieve much faster.

What you can ask

The platform exposes the nine tools that map directly to AMAPI's core resources. Here are some practical examples of what that looks like in conversation:

Enterprises: "List all enterprises in my project" or "Show me the details for enterprise LC012345" - useful for managed service providers overseeing multiple customer estates.
Devices: "How many devices are enrolled?", "Show me all devices running Android 13 or older", or "What's the compliance status of device XYZ?" - the bread and butter for estate oversight.
Policies: "What policies are currently active?" or "Show me the configuration for the BYOD policy" - helpful when auditing what's actually applied versus what's documented.
Applications: "What version of Chrome is deployed across the estate?" or "Show me the details for com.google.android.apps.work.clouddpc" - quick lookups that would normally require a Play Store console detour.
Web apps: "List all web apps published to managed Google Play" or "Show me the configuration for our intranet web app" - niche, but genuinely useful when you need it.

These aren't canned queries. You phrase the question however you like, and the assistant works out which tools to call, in what order, and how to combine the results. Ask it to compare compliance across two policies, or to summarise which devices haven't synced in the last 30 days, and it will chain the relevant API calls together.

I will pause here to say it's not all out-of-the-box-LLM. Without gates and a bit of logic to help the LLM decide which MCP tool to use (and always use the MCP tool) the responses were originally far less succinct. There's definitely some orchestration, but I've tried to keep it light.

Built for multi-tenant from day one

Each workspace operates as an isolated tenant with its own Google Cloud project credentials, encrypted API keys, user memberships, and role-based access control. Workspace owners manage secrets, admins handle invitations and members, and members get read access to estate data. Data is isolated at every layer: storage keys, cache entries, and audit logs are all scoped either per workspace, or per user.

On the security side, credentials are encrypted at rest with AES-256-GCM (the same standard used across banking and government), and the platform never returns encrypted values to the client. Authentication supports both Google OAuth for authorising Google Cloud Project access, while passwordless magic links handle access to AMAPI Commander's UI. There's also a comprehensive audit trail for privileged operations. The architecture has been through multiple rounds of security auditing, and the full technical detail is documented in the Technical Whitepaper for those who want to kick the tyres.

Keeping your data yours

A platform that queries fleet data needs to take data ownership seriously. Here's how AMAPI Commander handles it:

Nothing persists unless you want it to. Estate data caching is off by default. Every query goes straight to AMAPI, gets the answer, and the response isn't stored. You can opt into caching per workspace, which dramatically improves performance for repeated queries and reduces your Google API quota usage, but it's a deliberate choice rather than a default.

Workspaces can be fully deleted. Workspace owners and platform admins can delete a workspace entirely, which purges all associated data: configuration, encrypted credentials, cached estate data, chat history, audit logs, and memberships. There's no soft-delete or retention period, it gets wiped out.

Chat history is scoped and ephemeral. Conversations are stored per user, per workspace, with a configurable retention period (30 days by default). Users can delete their own chat history at any time. Message content is capped and sanitised before storage.

Credentials never leave the server. Encrypted secrets (OAuth tokens, API keys) are stored server-side with AES-256-GCM and workspace-bound authenticated encryption. The client only ever sees whether a secret has been set - never the value itself, not even the ciphertext.

User identifiers are hashed. Email addresses used for storage keys are SHA-256 hashed, so even the underlying blob store doesn't contain plaintext email-to-data mappings.

Logs redact sensitive data. Any server-side logging automatically strips tokens, secrets, passwords, and authorisation headers before they reach stdout.

In short, active steps have been taken to minimise data collection, and encrypt the data that is temporarily (as long as needed) kept.

Who is this for?

AMAPI Commander is a reference implementation, not an end-customer product. It's built for anyone in the Android Enterprise ecosystem who has direct access to an AMAPI-enabled Google Cloud project:

EMM vendors exploring how conversational AI and MCP can surface estate data - a working example of the experience they could offer their own customers.
Managed service providers who operate their own AMAPI projects perhaps via on-prem solutions on behalf of an EMM, and want a more accessible way to query the data they already manage.
Technical partners and developers integrating with AMAPI who want to see how MCP tools map to the API in practice.

Organisations managing devices through a commercial EMM won't have access to the underlying Google Cloud project - their vendor owns that. AMAPI Commander is a glimpse of what's possible when that data is made conversational, and an invitation for vendors to bring something similar to their own platforms.

What AMAPI Commander isn't

To reiterate for absolute clarity: this is not an EMM solution. It doesn't push policies or provision devices. What it does is make the data your EMM already manages through AMAPI accessible, queryable, and useful, without requiring everyone on the team to understand API documentation or navigate a management console.

What's next

AMAPI Commander is in pre-production, and I'm actively working through a heap of hardening items, including RBAC against specific enterprises within a workspace to enable limited project access for members. All of this to come before a wider release, so the platform is presently invite-only. If you're interested in early access, want to see a demo, or simply want to chat about the approach, I'd love to hear from you!

In the meantime, have a look at the Getting Started guide, or dive into the Technical Whitepaper for the full architectural detail.

MANAGED INFO is going licence-free

2026-01-23T00:00:00Z

MANAGED INFO is moving to a predominantly licence-free model for almost all core capabilities.

Over the last 18 months the project has grown substantially in scope, from a simple information/support surface to a flexible and capable tool for building device experiences. On a deeper level, it has integrated new functionality that isn't even visible to end users, but the capabilities it provides now offers organisations an EMM-agnostic tool supporting a myriad of features not available elsewhere.

I'm proud of many of the capabilities that have been integrated to date, it's been a fantastic learning experience. Getting hands-on with the AMAPI SDK in particular has been extremely useful for my understanding of the inner-workings on the development side of AMAPI day-to-day, but being able to roll out functionality that makes a difference generally is awesome.

Accolades of note:

Did you know MANAGED INFO was the first independent tool to roll out APK deployment, for example? The research, implementation, and subsequent write-up has been used across the ecosystem to help vendors build their own solutions.
It was also one of the first solutions to get approval and support for Device Trust, which I wrote about here.

As the functionality has matured, licensing has been something of an afterthought. Now, I feel, the licensing model doesn't really make sense. I've even been making many of the newer features (wallpaper support, certificate deployment, APK deployment) licence-free already, and am now looking to take things further.

Going forward, I'm restructuring licensing around the following boundaries:

Presentation and experience features remain licence-free
Integration and data-leverage features become licensable

The practical effect is to make MANAGED INFO easier to adopt and experiment with, while still aligning licences to features that provide partners and organisations with data they can in-turn use for other commercial purposes.

What remains licence-free

The following experiences are now available without a licence:

Customisation and layout

Custom cards (text, video, app launchers, grids, stacks)
Theme control and visual layout options
Wallpapers and UI customisation

Device experience

Built-in contact and organisational messaging
APK deployment in companion mode
Certificate deployment
Launcher and kiosk workflows
Optional app drawer and admin escape panels
Managed Settings integration

These are the capabilities that support displaying information and building bespoke device experiences, without extracting or exporting data externally. This aligns with how organisations commonly use MANAGED INFO to present help, support content, or tailored launcher surfaces.

Which capabilities are now licenced

A licence is required when MANAGED INFO is used in ways that materialise external value outside of presentation:

Device data integration (trust signals, network state, hardware metadata)
Export of device signals into external systems or dashboards
Companion usage in EMM workflows
Operational data sync to external endpoints

These features go beyond presenting information on device and into data leverage territory, where organisations can benefit operationally or commercially from the signals MANAGED INFO exposes, and going forward will be both licensed & allowlisted by external domain.

Impact on existing deployments

This change will roll out with 1.1.8.0 over the coming days.

Please check your managed configurations.

Organisations that have changed any previously-licensed configurations without a licence will find they're applied automatically with the update to 1.1.8.0.
Organisations with a licence will see no impact.
Organisations that may have already integrated with their EMM through the SetupActions or companion capabilities, please reach out.

Additionally:

For organisations with a licence, the device limits will no longer be enforced for use cases that don't require it. If the use case no longer falls under the licensed requirement, reach out to me to discuss options.
Where the licence fee has been removed, anything more than light support (bug fixes, implementation advice) will become a chargeable service (see support). Those organisations with licences are not affected by this.

A new name & what's coming

You may notice further references to MANAGED INFO HUB or MANAGED HUB across the site and documentation.

That name better reflects the current shape of the project with the aim that it reflects more than just the fixed info/support panel the project started with; it’s becoming something of a handy EMM companion app (not just for APKs, but Location tracking, Device Trust data, and metadata sync are all available to interested partners. Reach out for details!)

In terms of other changes in 1.1.8.0, this was predominantly about stability and performance, however the main new user-facing feature is an app drawer when MANAGED INFO is in launcher mode. The app drawer can be fully open, or limited only to the defined packages listed in managed config. It's pretty neat.

Wrapping up

Thanks to everyone to date who has used, supported, suggested improvements, or purchased licences for MANAGED INFO. For those who haven't, I hope you now take the opportunity to kick the tyres and see what MANAGED INFO can do for you!

Google Play Protect is now the custom DPC gatekeeper, and everyone is a threat by default

2025-12-24T00:00:00Z

My DPC has been blocked by Google Play Protect

For anyone landing here after searching for answers as to why you're seeing unsettling Play Protect warnings for safe, compliant apps, read this help article and submit an appeal.

What's the context here?

To understand the gravity of this, we first have to look at what a DPC actually is.

In the Android management world, the DPC is the "agent" application, the Device Owner that holds the keys to the kingdom. It can communicate with a backend - typically but not always an EMM server - and may enforce policies like Wi-Fi settings, app restrictions, and password requirements directly on the OS.

At least, in the enterprise ecosystem. More broadly the community has leveraged custom DPCs for turning their applications into native Android kiosks, building community/open source management platforms, expanding solutions out to use cases like parental control, device leasing, and more. Consider Acurast, which uses Device Owner (DO) to put a device into a pool of worldwide resources developers can use for their decentralised computing needs, Xibo which is a DO-supported media client, or FreeKiosk which does what it says on the tin.. amongst many others.

DPCs are used for all sorts of functionality for all sorts of use cases. They can also run entirely locally through hard-coded restrictions/functionality in cases where the whole use case is to showcase the app utilising DPC functionality itself. Historically, Google didn't care whose DPC you used, nor what it did, provided it called the right APIs and didn't outright abuse either the user or the OS. This allowed for a flourishing ecosystem of solutions built upon custom DPCs.

In parallel to this more recently (well, 2019), Google introduced the Android Management API. This native-feel implementation of a consistent and centralised management platform has been the default and only option for enterprise vendors to build their enterprise management solutions for the last few years, following the deprecation of the Play EMM API. Custom DPCs haven't gone away, though without the Play EMM API there's no app or account management available. This has to go through AMAPI. If you're an enterprise EMM vendor, Play access is a cornerstone of your solution.

AMAPI in turn has become more and more restrictive on who uses it and how; their permissible usage page has grown more complex and limited as time has progressed, most recently completely blocking new vendors from even touching the API without Google's approval of a vendor's business case, and then limiting the number of devices permitted to enrol without continued and repetitive applications for increased quotas. It's becoming quite a restrictive, overly-moderated experience.

As Google tightens the screws on AMAPI access, the custom DPC route has become a more appealing option. I can speak to several vendors I've worked with previously denied access to AMAPI who have turned to custom DPC, for example. For many use cases access to Google Play for app/account management isn't all that critical and achieves the goals in mind. Google's approval framework might suggest if a vendor can't get approval for AMAPI, they must automatically be doing something untoward, but given the permissible uses are limited and target some of the most popular use cases for restricted access - financing, device as a service (DaaS), and in-house solutions - that suggestion would be plainly wrong.

In any case, the move to start restricting custom DPCs could have been anticipated, though I'm not sure many (including me) did so. While I agree policing of the custom DPC market is beneficial (I'm sure some fall for the mandate to wipe and enrol their devices into a malicious solution, I've seen worse), the way Google has gone about it leaves a terrible taste in my mouth.

The problem with this

I want to be clear I am in favour of keeping the ecosystem safe. It's what I spend most of my days doing through the very DPCs in question (amongst other things). I'm also not just grumpy about this because it's change; I wrote of my support for developer verification just a few months ago.

On the face of it, the restrictions aren't unreasonable. Frustrating though they may be in limiting choice and freedom for projects and organisations taking advantage of the Android Enterprise framework, what Google has put in place is fine - it's even slightly less restrictive than the requirements for AMAPI as there's no explicit restriction on in-house solutions. I also can't argue the dev guidance and mobile unwanted software policies for some of the causes of being flagged outside of the allowlist, as it makes perfect sense - SMS, notifications, and accessibility permissions should absolutely be challenged given their sensitive nature, and a DPC should never be anything other than fully transparent with its capabilities and behaviours.

There are two very distinct issues I take with how this allowlist has come about, however.

The first is the lack of communication, and the lack of time to prepare.

In the aforementioned developer verification announcements, Google provides a year for developers to get on board. There are multiple approaches to verification offered, and generally speaking even those slowest to adapt to change have a justifiable amount of time to figure things out. It's not dissimilar to Play EMM API being deprecated, that's been going on for a few years now with vendors still tip-toeing over to AMAPI. There was an iFrame approval change that was deprecated in 2021, and in 2023 I was still writing about it. Let's not even touch on Device Administrator deprecation..

Custom DPC changes?

No public announcement via the Android Enterprise blog.
No customer community announcement, despite the Android Enterprise Customer Community being the primary hub for these sorts of discussions more recently.
No advanced warning, and no time to prepare. One day it worked; the next, end users are seeing a message what they're doing was "Harmful".
One helpdesk article appeared out of thin air at some point (and a couple of references in other docs).

Google made the change earlier this year and no one outside of existing partners would have known until their DPCs were being actively blocked, something demonstrated in the customer community multiple times:

This lack of communication feels tone-deaf. It ignores the reality of countless developers who have built livelihoods on the open nature of Android, only to be thrown face-first into an arbitrary wall.

The second is how it's being enforced.

Google Play Protect was introduced as the world’s most widely deployed mobile threat protection service. Its job is to find malware, identify potentially harmful applications (PHAs), and keep users safe from real threats, but here Google is using Play Protect as the gatekeeper, and by folding the "Approved DPC" list into Play Protect’s enforcement engine, Google has turned a tool designed for protection into a weapon of enforcement of Google's will.

There's obviously a distinction between GPP flagging on sensitive permissions, which is valid and I take no issue with, versus GPP running off an arbitrary list of package names a team within Google has to maintain. The latter is mind-boggling to me.

The weaponisation of a tool many in the ecosystem have applauded as a beacon of Android security means when a user or an IT admin attempts to enrol a device using a DPC that isn't on Google's allowlist, Play Protect intervenes.

It doesn't say, "This vendor hasn't completed their paperwork.", it displays some of the scariest warnings in the Android lexicon.

By using the same type of warning for a legitimate DPC as they do for an app trying to steal your banking information - because the developer hasn't asked for permission from Google to use standardised, open APIs - Google is intentionally blurring the line between unauthorised and unsafe. It isn't about code quality or actual PHA behaviour; it's about control. A perfectly safe, well-written DPC can be "blocked to protect the device" simply because the developer hasn't filed their paperwork (that they may have known nothing about, per above) or doesn't fit Google’s current vision of what a DPC should be.

This is a massive erosion of trust. If "unsafe" just means "not a Google approved application," my prediction is we will eventually see the messaging for Play Protect soften, lowering the likelihood of taking actual malware warnings seriously. It all starts with an "oh ignore the warning, just continue", and authority is lost. Google is crying wolf to protect its ecosystem boundaries, and in doing so, they are devaluing the very security tool they claim is vital for the platform's health.

With this allowlist, the days of building a custom DPC for anything but what Google considers a justifiable use case are heading towards a reality where this may not be possible. Whether you’re a developer building an open-source management tool, or a company with a bespoke internal DPC for a fleet of industrial devices, you now have to go through an opaque verification process that is down to the interpretation of the human undertaking the approval at the time. If you're building anything else, that human may just not put the package name on the list.

By introducing this barrier, Google is having a very real impact on innovation and accessibility; the "guilty until proven innocent" approach blocking unverified DPCs by default during provisioning shows Google is treating any independent developer as a potential threat. This doesn't just stop "rogue" apps; it stops legitimate, innovative solutions that haven't been given Google's approval.

Again, I'm not against protection for users in the ecosystem. I find it, however, baffling with all the signals Play Protect gets from a device, with all of the ecosystem data Google consumes across billions of Android devices, all of the pattern recognition, user feedback, all of this noise Google has chosen to forego every ounce of technology they use powering Android's industry-leading security.. for a list. Implemented with little to no consideration for the ramifications to businesses and communities.

What you can do if you're affected

The answer is to get verified, because this new reality treats every custom DPC as hostile until you prove otherwise.

If you're going to navigate it, here are the hoops; steps that shouldn't be unnecessary if Play Protect judged behaviour instead of defaulting to the ban-hammer:

Align to Google’s permissible usage list: no device financing schemes; no surveillance-first builds; no silent push/preload/auto-install without explicit customer and end-user consent.
Strip sensitive permissions to the minimum required to function so Play Protect has less to flag while you apply.
Cross-check against the Mobile Unwanted Software (MUwS) and Potentially Harmful Applications (PHA) guidance so nothing in your application is misread as malicious.
File the appeal once you’ve done the above.

If you’re blocked mid-provisioning, tell admins and users plainly that the warning is about allowlisting, not malware, and point out the option for them to continue the install if present in the Play Protect warning.

To close this out

Standardisation is a good thing. I’ve spent years advocating for the Android Management API (AMAPI) and a more consistent experience across OEMs. But standardisation should not be achieved like this.

Google needs to decouple technical safety from verification. If an app isn't verified, the OS should tell the user that. It should say: "This management tool is from an unverified/unknown/unapproved developer. Proceed with caution." It should not say: "This app is trying to bypass security." By using the PHA stick to enforce partner rules, Google is signalling that the wider community - the tinkerers, the niche hardware vendors, and the independent developers - are no longer a priority. It’s a move that lacks empathy for the diverse ways Android is used across the world.

The ship has sailed to put a pause on this now, but it's not too late to put out visible announcements, talk about the security, justify the change, adjust the messaging - everything that was done with developer verification should be done here, too.

To the developers and vendors struggling with this: My advice is to document everything: Any failed appeal, any poor user experience, and any customer you lose because of a misleading warning. Submit it to the customer community and make sure you're seen and heard. We've made incredible changes through the community over the last few years. Feedback matters.

12 deliveries of AE-mas (What shipped in Android Enterprise in 2025)

2025-12-22T00:00:00Z

Note: This is cross-posted from the Android Enterprise Customer Community

2025 was a big year for Android Enterprise.

This was the year several long-missed features finally landed, Device Trust became a thing, zero-touch got a compliance and audit boost, provisioning saw a revamp, and the Android Management API quietly kept adding the sort of controls that make admins' lives easier.

So, in the spirit of celebrating a strong year for the platform, here are 12 Features of AE-mas, in no particular order, chosen somewhat at random as - would you believe - the list could have been longer should I have chosen not to follow the 12 days of Christmas as the theme..

12. APN overrides via AMAPI

APN management finally arrived.

In May 2025, AMAPI gained apnPolicy, allowing admins to define and enforce APNs directly through policy. This closes a long-standing gap for cellular deployments where “just set the APN” has historically been anything but. It's great to see this functionality pulled out of OEM config and into the AMAPI layer, giving admins access to on-device APIs that have been effectively off-limits for years.

Read about APN here.

11. Developer verification for Android

Developer verification isn't coming until next year, but we're talking about it already, and work is in progress to bring it to fruition now.

Developer verification raises the bar for Play publishers by requiring stronger identity verification. For enterprise, it’s a supply-chain win: fewer convincing lookalikes, higher friction for malicious publishers, and a clearer answer when security teams ask “who made this app, exactly?”. There’s pushback in the community, there's a lot of misunderstandings about the requirements and ramifications, but hopefully as time goes on this will settle on both sides through further transparency and discussion.

Organisations deploying private apps to their own tenants are currently exempt, but it remains a big change nonetheless, and organisations benefit from the wider boost in authenticity of apps and developers.

I covered off more about developer approval here.

10. Device Trust from Android Enterprise

This was the year Device Trust arrived.

Device Trust enables real-time posture and integrity signals (Play Integrity verdicts, boot state, security patch recency, lock-screen presence, strong auth age, OS tamper signals) that can be evaluated continuously rather than only at enrolment, and on both managed and unmanaged devices. It's a huge boost for MAM-type deployments, security solutions, and allows traditionally EMM-dependent vendors the freedom to operate independently.

This isn’t a small feature. It fundamentally changes how Android Enterprise fits into modern security architectures.

I wrote more about Device Trust here.

9. Custom app management via AMAPI (`CUSTOM` install type)

One of the most consequential releases of the year, perhaps even since AMAPI began half a decade ago.

AMAPI introduced first-class support for installing and managing custom applications using installType: CUSTOM, backed by signing certificate validation (appSigningKeyFingerprints) and explicit install and uninstall commands. It allows organisations reliant on line-of-business (LOB) internal applications to ditch any and all wild-west sideloading for a policy-driven, verifiable deployment, which is exactly what enterprise actually needs. All without the need for uploading apps to Google Play.

I wrote more about custom apps here.

8. Zero-touch portal audit logs and admin roles

The zero-touch portal became auditable and permission-scoped in 2025.

Google rolled out audit logs to the zero-touch customer portal, capturing all admin actions needed to ensure the platform is no longer a black hole of who did what. Alongside this came clearer admin role separation, reducing the blast radius of operational mistakes.

For regulated environments, this turned zero-touch from a black box into something governance teams could actually trust.

7. Android 16 provisioning improvements

One of the greatest improvements to the enrolment flow happened in 2025, and it was so long overdue!

Android 16 brought a clear push toward more reliable setup flows, fewer steps, and the ability to update it on the fly, as opposed to being stuck adjusting it only on major version releases.

I put out a video nearer the start of the year, while 16 was still in beta, which you can see on LinkedIn here.

With this newer approach, Google is beginning to leave behind the old managed provisioning flows baked into AOSP, though they're still there as a fallback today. It'll be interesting to see how this evolves.

6. Application roles in Android Management API

This was unexpected.

Application Roles formalised entire classes of enterprise apps, including:

COMPANION_APP
KIOSK
MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE
SYSTEM_HEALTH_MONITORING

Apps assigned these roles can be exempt from background execution limits, power management, suspension, and hibernation on modern Android versions, with user control restricted by default.

This isn’t just about companion apps - it’s about enterprise software finally being treated as first-class by the OS, and adds much-needed flexibility with far less configuration and overhead.

5. Default application management policy

Admins finally gained control over default apps.

AMAPI added a policy allowing admins to define a prioritised list of default applications per app type (browser, dialler, etc), setting the first qualifying app as default and preventing user changes.

For compliance-sensitive fleets - browsers, diallers, PDF viewers - this is the sort of boring control that saves hours.

It's predominantly Android 16+, but there's a few that go back a few versions of Android.

Read more about default applications here.

4. RCS archival

RCS has long been the compliance blind spot for Android Enterprise fleets, with SMS/MMS archiving handled by legacy tools while RCS was left out in the cold. In December, Google release a supported way to archive RCS/SMS/MMS on fully managed devices, with Google Messages as the mandated client. Once those prerequisites are met, admins can configure Messages to forward message bodies, metadata, and attachments to a SIEM/service/archival tool on a schedule or trigger with no needed workarounds or limitations of legacy solutions. It’s - to reiterate - Google Messages only for now (OEM messaging apps remain out of scope unless they add their own support), but it gives regulated orgs a sanctioned retention path for rich messaging at last.

It has been met with quite a bit of mixed feelings, and even more FUD. I go into more detail about RCS archiving here.

3. App functions and cross-profile controls

Android 16 brought app-to-app interaction under policy control.

New settings allow admins to govern whether apps can expose app functions, and whether personal-profile apps can invoke functions exposed by work-profile apps, bringing finer control to cross-profile linking scenarios.

Niche, but powerful for when this functionality takes off in enterprise workflows.

2. Android App Bundle (AAB) support in the Managed Play iframe

This finally removed a long-standing enterprise limitation.

In March 2025, Android App Bundle uploads became supported in the Managed Google Play iframe. Private apps finally gained parity with public Play distribution, including split APK delivery and more efficient installations.

I wrote more about AAB here.

1. Android’s accelerated platform release cadence

The change that underpins everything above.

Android is shifting toward more frequent platform releases, with Android 16 landing far earlier than usual and signalling a broader move away from a single annual cadence.

Harder to track? Maybe. I'm having a lot more fun poking around the Android Canary builds looking for unreleased functionality than I do sleuthing around AOSP code, though!

Better for shipping enterprise capability without waiting a full year? Also yes.

Signing off

Android Enterprise levelled up across the board in 2025.

From trust and supply-chain integrity to app management and provisioning improvements, the team set the bar really high this year. Let's hope the momentum continues in 2026!

Which of these made the biggest difference for you this year, and what are you hoping lands in 2026?

Happy holidays and here’s to a wonderful New Year!

The 12 AE requests of Christmas (2025 Edition)

2025-12-22T00:00:00Z

Christmas is upon us! Deck the halls with JSON schemas and so forth.

As we wrap up 2025, we’ve seen some massive wins for the Android Enterprise and the Android Management API (AMAPI) this year; APN overrides, custom apps, and Device Trust to name a few which I've covered off over on the Android Enterprise Customer Community. But let’s be honest: while Google has been busy with tightening permissible use policies, building out RCS archiving support, and creating a massive spread of Device Trust signals to consume, the community’s wishlist is still longer than the queue for a mulled wine at a Christmas market.

If Santa (or the Android Enterprise product team) is listening, here is what's on my list while we wait for the chestnuts to cool.

12. Self-service zero-touch uploads

On the twelfth day of Christmas, Google could have given to me: the ability to actually add my own devices to zero-touch.

Currently - and as with every feature request article I've written since ZT's inception - we’re still tethered to authorised resellers for zero-touch. If a regional ops team buys 30 handsets locally to replace water-damaged devices on a construction site, that means 30 devices isolated from an existing ZT environment with no immediate (if ever) capability to get them added in. We need an admin upload process, perhaps tied into already-enrolled devices for a level of proof of ownership, an opt-out grace period similar to Apple Business Manager, or another means to prove ownership and claim our hardware without the reseller middleman.

Practically every other OOBE solution on the market across most OSes covers this and has done for years. This is crippling a fantastic tool.

11. Frictionless DPC migration

DPC migration has been supported since Android 9.0, and yet in 2025, migrating between EMMs still feels like performing open-heart surgery with a butter knife.. except that's probably actually doable without killing the subject, unlike the mandatory wipe needed for Android devices today.

A customer splitting business units across two EMMs, or just migrating from a crappy vendor to something better, should be able to move a device from location A to location B with an admin click, not a wipe-and-reissue. We need Google to stop being afraid of vendor pushback and give us a native, reliable way to move management between EMMs without a factory reset. Apple’s already got "seamless migration" down in iOS 26, there's no justification for keeping it from the ecosystem any longer.

I despise having to write any sentence containing "Apple already.." - don't do this to me, Google.

10. Silent special permission grants

We own the devices. We are big boys and girls. So why am I still asking an end-user to manually navigate to Settings > Special App Access to toggle Display over other apps or enable Accessibility? For dedicated/COSU devices, the EMM should be able to allowlist these permissions silently - think a warehouse picker app that needs overlay and accessibility for heads-up instructions without breaking kiosk mode, or granting the companion app data usage to get more usage details about the device.

By all means protect users generally, but if a company owned device, especially one flagged as dedicated, occasionally it would be nice if we could protect an admin's peace rather than the prospect of a potential end-user touching a kiosk unit.

9. Native VPN config

This is a nicety more than anything I'll be knocking doors down for, but another feature I'd like to see pulled out of OEM config and into AMAPI is the ability to create and initiate a native VPN config.

I know apps handle this fine today, but why should I have to use an app? At best it's administrative overhead, at worst it's another subscription.

In 2026, we shouldn't need a third-party app's managed configuration support just to set up a basic VPN. We need native JSON schemas within the AMAPI policy for IKEv2, L2TP, and IPsec. One policy to rule them all, without the extra APK bloat.

8. Provisioning-time logs

Admins live in fear of enrolment failure screens. When it happens, the device often resets, and the logs vanish into the digital ether. A batch of devices in an RF-dense factory failing QR enrolment at 80% can’t cough up adb logcat; a “send provisioning logs” button (Quick Share or pre-configured email) would let support correlate network issues or policy errors without a trip on-site.

7. Remote bug report fetching

DPM has requestBugreport(). AMAPI has... a lot of customer back-and-forth. Field scanners rebooting intermittently when the camera opens shouldn’t require a remote support session, email chains galore, or to send the device in for a service (because walking users through fetching their own bug report to send - if that's even possible while replicating the scenario - isn't normally going to happen). Bug report fetching needs a direct ISSUE_COMMAND, and perhaps a flag or two for where and how to send it.

It's one of those things that puts AMAPI vendors at a competitive disadvantage for support compared to their custom DPC counterparts. This basic functionality should have been prioritised from the outset.

6. Private DNS via policy

Private DNS capabilities are only gaining in popularity as more of the world cotton-on to the benefits of secure DNS. It's becoming a staple of modern network security. In 2026, being able to force a specific secure DNS provider via a policy simply has to happen.

I put this on the list literally because I'm struggling with this with a customer who has moved over from a custom DPC solution. Another competitive disadvantage to navigate.

5. Public beta track support

Managed Play tracks are great. I use them to death and back, but public (open) beta apps aren't an option. If a developer has an open beta on the Play Store, we should be able to opt-in via track ID just like we do for private internal tracks, rather than begging for a duplicate internal track just to participate in open testing.

The whole tracks management in Play puts a lot of pressure on devs who may have just barely figured out the open testing options, and in a lot of cases pushing a bugfix into beta before the production version gets a bump is as good as it's going to get.

Granted we have custom app support in AMAPI now to work around this, but how about we just make this work, too?

4. Managed config for app tracks

Currently, managed configurations have a terribly naughty habit of only respecting the Production version of an app.

If I’m testing a new build on the "Alpha" track, I need my test configs to apply to that specific version; QA flagging a breaking change in “Alpha” is meaningless if the flag only hits Production.

Today I get around this mostly by writing JSON directly up to AMAPI with the managed properties that aren't exposed. It can be so much better than this.

3. Native ephemeral & multi-user

The Shared Device problem has been solved by third parties for years, but we’re still waiting for native AMAPI parity with the UserManager APIs. We want to create and manage ephemeral users (shift workers) directly through policy without relying on heavy-handed wrappers: cached apps, login/logout flows, and a data purge at logout - all driven by policy, not a custom shell app. Even better if it could hook into modern identity platforms within the Android accounts manager.

2. Offline system updates

The ability to push system updates from a local/offline location has been one of my most favourite custom DPC features. I don't use it so much today as I no longer build Android devices (for now), but it remains the case that not every device has a suitable path to Google’s OTA servers.

For air-gapped warehouses or secure labs, we need to point the device to a local file server and say update from here. A logistics hub with no internet should be able to stage an OEM-provided OTA on an SMB share and push it overnight via policy, not incite disruption with temporarily moving devices to a different network just to patch.

Likewise in environments that can't justify 1,000 devices all consuming internet bandwidth from an OTA, throwing it up internally is the obvious answer to this as the second-best would be touching devices with an update file on an SD card (where the OEM supports it).

1. Companion extensibility

This is the big one. Google has been promising deeper extensibility for years. We need the AMAPI SDK to unlock the entire DPM/UM API surface for companion apps. If we could run any DPM call through a local extension, most of the items on this list would be solved overnight. Let the companion app be the bridge to the local OS power that the AMAPI can't (or won't) reach - whether that’s VPN policy control or feature toggling on rugged gear.

Bonus: Policy-defined system update engine management for 3rd party clients

A bit of a long-shot, but I've been thinking about building a FOTA service for years. The huge barrier for entry is the need for the OEM to provide the necessary elevated permissions to make it possible to run correctly on-device. With a bit of policy magic for managed devices it would be wonderful to be able to offload OTA management to a particular package. This could also solve for the offline system update issue above, as well.

What’s on your wishlist? Did I miss a gap that's been haunting your 2025 deployments? Let me know, and maybe - just maybe - we’ll see a few of these in the new year.

Happy holidays!

RCS Archival and you: clearing up the misconceptions

2025-12-05T00:00:00Z

Recent headlines have sparked concern and confusion about a new Android feature that supposedly "lets your boss read all your text messages". Sensational claims like “Google starts sharing all your text messages with your employer” have understandably raised privacy concerns. In reality, Android RCS Archival is a tightly scoped enterprise feature designed for regulatory compliance - not a free-for-all licence for employers to snoop on any phone. This post will clarify what RCS Archival actually is, how it works, and debunk the common misconceptions.

What Android RCS Archival actually is

RCS Archival is a feature introduced by Google to help organisations meet regulatory requirements (for example: financial, legal, and government sectors).

Modern messaging creates a compliance challenge. SMS could historically be archived via carriers, but RCS (the upgraded texting standard used by Google Messages amongst others) is end-to-end encrypted, which means organisations cannot simply rely on carrier logs or network-level capture.

From Google’s official announcement:

“This new capability, available on Google Pixel and other compatible Android Enterprise devices gives your employees all the benefits of RCS — like typing indicators, read receipts, and end-to-end encryption between Android devices — while ensuring your organization meets its regulatory requirements”
— Google Android Enterprise Blog

How it works:

A partner archiving app (Smarsh, CellTrust, BAYTON) integrates with Google Messages.
When enabled, messages sent, received, edited, or deleted are captured on the device itself, not intercepted in transit.
Encryption remains intact; the capture happens after decryption on the device, similar to how work email archiving has always functioned.

This is not a backdoor. It is an endpoint-level compliance mechanism, and it only works under tightly controlled enterprise management environments.

Fully managed, company-owned devices only

This cannot be stressed enough:

RCS Archival does not work on personal devices.
It does not work on BYOD devices.
It does not work on Work Profile setups (both BYOD and work profiles on company-owned devices (COPE)).

It only applies to devices that are:

Company-owned
Provisioned as fully-managed
Under complete MDM/EMM control

Google’s documentation makes this explicit:

“This feature works for Google Messages on fully-managed Android devices.”
— Google Support

Even if an organisation wants to archive messages, they cannot do it on your personal device. It is simply not possible for this feature to function anywhere except on fully managed devices.

Not enabled by default

Android's RCS Archival is opt-in for an organisation, not automatic.

To activate it, an IT administrator must:

Deploy a supported archiving application.
Configure messages_archival via managed configuration in their EMM.
Explicitly assign the policy to targeted devices.

If they do not do all three, archival does not occur.

From Google:

“IT administrators can enable RCS Archival through a simple configuration. You have full control to decide which devices have the feature turned on and which archival application you deploy for your organization.”
— Google Android Enterprise Blog

There is no “silent switch” Google can flip globally. There is no mass rollout to all users. There is no automatic activation for all Pixels (or other Android Enterprise devices as support rolls out).

Transparent to employees

A crucial part of this design is user visibility.

“Employees will see a clear notification on their device whenever the archival feature is active.” — Google Android Enterprise Blog

Meaning:

You cannot be silently monitored.
If the feature is active, you will see a prompt in Google Messages.
Once you see that warning, you know every message in Google Messages is being archived.

This ensures the feature cannot be used clandestinely. It's intentionally transparent.

Encryption remains intact

One of the more misleading claims circulating is that RCS Archival “breaks” end-to-end encryption.

It doesn’t.

RCS encryption protects messages in transit. Archiving happens on the device after the message is decrypted for display.

This is exactly the same model used by:

Email archiving on corporate laptops
Instant message archiving in regulated industries
Call recording on corporate phone systems

Encryption remains intact. The device itself is configured to retain business communications.

Only Google Messages is affected

RCS Archival applies exclusively to Google Messages.

It does not affect:

WhatsApp
Telegram
Signal
Slack
Teams
Facebook Messenger
Any other third-party messaging app

Those apps retain their own security models, separate from Android’s enterprise capabilities. Will similar archival solutions become possible with these applications (or any others) in future? Possibly.. but today's RCS Archival offered by Google is app-level and limited only to Google Messages.

Myths vs facts

Myth	Fact
“Google lets employers read messages on your personal phone.”	False. Only company-owned fully-managed devices can be archived.
“It’s enabled on all Android phones by default.”	False. IT admins must explicitly enable it via EMM configuration.
“Your boss can secretly monitor your RCS chats.”	False. A clear notification appears on the device when archival is active.
“This breaks end-to-end encryption.”	False. Encryption in transit remains. Archiving happens only on the managed device, after decryption.
“Employers can now read your WhatsApp messages.”	Completely false. Only Google Messages (SMS/RCS) is supported.

What this means for employees

If you’re using a company-issued phone:

Treat it as a work device.
Expect work communications to be recorded.
Watch for the archival notification in Google Messages.

If you’re using your personal phone:

Nothing changes.
Your employer cannot access your messages.
The feature doesn’t function on personal devices.

This entire capability is irrelevant to personal Android users.

What this means for IT leaders & CIOs

For regulated industries:

This finally closes the compliance gap around RCS.
It restores parity with SMS and email archiving.
It maintains security and device-side encryption.

You choose:

Whether to enable it
When to deploy it
Which archival solution to use

And your users are transparently informed when it’s active.

Conclusion

Despite dramatic headlines, Android’s RCS Archival feature is not a privacy invasion, not automatically enabled, and not applicable to personal phones. It aligns with what should be typically expected of a company device - actions may be monitored, data may be recorded.

If your organisation issues fully managed Android devices, you can now archive RCS/SMS securely and compliantly. If you’re an employee using your own phone, relax. This does not affect you, and your boss cannot read your messages.

Google summarises its purpose best:

“[RCS Archival] helps your organization meet strict compliance needs while using the advanced security of Google Messages.”
— Google Android Enterprise Blog

Still unconvinced?

Get in touch, and I'll provide a demo with my own archival app, MANAGED ARCHIVER. You'll be able to see not only what happens on-device, but on the server-side, also.

Device Trust from Android Enterprise: What it is and how it works (hands-on)

2025-10-15T00:00:00Z

Hybrid and remote work has become increasingly more prevalent over the last several years, with bring-your-own (BYOD) providing a driving force in enabling a work-from-anywhere-on-anything approach to the modern enterprise.

While you'll find no end of articles for and against flexible work practices, the reality is they're here, and they're challenging IT departments the world over on how to ensure any device is safe, stable, and secure when interacting with corporate resources. Traditionally this would be through the enforcement of an MDM, or vendor lock-in through particular MAM vendors to allow for access to corporate resources, but what if there was another way?

With the launch of Device Trust, Google is providing a new avenue for tapping into the vast device data repository previously mostly reserved for MDM providers of the Android Management API (AMAPI), allowing many more vendors across many more use cases to understand device posture - and how identity, threat, security, and management systems can interoperate - in a way that is far lower effort, far higher reward, and reduces local device overhead with multiple different solutions all attempting to poll for basically-equivalent data.

Far from being just another management API, Device Trust is positioned as a core component in Android's Zero Trust architecture. Enabling continuous device verification across all modern Android devices, it offers a practical way to understand device security and posture in real time, irrespective of management.

To reiterate - because this can't be understated - with Device Trust, it's no longer about managing the device, instead choosing to make use of the device signals offered to ensure even without heavy, restrictive, or invasive device management policies, access can be granted to corporate resources.

Google frequently, and rightly, points out that many data breaches in organisations stem from inappropriate access on mobile devices; reasons can include weak device posture, outdated software/security patching, or unsecure networks (amongst others). Device Trust aims to surface signals that highlight these risks for vendors, providing the ability to make in-the-moment decisions based on real signals, not assumptions.

What Device Trust is - and isn’t

Although Device Trust requires the Android Device Policy application to fetch and return a snapshot, there's no management required. Android Device Policy sits in a privileged position on-device, granted the appropriate roles to always be able to fetch a mix of public and restricted (typically to DPC) signals immediately on request.

Of course if the device is managed, be that on the Android Management API or another platform, it makes no meaningful difference. If anything it takes some of the permission management out of the setup process when pre-granted by policy.

Whatever the environment, Device Trust surfaces a verified snapshot of the specific device it's running on: who manages it, how it’s configured, what security controls are present, and whether anything looks risky, so downstream services can base decisions on current telemetry.

It stops short of enforcing policy, remediating issues, or replacing Android attestation; it’s simply the context layer that turns raw device signals into something IdPs, EMMs, and other vendor types can act upon, and that's the whole point.

You can find the official overview here. The developer docs explain how to register and pull these snapshots.

So.. how does it work?

First and foremost, as above this platform is for approved partners only, and gated by an application process. It doesn't mean anyone with any app will suddenly be pulling signals of devices for their own uses.

Additionally, support is provided for Android 10 and above. Even on Android 10 the likelihood is strong devices would fall foul of any desired posture states in use across most organisations (in other words, if you're running < Android 10, you don't need Device Trust to tell you you're running an outdated and likely unsecured estate).

In a nutshell, there are two approaches I see that would look to lean on Device Trust:

You're a vendor wishing to integrate trust-based policies/data points for Android devices into your solution
You're an organisation looking to adopt access/monitoring without full device management

Why would an organisation opt out of full management? There may be several reasons, including:

Pressure or pushback from employees
No existing management platform
No desire for full device management, but a requirement to ensure devices are secure
Roaming or temporary access requirements for contractors, seasonal workers, etc.

Are the more reasons? Absolutely. Could you challenge the reasons above with counterarguments and education to the benefits of full management? Also yes. Ultimately however this is about flexibility; if I'm engaging with a customer whose employee base echoes a persistent (incorrect) perception that an MDM can watch what you're doing, track your app usage, view your files, so on.. and no justification is working, I'd sooner see them implement a middle-ground like Device Trust over nothing at all.

Device Trust currently provides over 20 device signals, closely tied alongside the Play Integrity API (integrated separately), covering things like:

Device attestation and integrity
Management state and ownership
Patch levels and OS version
Encryption and screen lock complexity
Play Protect status and network security

These are provided as a snapshot to the calling application on-device, and can be called as often as required in order to ensure access is granted/denied based on a current, in-the-moment state. It makes for an extremely dynamic solution, with ongoing verification helping organisations enforce policies that adapt as conditions change.

What does that mean? To pick a simple data point - access to resources may be granted under normal conditions, but should a user join an open Wi-Fi network? Immediate revocation. If that's too obvious an example, how about if a device hasn't updated its security patch level within 30/60/90 days? Access revoked.

Isn't this already available in EMM platforms?

Certainly, but if we ignore the scenario where an organisation doesn't use an EMM today, Device Trust benefits almost every other vendor type in the ecosystem in addition to EMMs themselves, the latter for the real-time ability to pull this data in AMAPI-based EMMs that isn't typically possible.

If you're a Mobile Threat Defence vendor, an Identity Provider, or a security solution for example, to gain access to some of the signals provided by Device Trust historically you would:

Need to integrate or partner with an EMM to deploy to estates
Build out the capabilities to fetch much of this information from scratch

If you're one of several vendors on a device - a device could easily have an IDP, an EMM, and an MTD solution in play across an estate today - your solution along with several others could be polling for this data constantly, and potentially fetching dissimilar results based on how and when data is fetched.

Device Trust by comparison feeds consistent, high-level posture signals to all approved applications in a structured and reliable way. It means all of these vendors can play nicely together without the historical tether to management. No longer would an MTD solution require API access into an EMM to understand the current (or last-received, at least) posture of a device. No longer would security tools have to integrate with other solutions to get the same - all approved vendors can call their own snapshot and receive it in milliseconds.

Coming at it from another angle.. no longer do non-EMM solutions require a customer has an EMM (or build/bundle one themselves) to get information from a device historically tied to either a Device Administrator or a Device Policy Controller (MDM agent).

This in itself is a big deal.

For the EMMs themselves, Device Trust offers a route to "managing" (quoted to mean more asset inventory) devices without a DPC, without enrolment, without wiping data or potentially even clashing with another EMM already on a device. It requires minimal work to adopt devices en-masse, and can still enable a hybrid asset management/access policy solution that gates internal resources.

In fact, I imagine this will become a popular option within the ecosystem, purely from the sheer number of organisations I speak to who will not reset existing devices to gain a level of management today (and Google won't enable DPC migration, despite Apple introducing equivalent in iOS 26), at least until the next hardware refresh cycle. Allowing an EMM to offer something of value for these devices is considerable.

Key signals and how to interpret them

The trust snapshot bundles various signals your app or backend can use to make smarter decisions, including:

Ownership type (company or personally-owned)
Management mode (profile owner, device owner)
Provider info including business name and DPC details
Patch level, OS version, pending updates, and published equivalents
Lock complexity and encryption status
Network state, Play Protect status, overall security

These help map device posture to meaningful states, either locally or back in your infrastructure for conditional access, compliance, or alerting.

Use cases across roles

Device Trust is most powerful when different roles in the stack use it in concert. Here are some examples:

EMMs / UEMs: Much of the data already exists for EMMs with managed devices, but a companion application could, in theory, be far more reactive to immediate state changes; triggering policy changes the moment a device returns poor posture, blocking devices that no longer meet posture requirements in the moment rather than on the next interaction with the AMAPI services/MDM backend. The bigger opportunity, for me, comes with the value EMMs can offer for unmanaged devices; tracking assets and their posture without full control of a device will make the prospect of posture-gated resource access far more palatable.

Identity Providers (IdPs): Gate login or data access based on posture (for example, disallow sign-in if device exceeds patch tolerance). This one is a clear and obvious use.

MTDs / Threat Tools: Correlate threat signals with verified posture to refine risk scoring, build stronger threat profiles based on device information, and influence EMM policy actions where a management platform is detected.

Security Tools: Surface posture locally in the app, explain compliance to users, and offer integration into remote SIEM, access, or security logging systems. Independent tools I feel offer the strongest opportunity for the most flexible integrations, and is the route I'm testing currently.

Policy, decisioning, and layering

You may wonder with the above use cases, how Device Trust adapts to the differing requirements of vendors, particularly if/when in use concurrently on a device?

It doesn't. Device Trust itself doesn’t enforce policy - it’s passive. That means the vendors themselves provide policy options in their own environments, and simply use the signals provided by Device Trust to enforce the appropriate actions they take. The real value comes from how vendor policies interpret these signals:

Identity providers can block or allow login based on device posture
Threat detection tools can raise alerts on suspicious changes
EMMs can prompt configuration or compliance nudges
Apps can restrict features or guide users through fixes

Policies should handle missing signals gracefully and decide whether to fail open or closed, depending on context, to avoid blocking legitimate users unnecessarily.

Google recommends layering Device Trust over attestation and Play Integrity for stronger guarantees - if attestation fails, the snapshot likely can't be trusted. Unfortunately, though SDK integration exists for Play Integrity, today Device Trust and the AMAPI SDK it relies on has no in-built support. This means vendors have to integrate this separately. To be fair, many services will already have an integration in place given the historic requirements mentioned earlier, but for newer apps & services, it's an extra step.

Challenges, trade-offs, and privacy

There are some things to keep in mind:

Not every device or OS version returns all signals correctly based on varied testing; expect gaps.
Avoid rigid gating that frustrates users with false positives.
Signals are abstracted to protect privacy and require approval to access on unmanaged devices.
Registration and vetting can take some time, and the business case should be strong as with all parter programmes within Android Enterprise.

Handling these gracefully and communicating clearly with users helps keep frustration low.

How I've implemented it

Following on from the APK support work I did some time back, I turned once again to my kitchen sink of an application: MANAGED INFO. In this case it made sense to revisit as I already provide device information as part of the support tools it offers out of the box.

For this particular project, I opted to initially spin up a Managed Device Dashboard that only shows when MANAGED INFO is EMM-configured, it combines APK, location services, and now a device status screen. This clearly defeats the purpose of Device Trust - I'm aware - though once it's at a point I'm happy to provide it as part of the existing card configuration system, it will become generally available for unmanaged devices, without the need for any elaborate access measures.

There were a few preparatory requirements to get things going.

First, I had already integrated the AMAPI SDK to enable APK deployment, I bumped it up to 1.7.0-rc01 to include all of the latest signals, including business information to help identify AMAPI-based EMMs.

Next, I had to add new permissions for Device Trust to fetch network information and password complexity in use:

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.REQUEST_PASSWORD_COMPLEXITY"/>

Finally, I needed to adjust my notification receiver to include a callback for monitoring when a device user accepted, or declined, to install the Android Device Policy app on devices where it is not pre-installed:

override fun getPrepareEnvironmentListener(): EnvironmentListener {
    return object : EnvironmentListener {
        override fun onEnvironmentEvent(event: EnvironmentEvent) {
            val kind = event.event.kind.name
            val human = when (event.event.kind) {
                EnvironmentEvent.EventCase.Kind.ANDROID_DEVICE_POLICY_INSTALL_CONSENT_ACCEPTED ->
                    "User provided install consent"
                else -> "Event: $kind"
            }
            Log.i("NRSAMAPI", "DT PrepareEnvironment: $human")
        }

        [...]
    }
}

These steps don't include general organisation and prep for fetching, caching, and using Device Trust data within MANAGED INFO, but as that's somewhat subjective from project to project I've left it out. What I will say is rather than storing the snapshot to datastore, I cache it to classes when pulled through a ViewModel, as the data can (and is expected to) change often; sitting on stale info when it takes moments to refresh seemed unnecessary. This also applies when I finish implementing the ability to export the data to a remote endpoint; workers will fetch the state on-run and always return the freshest data possible. What does go to datastore are things like permission decisions, consent for install, and other items that determine the user experience presented.

Basically everything above is already explained in the integration guide for Device Trust, which I'd recommend reviewing as the source of truth, not my examples above. Once implemented, I was able to build up a relatively straight-forward dashboard in a bottom sheet:

Based on the above, here are the highlights:

The topmost card is an amalgamation of device details, ownership, management state, and security patch level. The gradient reacts to the freshness of the security patch level, as a primary indicator of overall device software support. It moves between green, orange, and red respectfully.
The device posture card is actually currently based on a risk assessment, where all items are given a score based on their significance. I previously showed this device score out of 100, but have since opted to show Critical/At risk/All good statuses. I'll likely deprecate the score and instead more explicitly highlight individual items based on their impact directly.
The card grid captures most of the available data points offered by Device Trust, and each card will show a state according to risk. These are again green, orange, red respectfully.
Finally, critical apps are presented with their versions and installation source.

What I don't currently have implemented is Google Play Integrity, and that's because - as above - the AMAPI SDK doesn't offer it as part of the trust snapshot. I'd like it to rather than doing the integration myself, but I'll likely end up adding it in later.

So that's the bottom sheet. As I considered the available signals further, I considered the EMM use case and where they could be of further value. I added them to two distinct locations within the EMM-managed experience I've been building:

The Managed Device Dashboard

For EMM-enrolled devices, the Managed Device Dashboard is my opinionated view of a central experience for all EMM-related information and services. For those following along at home with an installed version of MANAGED INFO (1.1.1.1 at time of writing), on EMM-managed devices this is available via Settings (menu) > Managed device dashboard.

The information grid at the top of this page is a mixture of managed configuration, and Device Trust signals.

FrontDoor-01 is managed config, falling back to device model provided by Trust
Management provider is Trust, provided in SDK version 1.7.0-rc01
Policy, Group, are managed config
SPL, Ownership, Mode is Trust
Role actually comes from the AMAPI SDK, but outside of Trust. When an application role is assigned (added in September 2025) it will send a notification to any configured receiver an application may make available. While I was working on Device Trust, I also added full role support to be able to receive these role notifications, save the assigned role to datastore, and make it available in the Managed Device Dashboard. I think it's nifty.

The rest of the screen make up various projects I'm working on, and aren't wholly relevant here. More docs on anything of interest can be found on the MANAGED INFO documentation.

SetupActions during enrolment

Again for EMM-enrolled devices, MANAGED INFO can offer a customisable (~~when I enable it, likely 1.1.2~~ available from version 1.1.2.0) enrolment screen typically provided by companion applications. Since I'd integrated the SDK and have completed a few projects that required MANAGED INFO to be opened on enrolment, I figured a SetupActions flow would make sense to ensure it happens.

Typically shortly after completing this, the support for application roles included the ability to silently awaken installed applications when a role is assigned, rendering this somewhat redundant now, but still, I have it, and Trust signals here felt like a nice addition:

Not dissimilar to the Managed Device Dashboard, the SetupActions screen here simply exposes a few pertinent details of enrolment; a mixture again of managed configuration information, and Trust signals.

Management provider is provided by Trust
Ownership, Mode are provided by Trust
Policy, Group are provided by managed configuration.

As an EMM-managed device, all of this could be provided through managed configuration; that's how I would have done this previously, but I really quite like the idea that this information is local to the device - no matter what an MDM could want to provide, what the device is experiencing directly is what's shown here. It's a nice little piece of validation.

Challenges

Play Integrity
As above, the primary omission is Play Integrity. I will get to this, but I'd have preferred to see this provided by the SDK as part of the Trust snapshot.

Understanding Google may consider it redundant to provide it when an existing partner already has it, perhaps making it available as a separate call (rather than the default device) or with a flag would seem like a nice middle ground to me.

Application sources
If you paid close attention to the screenshots of the bottom sheet above, you may have noticed all critical apps are showing up "Unspecified". This appears to be a Device Trust bug/issue, as it's returned this way in the snapshot. I know I can override this, I've pulled this data myself in Package Search however I'd prefer it if I could show data from DT unmodified.

~~Critical apps~~ Currently on some devices in the last week or so, critical apps shown go far beyond the five or so Device Trust typically provides, and returns in the snapshot every system app available on the device. I assume this is a bug, so hopefully this will revert soon.

Oct 22: After working with Google, this was determined to be working as intended, and not strictly a Device Trust issue, but a behaviourial change when an application using Device Trust also has the companion application role via EMM policy. Google's docs have been updated:

New:

Device#getApplicationReports() returns details on all installed 
applications to extensibility apps and calling application with 
role COMPANION_APP on a managed device. For all other use cases 
Device#getApplicationReports() returns details on the following 
critical apps:

* com.android.chrome
* com.google.android.gms
* com.google.android.apps.work.clouddpc
* com.android.vending
* com.google.android.webview

Old:

Details on:

* com.android.chrome
* com.google.android.gms
* com.google.android.apps.work.clouddpc
* com.android.vending
* com.google.android.webview

Provides:

* packageName
* versionName
* longVersionCode
* signingKeyCertSha256Fingerprints
* lastUpdateTime
* installerPackageName
* applicationSource

Unreliable system update state
This isn't unique to Device Trust, as this also happens for AMAPI-based EMMs also. Some OEMs utilising custom OTA services (for system updates) don't appear to communicate well with Android Device Policy, and so pending updates aren't reflected in synced states.

TODO

I mentioned a few pending items in the above, but to summarise everything coming to this feature in due course:

~~Play Integrity integration~~ - 1.1.2.0
Tap actions: It's fine showing developer options are enabled, but with tap actions I'll allow device users (where enabled) to tap to the relevant location in Settings to rectify the ongoing issue, this could be disabling developer options, checking for an update, turning on Play Protect, and so on. Whenever I add tap actions to things, I always consider the impact it may have on an organisation - for example tapping something that will open Settings may then unexpectedly give end users full Settings access on a device, even when this is disabled by policy (some tablets are notorious for this with their split-screen Settings view) - so make a restriction available in managed configs to turn it off.
Remote endpoint exports: Similar to the location feature, I'll add in basic API exports. Currently this requires a bearer, I'm considering webhook support amongst alternatives. If you're interested in exploring this and have ideas, get in touch!
General improvements and fixes: Having done a pretty solid first-pass, I'll spin around from the beginning and do a bit of clean-up, likely starting with the score-based state card. - 1.1.2.1
Additional data points: Those provided by Device Trust don't cover off every possible check an application can run on-device - plenty are generally available within Android gated by standard or special permissions. I'll spend some time determining what adds value (e.g. Wi-Fi network SSID can be handy).

Final thoughts

Device Trust adds an important layer to Android’s security foundation, helping organisations align with modern cybersecurity and Zero Trust principles, irrespective of device management, and allows more of the partner ecosystem to build smarter, faster solutions leveraging signals not previously easily available to them. It’s not a replacement for MDM, nor should it be, but adds a brilliant middle-ground that fills a gap left vacant for a long time.

I think it'll equally be a solid stepping stone into full device management for many over the coming years, and I look forward to driving its adoption where I can over time.

If you’re working with IdPs, EMMs, MTDs, or developing real-time device hygiene and access decisions, Device Trust deserves a serious look.

Android developer verification: what this means for consumers and enterprise

2025-09-02T00:00:00Z

Google's August 2025 announcement of developer verification has caught quite a bit of attention in the Android community. Why?

From September 2026, all apps installed on certified Android devices will have to come from a verified developer across several regions, with a global rollout the following year. Google frames the change as implementing an “ID check at the airport”, it will confirm developer details at install time in an attempt to avoid fraudulent copies of a legitimate app from being installed, and it will also make it much harder for bad actors to disappear and re-emerge under a new name.

As someone who spends a lot of time working at the intersection of product management and engineering across the enterprise ecosystem, here's my take on why this matters and what it means for consumers, developers and organisations.

Why Google introduced verification

According to Google's own analysis, malware from internet-sideloaded sources is more than 50 times more prevalent than malware from Google Play. Attackers exploit anonymity to impersonate brands, distribute fake apps and drain users' finances.

Potentially Harmful Applications (PHAs) are rife within the ecosystem, just last year alone Google blocked 2.36 million policy-violating applications, and banned more than 158,000 developer accounts from Google Play - that's just Google Play, and that's just one distribution method. Those apps don't simply vanish; they'll pop up on other 3rd party stores, via dodgy web ads, fraudulent websites.. the risk is very real.

So real, in fact, Kaspersky claims just over 50,000 malicious apps were detected in Q1 of this year running on Android devices according to this report.

👋 Oh hey, if you're an enterprise with EMM-enrolled Android devices using managed Google Play as your application distribution method, the Potentially Harmful Application (PHA) installation rate is only around 0.009%, per the 2024 Android Security Paper (page 32, ref: Google security services). Just in case the above figures were starting to brew some perceptions..

To tackle this, Google will require developers who distribute apps on certified devices - whether through Play, alternative stores or direct downloads - to register and verify their identity. The process involves two main steps: verifying the developer's identity and then registering apps using the package name and signing keys; student and hobbyist developers will have a separate portal with fewer requirements. Importantly, Google emphasises that developers remain free to sideload apps or use any store they prefer, preserving Android's open nature.

Our recent analysis found over 50 times more malware from internet-sideloaded sources than on apps available through Google Play.

Android Developers blog

Positive reaction has come from regulators and industry bodies. Brazil's banking federation, quoted in Google's announcement, describes the policy as a “significant advancement in protecting users and encouraging accountability,” while Indonesia and Thailand's digital ministries call it a "balanced and proactive measure". There is a genuine need for better deterrence against repeat offenders; if you've ever seen fraudulent banking apps trick unsuspecting users, you will appreciate why verifying developer identity matters.

Of course, Google Play itself isn't devoid of PHAs, according to a recent report from Zscaler (via techradar). Developer verification should, in theory, help here also, though to what extent is to be seen as developer verification in Play has been available for a while already.

Early concerns and developer sentiment

The immediate community response has been mixed. Privacy-conscious developers worry that verification erodes the anonymity that has long been part of Android's culture, and raise practical questions about how the system will handle things like package-name collisions - concerns I haven't yet seen clearly answered. Others fear that requiring legal names, addresses and D-U-N-S numbers could deter hobbyists or small open-source projects from publishing, even outside of Play. These criticisms hold water to a point: security requirements should not become barriers to entry or stifle experimentation.

However, framing verification as an oppressive burden misses some nuance. Developers who distribute via Google Play have been subject to similar verification since 2023, so many already comply. For students and hobbyists, Google is offering a lighter-weight console. And crucially, local development isn't affected. You can still build, install and debug your app on a device using the Android Debug Bridge (ADB) and Android Studio, meaning hobby projects, corporate prototypes and test builds remain free from the new requirement.

Google has publicly emphasised that “sideloading is fundamental to Android, and it's not going anywhere,” assuring developers that this change simply adds traceability, not outright removal of sideloading capabilities.

Sideloading is fundamental to Android, and it's not going anywhere.

Sameer Samat, President, Android Ecosystem, Google

Of course, registering as a verified developer will take some time and potentially overhead. For large enterprises this could be a footnote (or it could be a nightmare, if existing challenges with Android Enterprise organisation ID management are anything to go by historically..); for smaller teams it will be an extra administrative task. But when weighed against the financial and/or reputational harm caused by fraudulent apps or stolen data, having to provide proof of identity feels like a reasonable ask. The requirement doesn't restrict where apps come from or force developers into Google Play, and it shouldn't hinder legitimate distribution by third-party app stores.

What it means for consumer safety

From a user perspective, developer verification has clear benefits. When a developer must prove who they are, it becomes significantly harder to spin up a new account after a scam app gets taken down. Users will know that every app on a certified device comes from someone traceable, and regulators will find it easier to investigate and prosecute fraud. That doesn't mean all malware will vanish - verification doesn't vet an app's code - but it does raise the bar for attackers.

Critics have argued that requiring verification might discourage open-source or independent developers. Yet, history suggests that anonymous distribution channels are where malware thrives. Google is not closing those channels; it is adding a basic accountability layer akin to "showing ID at the airport". You can still carry your own bags through security, but you must show that you are who you say you are. That's hardly draconian.

Oh, and just to point it out, this verification is on the developer, not the user. Commentary suggesting burdens on end-users wanting to install random internet APKs shouldn't be compared to ID verification are.. misguided. As a user, installing an unverified app requiring extra effort should be a red flag for the safety of the application in question, not an immediate drive to work around it.

Enterprise implications: initial alarm, then relief

While consumer benefits are clear, the enterprise reaction has been more sceptical. Corporate IT departments can rely heavily on APK deployment to distribute in-house applications, supply-chain tools and partner apps. Many organisations sideload apps using the custom DPCs, (and more recently now via the Android Management API (AMAPI) or their own app catalogue because Managed Google Play does not fit every use case or requirement. In community discussions, administrators worried that Google was inserting itself into their internal deployment: long-time advocate for enterprise freedom, Matt, called for “the same blanket exception that was applied to Google Play Protect” so that fully managed devices wouldn't need to verify their own in-house apps. I've seen first-hand the amount of APK sideloading that happens, particularly with smaller companies using AMAPI, because they cannot (or couldn't, as of a week before this article was published) distribute via an EMM platform. The notion of having to register every internal tool with Google felt intrusive and potentially expensive.

These concerns gained traction until Google clarified its position. In a follow-up post on the Android Enterprise community, the Google announced three key exemptions:

Extension for enterprise devices: Apps from Google Play installed on fully managed devices or within Work Profiles can continue to be installed without developer verification until September 2027, giving organisations an extra year to prepare.
DPC-installed app exemption: Applications installed via an Enterprise Mobility Management (EMM) Device Policy Controller (DPC) are exempt from verification indefinitely. This means that if an organisation installs an app through its EMM agent, it will not need to verify the developer.
Managed Google Play private apps: Private applications uploaded through Managed Google Play are also exempt indefinitely.

These concessions are significant because they preserve the autonomy of enterprise deployments. Administrators can continue to manage corporate devices and distribute bespoke apps without registering them with Google, as long as they use a DPC or Managed Google Play. The requirement only applies when users sideload apps directly onto certified devices outside of those channels.

With this clarification from the Android Enterprise team, I feel like the enterprise ecosystem is wholly unimpaired by the changes. It'll be a relief to many.

So, is developer verification a good thing?

On balance, yes. The policy addresses a real problem - anonymous actors using sideloaded apps to commit fraud - while preserving Android's openness. Consumers stand to benefit from a more trustworthy ecosystem, and legitimate developers gain a stronger reputation. The identity-verification process may feel like an administrative overhead, but most developers distributing widely will already have processes in place for Play or other app stores. Hobbyists and local development remain unaffected; ADB sideloading still works.

For enterprises, the initial fear that Google would insert itself into corporate app management has been allayed by the DPC and Managed Play exemptions. Organisations should still pay attention to the long-term direction: by 2027, apps installed outside of DPC and Managed Play channels will require verification on managed devices. That's a gentle nudge towards using the official tools that provide better visibility and control.

As these things tend to be, it's a classic trade-off: an increase in friction for developers in exchange for a substantial reduction in harm to users. As with any new policy, implementation details need further clarity and ongoing discussion, but with the enterprise concessions now on the table, the pendulum swings decisively towards developer verification being a good thing for the Android ecosystem.

Timeline at a glance

Phase	Dates	Notes
Announcement	Aug 2025	Google announces developer verification
Early access	Oct 2025	Early access begins. Invitations will be sent out gradually.
Verification opens	Mar 2026	Verification opens for all developers.
Enforcement begins	Sep 2026	Requirements go into effect in Brazil, Indonesia, Singapore, and Thailand. At this point, any app installed on a certified Android device in these regions must be registered by a verified developer.
Global rollout	2027 & beyond	Requirements roll out globally.
Enterprise extension	To Sep 2027	Fully managed & Work Profile devices temporarily exempt from installing unverified developer applications via Google Play
DPC & private app exemption	Indefinite	Apps installed via EMM DPC or Managed Google Play never require verification

Frequently Asked Questions (FAQ)

Does this mean I need Google's permission to run my own apps?
No. Verification requires developers to confirm their identity and register package names, but Google is not reviewing app content for apps outside of Google Play. Local development, testing and internal distribution through above referenced channels are unaffected.

Is sideloading going away?
No. Google has explicitly stated that sideloading is "fundamental to Android, and it's not going anywhere." The change introduces accountability by requiring developer verification on certified devices, not a ban on sideloading. That doesn't mean you should install apps from unknown sources.

Can I still use ADB to install my own builds?
Yes. ADB installations for local development remain unaffected.

Does this affect enterprise app deployment?
Enterprises have exemptions. Apps installed through an EMM Device Policy Controller (DPC) or published as private apps in Managed Google Play are exempt indefinitely. Fully managed and Work Profile devices installing public apps from Google Play have an extension on permitting installation without developer verification until September 2027.

Is this just a revenue grab?
No. Developer verification uses the same $25 one-time registration fee already in place for Play Console accounts. Student and hobbyist developers will have access to lighter-weight options with no fees (as currently documented).

Does this change anything for non-certified devices?
No. The requirements only apply to certified Android devices with Google Play services. Non-certified devices are unaffected.

What do you mean an extra year to prepare for Play Store apps in enterprise?
It means eventually some of the applications an organisation relies on may not be possible to install on new devices from 2027 - exactly the same consideration for consumers in 2026. If an organisation needs an application, now is the time (yes, in 2025) to reach out to the developer(s) of the required apps to ensure they are aware of, and willing to comply with, these requirements.

Will installed applications be removed after the deadlines?
No. It will not be possible to push updates to the apps for developers without verification though, so that poses its own risks.

Note: All information reflects publicly available sources as of 2 September 2025 and may evolve as Google refines the programme.

AMAPI finally supports direct APK installation, this is how it works

2025-09-01T00:00:00Z

With the release of AMAPI SDK 1.6.0-rc01, Google has introduced long-awaited support for direct APK installation via the Android Management API (AMAPI). This new capability allows EMM solutions leveraging Google's Android Device Policy (ADP) to install and update apps on managed devices without relying on Google Play or other third-party mechanisms.

Up to now, direct APK deployment was only possible through custom DPCs*, giving more mature EMM vendors graced with the permission to use them a significant advantage in scenarios where Play distribution was impractical or unavailable. Now, with native package manager support in AMAPI, organisations can streamline app delivery, enforce version control, and maintain security standards - all within the AMAPI framework.

*Historically, sideloading APKs or using third-party installers requiring enabling "allow unknown sources" - a process that demanded direct device interaction from IT admins - was also possible. Some OEMs provided proprietary enterprise sideloading solutions as well, but these varied widely and forced organisations to research and adapt to each vendor's approach. With AMAPI's universal support for direct APK deployment, these fragmented workflows are unified: admins no longer need to manually configure devices or investigate OEM-specific options, and the heavy lifting and risk associated with traditional sideloading are eliminated, streamlining app management across all supported Android Enterprise devices.

This update marks a major shift in how private apps (as in, truly private apps) are managed on Android Enterprise devices, levelling the playing field for AMAPI EMM vendors and simplifying workflows for IT admins. The following article details how this new feature works in practice (or, rather, how I chose to implement it) and how you can leverage it for robust, reliable app deployment.

APK installation and developer verification requirements

The timing of this feature is uncanny as we have recently equally grappled with the notion of all applications from next year requiring developer verification.

I've penned a whole article here, but in a nutshell.. DPC-installed applications are exempt!

Setting the environment

APK deployment is enabled through the AMAPI SDK, a library Android applications can import in order to communicate with Android Device Policy locally on-device, and benefits from support for commands, some administrative delegation (managed config management!), and so forth.

Anyone building an AMAPI EMM likely already has the SDK integrated, but that hasn't been a requirement for my applications so far - at least while my approval to integrate Device Trust remains pending with Google currently.

So, first and foremost, we need to ensure the SDK is integrated. If you're considering supporting the SDK, be aware the min SDK is API level 23 - or Android Marshmallow - as of 1.6.0-rc01. My applications currently support down to Android 7.0, so that's no stress to me today, but it's a consideration when relying on any external SDK or library.. you lose the ability to single-handedly define the Android versions you target. Obviously typically I'd speak to the benefits of modern Android and maintaining an up-to-date device estate, but in the context of building a solution for the wider market, backwards-compatibility is a necessity.

Also be aware the library isn't tiny. It added a bump in size to the app download; this could likely be improved through build optimisations, but not something I've looked into yet.

Defining the strategy

Given the time it's taken to land in AMAPI, I very much assumed it'd be a highly-engineered, rather rigid implementation basically entirely handled through Android Device Policy; giving EMM vendors a strict schema to follow to push APKs to it. Essentially I expected it to be a command, like eSIM, like wipe, like relinquish ownership, so on.

I assumed extremely incorrectly.

On the contrary, from my understanding and interactions with it so far, the SDK offers a couple of commands the EMM companion app can fire to install & uninstall an APK delivered through the companion itself.

How does the APK get to the device? Your problem.
How does it handle retries, network issues, compatibility issues, data usage.. etc., etc., etc.? Again.. all you.

In fact, working through building a proof of concept almost the entirety of the weekend, this has been the biggest challenge:

Uploading and storing APKs somewhere accessible
Delivering APKs to the device (my app)
Defining a caching strategy
Handling the logic, marred by directly-lived nightmares of yester-decade when old Device Admin deployments were causing £1000's in data charges due to extremely poor handling of constantly pulling APKs down to devices not compatible with the package being installed.
Ensuring the APK is valid, complete, and matches what has been uploaded when it's downloaded to the companion app.
Handling local issues, such as compatibility

.. and more. You get the picture here. Google, from my understanding of the documentation and experience this weekend, leaves everything to the EMM vendor to figure out, including how to even know the policy has been updated with new CUSTOM applications to trigger the companion into life.

That's bittersweet. I'd expect most vendors - particularly those that have been around for a while - will have their own implementation of package deliveries used for other platforms, other scenarios, etc. In that case this feature can simply plug and play. On the other hand, for the newer platforms embracing AMAPI in the last few years, it's a big shift to need to build this on the back of a service that does most-everything else directly.

Thankfully, the actual main event of installing APKs is documented, includes samples, and isn't complex. There's a useful guide here.

Planning the approach

I used MANAGED INFO as my base. Given I need to support the SDK here for Device Trust #soon, this was the nudge to just get it sorted.

Pulling in the SDK was simple, and I used the guide above to get the basics in place.

From there, I opted for a simplistic managed configuration approach for the proof of concept; I don't have a big, robust EMM solution to automate all the desired if/then logic, nor do I support FCM in MANAGED INFO (because it hasn't been necessary up to now), so a fully-manual approach that could be quite easily scripted for automation later appealed to me. Right now, that means defining the application policy with the custom install type, and then following up with a MANAGED INFO managed configuration entry with the details of the package to be installed (because MI is never aware of the AMAPI policy).

For the proof of concept, I host packages such that they are accessible to MANAGED INFO. In my case that was in my CDN, though I've ensured JWT support for minimal auth, and it should support things like AWS' timed URLs as well without modification. An API definition could be implemented later.

Since MANAGED INFO already supports managed config, it was quite easy to hook a unique worker into the startup / receiver flow that allows a ViewModel (this handles the "business" logic of an app) to check for the presence of packages in the managed configuration payload, and initiate the worker any time the application starts, or the managed configuration changes. I opted to also run it on a schedule, checking for any changes that may have been missed in an MC update due to any unforeseen OEM battery/memory optimisation quirks (this is an edge-case, but one never knows).

I also opted to build an index in datastore for packages defined in managed configuration. While not entirely necessary for installation, this allowed for the tracking of existing apps when the managed config changed, allowing me in turn to handle uninstall events, as if the package is removed from managed config, it can be assumed it's no longer intended for installation. I plan to add another option later to retain packages removed from managed config, but under normal circumstances they would only remain on the device if the policy retains them, or when removed from policy if Google Play is set to Blocklist rather than the default of Allowlist. Things start to get a bit complex when overthinking the options here; for now if it's in config install, if removed, uninstall.

I want a simple UI that offers a status screen for custom applications. This is a preference, not a mandate. First-runs with the APIs had everything working in the background with no UI and it was fine, but I like a nice UI.

Of course all of this requires MANAGED INFO to be launched at least once in order for the managed config to be read, the workers to be scheduled, etc. It's likely to already be the case if you were leveraging MANAGED INFO as a support application or kiosk before this functionality landed, but I wanted to guarantee MI is launched during enrolment to ensure this covers all use cases.

I leaned into AMAPI's companion policies, specifically SetupActions, and then combined this with ExtensionConfig (as the latter is required for the SDK features to function, and prevents user/OS interference of the app running). This alone won't work for devices already in-life, but it's fine for this exercise.

Here's the enrolment splash screen, which automatically closes at the moment as there are no other requirements beyond opening:

Managed configuration definition

The managed configuration consists of 5 keys:

packagemanager_package_name
packagemanager_package_versioncode
packagemanager_download_url
packagemanager_package_admin_sha
packagemanager_package_hash

Package name is clear. Without that things would be difficult to manage.
Version code is used for update management. Every time the worker runs, it will validate the version code of the application installed, compare it with the APK, and if the APK is newer, it'll push an update. It is also used to validate the APK cached is most-recent, and re-downloads the file if not. This is a backup for when file hashes aren't defined.
Download URL is again clear. Remote location from which to fetch the file.
Package Admin SHA is a base 64 validation of the admin certificate SHA256. It is used to validate the downloaded package matches expectations. AMAPI also validates this before installing the APK with the same input used in the AMAPI policy.
Package hash same as above, if this is configured, MANAGED INFO will validate the hash of the file matches that provided in the managed configuration. It'll do this on download, before passing to AMAPI, and before downloading a new copy of the package from the remote source to avoid data use.

The AMAPI policy

Here's a snippet of the full AMAPI policy I'm testing with:

{
    "applications": [
        {
            "packageName": "org.bayton.managedinfo.dev",
            "installType": "REQUIRED_FOR_SETUP",
            "managedConfiguration": {
                "packagemanager_install_applications": [
                    {
                        "packagemanager_application_settings": {
                            "packagemanager_download_url": "https://cdn.bayton.org/download/buttonManager.apk",
                            "packagemanager_package_name": "org.bayton.ffswitchlauncher",
                            "packagemanager_package_admin_sha": "Gsk-H2KnwZs9BeKS8a2hCdpFGhQeFXAn1DLDhE7UfKw=",
                            "packagemanager_package_hash": "",
                            "packagemanager_package_versioncode": "1"
                        }
                    },
                    {
                        "packagemanager_application_settings": {
                            "packagemanager_download_url": "https://cdn.bayton.org/download/kissLauncher.apk",
                            "packagemanager_package_name": "fr.neamar.kiss"
                        }
                    }
                ]
            },
            "extensionConfig": {
                "notificationReceiver": "org.bayton.managedinfo.receivers.NRSAMAPI"
            },
            "autoUpdateMode": "AUTO_UPDATE_HIGH_PRIORITY"
        },
        {
            "packageName": "org.bayton.ffswitchlauncher",
            "installType": "CUSTOM",
            "customAppConfig": {
                "userUninstallSettings": "ALLOW_UNINSTALL_BY_USER"
            },
            "signingKeyCerts": [
                {
                    "signingKeyCertFingerprintSha256": "Gsk-H2KnwZs9BeKS8a2hCdpFGhQeFXAn1DLDhE7UfKw"
                }
            ]
        },
        {
            "packageName": "fr.neamar.kiss",
            "installType": "CUSTOM",
            "customAppConfig": {
                "userUninstallSettings": "DISALLOW_UNINSTALL_BY_USER"
            },
            "signingKeyCerts": [
                {
                    "signingKeyCertFingerprintSha256": "7AOOWxLJ+43yO17MH3HdJRvFA7MM7I1YoAz64sMavxs="
                }
            ]
        }
    ],
    "setupActions": [
        {
            "launchApp": {
                "packageName": "org.bayton.managedinfo.dev"
            },
            "title": {
                "defaultMessage": "Let's get started"
            },
            "description": {
                "defaultMessage": "You're just a few steps from completing enrolment"
            }
        }
    ]
}

You'll note:

Two defined custom applications are present
The managed config used by MANAGED INFO also referencing the two apps
SetupActions to have MANAGED INFO launch on enrolment, and
The relevant settings required to ensure AMAPI doesn't reject the calls from the SDK.

Again, this is a very open approach to this type of feature. I'd imagine vendors will have companions pull packages from internal repositories or API endpoints and completely forego the requirement for a managed configuration.

I could have done this too, through the PING infra I run for my projects, but I like the openness of this approach.

Designing the logic

So with MANAGED INFO primed to launch on enrolment, and having the managed configuration prepped to provide the worker with the package details, it was then time to define how to process this new feature. The following is an overview of the worker logic and implementation.

Step 1: Read managed configuration

On initiation, the worker first reads the available managed configuration. If empty, it will call on a function to check/import managed configurations from disk ad-hoc, and checks again.

If there are no packages defined, everything stops there, the worker will also disable itself until such time the ViewModel wakes it up again on detection of packages in the managed configuration. If present, however, it confirms the number of packages, and moves on to step two.

Step 2: Figure out, and filter out, packages to process

The goal here is not to unnecessarily undertake actions when there's no justification for it, so the worker only hits the network when it's deemed necessary.

Determine and read from the managed configuration
If the configuration differs from the index, are packages added or removed?
- If added, the index is updated and continues
- If removed, the index is updated and an uninstall job is queued
If managed configuration specifies a target version code for a package, and the device already has that version or newer, it moves to the next package with no further processing
For packages that aren't installed, it'll see if a version of the package file has been downloaded to disk previously. If it hasn't, it'll be downloaded at this point on any available network (network types are a TODO)
When packages exist on-disk, the worker will check for any optional hashes provided in the managed configuration to validate all packages are the version(s) expected.
- Package hash will ensure the downloaded version of the APK matches the expectation of the admin
- Signature hash will ensure the APK hasn't been tampered with, or signed with an alternative signature
If verification fails, MANAGED INFO will make 1 attempt to download an updated version and re-run the checks. Continued verification failures will have it stop here for the relevant package(s)

All of this aims to avoid unnecessary downloads and processing, while trying to ensure the APK someone might send to MANAGED INFO is genuine, even if the remote storage repository were to be compromised.

Step 3: Stage the APK

If all is looking correct and valid, the packages are sent to Android Device Policy for processing.

Should AMAPI reject the package, it'll be logged and retried up to three times. All verifications will be undertaken again to ensure nothing has changed in the caches locally.

After the third time, the worker will end, and will try again after a managed configuration change, or within an hour.

The app catalogue screen within MANAGED INFO will surface any installation errors, and allow a user locally to try again.. otherwise, it will try again with the cached APK on the next scheduled run (time based or on configuration update)

If a package is removed from managed config

After the uninstall job is queued by the initial package processing step (because the package is no longer detected in managed configuration), the app triggers an uninstall custom app command to remove it from the device. Even if the policy hasn't been updated to remove the same package. I opted for this approach - for now - in the spirit of ensuring the managed configuration is the source of truth, and no package actions are run (which could invoke network usage) without explicit definition. Do remember the aim here is for either scripting or some form of automation that has the EMM keep the policy and managed config in sync, so the likelihood of the policy and managed config diverging should be low. This is a just in case.

This also takes into account the Play Store Mode limitations I referenced in planning the approach; this way even if the Play Store is in Blocklist, it will still remove an app when the package is removed from the managed config.

There's a brief period of time (~1s) where the config is updated, but the package hasn't yet uninstalled: here the app will report "unmanaged" until the command is successfully processed.

Implementation considerations

Some of the other considerations that emerged during the brainstorming of this implementation.

Networking and timeouts

Sensible timeouts (15s)
4xx (permanent) failures. The worker throws a dedicated exception and fails (doesn't waste retries).
5xx/timeouts (transient) failures. The worker retries up to 3 total attempts before failing, until the next invocation.

The application install worker will only progress when a network connection is present, so logs won't fill with failed attempts.

Integrity validation (optional, recommended)

Two optional checks, controlled by managed configuration:

Signer SHA (sha256)
- This is the signing certificate SHA-256 (hex or base64/URL-safe).
- The cert is extracted from the APK and compared to managed config. On mismatch: redownload once; if it still fails, fail for that app.
File SHA (hash256)
- This is the APK file content SHA-256 (hex or base64/URL-safe).
- The file hash is generated from the APK and compared to managed config. On mismatch: redownload once; if it still fails, fail for that app.

If these are omitted, it's more likely the APK file(s) will be downloaded more often.

Unfortunately, in testing I found some older/non-mainstream devices are unable to validate the signature/hash of the APK locally. In cases like this I don't yet have a solution; I spent more than a few hours trying to get around this.. but alas. TODO. For the moment the application simply won't install unless the file hash/sig cert hash is removed; this is a design choice I made to respect the requirement for explicitly opting to verify the package before install. If an app isn't installing and these are configured for testing, whip them out and try again. I'd appreciate makes/models of problem devices if you're happy to provide them.

Install, update, remove, or skip decision logic

Not installed > install.
Installed and staged is newer > update.
Same version > skip (with log).
Installed newer > skip (with log).
Installed and config removed > remove

Retaining APKs on-disk

When a package is pulled down and passes known verifications, it remains cached for up to 60 hours in order to avoid burdening network (or increasing cellular data fees) during periods where the app may be reinstalled for any reason. Longer caching is a consideration, but there's a balance between filling up storage and ensuring network usage is always minimal. I'd probably be inclined to add more managed configuration options to allow for flexible management of this (including caching forever, until verification drives a re-download).

Points of feedback

The SDK calls on firebase quite often, and I would like to disable this (that's not limited to custom apps, but a general SDK thing it appears)
Initial approaches sent all pending packages to Android Device Policy in one go, and ADP didn't like that. While implementing the receiver for confirmation of installed apps, this approach saw ADP return only one response against multiple install requests
1. Further development saw the worker wait on a response from ADP before processing the next, but this is quite a bit slower.
ADP doesn't inform MANAGED INFO of policy updates, which would be my preferred trigger for the worker logic

Testing the app yourself

MANAGED INFO version 1.0.8.1 is available on Google Play at the time of writing. Feel free to replicate everything described above in other AMAPI environments, there's a starter-policy below that covers everything above, in summary:

MANAGED INFO notification receiver: org.bayton.managedinfo.receivers.NRSAMAPI

Most platforms on the market won't support the customisation required to launch MI on enrolment, but if yours does:

Import the app into the enterprise (with or without an EMM), set it to REQURED_FOR_SETUP under install type
Configure setup actions, if the EMM supports it
Configure extension config
Define the applications in the AMAPI policy under CUSTOM install type
Fill in the relevant details of MANAGED INFO's managed configuration, package installation is rendered at the bottom of the MC list.

Note: setup actions can be omitted, but you'll need to open the app directly at least once. Nothing else can be skipped above, otherwise it'll error.

If you're interacting with AMAPI directly, either via the explorer or something like Postman, here you go:

{
    "applications": [
        {
            "packageName": "org.bayton.managedinfo",
            "installType": "REQUIRED_FOR_SETUP",
            "managedConfiguration": {
                "packagemanager_install_applications": [
                    {
                        "packagemanager_application_settings": {
                            "packagemanager_download_url": "https://cdn.bayton.org/download/buttonManager.apk",
                            "packagemanager_package_name": "org.bayton.ffswitchlauncher",
                            "packagemanager_package_admin_sha": "Gsk-H2KnwZs9BeKS8a2hCdpFGhQeFXAn1DLDhE7UfKw=",
                            "packagemanager_package_hash": "",
                            "packagemanager_package_versioncode": "1"
                        }
                    },
                    {
                        "packagemanager_application_settings": {
                            "packagemanager_download_url": "https://cdn.bayton.org/download/kissLauncher.apk",
                            "packagemanager_package_name": "fr.neamar.kiss"
                        }
                    },
                    {
                        "packagemanager_application_settings": {
                            "packagemanager_download_url": "https://cdn.bayton.org/download/org.privacymatters.safespace.apk",
                            "packagemanager_package_name": "org.privacymatters.safespace",
                            "packagemanager_package_admin_sha": "lEFprXu0adq99f+wlQPOdF69ZzCha4WYaAjEUjp97mM="
                        }
                    }
                ],
                "enable_intro_card": "0x0",
                "enable_org_message": false,
                "enable_quick_actions": false,
                "enable_device_details": true,
                "customisation_settings": {
                    "enable_device_identifiers": false
                },
                "enable_contact_details": false,
                "device_details_settings": {
                    "device_details_enable_basic": true,
                    "device_details_enable_radio": true,
                    "device_details_enable_network": true,
                    "device_details_enable_hardware": true,
                    "device_details_enable_software": false,
                    "device_details_enable_connectivity_check": true
                }
            },
            "delegatedScopes": [
                "CERT_INSTALL"
            ],
            "autoUpdateMode": "AUTO_UPDATE_HIGH_PRIORITY",
            "extensionConfig": {
                "notificationReceiver": "org.bayton.managedinfo.receivers.NRSAMAPI"
            }
        },
        {
            "packageName": "org.bayton.packagesearch",
            "installType": "FORCE_INSTALLED",
            "defaultPermissionPolicy": "GRANT",
            "managedConfiguration": {
                "enable_package_version_sync": false,
                "enable_system_apps_database_sync": true
            },
            "delegatedScopes": [
                "CERT_INSTALL",
                "MANAGED_CONFIGURATIONS"
            ]
        },
        {
            "packageName": "org.bayton.ffswitchlauncher",
            "installType": "CUSTOM",
            "customAppConfig": {
                "userUninstallSettings": "ALLOW_UNINSTALL_BY_USER"
            },
            "signingKeyCerts": [
                {
                    "signingKeyCertFingerprintSha256": "Gsk+H2KnwZs9BeKS8a2hCdpFGhQeFXAn1DLDhE7UfKw="
                }
            ]
        },
        {
            "packageName": "org.privacymatters.safespace",
            "installType": "CUSTOM",
            "customAppConfig": {
                "userUninstallSettings": "ALLOW_UNINSTALL_BY_USER"
            },
            "signingKeyCerts": [
                {
                    "signingKeyCertFingerprintSha256": "lEFprXu0adq99f+wlQPOdF69ZzCha4WYaAjEUjp97mM="
                }
            ]
        },
        {
            "packageName": "fr.neamar.kiss",
            "installType": "CUSTOM",
            "customAppConfig": {
                "userUninstallSettings": "DISALLOW_UNINSTALL_BY_USER"
            },
            "signingKeyCerts": [
                {
                    "signingKeyCertFingerprintSha256": "7AOOWxLJ+43yO17MH3HdJRvFA7MM7I1YoAz64sMavxs="
                }
            ]
        }
    ],
    "defaultPermissionPolicy": "GRANT",
    "appAutoUpdatePolicy": "ALWAYS",
    "playStoreMode": "WHITELIST",
    "setupActions": [
        {
            "launchApp": {
                "packageName": "org.bayton.managedinfo"
            },
            "title": {
                "defaultMessage": "Launch MANAGED INFO"
            },
            "description": {
                "defaultMessage": "For new enrolments, this ensures MI is launched as soon as possible in order to fetch and install defined APKs"
            }
        }
    ],
    "advancedSecurityOverrides": {
        "developerSettings": "DEVELOPER_SETTINGS_ALLOWED"
    }
}

Alternatively, scan this QR code to immediately enrol into my test environment (factory reset is permitted):

I'd welcome feedback, both on the experience, and the design choices/implementation. How would you handle it differently for your project/product?

Finally, if this is something you'd like to see in your own platform, get in touch to discuss 😁

The Android Management API doesn't support pulling managed properties (config) from app tracks. Here's how to work around it

2025-04-23T00:00:00Z

I've had a use case thrust upon me this week, something I hadn't really paid much attention to as I considered and assumed it to be basic functionality.

But wouldn't you know? Nope!

If you're one of an increasing number of organisations trying to get to grips with Google Play's app tracks, you'll likely already understand the perceived benefits:

Multiple application versions through one app listing in Google Play
Customisable tracks for easy identification and naming alignment with internal processes
Direct access to said tracks via EMM policy for managed devices
All the benefits of Google Play's infrastructure for testing and debugging development builds

It's handy, right? The alternative is creating multiple app listings, which can - depending on app visibility - do anything from trigger Play's Repetitive Content Policy to add more workload and management overhead in building, uploading, and maintaining multiple applications on the Play Store (obviously can be countered by CI/CD, but that's not the point).

Unfortunately one of the limitations with app tracks, that wouldn't be there if using multiple Play Store listings, is the visibility of managed configuration.

Circling back to the use case:

A customer has successfully had their ear bent to the benefits of managed config for configuring their application(s) out in the wild, and with quite a robust QA process, has historically had multiple versions of an application being deployed to devices across their estate in tandem as part of it. In onboarding to NinjaOne MDM, with AMAPI (AMAPI still doesn't support APK deployment as of April 2025), the obvious route for this workflow was via app tracks - this is also considering additional requirements not fully described here.

All had been well until it came time to test the managed config. The app track was selected, the application version landed on-device, but managed configs remained empty. Why?

{
  "name": "enterprises/xxxx/applications/com.applauncher",
  "title": "App Launcher",
  "appTracks": [
    {
      "trackId": "4620480462718573",
      "trackAlias": "Dev"
    }
  ],
  "playStoreUrl": "https://play.google.com/store/apps/details?id=com.applauncher",
  "distributionChannel": "PRIVATE_GOOGLE_HOSTED",
  "appPricing": "FREE",
  "minAndroidSdkVersion": 31,
  "updateTime": "2025-01-17T20:51:47.764Z",
  "availableCountries": [
    "AD",
    ...
    "ZM",
    "ZW"
  ],
  "appVersions": [
    {
      "versionString": "1.33",
      "versionCode": 33,
      "trackIds": [
        "4620480462718573"
      ]
    },
    {
      "versionString": "1.6",
      "versionCode": 6,
      "production": true
    }
  ],
  "fullDescription": "App Launcher"
}

Notice anything missing in the above applications.get via AMAPI?

managedProperties is absent. Despite being available in the track being pushed to test devices, the applications.get API endpoint will only return on PRODUCTION where at this time no managed properties were defined.

Here's an example of what could be shown in the above, as taken from my application:

"managedProperties": [
    {
        "key": "startPath",
        "type": "STRING",
        "title": "Application start page",
        "description": "Set the page the application relative to the domain. Default is /, so to start on the Android docs page input /android.",
        "defaultValue": "/"
    }
],

I'm sure Google could fix this by adding another request parameter for trackID (alongside name and languageCode as shown here) but today they don't.

OK, so how can this be addressed?

As ever I'll focus on AMAPI here, Play EMM API vendors have a lot more freedom with their custom DPCs to integrate this as desired.

When building your AMAPI policy, managed configurations form part of the applications payload, and look something like this -

{
    "installType": "PREINSTALLED",
    "packageName": "com.applauncher",
    "autoUpdateMode": "AUTO_UPDATE_MODE_UNSPECIFIED",
    "accessibleTrackIds": "4620480462718573",
    "managedConfiguration": {
        "payment_gateway_url": "https:\/\/bbc.co.uk"
    },
    "defaultPermissionPolicy": "PERMISSION_POLICY_UNSPECIFIED"
},

Typically, an EMM will take one of two approaches to managed configurations:

Use the managed configuration iFrame, which generates the restrictions form.. within an iFrame. This then returns an ID to the policy.
Build a form dynamically from the managedProperties of the applications.get API call - this is my preferred route as it's far more flexible.

If the EMM is using option 1, it becomes more difficult to achieve the objective as it would require the clearing of the ID and a full resubmission of MC via managedConfiguration. If EMMs don't clear the ID first, they will be met with an error 400 on policy save, despite the documentation clearly stating ID will be ignored:

The managed configurations template for the app, saved from the managed configurations iframe. This field is ignored if managedConfiguration is set.

Since EMMs use the iFrame for simplicity, this is less likely to happen.

For option 2, as above there's a lot more flexibility. The vendor will have a configuration form (or the concepts of one, Intune) which will dynamically generate the appropriate inputs based on the PRODUCTION track applications.get command the EMM performs.

But they don't have to do this. An EMM vendor could add either a custom configuration form, or a JSON editor directly, like that of Intune, which would allow the editing and adding of configurations as desired.

Now when an application is known to have managed properties set in an app track version, even if the production version doesn't have anything to generate a form against, the managed config JSON can still be added to the policy, and will be sent down to the application regardless where it will apply successfully.

Like this:

"managedConfiguration": {
    "payment_gateway_url": "https:\/\/bbc.co.uk"
}

To summarise

If a policy can be edited via a JSON/custom config editor, it's simple and straightforward to obtain the restrictions from the application and input them under managed configurations manually rather than leaning on the EMM to build the configuration form. If the EMM doesn't offer this, and equally can't provide access to an API to allow similar, then it may be worth raising it as a feature request.

Get in touch if you've any questions on this!

Hands-on with CVE-2025-22442, a work profile sideloading vulnerability affecting most Android devices today

2025-04-13T00:00:00Z

Mr. Cowell made me aware of a Medium article by Bastien Bobe, field CTO at Lookout, this week. His article gave me a good overview of a vulnerability discovered by Alan Zaccardelle that I'd previously not heard about.

I'd encourage reading the linked article above for the overview and demo video of the vulnerability, but in a nutshell the issue is as follows:

During work profile setup, there's a temporary state as the profile initialises where no policies are applied. It's too early for organisational policy to enforce (in which sideloading is always prevented by default) and there's no default policy in place on Android's side.

The work profile is wide open.

This means if a user has developer settings enabled, USB debugging turned on, and the device connected up to a computer, applications can be sideloaded via ADB. For those more advanced, a script can be written to check for the presence of the work profile, and immediately adb install package.apk as many apps as desired until continuing on to the point of registration/enrolment and corporate policy application.

Here's a video of my own tinkering (I don't pause the process, so policy can be seen blocking further installs), and I'll continue the article below:

https://youtu.be/cw8i-vd0CiE

What versions of Android are in scope?

Pretty much all Android versions going back 10+ years.

Android 16 beta 3 is already patched, so 16 will be the first release in recent times to launch without it. For Android 12-15, a patch has been provided in April's SPL. Everything prior to that is for the respective OEMs to find and fix themselves (though running Android 11 or earlier today comes with many more risks than just this, if not manually maintained by the OEM).

What are the ramifications?

The clear risk is the presence of unauthorised applications in the work profile, and the potential for data leakage through them. The entire point of the work profile is to isolate corporate apps and data in a separately encrypted and siloed environment; allowing unauthorised applications can effectively bridge the cross-profile divide, and this is quite obviously bad.

Unlike Bastien's take, I'm less concerned about malicious, or Potentially Harmful Applications (PHAs) being a risk, as despite his claim, Google Play Protect scans over 200 billion applications a day across certified Android devices globally, including at-least daily checks for known bad applications, and real-time checks of non-Google Play installed applications. Obviously AOSP doesn't benefit from this, but it's a safe assumption most work profile deployments are using certified devices.

So this:

By design, MDM won’t be able to detect malicious or unwanted apps in the work profile

Is misleading. While MDM isn't necessarily the on-device engine scanning apps (that is GPP), Android's built-in protections work well with, and are enforced by, MDM. Of course vendors like Ivanti also have MTD built in, in which case the MDM will be able to detect these apps directly, in addition to GPP.

Suggesting unwanted apps can run amok on the other hand is a fair claim, and data leakage is a concern.

What can organisations do to protect themselves?

It just so happens if your EMM leverages the Android Management API and is not Intune, you don't have to do anything. Within a few minutes, as shown by my video above, AMAPI removes any unauthorised applications; arguably before these apps could really get much - if any - data.

Why not Intune?

Microsoft, despite being the AMAPI for other use cases, uses Company Portal (custom DPC) with work profile devices, though they may apparently be moving over #soon. As such they do not benefit from the AMAPI behaviour that automatically removes unauthorised apps, and these devices are susceptible when using Intune also.

What about non-AMAPI platforms?

If you're an Omnissa (Airwatch/WS1), SOTI or Ivanti (MobileIron) house, or other custom DPC platform, organisations have to be vigilant; keeping tabs on installed applications for work profile devices and locating outliers as they may appear.

Although Bastien says:

If you don’t have an MTD application deployed in your work profile, you won’t see anything and the malicious user can exfiltrate data for years…

This is also misleading. MTD will make things exponentially easier/faster to detect anomalies, but many MDMs show installed applications within application inventories synced from devices. While there may be gaps in this capability across the ecosystem, it's a common feature.

While this CVE is active across an estate, taking the time to pour through application inventories synced up could save a lot of hassle later on. This could potentially even be done via automated reports and some basic scripting through a vendor's APIs.

Other things you can do?

Make sure Google Play Protect is enforced.: It'll be enabled, but users will have the ability to adjust settings if not enforced. You can fix that.
Build blocklists of known troublesome apps: Magisk, SMS Backup & Restore, Dropbox, Seal, etc, etc - build out your lists of known apps to block, and if a user tries to sideload, these will be removed even if the platform isn't AMAPI.
Prevent installation from unknown sources: That won't technically help to prevent this, but protects an organisation against threats generally. See Why you shouldn't install apps from unknown sources.

Or invest in an MTD

The linked article is obviously very heavily biased towards the benefits of MTD, but speaking without bias, I'm all for the additional security on mobile devices providing the solution isn't just a glorified antivirus, as these are generally ineffective in Android - doing little, if anything, more than Google Play Protect.

A full-featured MTD can help monitor not only applications, but network traffic, help prevent phishing/smishing) and much more. And for what it's worth, I think Lookout is a great option for this.

Here are some considerations I've written previously that should still be relevant.

Has this affected you?

I'd very much like to understand the potential impact this CVE has had, or will have, now that it's public and not universally patched. Are you seeing applications showing up in reports you don't expect? How are you handling it?

Get in touch, if desired!

AAB support for private apps in the managed Google Play iFrame is coming, take a first look here

2025-03-22T00:00:00Z

The Android App Bundle (AAB) is a modern application packaging format introduced by Google to streamline and optimise Android app distribution. Unlike the traditional APK, an AAB contains all the necessary compiled code, resources, and assets for an app only for the purpose of permitting dynamic packaging; it cannot be directly installed through Android's package manager on-device (3rd party options exist though!). Instead, it is uploaded to Google Play, which dynamically processes & bundles the respective code into highly-optimised APKs specific to the device(s) downloading the app.

The AAB format has been available to Android developers since 2018, and mandatory for new app uploads from the Google Play console since 2021. The Google Play iFrame, used by enterprises for private app distribution, has however historically mandated APK uploads. Based on a recently-updated help doc, support for AAB in enterprise scenarios appears to be now possible, although it doesn't seem fully rolled out yet.

It's live!

Not a day or so after this article went up, Google announced general availability, including answering some questions and touching on scenarios raised below. I'll dot additional thoughts in callouts like this one where relevant with updated data.

All the same, I spent some time figuring out what's possible so you don't have to!

How AAB and APKs differ

First thing's first, is this a pitch to organisations to immediately push all private applications over to AAB?

No. There are valid use cases for both, which presumably (in addition to understanding the effort it may take organisations to convert over) is why Google will continue supporting APKs in the iFrame. That said, here's a brief overview of each.

APKs

An APK is a single package file containing all the resources, assets, and compiled code for all supported device configurations. While this offers the greatest compatibility across a device estate, it means APK files are often larger than necessary as they include resources irrelevant to the downloading device.

APKs offer simplicity and convenience for developers who want a quick, straightforward way to package and share their applications. They ensure broad compatibility across all Android devices without additional processing or conversion. Additionally, APKs support offline installation, making them ideal for environments with limited or no connectivity. Their self-contained nature enables immediate deployment and rapid testing, which accelerates development and iteration cycles. Furthermore, APKs provide flexibility by allowing distribution through various channels beyond Google Play, including alternative app stores or direct downloads.

Finally, because APKs don't rely on Google Play explicitly, they're suitable for devices lacking Google Play access, or regions where it isn't available. That covers everything from deployment to devices in restricted countries such as China, to closed-network environments without direct access to Google Play. AOSP is a consideration also, but there's a lot more to managing AOSP that I won't dive into here.

Android App Bundles (AAB)

Like an APK, an AAB is a publishing format containing all the necessary components in a single file, the difference is in the processes that occur after uploading to Google Play, as I opened with above.

As well as significantly reducing app sizes through dynamically generated, optimised APKs tailored to each user's device, AABs also support dynamic delivery of features and resources, enabling efficient feature rollouts and resource management.

Release management is also simplified, as developers maintain only a single upload file, eliminating the need to manually handle multiple APK variants for different architectures or feature sets.

Additionally, AAB leverages App Signing by Google Play, centralising key management, potentially increasing security, and simplifying key recovery - particularly sometimes beneficial in organisations who have struggled with key storage and management in the past.

Finally, AABs allow for larger uploads to Google Play, exceeding the 100MB APK limit that appears to be a blocker for the organisations I've worked with quite often.

Leveraging AABs with Android Enterprise

In enterprise scenarios, Android App Bundles enable organisations to deliver tailored application experiences by dynamically serving device-specific features, languages, and resources as needed. This customisation simplifies version management, reduces deployment overhead, and leads to streamlined app lifecycle management, significantly improving end-user experiences. For organisations operating under tight data budgets, the optimised app sizes alone can justify migrating to the AAB format due to significantly reduced download sizes and improved efficiency.

Enough talk, AABs in action

For the context of this article, I opted to take an existing APK and convert it to AAB. There are two reasons for this:

It seemed like the more complex approach, so makes for more interesting reading.
Google hadn't yet turned on AAB uploads for new private apps from the iFrame for my enterprises.

General availability update

I have added the experience for new AAB uploads towards the end.

Here's where we start; I have a private application uploaded as an APK:

Clicking into the application, I can select Advanced editing options to head to the Google Play Console:

I can then head into the application, click Test and release > Production and create a new release. All so far, so normal. Other tracks are available if Production isn't desired.

On any other day, if I were to manage an app update from within the Play Console - which is a perfectly valid approach for organisations with advanced knowledge of developing and distributing applications - I would upload an APK via the upload link.

We're not here for APKs though. To go further, I need to enrol into Play app signing.

Enrol into Play app signing

Play app signing is a requirement for AABs, as Google needs to be able to sign generated APKs on behalf of the organisation when distributing them to devices. I'm clicking Use Play app signing to continue:

For organisations/developers using a Java KeyStore to facilitate application signing, either via Android Studio or otherwise, this next step offers a guide for extracting the private key from it to allow Google to manage it. I'm using Android Studio and want to upload the key I used to originally sign the APKs, so that's what I'm configuring here:

Give Google our keys!?

This is down to the organisation and/or the personal views of the developer. I can appreciate this isn't a desirable choice for some, and that's OK. Google offers alternatives for setup, including dual-releases, but you can stop here and return to APK management if desired.

If you're on the fence, pros and cons:

Pros:

Simplified key management:: Google securely stores and manages your app signing keys, reducing the complexity and risk of losing keys.
They're stored securely:: Google uses strong cryptographic security standards to store keys securely, minimising potential breaches or key leaks.
Easy key recovery:: ~~In case of compromised or lost upload keys, Google provides a straightforward and secure method for recovery without losing your app’s listing and user base.~~

General availability update

According to App bundle FAQs, key recovery is not supported for iFrame-uploaded applications at this time, which is a significant omission to the benefits of AAB. Instead, for this feature, a full developer account is required.

Optimised distribution:: Google Play can leverage advanced features like dynamic feature modules and optimised delivery because they control the final signing process.

Cons:

Loss of direct control:: You relinquish direct control over your signing keys to Google, leaving your app's distribution and security dependent on Google's practices and infrastructure (via Play).
Dependence on Google:: You'll require careful planning if you choose to distribute your app via alternative channels (non-Play) to ensure friction points are minimised.
Security concerns:: Organisations with strict security or compliance policies might find Google's key management approach incompatible with their internal security practices.

Ultimately, whether Google Play App Signing is suitable depends on your organisation’s requirements for security, flexibility, compliance, and control.

That isn't a finite list, and I'm also not an expert, so feel free to read more into this through other sources. Still here? Let's continue!

The script in the above image is:

java -jar pepk.jar --keystore=foo.keystore --alias=foo --output=encrypted_private_key_path --rsa-aes-encryption --encryption-key-path=/path/to/encryption_public_key.pem

Note: The KeyStore and alias - if you're unfamiliar - should match what's shown in Android Studio when prompted during the building of a signed application. If you know what you're doing, do your thing.

Once the private key .PEM file is output, it can be uploaded to Google via Upload private key:

After which I'm then prompted to agree to Play app signing terms. I glanced at it for a good 15 seconds.

And we're enrolled:

Upload the AAB

There are two ways to now get the AAB up, via console and via iFrame. To ensure it works as I'd expect it to, I opted first to test it in the console where I am confident AAB uploads would be supported. Not least because there's a draft release still pending.

I headed back to Test and release > Production, and clicked the Releases tab, allowing me to Edit release:

As now pictured, Releases signed by Google Play is showing, so I'm good to select and upload an AAB in the upload area below:

If you scroll up, you'll note the version in the managed Play iFrame was on version 1.0, and the console here is now showing version 2 (1.1). I carried on through the process, paying attention to any damning errors, warnings, and messages (the Play Console is missing an Oxford comma, there). I chose to ignore two warnings about obfuscation and a government declaration, because I haven't needed to worry about them in the iFrame. I'll update here if that becomes a problem later:

Send the change(s) for review..

..and voilà!

8 nail-biting minutes later, the iFrame also updated to the latest build.

And finally, it pushed to my test device nice and quickly, no fuss at all. Note the size difference between versions below. All I did was bump the version in build.gradle and build an AAB rather than an APK for the newer version!

Note: I'm aware this is not the same device, their version sizes matched on 1.0, though.

Updating from the iFrame

While in the iFrame, I'd be remiss if I didn't test it here also. It's literally a case of editing the app as normal, and just selecting the AAB instead:

Done.

Upload a new AAB from the iFrame

With AAB support fully rolled-out, testing AAB uploads via the iFrame directly turned out to be a lot simpler.

First, I add a new app:

Then, I upload my AAB and accept the terms. I definitely read these again. Create!

And as quickly as that, my AAB is uploaded:

What needs work?

General availability update

The first two of the following issues are resolved, as noted by the demonstration of uploading a new AAB added above. Feel free to skip to key management.

~~While in the iFrame, I'd be remiss if I didn't test it here also. Here's one of a few snags with the process currently, which I'll state after the image:~~

Did you see it? It still references APK file, but it does in fact allow the upload of an AAB. Luckily the file extension is conveniently left in place (thanks, Google!) so you can see it is, indeed, an AAB. Based on Google's help doc, what we can expect to see, at some point, is a more generic label replacing APK file:

~~One of the other snags that currently exists is the inability to upload an AAB as a new application from the iFrame, even having followed Google's guidance in enabling Play app signing.~~

~~The upload allows the selection of an AAB, but the submit button remains greyed out. I went into browser tools and manually enabled the button, only to be met with another error:~~

Key management

It's worth pointing out when doing AAB uploads from the iFrame, Google will generate the key:

Note: Private apps that are created for the first time by uploading an AAB to the iframe will use a Google-generated app signing key. Use one of the options below to use your own signing key:

Use the Play Console to create the private app with an AAB

Use the iframe to create the private app with an APK then switch to AAB.

Tying back to the callout above, if you have desires to use your own key with all uploaded apps, follow their advice and use the console with a full developer account to upload a new application.

Finally, and hopefully another symptom of this not yet being fully rolled out, is the lack of permissions for key management:

General availability update

Unfortunately this won't change. Google have, as above, limited the options admins have for key management with iFrame-uploaded AABs. It's too bad, as it looks like the below concern has been further validated once again.

It's an ongoing frustration generally, actually; permissions are overly restrictive across the portal due to the unique way Android Enterprise app management is set up. I'd like to be able to have my delegated accounts (i.e. jason@bayton.org, not the Google service account) act like an admin when it is granted admin permissions: create apps here, rotate keys in this instance, and so on. I haven't been able to get that working as yet.

In summary

Google's move toward supporting Android App Bundles for private app distribution in the managed Google Play iFrame is well overdue, but great to see. ~~While clearly still in the rollout phase, early exploration shows what's already possible and highlights some areas needing further refinement.~~

For organisations ready to embrace smaller app sizes, streamlined deployments, ~~and more flexible/redundant key management,~~ the transition from APK to AAB is worth considering, ~~at least when it becomes fully available; full support within the iFrame will undoubtedly make this process smoother and more broadly accessible in the near future.~~

As always, plan your strategy carefully - particularly around key management and app distribution - to align with your organisation's security, compliance, and operational requirements.

What's new (so far) for enterprise in Android 16

2025-01-30T00:00:00Z

A little earlier in the year, Android 16 beta 1 has just landed! With the first beta available, it's time to take a look at what's new, so far, in Android 16 "Baklava".

This is, as last year, a non-definitive and unconfirmed list of changes. Like the work profile changes in Android 14 things can change at any point and without warning.

Here we go!

No bump to minimum SDK version for installation of apps

The first beta does not include a change to minimum SDK for app installation. Will it come later? We shall see.

For context, every year now since 14 the minimum version an application must target has increased. In Android 15 it was 24, in 14 it was 23..

If you're interested in what "targeting" is, it looks like this within an application's configuration:

defaultConfig {
    applicationId = "org.bayton.example"
    minSdk = 24
    targetSdk = 23
    versionCode = 1
    versionName = "1.0"
}

Minimum SDK is the lowest version of Android an application will support, this typically changes when new features introduced could cause compatibility issues. It could also change when a developer no longer wishes to support an older version of Android. In either case the application will no longer be available for installation from Google Play on an affected device, and will error when sideloaded.

With the shift in timing for this release it's not clear if this'll be mandated so soon after the bump to 24 in 15, or if that'll come in a quarterly release at a later point. Currently 16 follows 15: only apps that target Android 7.0 - API level 24 - or later will be permitted.

jason@MBP adb install app-release.apk
Performing Streamed Install
adb: failed to install app-release.apk: Failure [INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 23]

To reiterate my sentiment from last year on this topic:

As ever, we're talking about applications targeting a version of Android 10+ years old. While some organisations with line-of-business apps that haven't seen an update in half a decade may balk at the idea of getting their applications updated or rewritten, the justification behind this limitation is solid - security. Where apps targeting <6.0 were able to abuse the old permissioning system (pre-runtime!), apps targeting 7.0 are still able to abuse device administrator and similar APIs. This isn't something you want potentially leveraged directly or indirectly on your managed estate.

App functions control

Not too much research has been done about this feature arriving in 16, but from what I've found, this looks like a new way of allowing applications to interact with one another through the publishing of "functions" an app can perform.

Google's example here suggests an assistant app can search on-device for applications with a known function for creating a note, which replaces a slightly more convoluted approach app developers have to take today:

An assistant app is trying to fulfill the user request "Save XYZ into my note". The assistant app should first list all available app functions as AppFunctionStaticMetadata documents from AppSearch. Then, it should identify an app function that implements the CreateNote schema. Finally, the assistant app can invoke executeAppFunction(ExecuteAppFunctionRequest, Executor, CancellationSignal, OutcomeReceiver) with the functionIdentifier of the chosen function.

This feels, and not just because of the example used, like it'll make the lives of Gemini, ChatGPT, and many other assistant application developers far easier. What I don't get from the example offered is how to target apps. I could have Keep, Obsidian, and several other apps offering a function to create a note. I'm sure this will be explained in due course though (if it isn't already and I just missed it).

For enterprise, Google has added a few restrictions on app functions; they can currently be disabled outright, and disabled cross-profile. I'm hopeful we'll see this ecpand to follow Credential Manager and Widget APIs that allow a block with package exclusions for greater control. We'll see.

Disallow NFC radio

Originally found in the Android 15 documentation, this one was referenced in the UserManager APIs, but never ultimately landed in 15.

As it says on the tin. If you're thinking "Don't we already have an API for NFC?" Yes we do, but that's to control the beaming of data between devices. This is a full on radio disable and will probably live under DeviceRadioState in AMAPI at some point later.

As of this release it's now officially showing up as a Baklava feature.

Disallow Thread Network

Here's another previously-referenced feature to show up confirmed for Baklava.

This is related to comms with thread devices. Again, it's a cut-and-dry, simple restriction. More details on its use will come in time.

Automatic time & automatic time zone policies

New in 16 as of (around) beta 3 are two new policies, automatic time and automatic time zone.

Both of these APIs have existed since Android 11 with setAutoTimeEnabled and setAutoTimeZoneEnabled respectively, and even prior to 11 there were APIs that influenced time and time zone settings.

There's currently no justification documented for revamping these again, and I don't want to speculate, but as and when more information is shared I will update here.

Improvements to provisioning

For years now Android has bloated out the provisioning flow with screen after screen of additional prompts, messages, and delays. Admins want to initiate provisioning and just have it provision, and the longer that takes the more frustrating it becomes to potentially have to do this; whether that's end-users getting their devices, or employees in staging environments doing 5, 50, 500 devices at a time - every minute counts.

In 16 Google have taken steps to improve this, and, well, the proof is in the pudding -

https://www.youtube.com/watch?v=i_73MhGGsDc

In my limited testing on two generations of Pixel devices, I noted:

Fewer interactions needed, so if you lose focus and do something else while the device is provisioning, it's less likely to be stuck on a screen waiting for a button press.
Faster provisioning times, for work profiles on company-owned devices at least. Fully managed was more or less the same amount of time, but either way at about 2 minutes it's not terrible.

This is amazing to see, though as I mentioned on LinkedIn, I'd hope OEM setup screens are targeted next. They took up a majority of the final stages of setup in the video above.

That's not all folks!

This is extremely short and sweet given how early in the process we are for 16. Expect several more betas with several more changes. Check back here again soon!

Android 15: What's new for enterprise?

2024-10-31T00:00:00Z

Android 15 launched officially for Pixel on October 15th. This was about a month and a half after the release to AOSP on September 3rd.

It has been a rather odd series of events this year; Pixel typically receives the latest and greatest version of Android in tandem with its release to AOSP, and the marketing and messaging goes out in unison for Android as a whole, but with Pixel's delay it caused something of an anticlimactic debut for AOSP, with most of the Android 15 blogs and announcements only really happening at Pixel's launch.

Hopefully that doesn't become the norm, I'm not a fan of delaying announcements until an OEM - Pixel or otherwise - is ready with their own implementation; I can't imagine Google would have done this if Oppo, Samsung, HMD or others asked for the same.

That said, here we are.

I could have covered this post off for the most-part after the AOSP drop, I chose to wait until Google released their marketing materials. AOSP/developer docs rarely tell the whole story of enterprise support in an Android release, and 15 has been no different; I'd covered pretty much everything I found for AOSP in What's new (so far) for enterprise in Android 15 and so it was the wider Google Play Services and undocumented functionalities that were left to be covered.

The below aims to provide a comprehensive overview of enterprise features, so may skip some items mentioned in the blog from April. Feel free to jump back there (link above) for more general Android 15 features. Let's start with a headline feature.

Private Space

Android 15 introduces Private Space, the ability for users to protect a selection of apps in a private, additionally-authenticated profile on the device. These applications are isolated - similar to a work profile - from the rest of the applications on the primary parent profile.

When Google announced Private Space with 15, I wrongfully anticipated this to be a mostly non-enterprise feature that wouldn't coexist in the management space. After all, it comes across as the work profile for unmanaged devices, in a way (certainly the tech it's built on tells me this).

But here we are! The multiple work profiles on one device I've been asking for that Google said they'd never support 😁.

Default behaviour for managed devices

The way this is managed is nuanced, per Google:

The default value for an unmanaged user is false. For users with a device owner set, the default value is true and the device owner currently cannot change it to false. On organization-owned managed profile devices, the default value is false but the profile owner can change it to true via the parent profile to block creating of private profiles on the personal user.

So in other words Private Space is disabled for fully managed devices by default, and cannot be enabled. For work profile-enabled company-owned devices, this can be managed.

In testing, my fully managed device does indeed fail to create a Private Space, but doesn't indicate why - it simply fails:

An interjection from the DPC to say this isn't possible would tremendously improve the UX.

General management policies in the Private Space

If you're concerned the Private Space may become a wild-west of hidden app and user activity, fret not! Policies that have previously applied device-wide, such as the installation of apps from unknown sources, are still device-wide. The Private Space adopts these restrictions with no additional management overhead.

Application management in the Private Space

While it's blocked on fully managed devices (which would be a great use case for a reversed COPE, I'll touch on below), it's very much possible to create a Private Space in COPE and co-exist with the work profile.

Hang on, you may be thinking, doesn't that just mean users can add apps to a Private Space if they're not permitted to add them to their personal profile?

As it turns out, no.

Android 15 for business introduces the ability to apply a limited set of security restrictions to specific apps outside the Work Profile. Existing personal app allowlist or blocklist policies can be extended to the new private space feature. In the future, additional privacy preserving security configurations for core apps will be introduced and made backward compatible with Android 15.

via

The policies applied for permitted or blocked apps in a COPE deployment scenario also apply to the Private Space for AMAPI enrolments. CustomDPC EMMs will gain the same functionality at a later date (no ETA provided by Google).

The case for Private Space on fully managed devices

It popped up in the AE Customer Community and I think it's worth further discussion:

I quite like the prospect of reversing the existing COPE model to fully manage the device, but have an inaccessible profile (Private Space) for workers. Maximum control of the device with a lower-perceived, but potentially acceptable level of privacy for workers. As indicated for pool/shared devices where you auth, but can pop a few personal apps for break/other reasons the admins can ultimately remove at will.. I like it.

Private Space has obviously not been enabled on fully managed devices due to the privacy concerns, I would assume, previously associated with work profiles on fully managed devices. Furthermore, I would expect there are nuances within a fully managed and dedicated use cases (which are mostly shared under the Device Owner (DO) ownership model) that would render this feature incompatible and possibly cause problems. It's also likely a lot of work resurrecting deprecated approaches to cross-profile policies and such that would bring this much closer to pre-11 Android fully managed devices with work profiles..

..but it could be disabled by default, as it is for fully managed devices, and in organisations that want to allow a reverse-COPE wherein personal apps and data live in a separately encrypted, isolated container with limited cross-profile oversight (personal usage policies would have to apply on fully managed only, just for Private Space), it could work.

Supporting this would further add the flexibility organisations want as the personally-owned vs company-owned debate rages on amongst admins.

What Private Space isn't

Fort Knox.

Unfortunately, and Google to their credit do highlight this, Private Space is still a profile running within Android; the applications installed in this space can be detected with relative ease and so although it makes it extremely difficult to access app data, it doesn't prevent the determined from piecing together a perception of someone based on the apps they're hiding away. Assuming they have access to the device.

Giant Private Space icons added in PACKAGE SEARCH for emphasis only.

I do feel it could be improved, for example with the work profile implementation there are policies that prevent an app inside the profile from locating applications outside of it, so if I run PACKAGE SEARCH within a work profile, I cannot see the user apps installed in the parent profile.

I appreciate this is not 1:1, effectively asking apps in the parent profile to be blocked from running package manager searches on any packages flagged against the Private Space, but I'd like to believe it's possible.

So that's Private Space. Next? COPE:

Enhancements to company-owned work profiles (COPE)

Google has been busy this year boosting the functionality of the company-owned work profile deployment scenario, and it's a trend I'm here for! Still struggling with the loss of work profiles on fully managed devices, every small bump in functionality that regains some control over the parent (personal) profile of a company-owned device is nothing short of a treat.

Here's what's new in Android 15:

Control of parent profile screen settings in company-owned work profile deployment scenarios

For company-owned devices running work profile, the following previously fully managed-only restrictions can be applied to devices:

Screen off timeout (not to be confused with time to lock, which still supersedes this in terms of hierarchy)
Screen brightness (the actual brightness or the screen)
Screen brightness mode (manual or automatic)

Google announced these as power management controls, I suppose they could contribute to lower power consumption at the cost of user satisfaction if you were to enforce fixed brightness on personal-use devices. They could also contribute to significantly higher power consumption.

I'm not sure what use cases were identified here that led to it being framed this way, but I imagine this could be a frustrating experience for knowledge workers if not implemented by organisations appropriately; who could use a device outside on a Summer's day while being limited to 30% brightness? Who would want to check an incoming call or notification in the middle of the night with a screen that doesn't adapt to the ambient conditions of the room, but rather turn on at 100% brightness?

In contrast, enforcing automatic would be a sensible default. Be mindful if deploying fixed brightness or brightness modes to personal-use devices.

Application defaults in the personal profile for company-owned work profile devices

Extending further control of the personal side of the device for COPE deployments, Google is allowing organisations in Android 15 to set default applications for the dialler, messaging app, and browser.

To be absolutely clear, these defaults will be whatever the Android device ships with, so it wouldn't be possible to set Edge as a default in the personal profile across a managed estate. Rather, Samsung may default to Samsung Internet, Pixel to Chrome, etc. This avoids a potential privacy risk in allowing organisations to set their preferred apps as the personal default, complete with whatever identifying information and usage data they may be able to extract from the personal profile and into corporate servers.

By implementing these defaults, organisations prevent the opposite scenario where a user may choose to use a non-recommended (or downright potentially harmful app) as their default in the personal profile, and open the device up to additional security risks.

Google states these must be initially configured at provisioning time. That is to say set in the policy applied at the time of enrolment. If being set retrospectively, as would be required for any existing device updating to Android 15, this can be done through the use of allowlists:

The default messaging app can be set at any time. To enforce OEM defaults for dialler and browser after set up, this control must be combined with an app allowlist.

These do not apply to Android 15's Private Space (discussed below), as these applications should not be present in the Space to begin with.

Security & privacy changes

Android 15 additionally introduces a fair few security improvements also, some of which include:

Migration of events from logcat to SecurityLog

From 15 we'll start seeing more information provided to SecurityLog. For those who've debugged an Android device under management, unless you're working with the device directly, pulling & reviewing logcat can be a pain.

As SecurityLog, along with NetworkLog, can be fetched through the EMM, this offers a much simpler option and ongoing review of the respective logs.

The intention is to more closely align with NIAP requirements, and allow for quick review of administrative device changes.

In addition, Android adds an event for the backup service being toggled by an admin which will also now be available for admins from 15 when pulling security logs.

Improvements to Factory Reset Protection

Though there are no enterprise-specific changes to factory reset protection, I believe it's important to highlight some changes made to how it works within the context of an enterprise device, namely:

Enabling OEM unlock in developer settings will no longer deactivate FRP
Bypassing the setup wizard, which isn't uncommon for dedicated devices/OEMs, will no longer deactivate FRP.
Adding accounts, passwords, and applications will no longer be possible while FRP is active

Going forward it will be evermore important to ensure both FRP, and enterprise FRP (wherein organisations set the allowlisted Google accounts), are properly maintained and processes correctly followed for resetting devices, if the EMM does not turn FRP off by default (hi, Omnissa..)

A bump to minimum SDK version for installation of apps

As expected, the restriction on installing applications targeting very old versions of Android is getting a bump. In Android 15 it will no longer be possible to install apps targeting API level 23 - Android Marshmallow / 6.0 - or older. Only apps that target Android 7.0 - API level 24 - or later will be permitted.

jason@MBP Downloads % adb install app-release.apk
Performing Streamed Install
adb: failed to install app-release.apk: Failure [INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 23]

Just as last year, we're talking about applications targeting a version of Android 10+ years old. While some organisations with line-of-business apps that haven't seen an update in half a decade may balk at the idea of getting their applications updated or rewritten, the justification behind this limitation is solid - security. Where apps targeting <6.0 were able to abuse the old permissioning system (pre-runtime!), apps targeting 7.0 are still able to abuse device administrator and similar APIs. This isn't something you want potentially leveraged directly or indirectly on your managed estate.

Restrictions on device identifiers for personally-owned devices

From Android 15, applications with the permission android.permission.MANAGE_DEVICE_POLICY_CERTIFICATES will be able to fetch getEnrollmentSpecificId, which is an enrolment-specific, unique device identifier that persists across re-enrolments when done so into the same deployment scenario (i.e. fully managed or personally-owned work profile), by the same vendor agent, into the same enterprise (organisation/bind).

It is an alternative to identifiers such as IMEI and serial number, which Google no longer grants access to for applications without the appropriate device or profile owner role, or DELEGATION_CERT_INSTALL via policy, and becomes the default and only option for fetching a unique device identifier for personally-owned work profile devices in future.

To be clear - applications in a personally-owned work profile deployment up to now with the delegated permission of DELEGATION_CERT_INSTALL have been able to fetch a device serial number with relative ease, something that defeats the entire purpose of restricting access to the identifiers, considered to be personally identifiable information, in the first place. That loophole is closing.

Head's up

At time of writing there's a bug in 15 - on the Pixel 9 Pro XL at least - preventing delegated scopes from being retrieved by managed apps within the work profile. It works fine in the parent profile. If you'd like to validate this yourself, here's a snippet to call from within an application:

val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
val delegatedScopes = dpm.getDelegatedScopes(null, context.packageName)

Security exceptions for sensors-related permissions

From 15, device admins targeting API level 35, including DPCs and device admin role holders, will begin throwing security exceptions when attempting to set permissions for some sensors-specific permissions, including:

Manifest.permission.ACCESS_FINE_LOCATION
Manifest.permission.ACCESS_BACKGROUND_LOCATION
Manifest.permission.ACCESS_COARSE_LOCATION
Manifest.permission.CAMERA
Manifest.permission.RECORD_AUDIO
Manifest.permission.RECORD_BACKGROUND_AUDIO
Manifest.permission.ACTIVITY_RECOGNITION
Manifest.permission.BODY_SENSORS

The two scenarios where this is expected to happen is:

The calling agent is a profile owner, rather than a device owner (so work profile deployments, not fully managed)
The agent is a device owned on a fully managed device, but has EXTRA_PROVISIONING_GRANT_OPT_OUT set during the provisioning process.

While this has been in place since Android 12, previously this would have silently failed. In future security exceptions will be triggered which should make it easier to debug.

New restrictions

It wouldn't be an Android release unless we saw a few new features to manage. Here's the run-down:

Content protection policy

The content protection policy offers admin control of a new feature for real-time threat detection within the Google Play Protect arsenal of protections covered in a prior security blog from February.

For Pixel devices, the toggle for this is in Settings > Security & privacy > More security & privacy > Scanning for deceptive apps.

It is buried deep in Settings.

When the configuration is unspecified, currently the respective toggle is off for fully managed devices. Switching to enforced then enables the setting.

This is a great approach, sympathetic to the feedback its announcement generated from administrators already frustrated with overbearing Google Play Protect policies that cannot be disabled (full disclosure, I'm generally in favour of GPP, but I'm aware of the problems it causes for some organisations), while allowing its use for organisations that feel they need it.

For EMM vendors, this is already present in AMAPI as contentProtectionPolicy under AdvancedSecurityOverrides.

Android 15 also introduces the permission android.permission.MANAGE_DEVICE_POLICY_CONTENT_PROTECTION for apps which are not the device or profile owner to be able to interface with this API.

Google Play Protect app scanning changes

In a related note, in September 2024 Google made a considerable change that will placate any organisation deploying sideloaded enterprise applications, including those installed via the EMM DPC (agent), internal services, or sideloaded in more traditional ways. These applications will no longer be sent to Google for scanning, and no longer prompt end users to take any action against them unless they are known to Google to be potentially harmful. More information here.

Disallow NFC radio

As it says on the tin. If you're thinking "Don't we already have an API for NFC?" Yes we do, but that's to control the beaming of data between devices. This is a full on radio disable and will probably live under DeviceRadioState in AMAPI at some point later.

This appears to be a natural progression from the earlier DISALLOW_CHANGE_NEAR_FIELD_COMMUNICATION_RADIO which prevents the turning on/off NFC in settings.

eSIM management

eSIM has been given a respectable amount of attention in 15. Here's what's new:

Disallow SIM Globally

The API I found earlier in the year appears to be a subset of a larger eSIM management framework being introduced with Android 15. For completeness, as the earlier post was quite light, here's what Disallow SIM Globally actually means:

Available for both fully managed and company-owned work profile devices, disallow SIM globally (DISALLOW_SIM_GLOBALLY) is an eSIM restriction to globally prevent the user download of eSIMs to a device.

While I earlier assumed it may have been globally disabling cellular, killing the radio and hiding the respective settings, status bar messaging, and so forth (useful particularly for lower-cost tablets that often come with cellular) this is not the case.

In my testing, with the restriction enabled I was able to go into settings, begin eSIM setup with the scan of a QR code, and only then did it prevent setup with a generic error message that suggests there's a problem with the eSIM rather than a policy restriction in place:

The experience could be improved dramatically here just with the addition of management UI, and preferably earlier in the process of adding an eSIM, also.

Expanding 9.0 APIs for eSIM management

More broadly Android 15 introduces eSIM configuration capabilities via EMM. Based on what I've been able to find, eSIM management is directly associated with eSIM subscription management introduced in Android 9.0, and has been expanded in 15 to allow remote configuration via EMM, or the appropriate permission:

Starting from Android Build.VERSION_CODES.VANILLA_ICE_CREAM, if the caller has the android.Manifest.permission#MANAGE_DEVICE_POLICY_MANAGED_SUBSCRIPTIONS permission or is a profile owner or device owner, then the downloaded subscription will be managed by that caller. In case the caller is device owner or profile owner of an organization-owned device, switchAfterDownload can be set to true to automatically enable the subscription after download. If the caller is a profile owner on non organization owned device switchAfterDownload should be false otherwise the operation will fail with EMBEDDED_SUBSCRIPTION_RESULT_ERROR.

It would appear EMM vendors with either custom DPCs or via AMAPI will be able to lean into this API from 15 to add and remove EUICC subscriptions. Neat.

Further, it will even support partial payloads! Providing the device has already been registered with an eSIM on a carrier's SMDP+ server, it will allow the device to reach out to that server, declare itself and get it's eSIM. This has the potential to significantly simplify eSIM management, reducing the number of eSIM configurations necessary for large deployments.

Personally-owned device users will be able to remove the configured eSIM, though for company-owned devices, the additional policy DISALLOW_CONFIG_MOBILE_NETWORKS can be set to ensure eSIMs aren't deleted.

Disallow assist content

This restriction allows administrators to prevent privileged apps, such as Assistant, from receiving contextual device information. These include screenshots, package names, and more. Useful for admins wishing to reduce the sprawl of information access privileged apps can have. This is scope-specific, so on fully managed devices will apply device-wide, but on profile-enabled devices restricts only to the managed profile.

Circle to search

Relatively straightforward, an enterprise API is being introduced to lock down circle to search - one of the most hyped up features I've seen in a long time.. but probably not something organisations want accidentally invoking on dedicated devices while customers try to order a Big Mac! This is a nice continuation of assist content above, limiting the amount of data being sent to Google services.

With Android 15, setKeyguardDisabledFeatures has been expanded with widget management to coincide with the re-introduction of lockscreen widgets for tablet devices. At this time it appears to only apply to widgets in managed profiles, with Google explicitly stating:

..the profile owner of an organization-owned managed profile can set KEYGUARD_DISABLE_WIDGETS_ALL which affects the parent user when called on the parent profile.

More testing is needed to determine why this isn't available for fully managed devices.

To note for wider context, lock screen widgets were removed way back in 5.0 citing, if I remember correctly, low use. With the recent focus on tablets, and Apple adding their own, Google clearly figured they matter again!

Other changes and requirements for 15

Rounding off what's new, here are some additional features that don't fit into the above categories:

Platform signed permission management

When a vendor works with an OEM to get their application platform singed, the application is granted all system-level permissions available on the device. As you can imagine, that is an unprecedented level of device access to data and services reserved normally for only the OEM system apps, and Google's preloaded suite of applications.

In Android 15, Google is introducing system permission management, allowing OEMs to grant or deny permissions to signed applications that allows for the considerable down-scoping of access of a signed app to only the explicit permissions required to function. This won't apply to system apps bundled with a set of permissions in the OEM system image, but should permissions change in a later system app update, these permissions would also be denied automatically unless allowlisted in the respective system configuration.

There's an additional config to allow platform-signed shared UIDs for non-system applications that have additionally previously required access to this.

There are new alerts in logging to determine the permissions applications are no longer retaining access to, which vendors should already start looking at today to avoid loss of functionality.

Knowing how many enterprise vendors lean on platform signature permissions today (basically most EMMs, several SaaS products, etc), this has the potential to cause headaches as 15 lands on devices, unless OEMs and vendors work together proactively to avoid this.

Screen recording improvements

If you're like me and record your screen far too often to demonstrate anything from a device feature to a bug, user guides and more, you'll be pleased to hear the previously Pixel-only feature introduced in Android 14 is coming to the wider ecosystem with the 15 update. Now users can limit screen sharing to just the app they want to show, and no longer fret on the possibility to showing something that may not be appropriate for the context.

Continuing the theme of recording, this is not so much an enterprise feature in and of itself explicitly, but Android 15 will alert apps when the screen is being recorded, allowing them to hide contents.

I can imagine this might be useful for enterprise applications across the board to bolster DLP (data loss prevention), and based on murmurings in Tech News, Google is testing restrictions in Chrome to prevent sensitive information from being recorded (addresses, card details, passwords, etc).

Broader system update visibility

From 15, applications granted the permission android.permission.MANAGE_DEVICE_POLICY_QUERY_SYSTEM_UPDATES will be able to obtain information about a pending system update. This softens the current requirements that an application be a device or profile owner in order to fetch this information.

What this doesn't do, unfortunately, is offer any more information about the update(s) available. Today we can see an update is available and that it's a security update. This API needs to be updated to show -

build info,
size,
how long it's been available (not just when first detected), - SPL/Android version

All of this is offered either through GOTA, Google's OTA management server many OEMs are encouraged to leverage (some don't of course, consider e-FOTA from Samsung, or HMD's new FOTA platform), or the build fingerprint of the package itself.

Check MTE status

Expanding on the options for getting and setting MTE policies in Android 14, in 15 it will now be possible to merely query the current state (evidently something that should have, but didn't, quite make it to the 14 release!)

Deeper dedicated device experience management

With Better Together Enterprise, AKA the new customer signup flow, Google is introducing a new provisioning option for dedicated devices, in addition to PERSONAL_USAGE_ALLOWED and PERSONAL_USAGE_DISALLOWED, Google are introducing a third allowPersonalUsage AMAPI enrolment token configuration option of DEDICATED_DEVICE.

That alone isn't an Android 15 feature, but an accompanying flag OEMs can set from 15 within the device software declaring it a dedicated device should give many dedicated device-based organisations a reason to take note.

Such distinguishing features between knowledge worker devices and the new dedicated devices flag include:

Setup Wizard customisation
Default restrictions within the Android experience

Managing dedicated devices, which have always been treated identically to any other consumer Android device on the market, has been a frustrating experience; devices an end user would never use shouldn't need to configure accounts, access Google Play, deal with all the setup wizard interruptions around privacy callouts and more. I'd really hoped the EDLA licence would have solved a lot of problems, but so many years now after its introduction the differentiation is still minimal from MADA.

Fortunately it looks like Google are taking another approach. Unfortunately a few years too late for the almost 5 years I supported dedicated devices on a daily basis, but I look forward to future projects benefiting from these changes.

What didn't make it

These didn't make it today, but may pop up in a QPR or future Android version release:

Dedicated document preview app

In the earlier Android 15 article I referenced a new mandate for OEMs to include a document viewing app, saying:

The absence of a document preview application for managed devices has been quite a noisy complaint from organisations for many years, overshadowed only by missing camera &/ gallery applications. None of these apps have been mandated by Google for the fully managed/work profile user experience, and so the common trend is to see them simply not added.

It appears Google changed their mind on this, which is not uncommon across releases by any means. The 4 or so years I spent working on Android hardware I saw many instances where proposals ultimately didn't make it - sometimes due to an internal direction change, sometimes pressure from OEMs. Either way it looks like that has happened here also, so we'll go another year without a dedicated document preview app.

Skip adding personal accounts during company-owned work profile provisioning

In the earlier article I referenced a change I interpreted as offering the possibility for organisation admins to set provisioning-time configurations that skip the add-account flow during managed provisioning of a company-owned work profile device. This would have been a small quality-of-life improvement that would shorten down the COPE provisioning time for scenarios where either:

users don't wish to immediately add a personal account and complete the full setup of their device, or
where devices are perhaps staged elsewhere and sent to users registered and ready to go.

Alas, we won't see this in 15.

With that said, it has been submitted as a feature request to Google! In future, we may see a provisioning time option similar to allow the skipping of personal setup, perhaps palmed off to deferred setup, or triggered on the first boot after provisioning completes.

Why would it be useful? Mostly echoing the above - organisations still pre-provision devices, even those on zero-touch, before sending them out to users in an effort to reduce the hand-holding needed for setting up a device. With the COPE model there are privacy and ethical considerations preventing the setup of a personal profile with a user's account, and obviously skipping the account setup renders the setup process less intuitive, even with deferred setup.

Ensuring the work side is sorted, then shipping it out to an end user to add their Google account and go I find quite an enticing option in this and similar scenarios.

Disallow Thread Network

At the time of writing, Google developer docs still don't have an entry for the Thread API, but reference it in the UserManager docs as an unlinked entity. At some point the link to UserManager should go to the right place.

In the meantime it appears the source for CTS contains a test for this API. From that it's somewhat clear what this API is intended for, and we no longer need to assume:

// If the device doesn't support Thread then as long as the user restriction doesn't throw an
// exception when setting - we can assume it's fine
@RequireFeature("android.hardware.thread_network")
@RequiresFlagsEnabled(Flags.FLAG_THREAD_USER_RESTRICTION_ENABLED)

If that's too ambiguous, the CTS docs reference the hardware feature android.hardware.thread_network, which additional source commits tie directly to Thread network support.

It looks like it'll be a relatively straightforward boolean (on/off) restriction allowing managed devices to interface with thread network devices when it's added to Android at a later date.

Did I miss anything?

If I did, you know where to find me.

How Goto's acquisition of Miradore is eroding a once-promising MDM solution

2024-09-24T00:00:00Z

Back in 2014, I discovered Miradore, an ITSM solution with a then-emerging Mobile Device Management (MDM) product that promised a robust set of features for managing Android devices. My initial review, Miradore Online: Free MDM, highlighted the platform's potential and its generous free tier, which made it stand out in a market otherwise dominated by costly alternatives.

Miradore isn't defined by their free tier, of course, there's a rather large and feature-rich product behind it. It's what drew me in to their product in the first place however, and has been a consistent, defining feature of their platform for more than a decade.

Over the years, I revisited Miradore multiple times, documenting its growth and the expansion of its feature set in articles like Miradore Online MDM Review: A Second Look and Miradore Online MDM: Expanding Management with Subscriptions.

In 2022, when Miradore announced its acquisition by Goto, I met the news with cautious optimism. Goto, a company known for its suite of remote work tools, seemed like a reasonably safe choice to nurture Miradore's growth. Official announcements from both parties, such as Goto Acquires Miradore and Miradore Acquired by Goto: What Happens Next?, painted a rosy picture of enhanced resources and expanded capabilities.

However, the honeymoon period is certainly over now. Since the acquisition, Goto has more and more shown its disdain for Miradore's core MDM USP, systematically stripping away key features from the free tier and fundamentally altering the product's value proposition and accessibility.

The erosion of the free tier

Last December, a significant change came when Goto removed essential functionalities from the free plan. Email configuration, VPN setup, Wi-Fi settings, contacts management, and mail were no longer accessible without a paid subscription. Details of these changes weren't outlined in Miradore's release notes, instead opting to send direct emails to certain customers only. I personally heard about it second-hand. Nevertheless, the impact was felt by long-time users who had integrated these features into their device management workflows.

The situation worsened then in April; Goto further restricted the free tier by limiting mass actions - a cornerstone feature for any MDM solution. According to the official announcement:

We have modified our Free plan and limited the mass actions. From now on, Free plan customers can:

Deploy configuration profiles one device at a time

Synchronize a single device at a time

These changes effectively crippled the efficiency that Miradore once offered. Administrators now have to perform repetitive tasks individually for each device, a tedious process that is impractical for organisations managing more than a handful of devices.

But Goto isn't finished. Later this year, they have announced plans to cap the number of devices on the free plan to 50, down from unlimited. The forthcoming changes were communicated through another release note recently.

Yes, effectively unlimited devices down to 50. They aren't adjusting the tier functionality either, so it remains quite limited in capability after this change also.

The impact on organisations

Obviously paying customers on higher tiers are wholly unaffected by these changes, and the remaining Miradore team within Goto continue to do a wonderful job with their customer base.

That said, many of the paying customers they have will have come in through their free tier, often selected because organisations could get started and grow their estates without a licence commitment. These cumulative changes have made Miradore's free tier not just limited but virtually unusable for organisations of any moderate size and/or complexity, and pit Miradore far more directly with competing platforms, such as Manage Engine's 25 free licences. Fewer, yes, but not feature-limited.

If you're going to enforce limits, you'd be wise typically to pick a path - limited licences, or limited functionality. The removal of both critical features and the imposition of device limits is a double-whammy that offers the worst of both worlds. I'd ask how they expect groups on the free tier to remain loyal to a platform driven by decisions that scream "we don't want you here", but it seems apparent they haven't considered the question.

As someone who has championed Miradore for nearly a decade, I find this trajectory disheartening. The platform's Unique Selling Proposition (USP) was its robust free tier, which allowed organisations - especially smaller groups and communities with tight budgets - to manage their Android devices effectively without incurring additional costs, and I have directed hobbyists, charities, and indeed potential customers their way for years to benefit from this in order to take a first step into the enterprise management ecosystem.

Goto's strategy appears to be undermining this USP entirely. By going down the path they've chosen, they're alienating the very user base that helped Miradore grow. It's a puzzling move, especially when considering that the MDM market is more competitive than ever, and my sympathies go out to the remaining Miradore team suffering the consequences of these mandates.

Conclusion

Miradore's journey from a promising entry point into device management to its current state of limited functionality on a finite number of devices is a cautionary tale of how acquisitions can sometimes erode the very qualities that gave a product its place in a market. Goto's incremental worsening of their product will fundamentally change what Miradore offers, making it less appealing to organisations that may have used it as a jumping point into a higher tier at a later date, and more likely to be bundled with competing platforms in the decision-making process, unfortunately some with more compelling trial / free tiers than Miradore will soon offer.

My hope going forward is these changes derive very real, measurable impacts on user acquisition and retention, and force Goto to revert. Better still if they also then choose to step back and let the folks who built and know the product define how it should be positioned and operated in the market going forward.

Google Play Protect no longer sends sideloaded applications for scanning on enterprise-managed devices

2024-09-23T00:00:00Z

In a surprise announcement last week, Google have confirmed sideloaded applications - such as those deployed via EMM solutions - will no longer be sent to Google servers for Google Play Protect scanning on enterprise-managed devices.

Why apps are sent to Google

When an application is installed from a source other than Google Play, it is not considered safe by default. Google Play Protect, as part of the round-the-clock security it provides, tries to verify it.

If the application doesn't match any known applications in the GPP database, it will ask the end user of the device to allow GPP to send the application up to Google's dedicated infrastructure to run the necessary security verifications. This off-device service then undertakes the necessary tasks to ensure it's safe, devoid of anything harmful, and any future devices that install the application benefit from GPP knowing of its existence ahead of time.

This doesn't happen with applications that come down from Google Play because they've already undergone this security validation during the Play Store approval process. GPP knows the application, knows where it's from, and in most cases now sees an association with Google Play in the application metadata itself.

Why organisations dislike it

While the service itself really can't be knocked (free security), the approach of requesting from end-users whether an application can be sent to Google is troublesome.

If an organisation relies on in-house, or line of business, applications typically installed via the EMM agent directly (rather than using the Google Play iFrame or console uploaded as a private application), they may be familiar with this on-device prompt:

Source: Google

A disruptive, and oft-confusing interruption for end-users, this has caused questions around the quality, security, and trustworthiness of non-Google Play installed applications for years now.

It is an entirely-consumer approach forced upon enterprise devices with no administrative control; had an API been present to define the answer to the above prompt (akin to how organisations can set permissions, for example) this likely wouldn't have been an issue.

What's changing

As of the 6th of September (2024), applications sideloaded onto enterprise-managed devices, via any means, will no longer be sent for scanning, and thus the prompt will no longer present itself.

It is, in effect, a permanent "Don't send" preset for applications installed either into the parent profile for device owner deployments (fully managed, dedicated), or the work profile of a profile owner deployment, so yes, it applies to personally owned work profile devices also.

What it means for organisations

While sending applications for scanning will no longer be done, Google Play Protect remains active on devices. This is not a full disablement of on-device security, as on-device detection and prevention continues to function; known malicious apps, however they're installed, will still be flagged and may be removed.

Beyond this, nothing really changes in terms of recommendations for the overall management of applications from unknown sources. Where possible it should be blocked by default.

How this came to be

This announcement stems from a lengthy & passionate post on the Android Enterprise Customer Community, further highlighting the importance of the CC for direct feedback into Google and respective product teams.

It's a considerable win for the community and those who use it 😁

If you're on the fence about joining up to share your own feedback, I would hope this example of Google and the customer ecosystem working together to improve the experience for everyone offers the nudge you need. Find a link to join in the share box below 👇

Mobile Pros is moving to Discord

2024-07-22T00:00:00Z

Mobile Pros has been a slack group since inception, way back in the late 2010s. One of the biggest bug-bears for that platform is Slack's hostile approach to non-paying communities, withholding message history and denying access to attachments; it's meant a lot of valuable information over the years has vanished into the ether and put the community on the back-foot compared to other platforms in the ecosystem, which retain a wealth of available wisdom from their collective members.

While it's arguable the ecosystem moves quickly and information soon becomes dated, I say yes and no. Specific questions about Intune or a version of iOS more than a couple of years old? Sure, it has an expiry due to the pace of development and change (perhaps Intune wasn't a great example for pace... heh), but a lot of information - the basics of management, approaches to security, best practices, etc. - change far less over time (just look at the docs here to see things from 2019 still relevant today), and means rewriting the same answers over and over with the Slack we have.

Well, as of August, Slack will start deleting old history entirely. I've always wanted to find a way to make access to past messages, solutions, and discussions viable on Slack, even to the point of asking around for sponsorship opportunities, but it's simply not feasible, and so after months of thought and discussion between our core members, the Mobile Pros community is moving from Slack to Discord.

Why Discord? Predominantly the popularity of the platform, but equally the reasonable parity of function between that and Slack to avoid it being too-jarring an experience to migrate. It goes without saying Discord has some great community features we can leverage as well, and I'm looking forward to putting these into use. On polling the existing community, Discord won out, with Rocket.Chat, Mattermost, Discourse, and others also considered, though with any community it's immeasurably important to ensure ease of access and simplicity of engagement; my concern with rolling a hosted instance of an (arguably easier to manage) FOSS community platform would be yet another account on yet another platform which I know can put people off.

The Mobile Pros community has been going strong over the years and has nearly 1,900 members. While I expect to lose a few of you during the migration, I'm hopeful that most of you will join us on Discord. I know moving platforms can be a farce, but Discord is a very popular platform (far more so than when we looked at it back in 2021!) and I'm hopeful the move won't be too off-putting.

The Slack Mobile Pros group will be officially shutting down come August, but engagement there is actively discouraged already as content will not be migrated over to Discord automatically (and I spent a week doing it all manually!). If you want to continue engaging with Mobile Pros or if you’ve been thinking about joining, now’s the perfect time to get involved.

You can start joining our new Discord community today. Just follow this link to get started.

I look forward to seeing you all there!

(Oh, and for good measure, I've also pushed a static copy of Mobile Pros' Slack history to archive.mobilepros.org through the exceptionally simple tool from hfran. I was doing the work to migrate, I figured I might as well!)

^ Not any more :)

Avoid another CrowdStrike takedown: Two approaches to replacing Windows

2024-07-21T00:00:00Z

In recent days, the tech community has been grappling with the aftermath of a major outage caused by CrowdStrike. This incident resulted in significant disruptions across various enterprise Windows environments, leading to downtime and operational challenges for numerous organisations, public bodies, critical infrastructure, and more. The outage has highlighted the almost impenetrable hold Microsoft has on organisations the world over, and critically flawed Windows can be. It also highlights the importance of secure system installations, change control, and maintenance practices.. but human behaviour is harder to fix.

As organisations recover and reassess their IT strategies, it's absolutely worth taking some time to consider reducing the Windows stronghold - particularly for critical services - and explore alternatives to add a little redundancy to your organisation. The below guide offers a quick and simple run-through for installing alternative operating systems on existing endpoints, be they desktop/laptop or server.

Obvious heads-up

This guide doesn't go into the nuances of enterprise security beyond some basic best practices. Rather, it's to offer a taste of alternatives for non-production devices for intrigued administrators, or those told by their bosses to take a few eggs out of their basket. Proceed with understanding.

First up, Ubuntu

Ubuntu is widely used for both desktops and servers, and considered one of a few leading enterprise Linux distributions (others include RedHat, Suse..). Ubuntu is generally known for good compatibility with a range of devices on the market, and so makes for a nice introduction to Linux. This guide will walk you through the best practices for installing Ubuntu securely, whether setting up a workstation for knowledge workers or deploying a server for backend infrastructure.

Ubuntu Desktop for knowledge workers and end users

1. Preparing for Installation

Download Ubuntu from Official Sources: Always download the latest Ubuntu ISO image from the official Ubuntu website. Verify the SHA256 checksum to ensure the integrity of the downloaded file.
Create a Bootable USB: Use reliable tools like Rufus (for Windows, while you still have it eh?) or Etcher (cross-platform) to create a bootable USB drive. This ensures a clean and secure installation medium.

2. Boot from USB Drive

Insert the bootable USB drive into the target device.
Restart the device and boot from the USB drive.

3. Try Ubuntu Before Installing

When prompted, if you'd like to have a quick test-run to ensure it boots, choose Try Ubuntu to boot into a live session. This allows you to test the system and check compatibility before installation.

4. Begin Installation

Double-click the Install Ubuntu icon on the desktop to start the installation process.

Installation Options:

Language: Select your preferred language.
Keyboard Layout: Choose the appropriate keyboard layout.
Updates and Other Software:
- Select Download updates while installing Ubuntu to ensure that your installation is up-to-date with the latest patches.
- Choose Install third-party software if you need additional codecs or proprietary drivers.

Installation Type:

Erase Disk and Install Ubuntu: This option will delete all data on the disk and install Ubuntu. Use this if you’re setting up Ubuntu on a fresh system or replacing an existing OS.
Something Else: Choose this option for custom partitioning. Recommended for advanced users who want to create separate partitions for /home, /var, /tmp, and /opt.

5. Partitioning

For secure installations, it’s recommended to create separate partitions for system directories:
- /home: For user data.
- /var: For variable data such as logs.
- /tmp: For temporary files.
- /opt: For optional application software.
If using LVM, choose the Use LVM with the new Ubuntu installation option for better management of disk space.
Encryption: Select the option to Encrypt the new Ubuntu installation for security. This uses LUKS encryption to protect your data.

6. Complete Installation

Follow the prompts to select your time zone and create a user account.
After installation, remove the USB drive when prompted and reboot the device.

7. Post-Installation Configuration

Update System: Immediately update your system to ensure you have the latest security patches. Use the command:

sudo apt update && sudo apt upgrade -y

Enable Firewall: Activate and configure the Uncomplicated Firewall (UFW) to block unnecessary incoming traffic:

sudo ufw enable
sudo ufw allow ssh

Install Antivirus: Consider installing ClamAV or an equivalent FOSS AV to scan for malware and viruses, particularly if you interact with Windows systems.

Ubuntu Server for infrastructure and userless systems

1. Preparing for Installation

Download and Verify ISO: As with the desktop version, download the latest Ubuntu Server ISO from the official source and verify its integrity.
Create a Bootable USB: Use a secure method to create a bootable USB drive.

2. Configuring BIOS/UEFI Settings

Secure Boot: Enable Secure Boot for added protection during the boot process.
Disable Unused Hardware: While you're in BIOS, it's a good opportunity to disable unnecessary hardware to limit exposure.

3. Installation Process

Minimal Installation: Choose the minimal installation option to install only essential packages.
Disk Encryption: Use LVM with LUKS to encrypt your disk, ensuring data security.
Custom Partitioning: Create separate partitions for /var, /tmp, and /opt to contain potential breaches.

4. Post-Installation Hardening

Update System: Run system updates immediately:

sudo apt update && sudo apt upgrade -y

Configure Firewall: Use UFW to configure the firewall appropriately:

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw allow [your additional services]
sudo ufw enable

Install Fail2Ban: Protect against brute force attacks by installing and configuring Fail2Ban:

sudo apt install fail2ban
sudo systemctl enable fail2ban

SSH Hardening: Edit the SSH configuration file (/etc/ssh/sshd_config) to enhance security:
- Disable root login: PermitRootLogin no
- Change the default port: Port 2222 (choose any unused port)
- Allow only specific users: AllowUsers yourusername
- Ensure login by password is disabled. Key based auth ensures passwords can't be guessed.

5. Regular Maintenance

Automate Updates: If you haven't learned your lesson from allowing automatic updates to run amok, configure unattended upgrades to keep your system up to date automatically:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Monitor Logs: Regularly check system logs for suspicious activity using tools like Logwatch or setting up a SIEM system for central log intake.

Next, ChromeOS Flex

Before Google acquired it, CloudReady was the leading provider of a Chromium OS-based solution that aimed to bring a lightweight, secure operating system to older hardware. Now rebranded as ChromeOS Flex, this solution continues to deliver a streamlined computing experience, particularly for repurposing outdated devices. ChromeOS Flex brings the benefits of Google's Chrome OS to a wide range of hardware, offering a modern alternative to traditional operating systems.

Prerequisites

Supported Devices List
- Before beginning, verify that your device is compatible with ChromeOS Flex. Google maintains a list of officially supported devices on their ChromeOS Flex Supported Devices page. While ChromeOS Flex is designed to work with a broad range of hardware, checking compatibility ensures optimal performance and user experience. Unsupported (or unlisted) devices may work perfectly, or may lack functionality.
Requirements
- USB Drive: A USB drive with at least 8GB of capacity.
- Backup: Ensure all important data on the target device is backed up, as the installation will erase existing data.

Installation Steps

1. Download ChromeOS Flex

Visit the ChromeOS Flex website.
Download the ChromeOS Flex image and follow the instructions to create a bootable USB drive.

2. Create a Bootable USB Drive

Using the Chromebook Recovery Utility:
1. Install the Chromebook Recovery Utility from the Chrome Web Store.
2. Insert the USB drive into your computer.
3. Open the Chromebook Recovery Utility.
4. Click Get Started and select Chromebook or Chromebox.
5. Click Select a model from a list, then choose Google ChromeOS Flex.
6. Follow the prompts to create your recovery media.
Using a Different Tool:
1. Download and install a tool such as Etcher or Rufus.
2. Select the ChromeOS Flex image file you downloaded and your USB drive.
3. Follow the tool’s instructions to write the image to the USB drive.

3. Boot from USB Drive

Insert the bootable USB drive into the target device.
Power on the device and enter the BIOS/UEFI settings (usually by pressing F2, F12, ESC, or DEL during startup).
Set the device to boot from the USB drive.
Save the changes and reboot the device.

4. Install ChromeOS Flex

Upon booting from the USB drive, you’ll be presented with a ChromeOS Flex installation screen.
Follow the on-screen instructions to install ChromeOS Flex. You will be prompted to either try ChromeOS Flex or install it. Choose Install.
The installation process will erase all data on the device’s internal storage. Confirm that you’ve backed up your data before proceeding.

5. Set Up ChromeOS Flex

Once the installation is complete, the device will restart. Remove the USB drive when prompted.
Follow the initial setup process, which includes connecting to Wi-Fi, signing in with a Google account, and configuring device settings.

Best Practices and Tips

Backup Regularly: Ensure that any important data is backed up regularly, as ChromeOS Flex is designed for cloud-first usage with automatic updates and built-in security.
Update Firmware: Check and update your device’s firmware to the latest version before installing ChromeOS Flex to avoid compatibility issues.
Enable Developer Mode (if needed): For advanced users, enabling Developer Mode might be necessary to perform certain customisations. However, this is typically not required for most standard installations.
Check Compatibility Regularly: As ChromeOS Flex evolves, periodically review the supported devices list to ensure ongoing compatibility with updates.

For additional support and troubleshooting, refer to Google’s ChromeOS Flex Help Centre.

Conclusion

This is somewhat tongue-in-cheek, and a little dig towards Microsoft for rolling an OS that has the potential to fail so spectacularly to make everything suck for a few days. That said, the above guide nevertheless offers a practical way to explore an alternative, especially if you’re feeling less than thrilled with the current state of Windows.

Think of this article not as a comprehensive base on which to build a strategy, but rather as a chance to dip your toes into the world of alternatives. Whether you’re a knowledge worker in need of a new desktop experience or someone managing a server environment, there are secure and robust alternatives that might just be worth your time.

Happy experimenting, and here’s to exploring new possibilities!

Introducing MANAGED SETTINGS

2024-07-04T00:00:00Z

I've been supporting customers on their modern Android management journeys for several years now, and as you can imagine, the more customers you engage with, the more you notice patterns and friction points that resurface time and time again.

For me, having access to system settings from within kiosk environments is one such example of those friction points, and one of the first projects for 2024 I opted to undertake after launching my QR code generator last year.

Don't get me wrong, plenty of vendors in the ecosystem have Kiosk/launcher applications that will offer a solution from within their own applications, AirWatch/WS1 UEM's launcher & Knox Manage kiosk are some of the several examples of these. Recently though, and particularly with the surge of AMAPI based EMM platforms, it's become increasingly clear many do not.

So, I went about designing a relatively straightforward answer - MANAGED SETTINGS.

What is it?

MANAGED SETTINGS is a simple app that provides end users the ability to launch settings intents. This isn't a new concept; searching Google Play brings up many such apps. The key differentiator with MANAGED SETTINGS is the ability to toggle these various intents on and off based on the specific requirements of an organisation through managed config (and thus, the name was born). Out of the box I've aimed to support as many intents as is reasonable, omitting only those which are troublesome to support (i.e those commonly adjusted from the behaviour of AOSP across OEMs) or likely not to see any use, but over time more will be added, so too will custom intent support, allowing organisations to leverage OEM-specific intents with their managed estate without relying on me to implement and support them.

As an added bonus, organisations that struggle to document and/or support the unique and sometimes confusing layouts of OEM-customised settings applications across both their company owned and personally owned estates, are able now to deploy one consistent settings app to everything. Building your documentation around an agnostic, standardised application makes the whole process quicker and more straightforward for all involved.

MANAGED SETTINGS works across fully managed, dedicated, and work profile devices.

When can I get it?

I'm releasing MANAGED SETTINGS as a free application on Google Play, available today. In spite of its simplicity, a lot of time and effort has been put into this, so if you'd like to support the continued development of projects like this for the betterment of the Android Ecosystem, I'm offering a licensed upgrade for MANAGED SETTINGS which offers (currently) basic customisation of the in-app experience. In an upcoming release this will extend to theming to allow organisations the option of setting a colour scheme for the MANAGED SETTINGS app that'll enable closer alignment to the organisation's brand - but I want to ensure there's demand for that before I commit to it 🙂

Get it here:

If you're interested in learning more, visit the project page for an in-depth overview, support docs, and other resources.

Setting expectations for support

Though I've done my best to support the breadth of Settings intents across most major Android OEMs and recent Android versions, it's well known that sometimes intents just don't work, or the OEM Settings application in general causes issues. APN is a good example of an intent that'll work on some devices, but inexplicably fails (or gives permission issues) due to the way OEMs have implemented their telephony stack. I have multiple fallbacks implemented where possible to overcome some instances where an adjusted call is required, but I don't have the resources to test every device on the market.

Interestingly, tablet devices with split-screen Settings app implementations are also far more likely to inadvertently expose additional device settings due to how they're designed, and unfortunately I can't do anything to combat that. I'm more than happy to work with organisations finding issues with certain intents, and if I can resolve them I absolutely will.

To touch on EMM support as well, the managed config implementation is quite basic and should be supported by all major vendors without issue, certainly confirmed so far through my testing. That said, if your vendor isn't working correctly, I'm happy to get to the bottom of it.

Feel free to reach out to debug, and I hope you find MANAGED SETTINGS useful for your managed Android estate!

I'm joining NinjaOne

2024-06-18T00:00:00Z

It’s been a while since my last career update, and as interesting and diverse as the ecosystem is in opportunities to get involved with various projects*, I’m happy to be going back to FTE 😁.

Over the last several months I’ve been doing a lot more with AMAPI - as you’ll no doubt see if my posting history is anything to go by - and an opportunity presented itself to join NinjaOne to help build out and expand their endpoint management solution to mobile. Having interacted in the past (👋 Leo!) with NinjaOne, I know they’re a decent bunch, so I took the offer to go full time leading the Google stack in the just-launched NinjaOne MDM.

I’m incredibly excited to join at a time when mobile is a big focus for the organisation, and offers profound opportunities to take an already-successful endpoint management platform to the next level in the mobile ecosystem; as it stands today, 84 percent of companies allow or require employees to use their personal cell phones for work tasks, 19% of global Android shipments (according to the Android Enterprise Global Partner Summit) are strictly for enterprise, and the dedicated (AE) ecosystem is beginning to come together, particularly with Google’s changes in Android 15.

Having been a long-time advocate of enterprise mobility and endpoint management (see this article as one of the first handful of thought-pieces from nearly 10 years ago (🥲) which still holds some relevance), it's evident that the work-from-anything/anywhere productivity mobile devices have enabled is unrivalled in today's corporate environments - but it’s certainly not without its challenges.

The biggest problem I still see today in the ecosystem is the lack of awareness and education, with only 35-40 percent of organisations (I still believe that’s roughly where we are, though figures are from ~2020, and it sounds like enterprise shipments for Android may be contributing to that growing) using some kind of device management; many are still sending devices out into the wild without proper oversight or management – unaware of the implications or risks associated with supporting a (sometimes fully) mobile and remote workforce. This is even more prevalent in the SMB space.

One of the opportunities towards addressing this is via messaging, marketing and enablement through an already well-established platform; NinjaOne’s reach into the IT and MSP space offers a rare opportunity to be heard by many customers who haven’t necessarily thought about mobile device management up to now, and of course many more who haven’t felt they’ve got the tools to make the leap. I’m excited to drive that through NinjaOne’s MDM, and further promote modern Android (and ChromeOS!) management in the coming months alongside my MDM team, Josh & Paul.

*I’m still working on projects within the ecosystem in my own time, so feel free as always to get in touch if you’ve a mobility challenge you need assistance with 😊.

Samsung announces Knox SDK restrictions for Android 15

2024-06-15T00:00:00Z

Android's Device Administrator (DA) APIs were a cornerstone of device management since their inception way back in Android 2.2. However, with their deprecation in 2017 with Android 9.0 (and obviously prior given AE was introduced in 5.0), Google and the wider ecosystem (👋) has encouraged a shift to the more robust and secure Android Enterprise as DA APIs have slowly faded away. Embracing Android Enterprise provides organisations with better security, enhanced functionality, and clearer data separation. For an in-depth read, see:

In contrast, Samsung’s Knox APIs have maintained capabilities for applications outside of Android Enterprise for several years since DA’s deprecation, even while Google has slowly removed said APIs from circulation with newer Android releases. There have been use cases for this, especially around value-add solutions leaning on Knox APIs while devices are managed with other EMM platforms, but With Android 15, this is about to change.

In spite of how it looks, it may not be a sudden change of heart from Samsung, as the timing of this aligns closely with upcoming restrictions in Android 15 that appear to make this basically necessary.

Samsung's Knox SDK Update

Samsung is restricting access to several of its Knox SDK APIs for use only within the Android Enterprise management framework, gradually phasing out access for non-enterprise apps (or, at least, those enterprise apps not used within scope of Android Enterprise). Starting with Android 15 (Knox 3.11) later in 2024, only apps running as Device or Profile Owners will have access to the relevant Knox SDK features. By late 2025, with Android 16, all Knox SDK APIs will be restricted in the same way.

Samsung says this move aims to enhance device security and ensure that advanced features, like remote control capabilities, are only utilised within managed environments. For further details, check Samsung's announcement.

The affected APIs for 15 are:

SDK Class	SDK Method(s)
EnterpriseDeviceManager	setAdminRemovable
ApplicationPolicy	installApplication
	uninstallApplication
	uninstallApplications
	updateApplication
	setApplicationStateList
	setApplicationComponentState
	setApplicationInstallationDisabled
	setApplicationUninstallationDisabled
	stopApp
	startApp
	addPackagesToPreventStartBlackList
	addPackagesToDisableUpdateWhiteList
	addPackagesToDisableUpdateBlackList
	preventNewAdminInstallation
	preventNewAdminActivation
	addNewAdminActivationAppWhiteList
	addAppPackageNameToBlackList
	addPackageToWhiteList
CertificateProvisioning	deleteCertificateFromKeystore
	resetCredentialStorage
	addPackagesToCertificateWhiteList
SystemManager	setHardKeyIntentBroadcast

SDK Class	SDK method(s)
RemoteDesktop	All methods
RemoteInjection	All methods

And their accessibility:

Knox SDK methods	AE (DO/PO) apps	DA mode apps	Other apps
DA restricted methods	Accessible	Not accessible	Not accessible
Remote control methods	Accessible	Accessible*	Accessible*
Other methods	Accessible	Accessible	Not accessible

*Accessible in DO/PO

Google's Policies for 15

Google is expected to introduce new, sweeping mandates around custom API development and data access/management for devices launching with or upgrading to Android 15. They define where APIs can target (based on management mode), what they can do (such as special permissions management), and the visibility they provide organisation admins that don't align with that already in AOSP. It feels like the final nail in the coffin of DA and DA functionality outside of Android Enterprise management, and obviously impacts all OEMs (except those building for dedicated use cases alone, it appears so the likes of Zebra, Honeywell, Panasonic, and more may be exempt).

Potential impact

For enterprises, this shift presents both challenges and opportunities; the latter in hopefully being a final shove into migrating legacy deployments into Android Enterprise management and off of DA, though for the vendors reliant on these SDKs today for non-AE deployments, it poses a significant and quickly-approaching deadline to work with organisations in allowing functionality to be restored.. of course in some instances this won't be feasible for the use case of the app in question, or the ability for organisations to adapt. It'll be interesting to see what comes of this as 15 rolls out, and I'm sure we'll see plenty of conversations about it over on the Customer Community.

What's new (so far) for enterprise in Android 15

2024-04-11T00:00:00Z

Android 15 is live!

Android 15 is now live, check out the latest article for what ultimately landed!

It's that time of year again. Android 15 is available in pre-release, and combined with some of the changes I've seen committed to the developer documentation, there are a few tasty treats for organisations to come in the next dessert (Vanilla Ice-cream to don't you know).

This is, as last year, a non-definitive and unconfirmed list of changes. Like the work profile changes in Android 14 things can change at any point and without warning.

Here we go!

A bump to minimum SDK version for installation of apps

jason@MBP Downloads % adb install app-release.apk
Performing Streamed Install
adb: failed to install app-release.apk: Failure [INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 23]

Content protection policy

This appears to offer control for the scanning of harmful applications on a device, perhaps allowing admins to explicitly prevent line of business APKs from being flagged up on end user devices as potentially harmful, unrecognised, or any other state that'd trigger a complaint to the admin helpdesk. It has been a point of contention for the dedicated ecosystem for some years, particularly as Play Protect has become more active and aggressive over the last few Android versions.

Unfortunately CPP appears related to a newer Phishing Protection service introduced with Google Play Protect, and will not give admins the ability to disable on-device scanning overall. This is covered in a recent security blog from February.

I'm not sure it's something I'm personally going to be advocating for with customers for the most part unless it's actively causing issues, but it's amazing to see Google catering to the dedicated space for a change after so much increased focus on features that promote privacy at the cost of control for dedicated estates.

Android 15 also introduces the permission android.permission.MANAGE_DEVICE_POLICY_CONTENT_PROTECTION for apps which are not the device or profile owner to be able to interface with this API.

Disallow NFC radio

Disallow Thread Network

~~I'm assuming this is related to comms with thread devices, no additional context has been provided, but you can assume what's coming.~~

Unfortunately it appears this was removed a few months after finding the API.

Disallow SIM Globally

This sounds like it's ticking off a long-desired feature request to fully disable all cellular on a device, but again missing any additional context I don't want to jump to conclusions.

Vital apps mandate for document previewer

I touched on this in a recent doc. The absence of a document preview application for managed devices has been quite a noisy complaint from organisations for many years, overshadowed only by missing camera &/ gallery applications. None of these apps have been mandated by Google for the fully managed/work profile user experience, and so the common trend is to see them simply not added.

In fact, when I was building devices for enterprise, I spent a decent amount of time learning the intricacies of vital apps and considering the use cases of customers to determine what was vital to productivity. I'd always opt to deploy Files By Google as the "Downloads" application, as this killed two birds with one stone - file preview support & a file (download) manager. Any photos taken could then be viewed in this app.

~~But not all OEMs consider this, or really think about enterprise at all, and so it's nice to see Google identifying the gap and plugging it accordingly.. even if it took several years to do so.~~

It appears at some point ahead of release Google reversed their decision.

A switch to feature flagging

This isn't super new information, as Google have been feature flagging already with Android 14, but Google are touting Android 15 as their line in the sand for introducing their new approach to development, Trunk Stable. Mishaal Rahman, the prolific Android code-sleuthing extraordinaire, goes into more detail on Trunk Stable and aconfig (the feature flag system), as well as many more (lesser enterprise) Android features in this video from the latest AOSP & AAOS meetup:

https://www.youtube.com/watch?v=dLz6aIRC0hg&t=179s

The change is an interesting one, it comes across as there being more code out in the open to review, and the ability to potentially build Android flavours with feature flags enabled for early access to features not yet committed to a release, but equally seems that it'll be far harder to put a finger on timelines of when features will actually land in builds; could it be the next dessert release? A QPR update? Who knows.

Furthermore, this adds far more flexibility for the Android team, and I presume far less pressure on managing the development cycle for when things need to be pushed/pulled accordingly. Hiding work-in-progress code behind feature flags is probably considered a breath of fresh air for them 😁

Platform signed permission management

In Android 15, Google are introducing system permission management, allowing OEMs to grant or deny permissions to signed applications that allows for the considerable down-scoping of access of a signed app to only the explicit permissions they require to function. This won't apply to system apps bundled with a set of permissions in the OEM system image, but should permissions change in a later system app update, these permissions would also be denied automatically unless allowlisted in the respective system configuration.

There's an additional config to allow platform-signed shared UIDs for non-system applications that have additionally previously required access to this.

There are new alerts in logging to determine the permissions applications are no longer retaining access to, which vendors should already start looking at today to avoid loss of functionality.

Knowing how many enterprise vendors lean on platform signature permissions today (basically most EMMs, several SaaS products, etc), this has the potential to cause headaches once 15 launches.

Skip adding personal accounts during company owned work profile provisioning

From 15, Google allow organisation admins to set policies that skip the add-account flow during managed provisioning of a company owned work profile device.

Partial screen recording

Screen recording detection

I can imagine this might be useful for enterprise applications across the board to bolster DLP (data loss prevention)

App archiving

Another expansion of existing functionality, Android 15 introduces system-settings control over app archiving, previously only opt-in and managed by Google Play directly.

https://www.youtube.com/watch?v=TENFSugd82g

Presumably this will succumb to the same restrictions as disabling or uninstalling apps we have in place today (that is, users won't be allowed to depending on policy set). In my testing so far, archiving is just disabled on managed devices, with the option greyed out even on INSTALL_TYPEs of AVAILABLE (AVAILABLE means the app is provided to users within managed Google Play, but not downloaded or installed, so the user has full control over whether they wish to install it or not).

Backup job execution exception permission

Less enterprise-explicitly, and more of a general observation which may benefit enterprise app developers, Android 15 introduces the permission android.permission.RUN_BACKUP_JOBS, which:

Gives applications with a major use case of backing-up or syncing content increased job execution allowance in order to complete the related work. The jobs must have a valid content URI trigger and network constraint set.

This is a special access permission that can be revoked by the system or the user.

Protection level: signature|privileged|appop

It's a special permission, and likely only one being leveraged by vendors with OEM partner relationships given the protection level, but all the same it's pretty cool to see Google direct some attention to the backup use case.

Restrictions on device identifiers for personally owned devices

From Android 15, applications with the permission android.permission.MANAGE_DEVICE_POLICY_CERTIFICATES will be able to fetch getEnrollmentSpecificId, which is an enrolment-specific, unique device identifier that persists across re-enrolments when done so into the same deployment scenario (i.e fully managed or personally owned work profile), by the same vendor agent, into the same enterprise (organisation/bind).

To be clear - applications in a personally owned work profile deployment up to now with the delegated permission of DELEGATION_CERT_INSTALL have been able to fetch a device serial number with relative ease, something that defeats the entire purpose of restricting access to the identifiers, considered to be personally identifiable information, in the first place. That loophole is closing.

Broader system update visibility

What this doesn't do, unfortunately, is offer more insight into what the available update is. Today we can see an update is available and whether or not it's a security update. This API needs to be updated to show -

build info,
size,
how long it's been available (not just when first detected), - SPL/Android version

Check MTE status

Control of parent profile screen settings in company owned work profile deployment scenarios

From Android 15, company owned work profile deployment scenarios (COPE) will see scope of policies expand a little to include screen settings:

Screen off timeout (not to be confused with time to lock, which still supersedes this in terms of hierarchy)
Screen brightness (the actual brightness or the screen)
Screen brightness mode (manual or automatic)

This comes across as a quality-of-life (QoL) improvement, though I'd have liked to be a fly on the wall when the scenarios were defined to justify prioritising this.

Control over Private Space

Android 15 introduces Private Space, the ability for users to allocate a selection of apps in a private, authenticated profile on the device.

These applications are isolated - similar to a work profile - from the rest of the applications on the primary parent profile.

The way this is managed is nuanced, per Google:

The default value for an unmanaged user is false. For users with a device owner set, the default value is true and the device owner currently cannot change it to false. On organization-owned managed profile devices, the default value is false but the profile owner can change it to true via the parent profile to block creating of private profiles on the personal user.

So in other words private space is disabled for fully managed devices by default, and cannot be enabled. For work profile-enabled company owned devices, this can be managed.

In testing, my fully managed device does indeed fail to create a private space, but doesn't indicate why - it simply fails.

Disallow assist content

Circle to search

Relatively straightforward, an enterprise API is being introduced to lock down circle to search - the most unnecessarily hyped up feature I've seen in a long time. This is a nice continuation of assist content above, limiting the amount of data being sent to Google services.

the profile owner of an organization-owned managed profile can set KEYGUARD_DISABLE_WIDGETS_ALL which affects the parent user when called on the parent profile.

More testing is needed to determine why this isn't available for fully managed devices.

Deeper dedicated device experience management

With Better Together Enterprise, Google is introducing a new provisioning option for dedicated devices, in addition to PERSONAL_USAGE_ALLOWED and PERSONAL_USAGE_DISALLOWED, Google are introducing a third allowPersonalUsage AMAPI enrolment token configuration option of DEDICATED_DEVICE.

Such distinguishing features between knowledge worker devices and the new dedicated devices flag include:

Setup Wizard customisation
Skipping/prevention of Google account setup
Default restrictions within the Android experience

Managing dedicated devices, which have always been treated identically to any other consumer Android device on the market, has been a frustrating experience; devices an end user would never use shouldn't need to configure accounts, access Google Play, deal with all of the setup wizard interruptions around privacy callouts and more.. and now it looks like Google are finally doing something about it.

Unfortunately a few years too late for the almost 5 years I supported dedicated devices on a daily basis, but I look forward to future projects benefiting from these changes.

Additional management roles

Something of a placeholder at the moment, because I don't fully understand the implications (other than goading Googlers about the reintroduction of Device Admin where all apps have the ability to get Device Policy Manager API control rather than just the explicit device/profile owner as it has been up to Android 14 -- it's not that, for the record, but documentation is just so light it's easy to draw those kinds of conclusions 😅).

Once the scope of wider DPM role holders is clear, I'll update this here.

That's all folks!

15 is now live, check out the latest article for what ultimately landed!

Google quietly introduces new quotas for unvalidated AMAPI use

2024-03-25T00:00:00Z

Google have made one of the most significant changes to permissible use of AMAPI in the last few years, imposing new limits for the number of devices permitted to enrol without validating a solution for commercial availability (that being applying for the EMM community & validating up to a minimum of Standard solution set support).

The reasoning hasn't been provided, but my own experience of receiving requests for support and/or consultancy on an almost-weekly basis for projects that go entirely against permissible use (financing/leasing tools, internal EMM projects, etc) tells me this has been a wide-spread and troubling issue for the AMAPI team for quite a long time.

As ever, it is the actions of the few that spoil it for the rest of us.

What's changing

Google's Permissible Usage page has updated from no explicit maximum number of devices per project (it was a soft 1000 prior, referenced below) to now topping out at 500 devices.

Before	After
No mention	Default quota of 500 registered devices for each project.

In addition, the Android Enterprise features list (requirements) has additionally been updated from the prior 1000 devices to reflect the updated quota:

Before	After
If you intend to manage more than 1000 devices, your EMM solution must support all the standard features (star) of at least one solution set before it can be made commercially available.	If you intend to manage more than 500 devices, your EMM solution must support all the standard features (star) of at least one solution set before it can be made commercially available.

The prior 1000-limit was written, but not actively (automatically) enforced, allowing project owners to break this barrier without much in the way of immediate repercussions; of course any considerable use of the API would catch Google's attention eventually.

So what's different now?

The AMAPI API now enforces this quota, which wasn't the case before. The addition of two new events returned to project administrators via a UsageLogEvent, which is a collection of various events logged on devices from the use of ADB to power on/off, external media mounting, and so on, suggest the API itself has the limits baked right in:

"MAX_DEVICES_REGISTRATION_QUOTA_WARNING",
"MAX_DEVICES_REGISTRATION_QUOTA_EXHAUSTED"

No room for interpretation here. The API offers two states: a near-quota warning (the number which triggers this not published at time of writing), and a quota-reached state, presumably at which point further enrolments will either be wiped, or disabled (..and wiped after 5 minutes, which is standard behaviour for disabled devices on enrolment without a valid policy applied today). That's speculation until it's appropriately documented, though, since currently it is not documented under the EventType docs.

Interesting, but probably not overly strange, is using device events to trigger these states. I suppose it is a device registering with AMAPI that triggers the states, and so it works that the device informs the enterprise of quota warnings/limits. I'd have expected it to be pushed as an enterprise attribute though without reading too much more into it. Perhaps it'll make more sense once Google document it.

Exceptions continue

Despite the addition of these new, actively enforced quotas, it remains possible to request a higher limit on a case by case basis. Google now provide a form to - amongst other things - "respond to a quota limit":

Interesting also is this used to be a Google Cloud process, which suggests to me the Android Enterprise team are foregoing the established Google Cloud processes in favour of a more hands-on - and hopefully personal interaction with project owners.

What does this mean for the unvalidated?

Project owners today, prospective EMM vendors or scenarios where AMAPI is in use that don't breach permissible usage policies running over 500 devices should at minimum register their AMAPI solution with the EMM partner portal. If you haven't already started seeing quota warnings, you will soon. Obviously if it's not yet feasible to validate up to Standard solution set support, the form (https://goo.gle/android-enterprise-response) may offer a bit of runway.

For everyone else not quite at the point of hitting the limit, make preparations to validate your product with the AMAPI team before that threshold is reached.

Closing thoughts

Obviously this won't solve the problem of AMAPI being either abused intentionally or used in ways Google doesn't permit. There's little to stop those driven to do so from spinning up multiple projects across multiple accounts in an ever-continuing game of cat and mouse.

It is a deterrent though, an additional overhead to have to manage to make it worth-while, and perhaps that'll make enough of a difference to justify the engineering time (that could have been dedicated to offline system update management or ephemeral user support, just sayin' 😁) to implement this.

What is Play Auto Install (PAI) in Android and how does it work?

2024-03-07T00:00:00Z

If you have set up a modern Android device, may have come across the list of apps offered by your device just before you finish setup. This is referred to as Play Auto Install and is available to OEMs building certified Android devices.

The list of recommended and required applications suggests (or mandates) a selection of applications the OEM, carrier, or Google consider useful for your Android experience, and is an alternative to the other standard approach of just preloading APKs into the system image.

The way the apps are presented can differ, sometimes they're pre-checked with the option to deselect as desired, while sometimes they may be selected (or "included") with no means of de-selecting. The latter you'll often see with the suite of Google applications, but can equally be set as mandatory by the OEM as shown by Motorola's push of Microsoft apps (I promptly uninstalled) above.

So what's PAI? And why does it matter?

History

Since the dawn of time, application developers have sought means to ensure their applications and services are put in front of as many people as possible. Whether through ads in your browser or app store, partnerships with other developers or vendors to promote complimentary solutions, or the many other ways the general public has sponsored content thrust at their collective faces in modern society.

At some point this found its way into the sacred space of your personal device. I wouldn't be able to pinpoint exactly when, but an OEM in the early days of Android decided they'd like to offer the option of preloading the applications of partners into the builds of their Android devices, and forever diverged the platform from other popular mobile operating systems in the ecosystem to turn Android into a mule for bloatware.

From that point on devices shipped with applications preloaded within the OEM build of Android; often in the /system partition too (though less common as time went on, and partitioning changed in Android overall), which would not only eat into the available partition size defined by the OEM, but do so in a way that was non-removable by users, and with different builds destined for different regions, carriers, or otherwise including differing applications in response to the target market accordingly it added additional complexity to the build processes overall.

It did however as mentioned guarantee the applications preloaded could not be removed (unless apps would occasionally be found in the /data partition where they would be removable), and in some cases OEMs would go as far as preventing applications from being disabled as well, the only available means of "removing" a preloaded application that a user would not want on their device.

This still happens today, but it feels less prevalent now than back then. That's not a data-driven statement, don't quote me.

Drawbacks

Aside from the obvious user distaste for bloatware, for which the ecosystem has mostly come to terms with as a fact an Android device is likely to ship with apps and services they don't want; particularly in the case of carrier-subsidised devices where bloat is prolific? In the context of PAI there are known drawbacks to preloading apps in the system build:

It uses space - As mentioned above, but a little more detail: You can argue a 10MB Android app isn't making all that difference to the device as a whole, but again pre 9.0, where partitions were defined manually, there were real implications to this. Apps grow over time, and even if the preloaded app does not, it shares the partition with system applications, the GMS suite of apps, and more. Once a device is out in the wild the partitions can't be changed (pre-10!), and every OTA delivered must meet the size requirement of the partition it'll be installed on. From Android 10 this limitation went away, though you're still taking space from the user.

A real example of this was with the original 8" tablet I worked to bring to market way back in 2020 on Android 9.0. Although the 32GB of on-board storage was plentiful, the system partitions were sized conservatively to provide more available storage for customers. This was fine for the first year or two, but with the Android 10 upgrade almost all of the available space was exhausted. As updates through the year were pushed, and the GMS core suite of apps were updated with newer, larger APKs, it shrunk to the point an Android 11 upgrade would not have been feasible.

Now again this is in the context of Android 9.0, where partitions were fixed, Android 10 introduced dynamic partitions further improved in 11, but this could not be leveraged on a device that shipped with fixed partitions. To adjust the partition layout would have required devices are sent in for repair, flashed with a version of Android 10 that implemented dynamic partitioning, and then 11, 12, 13, etc would have worked absolutely fine, at the ongoing cost of shrinking user-available storage (but still nothing compared to the gargantuan sizes of Android builds from the likes of Samsung!).

I didn't ship bloat with my hardware, opting instead to lean on PAI to offer them up, which will be covered more below. I did however have a couple of system applications developed; an activation service, and an OEMConfig app, that were preinstalled.

It's inflexible - Once preloaded into a build, it's a permanent fixture of that build. If there are issues with the application - be that usability or security - it's going to be present every time a device running that build of Android is set up from a factory state. Obviously most applications will have a Google Play listing so the ability to update it after setup is a given, however until the OEM updates their build a new version of that application, and the OTA proliferates across their in-market devices, the risk remains.

It's inflexible (cont) - Partnerships end, and the money stops flowing. Whether being paid for a period of time, or based on activations, the application preloaded into the Android build is - as above - a permanent fixture of that build. It can be removed in an update, of course, but for the time it's there, that works against the OEM (but very much in favour of the app developer)

So how does PAI make this better?

What is PAI?

PAI - Play Auto Install - is a partner service provided by Google that allows an OEM to configure applications recommended (or required) without preloading those applications in the Android build.

Rather, the OEM builds a simple system app with a default PAI configuration, and then uses the PAI (or Android Device Configuration) portal to provide the ongoing management of it.

Within the portal, the OEM can target:

Region
Carrier
Build (Fingerprint)
- And by extension, OS version, custom builds for customers, etc.
OEM key (a value OEMs can set within their builds for customisation purposes, try an adb shell getprop | grep oem.key on your Android device to see yours)

And more. There's a considerable amount of flexibility to allow for granular targeting, and new versions of configurations can be published in a few clicks that in turn deploy immediately to devices.

An example app config

Here's an example PAI application config. This below, incomplete example of a configuration follows a format similar to how I configured PAI with my products in the past, with the intention to offer applications to allow rapid enrolment without requiring a Google account (PAI allows for install without an account configured!), but allowing the user to skip the screen and install nothing if so desired.

Why offer this?

I was building devices with a primary use case for enterprise deployment. Although the likelihood was slim, my view was should a customer wish to use one of the tablets for both work and personal reasons, they could opt to set it up as a standard consumer device, and rapidly pull in the relevant DPC to enrol almost immediately without needing to head over to Google Play and locate the relevant agent themselves.

Did it get much use? I don't think so. But it was an opportunity to test PAI and so I gave it a go.

In the screenshot above you see Google, followed by Motorola. This order and layout is configured within the app (not shown below), along with the desired default applications to be offered as follows, in a file called default_layout.xml in most of the PAI apps I've torn down:

<?xml version="1.0" encoding="utf-8"?>
<workspace>
    <autoinstall packageName="com.lookout.enterprise" className="com.lookout.enterprise.ui.android.activity.DispatchActivity" screen="2" x="0" y="4" groupid="0" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="com.fiberlink.maas360.android.control" className="com.fiberlink.maas360.android.control.ui.SplashActivity" screen="2" x="1" y="4" groupid="0" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="com.miradore.client.v2" className="com.miradore.client.ui.AuthenticationActivity" screen="2" x="2" y="4" groupid="0" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="net.soti.mobicontrol.androidwork" className="net.soti.mobicontrol.startup.SplashActivity" screen="2" x="3" y="4" groupid="0" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="com.mobileiron" className="com.mobileiron.MIClientMain" screen="2" x="4" y="4" groupid="0" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="com.mobileiron.anyware.android" className="com.mobileiron.polaris.manager.ui.StartActivity" screen="2" x="5" y="4" groupid="0" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="com.rim.mobilefusion.client" className="com.blackberry.ema.ui.HomeActivity" screen="2" x="1" y="3" groupid="0" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="com.zenprise" className="com.citrix.work.common.activities.LauncherActivity" screen="2" x="2" y="3" groupid="0" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="com.airwatch.androidagent" className="com.airwatch.agent.ui.activity.SplashActivity" screen="2" x="3" y="3" groupid="1" requiredPreload="false" installByDefault="false" />
    <autoinstall packageName="com.microsoft.windowsintune.companyportal" className="com.microsoft.windowsintune.companyportal.views.SplashActivity" screen="2" x="4" y="3" groupid="1" requiredPreload="false" installByDefault="false" />
</workspace>

As you can see in the above, the two configs - beyond defining the apps themselves - are installByDefault and requiredPreload.

installByDefault is as it sounds, the application will be pulled down to the device automatically, and allows no user customisation.
requiredPreload if false allows the user to uncheck it, true marks it mandatory.

When this application is imported into the PAI Android Device Configuration portal, you end up with something that looks like this:

Above: An example of the type of PAI config I provided with devices

As an OEM, you don't technically have to define the applications in the app config, because once imported, the portal will allow full application selection and the ability to override the configuration either way. If you look closely above you'll notice there are no references to config or activation in the app config, they were instead added through the portal.

Additionally, with this config you can also define Google and Carrier apps accordingly.

How is it better?

There are a few benefits to this approach

It can be adjusted at any time - Whether contracts for distribution end, a known issue is discovered, or any other reason an OEM may choose to cease deploying an application with their devices, it takes 5 minutes to edit and publish an updated PAI config, and no devices being set up from that moment will see the delisted application.

It's pushy, but not prohibitive - OEMs can mandate the installation of applications, but users retain the control to remove them if desired. Of course there are other means of preventing apps from being removed in the OS that can be leveraged with PAI, so if they wanted to, they could still choose to make users miserable.

There's no storage sacrifice - Predominantly a benefit for older OS versions, but all the same since apps are not being preloaded, they're not permanently taking up space within the build.

There's more flexibility - Apps can be offered without an install mandate. If developers want exposure, that's a reasonable, no-friction way of offering up your app without making the user feel like they need to take it.

It's simpler - You take all of the build-specific app-preload configuration and processes away from the OS developers, and handle it independently. If builds are being generated predominantly on preloaded applications (and if you know the dedicated world, you know that's not an unreasonable assumption), you can - in tandem with carrier and Runtime Resource Overlays handle a considerable amount of application and system customisation without needing to run multiple unique OS builds for it.

To conclude

If you weren't aware of Play Auto Install before this, hopefully this offers some insight into what it is, any why you might see apps on your device with a name like PlayAutoInstalls. That said, OEMs can name them anything, so I wouldn't advocate checking for exactly that name in your system apps (but the package name is more likely to be consistent, following the convention of android.autoinstalls.config, have a look on your device with an ADB command like adb shell pm list packages | grep autoinstall)

It'll be a safe app to have there, but equally one safe to remove if you're rooted, as the StackExchange thread asks above.

Moreover, it's a better and more efficient way of handling app installs without preloading APKs into the Android build, and more OEMs should leverage it where preloading is otherwise in use.

AMAPI publicly adds support for DPC migration

2024-01-25T00:00:00Z

In the last few days a new suite of APIs have appeared on Google's AMAPI developer docs page covering DPC Migration 🎉

I've written about DPC migration sporadically since 2018 when Google brought it up at their partner summit however the ambitious and frankly substantially overdue functionality has rarely been seen referenced since.

Google's DPC migration solution was intended originally to address the biggest, most burdensome problem organisations have today when moving between EMM platforms.

The wipe.

Whether that's the device wipe of a fully managed device, or the deletion of apps and data from a work profile, moving Android devices from one EMM to another took a substantially unfriendly turn with the introduction of Android Enterprise. It used to be simple to migrate between Device Admin providers, but of course with the bolstering of security came the introduction of Device Owner in place of Device Admin, with that rather large, frustrating, limitation only appreciated by the EMM vendors who know organisations won't easily leave them once they're enrolled due to the substantial cost to productivity.

Unfortunately at this point in time it seems like the resurfaced DPC Migration functionality has been quite rather watered down on what it was originally purported to be.

How this newly publicly documented capability is ultimately intended to be used from Google's point of view is up for debate, as it has not - publicly or otherwise - been covered in any opinionated articles that I've found.

My view, however, is this is intended primarily for the looming turndown of the Play EMM API, the suite of APIs supporting custom DPCs (those vendor branded agents, like WS1 Intelligent Hub, SOTI MobiControl Agent, and the many, many others) that facilitate granular device control before AMAPI stepped in.

The timing makes sense, as more vendors publicly adopt AMAPI (1, 2, 3, 4, 5, ...) a means of migrating existing customer install bases to the AMAPI backend is increasingly more important to reduce overhead of managing two management platforms for one OS within a single product.

So DPC migration in this case can be leveraged to migrate all existing Android devices within a single EMM vendor from the Play EMM API-based custom DPC they have today, over to Android Device Policy and AMAPI, while maintaining management of the device within the solution.

I do wonder though, could this be used to migrate custom DPC-enabled customers from one platform to another?

Technically I should think so. It'd obviously be a one-time action since the DPC migration docs clearly state it's a one-way migration and can't be reversed, though like the DPC migration capability in existence since 2018 it looks like it will need some bilateral support from existing vendors, and to placate them is likely not pitched as a supported mechanism.

This is further suggested by the docs that state:

This method can be called only by a Device Owner or Profile Owner. On Android 10 and below, this must not be called on a device with both a Device Owner and a Profile Owner.

Sidenote: Work profiles on fully managed devices, the older COPE, isn't supported for migration!? That'll rule out migrating your Android 10 and below COPE deployments to AMAPI. Talk about rubbing salt in the wound after they binned this deployment scenario, arguably the most versatile to ever be offered by Google, entirely off. You'd think this would be the perfect time to try to migrate the stragglers over to the replacement work profile on company owned devices deployment scenario instead.

At the very least it looks like pulling a cross-vendor migration off would be difficult, as:

The calling application must be an existing Device or Profile owner, in other words the existing EMM vendor managing the device.
Customers would have to pull userID and deviceID (amongst others) into the per-device token they generate in AMAPI, unless the outgoing vendor incorporates a migration function into their platform to talk to an external AMAPI enterprise which is.. unlikely.
And without the benefit of both Play EMM API and AMAPI access, nor direct integration with the agent app that'll be authorised to use the extensibility SDK (maybe?) the vendor themselves would have, undertaking this effort manually will be a pain.

There's also several metadata items that are validated, meaning spoofing the migration would be difficult:

DpcMigrationDeviceIdMismatchException
The management token is meant for a different device.

DpcMigrationDpcPackageNameMismatchException
The package name of the DPC does not match the records in Play.

DpcMigrationDpcPackageSignatureMismatchException
The DPC package signature does not match the records in Play.

DpcMigrationManagementModeMismatchException
The management mode of the device does not match what is specified in the migration token.

We're unlikely to actually see this even tried, which is a shame.

The DPC migration function is split between server, where tokens are created and managed, and the Extensibility SDK.

Google had been promising more functionality from the extensibility SDK allowing partners to fill the gap left by the lack of AMAPI feature parity with customDPC capabilities, it's interesting to see after almost a year of waiting for something to land there, it's this.

Anyway, in lieu of any further public information, this is what we have at the moment. It'll be interesting to see where this leads. Hopefully Google eventually gain the courage to release the full DPC migration capabilities to the ecosystem though, and Android Enterprise customers the world over will finally gain the ability to perform truly painless migrations.

Update

Google today published the release notes that directly reference this new feature.

Based on the document published (or updated) on 26th Jan, a day after this article, we get a complete view of what DPC migration is and does, and it aligns pretty well with the above. Check out the doc linked above for a full walkthrough, but here are some highlights:

Confirming a lack of support for WPoFMD:

This feature is not supported on fully managed devices which have a work profile running Android 9 or 10. Migrating these devices must not be attempted, and regardless of whether an error is raised, such devices are not supported for DPC migration.

Absolutely nothing has been offered in place, so COPE-heavy deployments are simply out of luck by the looks of things.

Confirming they've watered it down to support only one-way custom DPC to AMAPI migrations:

Note: This process is transparent to end users. It is a one-way only process (it cannot be undone once completed) and it cannot be used to migrate a device from one EMM to another.

And the requirements:

The device is already managed by your EMM with a custom DPC.

Your custom DPC is integrated with the AMAPI SDK.

The device is enrolled with Google Play EMM API.

The device belongs to a Managed Google Play Accounts enterprise.

The device runs Android 9 or later.

In case of work profiles on company-owned devices, the device must run Android 11 or later.

Again it's too bad we're not even seeing - at the very least - AMAPI to AMAPI migration being possible today. Hopefully that'll come in future.

How do Android devices become certified?

2024-01-08T00:00:00Z

If you've taken a passing interest in Android as a product/platform in recent years, you may be familiar with GMS (Google Mobile Services) Certification - more recently rebranded to Play Protect Certification.

If the concept is new to you, this certification is the combination of public requirements from the CDD (Compatibility Definition Document) - a reference that provides both requirements and recommendations for vendors building products to run Android that guarantee a baseline of security and compatibility within the Android ecosystem (applications work the same everywhere, there's a minimum encryption requirement, enterprise APIs and features are present, etc), and GMS requirements - a Google & vendor agreement that permits Google applications (like Google Play Services, Play Store, Gmail, etc) to be preloaded provided the vendor agrees to things like application placement, system update commitments, minimum version requirements, default services, out of box experiences (OOBE), and so on.

There's a bit more about Play Protect Certification, and how to check for it, in the FAQ here

Also explained in the link above, certification isn't a one-fits-all process, in fact you may have seen references to MADA, eMADA, iMADA and more in the news as Google makes changes to the agreements vendors are required uphold based on the regions they're selling into. Europe, India, Turkey, US.., and of course there's no certification for China at all, so it's all AOSP out there.

As an OEM you may have to certify a device under multiple licences in order to sell it into multiple regions, with user experience changes including the browser choice screen, app placement changes, and more, adjusted in accordance with local requirements, resulting court cases decisions, and other such stipulations. If you're planning to sell to different regions you'll likely have multiple SKUs (versions) of a device already to account for cellular radio requirements, local certification body (CE, UKCA, FCC,..) requirements, and other region-specific considerations, so multiple software SKUs (software builds tailored according to a particular specification) aren't as big of a burden as it might seem. Even less so since Android 10 with the introduction of Build Variants - a process in which multiple software SKUs with differing requirements can be generated from a primary software build automatically.

Who can certify devices?

If you're an organisation building Android devices, be that a new venture or as a change to an existing product line to support PP/GMS Certification, the obvious question is how can I certify?

In short, anyone can build a device and prep it for certification based on the CDD, but only organisations with a signed x/MADA or EDLA agreement with Google can actually obtain the GMS suite of applications, the requirements list, and submit the device to one of Google's approval partners (referred to often as "3PL") to undergo the testing and validation process (the aforementioned xTS tests in the FAQ above).

The likelihood of gaining this agreement as an organisation is low, as Google maintains a small list (~100) of approved partners, and often therefore the best course of action is to work with existing partners in order to bring your product to fruition.

Conveniently, Google provides a list of ODMs (Original Design Manufacturers. Companies that design and/or build a product to another company's specifications) and Partners on their Partners page, under the ODM tab.

It's a surprisingly common approach. A lot of smaller OEMs (and some larger) will lean on a partner in this list. Consider HMD for example, one of many OEMs known to use Foxconn. Many smaller OEMs will design and build their devices with a certified ODM entirely, outsourcing the full operation in the knowledge an ODM with an agreement will know how to get a device designed, built, and certified in-keeping with the requirements of Play Protect certification.

Or in theory, at least. In reality knowledge varies dramatically and partners need to be vetted.

Once an organisation is large and dominant enough in the market or a particular manufacturing niche to justify it, they can discuss with Google the prospect of signing their own agreement.

How long does certification last?

This gets a little complicated, as it varies by hardware, licence, and whether it's a new device or upgrading from an older version of Android.

Additionally, there are three states for approval windows:

Open: When approval for an Android release begins
Closed: When approval for an Android release can no longer be submitted
Expired: When an approved version of Android can no longer be preloaded in-factory

For new devices, if you're only considering when one version of Android can no longer be preloaded onto manufactured hardware, the baseline is about two years for handsets & three years for tablets/Android Go; if a device meets the criteria, it may benefit from 5 years on the EDLA.

But that depends on when in the Android OS version lifecycle you certify the device!

Take Android 13 for example, which was released in August 2022. The approval window for 13 opens in August 2022 since that's the public release date. You can then submit a device for certification for up to around 18 months (a year longer for EDLA) before Google closes the approval window to new devices.

If you then factor in the dates of expiry:

Handsets: Late '24
Tab/Go: Late '25
ELDA: Late '27

A handset could in theory attain certification at the beginning of 2024, and have its approval expire in under 12 months.

From the month following expiry, it is no longer permitted to preload that version of Android on newly manufactured devices. Those in stores, on a pallet sailing the ocean towards retail stores, or otherwise already departed from the factory aren't impacted by this, it just means no new devices can be manufactured with Android 13 preloaded.

That isn't a long time to crank out hardware, there's more flexibility with tablets and EDLA, but there's more here to consider.

If you wish to continue shipping your hardware after a respective expiry, you'd need to ensure you upgrade from - in this case - 13 to 14 within the upgrade window, at this point your device would be considered existing rather than new. The approval window for version upgrades usually closes 6-8 months after the current Android version approval expires, so offers additional time to certify after expiry. For handsets you'll be playing with fire if waiting that long to upgrade though, since expiry for the upgrade would be a few months away following certification if consistently leaving it to the last minute. Tablets and EDLA, not so much.. but still less time between upgrade sprints than if you keep on top of version releases.

This is one of the larger challenges for smaller OEMs; keeping on top of release cycles is no mean feat, and it's easy to start falling behind when issues arise without the people and resources to dedicate to it.

What makes the EDLA different?

Reading above, you may have picked up on the fact the EDLA has a much wider window from approval to expiry, but that's just the tip of the iceberg.

EDLA is a more recent GMS licence and stands for Enterprise Device License Agreement. It was introduced to address challenges faced by OEMs building devices intended for enterprise:

Non-standard form factors
Devices with much longer support lifecycles
Industrial/restricted environments

I go into more detail on EDLA with this article discussing a device that meets the intended use case perfectly.

In summary though, the EDLA extends an olive-branch to OEMs, partners and, importantly, customers, that struggle with the inflexible requirements under the consumer-targeting licence agreements that have existed for many years, and helps make Android a competitive platform to existing embedded and IoT platforms that dominate the ecosystem today.

Is it perfect? Absolutely not. There are still many, many limitations in place with enterprise devices today mandated by licence requirements that haven't been accommodated by the EDLA, but its existence signals effort to improve this device segment from Google and I look forward to its continued evolution.

What happens when certification does expire?

Eventually as an OEM you will make the decision to no longer provide major Android version upgrades, and both current version expiry and the upgrade approval window for the next Android version passes.

(Technically nothing prevents providing a multi-version jump, ie. from 12 to 14/15, but that's not very common).

It happens all the time, but doesn't necessarily prevent the continued software & security support of a device; Android devices are also subject to security updates after all, and often for years-longer than the commitment to major version upgrades.

These smaller updates targeting security and critical issues ensure devices in the market remain fit for purpose, even if they no longer benefit from new features and functionality.

As an OEM, there's another major milestone in maintaining security updates for an in-market Android device: when Security backporting ends.

Google provides backporting for CVEs and occasionally other patches for a period of three years from the introduction of an OS version. That means every patch they commit to AOSP, they undertake the necessary work to port it to the older Android version codebases, and from there OEMs can pull them down to implement in their builds. There's a little more complexity to the process than this, but this gives you an idea of what happens.

After three years, Google calls time in order to focus on newer Android releases and no longer does this work, causing the flow of patches to stop.

At this point the OEM must either:

End regular support for the device, and security updates cease.
Take the code committed by Google from a newer Android release and undertake the work themselves to implement the code changes into their own builds, test, and release.

By the time this decision is due, the device will often have been in the market long enough to justify calling time on support, however and particularly for enterprise devices, larger OEMs often have the staff and knowledge available to undertake the necessary work to continue supporting a device on an older version of Android for a significant amount of time.

And the cycle continues

Considering an OEM has multiple devices on the market at any one time, you can imagine this is quite the undertaking maintaining a suite of products across multiple major Android releases, but this is the nature of the ecosystem.

Is there anything you'd like to know about Play Protect Certification not covered here? Give me a ping on LinkedIn or contact me.

Mute @channel & @here notifications in Slack

2023-11-14T00:00:00Z

I've been using Slack a good deal more recently, and much like Teams' @everyone and Google Chat's @all, Slack's @channel and @here is a recipe for notification-geddon that's significantly overused in a lot of communities.

Did you know, however, you can turn these notifications off? Unfortunately it's a channel-specific change, but here's how you can do it:

Right-click on the channel
Click Change notifications
Under Mentions, uncheck Also include @everyone and @here

Here's a GIF:

Alternatively, here's how to do so through channel settings directly:

Finally, if the thought of going through each channel and setting this is too burdensome (I don't blame you), reach out to your workspace admin to request these are restricted across the Slack community as a whole.

But what about turning the tags off all together? If you're on the right plan and you're a channel manager, admin, or owner, you can (and should!). Here's the KB doc.

A guide to raising better support requests

2023-11-05T00:00:00Z

Dear support,

There is a problem with my devices, they won't load my app.

Does this look familiar? How about:

A customer reports their remote control connection is unstable, and performance is unreliable. It has been like this for some weeks.

Unfortunately these two examples are inspired by some of the many support requests I've observed in the last few weeks alone, with many more examples like this over the years I've been supporting customers and internal teams.

Why are these examples of weak support requests? The information provided is just enough to suggest there's a problem, but doesn't offer near enough of what is needed to debug the issue and instead requires the assigned support person, or team, to reach out to gather more information in order to be able to start troubleshooting.

In the first example, the support team will know:

There's an app
More than one device is affected, potentially. It's not confirmed but can be assumed based on the wording and still needs validating.

They will not however know:

How long it's been happening
The app in question (package name, version, recent changes)
What policies may be in scope to check for misconfigurations (in case of an EMM-enrolled device)
How the app is distributed
The devices in question (make/model/OS version)

.. and much more contextual information, all of which the support team will be forced to reach out to attain, adding unnecessary back-and-forth before the issue can even be addressed.

In the second example, support will know:

The customer is using a remote control product
It's not a one-time occurrence

But won't know:

What unreliable means; does the connection fail? Is it slow? Does it drop frequently?
Device(s) info (make, model, OS version)
Number of devices affected
Who the customer(s) is
If there are errors shown
Steps to replicate the issue locally
Environmental information, such as how devices are connecting to the internet

.. and more again.

Why does this matter?

By choosing to raise tickets similar to the examples above, it is guaranteeing the time to resolution for a problem will be considerably longer, more drawn-out, and require more effort on both ends. For internal teams communicating issues in this way it additionally demonstrates a lack of care and/or respect towards your colleagues' time and workload.

The aim of raising a support request is to resolve an issue, whether that's a problem in production, a resource request, or anything else related to a block associated with a product or service at a personal or company level.

Likewise, the aim of the support team is to resolve requests as quickly and efficiently as possible; they're supporting many customers and/or end users in most circumstances and having requests sitting unresolved negatively impact SLAs, KPIs, and often reflect poorly on the assigned support team or team member.

The goal then for both sides of the request is the same, and one of the most effective ways to ensure a request is resolved with minimal friction is to reduce back-and-forth with support; that doesn't mean pre-empting any possible question a support team member could possibly have, rather it's about putting in more than the minimum effort when raising a request that offers greater insight into the request at hand for a faster resolution, and a win-win for both sides.

So in contrast to the above, let's look at suggestions that can improve support requests. The following has a lean on mobility platforms and systems, but can naturally be adapted to other products and solutions

Provide information upfront

Here's your basic checklist when raising an issue with support that will substantially reduce the delay to debugging:

A concise description of the issue
How long it has been happening
How many devices are affected
Any specific tenant/platform/policy details to identify you
How many customers are known to be affected, and customer names (for MSP/internal support)
Device identifiers (serial number, IMEI) of affected device(s) support can opt to focus on
Device information, make, model, OS version, OS build number. Provide more than one if details aren't consistent across affected devices
Affected app information, package name(s), app versions (for app related issues)
Replication steps
Any scoped policies or configurations applied
Logs, pictures, video of issues respectively

An example of a support request offering some of the above information - taking the above first example of a submitted issue - could look like this:

Dear support,

I have this week deployed a new app via MDM, however it is not showing up on my devices.

The policy I am using is App deploy 1 and my tenant is Customer tenant 3. The devices targeted are a mixture of Android 11 & 12, I have checked and so far the app is not present on more than 10 devices, including the following IMEIs I have with me:

12345678901234
12345678901235

The application in question is my Package, a private application uploaded to the iFrame. I haven't had this issue with other applications from the Play Store so I'm unsure of why this one is failing. The policy saved fine and the app is showing pending install status.

When considering the above, the contrast between the first and second version of this support request is stark. From the revised ticket the support team will know:

This is a new issue
It's affecting multiple devices, two of which are provided for review
The customer environment, policy, and application names are provided for immediate troubleshooting
The application is a private app, and is an exception to the norm of public apps being used
The EMM is showing the app is assigned, but devices are not installing

With the addition of a few sentences and additional contextual information, the support team will have all of the information needed to start immediately troubleshooting, negating the need to ask additional questions, or set up a call for more info.

The only thing that would improve the above would be the addition of a bug report, since replication steps and video/image aren't relevant in this instance, though understandably fetching logs from devices may require assistance over a call, or at a minimum a detailed walkthrough.

Naturally depending on the type of issue there may be a need for more, or different, information. The remote control issue referenced in the above second example for instance would typically additionally require environmental information, such as:

Type of connection used (Wi-Fi, cellular)
Connection quality
- Distance from router for Wi-Fi
- Inside a building or outside for cellular, signal strength (bars shown, or dBm)
Can it be replicated on another network?
Can it be replicated with another device?
Average session lengths, if successful
Replication steps to any reliable session end
Are there firewalls in place, or network QoS policies active?
Load the device is under normally, as a lower-spec device may struggle casting its screen while performing other activities
Are prompts being received? In Kiosk deployments, apps may not be able to display over the locktasked kiosk environment, or the notification bar may be disabled

All of this information isn't expected in an opening issue request, but considering any of this for inclusion will significantly help in reducing the back-and-forth required, so as the requestor of a support ticket, the more information you provide upfront, the sooner an issue can be resolved.

Be reasonable with urgency

Is your request urgent? But is it really?

It's both tempting and commonplace to see relatively minor requests raised as urgent or critical.

The saying goes if everything is urgent, nothing is. If all requests carry an urgent or critical priority status, the efficacy of self-set priority will fade fast, and will potentially impact the speed at which your requests are addressed.

Is the issue local to just yourself, or not replicable on multiple devices? It's likely not urgent, as it doesn't impact overall business function or productivity.

Has a system update taken a store, or region, offline? That'll be urgent, or critical, depending on the defined SLAs in place with the support team.

Keep in mind, the priority is not a substitute for poor time management, always aim to raise requests in due time when taking into consideration the SLAs offered by the support team.

You probably don't need a call

One of the most common occurrences I've seen in recent years is the requirement from the support requestor to have a call to discuss the requests for further information needed by the support team. Further information being that which aims to obtain the missing information from the request that hasn't been provided upfront.

What typically follows is support setting up a call with the requestor wherein the support team simply asks the questions once again through a different medium, and notes down the answers themselves.

Obviously there are situations where calls are legitimately seeking assistance in obtaining the requested information (such as how do I find the OS version for the device or how do I collect device logs?) and these are wholly justifiable.

But if your intention is to defer the questions asked until they're asked again over a call, this is once more going to significantly delay how quickly your issues can be resolved.

Take the time to read the request for information, and offer best-effort answers based on your understanding for each question; even if only half of the questions are answered and a call is needed to cover off the remaining with additional context or explanation, you may have already provided enough information for the issue to be identified and again saved all sides time and effort where it doesn't need to be expended.

Timely responses help everyone

If you're raising a support request, be prepared to engage with the support team in a timely manner.

From the perspective of the support team, requests raised with little information and extremely slow responses are the worst. Not only can the request not be solved, but the support team is then burdened with adhering to SLAs and non-response processes that mandate multiple follow-ups for information, and this may be triggered multiple times through the lifecycle of a request.

By raising a request and then treating it as your lowest priority, everyone suffers.

Use the appropriate channels

Support teams may have a process in place for receiving requests through a multitude of channels, however often sending Teams/Slack/GChat messages directly to individual support personnel isn't one of them.

It's certainly one of the easiest methods to get the attention of a support team member, but it has the potential to cause issues later.

At best, it'll be a distraction, at worst the issue won't be properly logged and tracked, meaning there will be no formal request logged for the issue; this can present as a problem later if the issue requires retrospective review or similar issues exist and the team goes looking to reference.

Do both sides a favour, log the request through the company-approved channels, and keep communication there.

Go forth and raise better requests

Armed with the above advice, and a little insight from the other side, I trust you'll be able to create support requests both you and the support team you're raising to will benefit from. Just a few small changes to the approach of asking for help will make a world of difference.

Good luck!

Ask Jason: How should we manage security and/or OS updates for our devices?

2023-10-24T00:00:00Z

Damien asked, through the Mobile Pros Discord community:

We have approx 5000 COPE devices with just over 4000 of them Samsung all managed using WS1 UEM. Should we use e-FOTA? If not what? What about BYOD devices? Our security team is advising us to cut access to those who don’t have a patch of 2 months old. Our minimum version is OS 12 but this would mean cutting the access to quite a few devices whose manufacturer is no longer rolling out patches! I can do this via compliance policies on WS1 but I find this a bit extreme. [..] Jason, not sure if you can weigh in here? 😉

This is such a common question, and rightly so because it's one of those subjects that tends to involve more than one part of the business, with various understandings, opinions, and perceptions on what's secure across the whole mobility estate, not Android alone.

Jason says

For your question it's a little varied by use case but most popularly day to day for updates I tend to use the windowed update policy to push app and system updates overnight (or off the clock), and occasionally check in to see if anything is struggling.

Not being a Samsung house for the last few years I've not leaned on e-FOTA [recently] but I absolutely would for major update management (or rather, postponement) for testing, since the 90 days AE offers comes with caveats. It has many more features than typical OTA management as well I'm sure you could get used to :)

For cutting off, 2 months doesn't even permit the normal 90 day update cycle many OEMs offer. Perhaps over 6 months isn't unreasonable, but a non-supported device should be considered in the context of its supported counterparts. What was patched in 6 months after EOL? Probably nothing critical, possibly nothing overtly vulnerable. OEMs can technically get away with 12 months of SMR from new, and then only patch critical, which may be 10 a year, or none in 3. An arbitrary period of time doesn't make the best sense in that regard particularly for BYOD where your biggest concern is breaching the work personal divide, and any vuln capable of that would be talked about. You'd be ruling out almost brand new devices after just a year - in an extreme example.

Instead, I would (and do) monitor CVEs for impacting vulnerabilities and make a call to cut off devices that don't have the associated SMR once available. It's a monthly check but honestly compared to the support burden of arbitrary blocking of devices based on a number plucked from the sky it's my preference.

Fully managed estates without the additional protection of profile isolation I err to the side of replacement at EOL. Exceptions exist for this too though, kiosk devices fully locked down with no user access will be inherently less vulnerable than knowledge worker devices; there's a sliding scale of risk to consider based on use case as I mentioned, and that comes down to the risk appetite of the organisation.

Pixel 8 series launches with 7 years of software support

2023-10-05T00:00:00Z

Google yesterday announced the Pixel 8 series, something I almost missed being wholly occupied with the release of Android 14 and all the new enterprise docs and features that came with it. (You can see what's new here and find my notes on articles and such shared yesterday here).

There are plenty of new features exclusive to the model, but the biggest announcement as far as I'm concerned is that of software support.

Second only to Fairphone's commitment just a few weeks ago of up to 10 years of support for the Fairphone 5, Google as one of the larger OEMs on the market has come very close with a commitment of 7 years, both major OS and security patch support is guaranteed here, meaning the Pixel 8 should find its way up to Android 20/21 by 2030.

Today we announced our commitment to providing seven years of software support for Pixel 8 and Pixel 8 Pro, including Android OS upgrades, security updates and regular Feature Drops. That means your Pixel 8 and Pixel 8 Pro will be supported all the way into 2030.

- Google

The announcement post is not quite explicit enough as the above quote could be later construed to mean a mix of both OS and security patches, allowing Google to stop at Android 18 if desired given each major release benefits from CVE backporting for 3 years (as it stands in 2023, at least), however with further digging their own documentation offers a black-and-white commitment of both OS updates and security updates until 2030:

Phone	Guaranteed Android version updates until at least:	Guaranteed security updates until at least:
Pixel 8 & Pixel 8 Pro	October 2030	October 2030
Pixel Fold	June 26, 2026	June 25, 2028
Pixel 7a	May 8, 2026	May 7, 2028
Pixel 7 & Pixel 7 Pro	October 2025	October 2027

As you may notice from the above, this is a reasonable increase in support over previous devices, including the just-released Fold. This achievement looks to be linked to the new Tensor G3. Tensor, Google's in-house chip, offers them end-to-end control over the hardware they ship, and the support they provide. This is in contrast to many OEMs on the market reliant on the likes of Qualcomm and MediaTek, vendors with many chipsets available and little financial incentive to offer extended support on most of them (exceptions to this exist, see again Fairphone's use of the QCM6490).

https://www.youtube.com/watch?v=T-s34hql1ls

While we're looking at software updates, Google took the opportunity to announce a change to how they release updates:

As part of this effort, our security updates, bug fixes and feature updates won’t roll out on a specific day each month. Instead, we’ll deploy updates as soon as they’ve completed the necessary tests to ensure they improve the experience for all Pixel customers.

- Google

This is good news for Pixel customers. Though it may appear as if guaranteed zero-day updates are being dropped, in reality Google are foregoing a rigid schedule in favour of better-tested, more reliable updates overall, they may just not arrive on the same day every month.

Finally, Google also promise component availability for the full period of support, ensuring for as long as Google provides updates, customers and organisations will be able to repair their devices. That's a pretty big deal.

Another nail in the coffin for 3 years of support

To save rewording what I wrote in the Fairphone article:

OEMs offering just 3 years of security updates are basically offering one, maybe two OS version upgrades at a push, and just enough patching to tick a box for minimum viable lifecycle. For consumers with more aggressive hardware cycles (carriers offering annual upgrades, younger generations/enthusiasts swapping more often to keep up trends) it can be argued the effort to reward isn't too skewed, since beyond 3 years of security updates you're catering to a much smaller market. But for enterprise? Not even close.

Organisations for years have far, far outrun this lifecycle, and have suffered the higher TCO associated with replacing devices out of security update support to protect their environments. It's somewhat improved over the older standard 18 months as a typical EoL for software support (around the time MADA started referencing it), but it's long been desired to get this well up towards the 7 year mark.

- Fairphone raises the bar with commitment to Android updates

As it happens, well up towards the 7-year mark is exactly where the 8 series sits, making it a pretty compelling choice for enterprise use. If they confirm decent (3+ year) hardware availability also, to allow organisations to purchase more as they need them rather than changing to a newer model, that'd take the cake.

Android's work profile behaviour has been reverted in 14 beta 5.3

2023-09-07T00:00:00Z

Earlier this morning I noted the What's new for enterprise in Android 14 doc (now under a non-preview URL 🎉) has removed references to the work profile changes I wrote about in my previous docs and articles (1, 2).

Incidentally, I also had a minor beta update (5.3) pending across my Pixels.

Coincidence? No. Given the timing I assumed there may be a link between the two and thought I'd compare the update with the previous beta release (5.2) just in case. It didn't take long to confirm the change.

In UPB5.230623.006 (Beta 5.2) the following is shown when the work profile is on:

jasonbayton@Jasons-MacBook-Pro platform-tools % ./adb shell dumpsys user | grep -A 3 "Work profile"
  UserInfo{10:Work profile:1030} serialNo=10 isPrimary=false parentId=0
    Type: android.os.usertype.profile.MANAGED
    Flags: 4144 (INITIALIZED|MANAGED_PROFILE|PROFILE)
    State: RUNNING_UNLOCKED

.. and paused:

jasonbayton@Jasons-MacBook-Pro platform-tools % ./adb shell dumpsys user | grep -A 3 "Work profile"
  UserInfo{10:Work profile:10b0} serialNo=10 isPrimary=false parentId=0
    Type: android.os.usertype.profile.MANAGED
    Flags: 4272 (INITIALIZED|MANAGED_PROFILE|PROFILE|QUIET_MODE)
    State: RUNNING_UNLOCKED

This is the new behaviour, wherein the work profile remains running in a suspended state.

In UPB5.230623.009 (Beta 5.3), I see this for on:

jasonbayton@Jasons-MacBook-Pro platform-tools % ./adb shell dumpsys user | grep -A 3 "Work profile"
  UserInfo{10:Work profile:1030} serialNo=10 isPrimary=false parentId=0
    Type: android.os.usertype.profile.MANAGED
    Flags: 4144 (INITIALIZED|MANAGED_PROFILE|PROFILE)
    State: RUNNING_UNLOCKED

.. and paused:

jasonbayton@Jasons-MacBook-Pro platform-tools % ./adb shell dumpsys user | grep -A 3 "Work profile"
  UserInfo{10:Work profile:10b0} serialNo=10 isPrimary=false parentId=0
    Type: android.os.usertype.profile.MANAGED
    Flags: 4272 (INITIALIZED|MANAGED_PROFILE|PROFILE|QUIET_MODE)
    State: SHUTDOWN

Both SHUTDOWN and -1 is associated with the older behaviour on Android 13 and lower.

Heads-up if you're trying this yourself, it looks like some devices on 009 still appear to show the new behaviour. I'm able to replicate on two devices, but one Pixel 7a I have doesn't show a change. Let me know if you test this, what you see yourself!

It looks like beta 5.3 has therefore removed the new work profile behaviour, and reverted it back to how it was with Android 13. The release notes for 5.3 don't specify this as a change:

Fixed an issue where apps crashed in some cases after a CallStyle notification was posted.

Fixed various issues that could cause call or carrier service interruptions.

Fixed an issue where the system was using an inefficient path when placing CPU restrictions on apps running in the background.

Fixed issues with SurfaceFlinger that were causing a loss in system performance.

Fixed an issue on Pixel Fold and Pixel Tablet devices where the taskbar sometimes turned invisible while interacting with it.

Fixed an issue on Pixel Fold and Pixel Tablet devices where the animation on animated wallpapers stuttered when launching apps.

Fixed an issue on Pixel Fold devices where the interface layout was misaligned while customizing the Home screen.

Fixed an issue on Pixel Fold devices where the clock on the lock screen was flickering while animating.

Fixed various issues that were impacting system stability and performance.

But it's probably bundled in with the various issues impacting system stability and performance, as these things tend to be.

Why? I can't say. There's no public reasoning published; it's simply just been removed from public docs. Given this is so late in the development cycle of 14 (it was due any week now, before being potentially pushed back recently), it was clearly considered important enough to remove.

Perhaps we'll see it in Android 15, or sooner in a QPR - quarterly patch release - instead. Notification-geddon will continue for now, but if the call was made to pull it, I suspect it's worth it for the team to get the new behaviour just right.

As a side note, obviously this is the risk with documenting beta features.. they can vanish on a whim, and so I'll have to update my other linked docs to reference the change. It's not easy to balance offering advanced notice to organisations for potentially breaking changes with waiting until actual release, though in future I may err on the side of public availability given few organisations are pushing GO with major releases on day zero.

Fairphone raises the bar with commitment to Android updates

2023-08-30T00:00:00Z

Today Fairphone announced their newest smartphone, the Fairphone 5.

I've been a FP4 user for the last year, and had an FP3+ before that, the FP5 looks like a solid upgrade both in terms of spec and the headlines Fairphone are making with this new device.

They're well known for their focus on sustainability and longevity with a history of devices receiving support for several years - the FP3 (2019 on Android 9.0) just received Android 13, it's 3rd major OS version upgrade over 4 letters (they skipped 12), the FP2 before it saw it's final update on Android 10 in March 2023, 8 years after launch on Android 5.0, Lollipop.

Indeed, even with the odds stacked against them, and loss of support from chipset vendors - the FP3 SOC (Snapdragon 632) didn't support anything over Android 12 and required they take development in-house to keep the updates rolling - the Fairphone team continue to go above and beyond to maintain their growing catalogue of devices.

The brand new Fairphone 5 takes this commitment even further, as the first device Fairphone have guaranteed to support for at least 8 years, with the potential for longer still.

How are they achieving this?

At this point the FP team have more than a decade of experience building Android devices, so some of this commitment is coming from a place of understanding the OS intimately, but they've definitely been given a bit of a leg up by Qualcomm this time around in the form of the QCM6490, an LTS chipset typically more at home in the rugged/dedicated market powering Zebra, Honeywell, and other enterprise-grade devices.

Qualcomm offers support on their chosen chipsets for several years more than their consumer chip offerings (such as the 632 in the FP3), allowing the Fairphone team to leverage official chipset vendor support for many more years, in theory. It's of course yet to be seen what Android will look like by 19 and the implications this will bring for Qualcomm once the relevant GRFs (Google Requirements Freeze) expire, but FP are certainly building on a solid foundation.

How does this support stack up?

It is - from what I can see - the longest commitment of support for a consumer Android handset on the market. In a distant second place lies Samsung with 5 years of guaranteed security updates and 4 major OS version releases (later also adopted by OnePlus), Google Pixel with 5 years of security updates but 3 guaranteed OS version upgrades, and Motorola, Nokia (HMD Global) offering 4 years of security updates. Many other OEMs settle on 3 or fewer years of support.

Samsung declared themselves setting the new standard in support longevity for their select models, I think Fairphone is defining a new era.

Are 3 years of updates still relevant?

At this point it honestly comes across as a bare-minimum commitment.

OEMs offering just 3 years of security updates are basically offering one, maybe two OS version upgrades at a push, and just enough patching to tick a box for minimum viable lifecycle. For consumers with more aggressive hardware cycles (carriers offering annual upgrades, younger generations/enthusiasts swapping more often to keep up trends) it can be argued the effort to reward isn't too skewed, since beyond 3 years of security updates you're catering to a much smaller market. But for enterprise? Not even close.

Organisations for years have far, far outrun this lifecycle, and have suffered the higher TCO associated with replacing devices out of security update support to protect their environments. It's somewhat improved over the older standard 18 months as a typical EoL for software support (around the time MADA started referencing it), but it's long been desired to get this well up towards the 7 year mark.

Fairphone appear to know this; they've partnered up with the likes of Everphone in some markets offering their devices under a DaaS (Device as a Service) model, and have a page dedicated to business for everyone else. They've also put devices through Google's Android Enterprise Recommended validation, so they have a good grasp of what needs to be done to get on the radar.

Organisations get to benefit not only from a device with an immense software lifecycle, but one that comes with the added sustainability and environmental benefits on top, as well as best-in-class repairability for when the inevitable happens.

There's plenty more scope to improve their positioning in enterprise as a go-to vendor, things like custom management capabilities (OEMconfig), complimentary solutions akin to Samsung's eFOTA, software customisation, and more, but for the moment - in just software longevity alone - they're making a compelling case.

I look forward to getting one on test!

Product files: The DoorDash T8

2023-08-14T00:00:00Z

Welcome to Product Files, a series of articles that touch on some of the more interesting aspects of running a product organisation for the last several years.

As this series grows, additional links will show up here:

Google recently published a blog post and video by the DoorDash team that covered how the T8, supported by Android Enterprise's suite of management solutions, provided some pretty respectable achievements for them:

As the T8 slowly edges towards the end of its anticipated extended lifecycle and customers begin moving to newer options, I thought I'd take some time in this article to dive a little deeper into the product development of the RHINO T8 and some of the product decisions I made during the development of the tablet that ultimately made it attractive to DoorDash, becoming one of their most-deployed units today.

As I delve into some finer details of T8 development, I'd like to point out this is a device that began its lifecycle in 2019. Some of the features that made it notable at the time are simply par for the course in 2023. That said, I'm still very happy with many of the decisions made that contributed to the device it became.

What is the RHINO T8?

I touched on the T8 back in 2020 with my Building Android devices article. I'd recommend you take a gander at that if you haven't yet as I provided a good deal of relevant information as to where RHINO came from and the longer-term plans for the brand and ecosystem.

The T8 was part of the first generation of RHINO devices we built from the ground up, something that would not happen again with the recent gen 2 devices as the company opted instead to re-tool products already available in the market through ODM partners.

That said, here it is:

It looks, behaves, and mounts like a standard 8" tablet available from many OEMs in the market today, and especially today in fact, as the ecosystem has filled to the brim with tablets in the last couple of years; far more so than in 2019 when the T8 project kicked off. But that was the intention.

Developing the product

In strategising what RHINO should be, it was ultimately decided the RHINO brand would be used as a readily-available, widely-applicable showcase of what the company could produce; to act as a springboard into more complex and bespoke projects that could (or not, if bespoke was preferred) leverage these devices as their base. This achieved two objectives:

Customers could see and feel the build quality of a device in their hands rather than relying on the word of a sales rep. It cannot be understated the difference this has when asking a customer to commit hundreds of thousands of pounds for a product they won't see for 6-9 months.
For smaller projects the existing tooling and internal designs could be mostly or entirely reused, significantly reducing time to market

One additional benefit for the company was having own-brand stock available for customers simply wanting to buy a device, and as a value-add we were able to pop the company logo of any customer on the tablets for larger orders, giving a bit of organisational customisation most mainstream OEMs don't offer.

The T8 and it's larger sibling, the C10, were the first tablets I launched under the RHINO brand.

Going in to product development for these tablets, the key focus was to develop devices suited to enterprise; this meant considering aspects of use they wouldn't be subject to if consumer owned (and respected), even if MSRP wouldn't eventually be as competitive as an equivalent competing product in the consumer space (think Lenovo, cheaper Samsung tablets, etc). This mindset drove some key requirements for the device:

Ease of repair
Tough and resistant to unfriendly usage
Repellent to moist &/ corrosive environments
Long term component support
Resistant to battery ageing

Again, there's nothing groundbreaking here, and OEMs at the time were well-versed in similar requirements for their own offerings (H/T Zebra, Honeywell, Panasonic, etc), but almost across the board they were rugged devices and didn't aim to target the pro-sumer hybrid of consumer device with enterprise features.

But what does this mean in terms of product decisions?

Ease of repair

Some of the earliest samples and reference products that came from our manufacturing partner during initial stages of development painted a stark picture of what cheap hardware looked like when the only goal is maximising profit:

Glue blobs galore
Soldered components
Single-use clasps and anchors in the housing that would wear out after one to two disassembles of the unit, which was very easy to pull apart
Loose wiring
Cheap CMF (colour, materials, finish)
Zero modularity
.. and so on

I've pulled apart Android devices (amongst others) aplenty over the years and have seen all of these in use in excess. These devices develop faults and unless you're willing to pull out a soldering iron they become paperweights. By comparison, the exposure I've had to what flagship OEMs have done for internal design - especially thanks to channels like JerryRigEverything and his passion for tearing devices apart so the rest of us don't have to - gave me more than enough inspiration to find a good balance between ease of access, modularisation, and appropriate, re-applicable adhesives.

When it came to starting hardware development for the T8, the first few rounds of E/DVT (Engineering/Design Validation Testing) saw:

Soldering components swapped for push-fit or lego-style-connectors
High-wear items like the USB-C port and buttons either reinforced or modularised to their own sub-PCBA for ease of replacement
Loose wiring replaced by ribbon cabling
Mild adhesives used for holding the battery in place (with pull tabs) and display to the housing

During this process, I went through more than 10 iterations improving the rigidity of the unit from the first EVT, and ensuring the back wouldn't pop off too easily since it wasn't glued on. Budgetary and time limitations prevented more development in this area; but if I was doing it again today I'd have aimed to make the back cover predominantly secured by screws rather than of clips/clasps, since the latter naturally wears out over time and particularly for customised orders, new printed back panels would have to be made to order when they did wear out, which is a 30-90 day wait.

One final choice was opting not to bond the digitiser and LCD to one another; many OEMs do this with most devices today, which is in effect gluing the touch panel and the display underneath it together to make one item, the display assembly. There are arguments for doing this and it's generally a good thing, not least because the resulting picture can look much better without an air-gap within the assembly, and it also prevents dust and dirt from getting in there. That said, it also increases the cost both in terms of manufacturing cost to pay a factory to do this, but also when it comes time to repair a broken assembly; you're forced to replace the entire thing, or at least purchase the whole assembly, as even if you were to spend the appropriate time with a heat gun to try to separate them, the manufacturer will supply a bonded replacement.

With all changes in place, repairing a T8 became very quick & straightforward to do. Exactly the words repair centres and in-house maintenance teams like to hear when units come in with something broken.

Tough & resistant to unfriendly usage

In the process of improving repairability, the whole unit benefitted from greater protection from unfriendly usage by, for example, ensuring flex was minimised if the unit was crushed, twisted, or bent. Flex can be a major concern for a screen, since glass doesn't take to it near as well as other materials.

In addition to this I spent several weeks with my team reviewing options for the outer finish of the unit, aiming to find a balance between something that looked decent, but also held up against knocks, scrapes, drops, and so on. On the first few batches of the T8 this was a rubberised finish on the housing, and it held up quite well in the target environments as it:

Didn't really show marks
Could be wiped off easily
Offered better grip when holding it directly

In later production runs with a new manufacturing partner we opted to switch to a textured paint coating instead, offering most of the same benefits but more likely to hold up against harsher cleaning agents and such, as considerable use could see the rubber eventually wear away.

Then there were other design considerations, like the slightly-raised border that surrounds the screen. This is dual-purpose both to absorb shock from drops (along with the rest of the mostly-plastic frame) and keeps the screen ever-so-slightly further from an object that might otherwise impact it.

Repellent to moist &/ corrosive environments

Knowing the tablet was destined - even during the product development phase with interested customers that predate DoorDash - to land in kitchen and high-humidity environments, but not wanting to fully seal the device for an IP rating (a trade-off for repairability), we dipped the internal components in a moisture-resistant coating.

The tablet doesn't become impervious to moisture with this approach, as dropping it into water or using it during a heavy downpour may allow water to sit within the device and eventually cause a failure, but for humidity, and similar moisture devices may have to deal with, this worked.

Corrosive, in this context, is what is corrosive to a PCBA - impurities, salts, the like. I couldn't save the unit from an acid dip and keep it within a budget!

Long term component support

Early on in the company's history a partnership was formed with MediaTek, as we pivoted to enterprise MTK's AIoT division became our go-to for chipset selection that guaranteed long-term support & availability. The MT8765 in the T8 is by no means a powerhouse, in fact I think it's fair to say it wasn't the best choice of chipset in retrospect due to the performance issues I've seen over the years with it. For Android Go it would have been absolutely fine, and in truth the T8 would have made for a great Go device given the predominant use-cases for it, but we certified it for full-fat Android in the beginning and stuck it out.

That said, it's taken us from 9.0 to 12, with potentially longer support possible if desired. Since The T8 is coming up on 5 years in-market, that need is simply not there.

Outside the chipset all the standard multi-source component procurement was done by the team accordingly, so we rarely suffered component shortages even during some particularly tumultuous times for the global supply chain in the last few years; even now 4 years later and running another batch of 10s of thousands of units through production component supply has been pretty reliable.

Resistant to battery ageing

One of the more active requirements, especially from customers coming from consumer tablets they'd had docked to a power supply for 6+months and suffered battery ballooning, was to handle power management intelligently.

What I wanted to be able to facilitate from the get-go was a complete power management solution that allowed customers to:

Boot & run without a battery connected (when connected to a power cable)
Bypass the battery and run directly from power cable with the battery installed
Configure OEMConfig APIs to control this via software, if it wasn't feasible to interface the hardware

Unfortunately this quickly overshot time & budget requirements (but I did take some of this over to the M10p!), so I had to settle for a fully-software smart monitoring solution that would detect for how long the T8 had been plugged in, the voltages and cycles of the battery, and alter the charging profile accordingly. This required engineering coordination between the Android framework folks, kernel folks, and the engineers responsible for the PMIC design.

From a UX perspective, it also introduced some scenarios that customers (or rather, their users who didn't read manuals) raised concerns about. When the tablet had been on charge for more than 24 hours straight for example, we allowed the battery to discharge intentionally to align with the new power profile. Unsurprisingly support tickets did get raised about devices not charging. There were also tickets raised about this solution not kicking in where customers would turn the power off to the tablet when their stores/offices/spaces closed, and back on in the morning; the solution simply wouldn't ever kick in because it wasn't permanently (or >24h) on charge.

So it wasn't infallible, and accordingly we did see some genuine battery failures in the wild, but overall it's been a reasonably insignificant number compared to the number of devices shipped overall.

The Android journey

This is not so related to DoorDash choosing the T8, but I think it's interesting to cover since it's relevant to the article.

The RHINO promise has been bloat-free, vanilla Android since inception.

Beyond Google apps and a couple of OEM-specific services (activation server, OEMConfig, chipset support), and some OEMConfig APIs, my flavour of Android is as light and clean as it comes.

To achieve this was no insignificant undertaking as working with external engineering houses well-versed in the MediaTek turnkey builds (these are builds of Android the chipset makers offer with integrated support for the chosen chipset. Qualcomm, Rockchip, and others offer the same, often referred to as BSPs.) meant the only option for building Android I could get was to lean on these pre-made builds rather than building from AOSP.

Again as with many things in product development there are pros and cons. The pros for a turnkey/BSP build are normally time to market and little need for configuration. The cons come in the amount of time you choose to dedicate to removing bloat the chipset vendor includes. Engineering apps, battery optimisers, sound enhancers, carrier optimisation apps.. you name it, the vendor has an app for it, and it's likely included. Then come the tweaks to UI and defaults set - Icon shapes, default radio behaviour, navigation setup, and so on.

From the very beginning I built out a version-based requirements doc that combined a mixture of both best practice security and enterprise-friendly defaults, laced with some personal opinions on how Android should look, feel, and behave in line with examples set by Google and other OEMs offering vanilla builds. The turnkey builds were a fair departure from what I'd consider RHINO ready and so there was always a fair amount of work to do, even without custom development of OEMConfig and other bespoke functionalities.

Still with all the reconfiguration required it remained faster than building AOSP from scratch, though given the choice I'd prefer building from AOSP. Swings and roundabouts.

For the T8 we went through this process three times, the latest earlier in 2023 with Android 12. Each major OS build requiring porting of the changes made to the version before it, or setting up again based on the requirements doc from scratch. Upgrading unfortunately isn't much easier than building a version from scratch in my experience, but this could be down to the engineering partners I had available; my experience is understandably limited, and I imagine there's a good amount of investment in build management and development in larger OEMs that would offer a world of difference.

The T8 launched with Android 9.0. 10 was feasible already at the time, but it was considered too new for some more risk-averse in the company and the older, more stable version of Android was chosen for the first products in the RHINO brand. It's understandable in some theory, but on reflection it wasn't a great choice, and had implications throughout the product's lifecycle.

9.0 included a version of Treble that was definitely not close to final, a fixed (as in permanently-set) partition system, and some other less-than-forgiving attributes. It was 10 that introduced the concept of dynamic partitioning, and set the groundwork for substantially more flexibility in how OEMs work with the on-device storage for resizing and repurposing disk partitioning on-the-go in later Android versions. This has been realised in the release of 12 this year for the T8, but given the device isn't planned to see 13, both due to demand and MediaTek's apparent stance on chipset support, the benefit is no longer there.

Because we launched on 9.0, the same partitioning had to be used in 10 to allow an OTA (Over The Air) upgrade. Partitions can always be rewritten with a manual flash of a device, but an OTA update cannot adjust physical partition sizes. If we were launching 10 with a new device (like the M10p) we could have implemented dynamic partitioning, but as we wanted to upgrade from a fixed partition system on an existing device, we had to retain that.

The trouble with fixed partitioning is unless you configure partitions to accommodate larger on-disk sizes later - something you can't scientifically calculate given changes that impact system sizing can't be predicted for the next version of Android, never mind 2 or 3 later - you'll eventually run out of space and can no longer support the upgrade to a newer version without some significant hackery, if possible. This is effectively what happened with the T8, and why we went 9.0 > 10 via OTA, then 12 with a manual flash for existing units, or a preload from factory of 12 for units manufactured in 2023. The upgrade to 11 took the /system partition to a larger minimum size than we could accommodate on the 9.0-specced partition layout, and we deferred upgrading again until necessary.

Another aspect of maintaining an Android product over multiple years is GMS approval. Google sets approval windows for every Android release that state the latest possible time permitted for approving a new release of Android both as a new product, but also as an existing product that's upgrading; the latter has a bit more time since it's already an in-market device that needs to be supported. There are also expiry dates that stipulate the date after which it is not permitted to manufacture new Android devices with an older version of Android, though existing manufactured devices in the field could continue getting updates. These dates also differ based on form factor, Android flavour, and GMS licence (ie. EDLA (enterprise dedicated) devices).

It's a reasonably complex, though not necessarily complicated process.

For Android 10, the expiry date for GMS approval as a tablet on the MADA licence was Dec 2022, that means devices manufactured from January had to preload a newer version of Android from the factory, so 11+.

11 however passed the last date for GMS approval as a LR (launch release, an upgrade) back around August 2022, which meant when DoorDash picked up the phone and requested a brand new, freshly manufactured batch of T8s in late 2022, Android 12 development had to also be undertaken in order to have an approved Android build to put on the tablets in the factory before shipping out.

But what about security patches?

Security updates are comparatively much simpler to plan and manage than major version releases, on the whole. The T8 has received quarterly security patches since 2019, and will continue to do so into 2024 based on current plans.

The only implication with security updates is when Google stop backporting them. Backporting, to address the assumed question, is where Google will take the patch of a security vulnerability in the current version branch of Android (say, 13 as of August 2023) and undertake the necessary engineering to be compatible with older versions, so 12, 11, 10, before committing it to those version branches respectively.

OEM engineering resources then pick up the patches for the relevant version they're working with, along with patches from component suppliers, chipset vendors, and anyone else pertinent to a specific device, and roll it out into the device tree (source code for the device).

Google will not backport forever, however. There is typically a limit of 3 years per OS version before they cease backporting and instead focus on newer versions of Android.

As an OEM, you then have the choice of:

Continuing to support an Android version by cherry-picking patches from a newer version of Android and doing the engineering internally to apply to your device
Or upgrading to a newer version of Android

Manual backporting, as it's referred when the OEM does it after Google stops, can be challenging, especially for smaller OEMs or their engineering parters. I've often struggled to lock in agreements with partner resources, who would almost unanimously rather undertake the task of rolling out a new version of Android than keep the older version secure once Google moves on (either route demanding a reasonable chunk of change to achieve).

This is relevant because while the T8 has received security updates on time and religiously since launch with no action from customers required across 9.0 and 10, backporting for Android 10 officially ended in Feb 2023, and as such the last security update for that version went out to the customer base a couple of months ago. Customers who want to continue to receive security updates for another year will have to manually flash tablets to the latest version.

So to reiterate, launching on 9.0 was not a great decision. Thankfully all projects after the T8/C10 adhered to my mandate for leaning towards the newer versions of Android available to avoid such frustrations re-occurring, and 4 years later newer projects are faring much better.

Not all that bad

Though the T8's Android journey has been somewhat more challenging, this isn't reflected across all projects I've worked on and devices I've supported. I want to stress it's been mostly enjoyable to support the platform. I enjoy debugging (and squashing!) bugs, writing the release notes, scheduling the OTAs, planning feature drops, building out the OEMConfig (and other solutions) roadmap based on customer needs, and absolutely..

..more than anything..

..requesting bug reports from customers 38 times a day in response to one-sentence support tickets exclaiming something is broken. :).

Wrapping up

I've covered off a fair bit of my experience bringing the T8 to market from a product development point of view. I naturally haven't touched on everything that went into launching the T8, nor some of the more bespoke requests from DoorDash on customisations they've received over the years to the model, including:

Hardware revisions configured to local markets/geographies we didn't initially launch into
Custom hardware configurations (NFC was removed from one revision for a particular use case)
All of their custom branding and packaging
Their custom-manufactured accessories (cases, etc)

And many other value-adds that made the T8 the DoorDash T8. But ultimately a springboard from which to jump is what had them Dash through the Door (😁) in the first place, and I'm immeasurably proud of what I and my team achieved as the first major project of a new brand.

Android's work profile gets a major upgrade in 14

2023-08-09T00:00:00Z

This change has been reverted

Check out this article for more information. The below no longer applies to Android 14, but may be instead re-appear for Android 15 (or sooner in a QPR - quarterly patch release - if it's ready).

This'll be updated at a later date.

In case you missed it, my article on what's new in Android 14 covered off a subtle but significant change to the way the work profile functions when toggling it on and off (pausing it).

I've already popped together a technical overview of the change, as I like to do for many things that change on major releases. These intentionally lack any sort of opinion, bias, or objectivity as best I can in order to be simply taken at their intent - a straightforward technical change document highlighting what's changing, why, and the impact it may have.

This, however, is an article and fully subject to all of my opinions, so let's dive in a little!

Why is the work profile UX changing?

The reasoning for the change, officially, is pending Google's 14 marketing push likely due in the next several weeks when 14 lands. That said, tidbits of public information have popped up, and it's all about improving the experience for work profile users.

When you turn off a work profile on 13 and older, the whole work profile user turns off. This obviously kills the apps as expected, but it also turns off every other aspect of work profile functionality also - the cross-profile APIs used for caller ID and such, application updates, and for OEMs like Samsung, the ability to move data between profiles.

This obviously poses some challenges to providing a good user experience.

When the boss calls while the profile is off, users will see a call from a phone number rather than a named contact, making it much harder to ignore out of hours 🙂. Additionally, because the profile is entirely off, app update policies don't apply and therefore devices can fall out of compliance,ending up in a situation where the work profile is automatically removed, or at least access to corporate data is prevented due to DLP policies in place by the managing organisation.

One of the biggest annoyances reported with the work profile though? Notification-geddon. When the profile is turned off for a period and eventually turned back on, the device may be inundated with notifications all at once for everything that has happened while off.

How is this addressed in 14?

In 14 Google has switched up what "pause" means, and have instead taken a leaf out of the Digital Wellbeing book to focus on the suspension of applications themselves, leaving the work profile itself still running.

That means the management of the profile can continue unhindered, so applications continue to update, cross-profile APIs still function, and presumably OEM plugins like those from Samsung allowing cross-profile data migration (if you want to know what this means, open Gallery, select a picture, and in the menu there's a Move to work profile option) can continue to function, providing corporate policy permits it.

And notifications? They simply accrue in the background in the same way they do for Do Not Disturb, Focus, and similar Digital Wellbeing modes.

Balancing UX with UX

The drawback for this, understandably, is data and battery use while the profile is now paused. While the latter is going to likely be minimal during the pausing of the work profile - not easy to compare scientifically since there are many other changes between 13 and 14 that will equally contribute to differing battery use - data usage can silently climb in the activities of app updates, notifications, and everything/anything else a suspended app can still do while the work profile is off, rather than only being permitted to do so when turned on as per 13 and older (though Google confirm things like location won't be permitted when the profile is paused).

While that's not going to be a problem for me, and likely many folks reading this, Android is a global platform, and devices are managed all over the world. This is why I felt it pertinent to mention it on the tech doc, because there are users with limited, capped, or expensive usage-based internet plans at home (I'm talking ISP, not cellular) - my Dad in Wales is capped to 10gig in a month out of choice because it's cheap! - and those who actively turn their work profile off to avoid usage in addition to gaining the benefits of the work-life balance the work profile provides may find themselves seeing the effects of this change quite quickly.

Again, most will likely not even notice, but our ecosystem is vast and the Android user base geographically-diverse. Since the option to turn off the work profile completely is gone, I want to make sure organisations - and users in particular - know what's coming before it causes a problem.

A net-positive change

Overall the changes make sense for the evolution of Android Enterprise, and it's wonderful to see Google's PMs honing in on the finer details of headline functionality. Combined with fix for work profile screenshots and several other cross or work profile features, it's a decent release, generally.

Google's inactive account policy may not impact Android Enterprise customers

2023-08-03T00:00:00Z

Back in May Google announced a change to their account inactivity policy. If you're a Google account owner you may have received an email also:

If not, it was covered quite extensively by the media:

I'd considered adding to the noise back then with an enterprise point of view, but it occurred to me there really wasn't any clarity for enterprise customers leveraging a Google account to bind Android Enterprise to their EMM at that point, and so I've been busy working in the background to understand the implications for Android Enterprise customers and if there's truly a mandate to keep the account active in order to prevent the bind from being deleted, and thusly, all enrolled devices becoming either unmanageable or wiped entirely (depending on EMM).

The good news is, per my understanding, Google is working on a solution for the enterprise bind use case that will address Google accounts associated to an active bind being subject to the inactivity policy. There is no official word on this as yet (I'll update when that changes), so this is obviously, and unfortunately, subject to change.

That said, since the original May announcement the list of exclusions to this policy has grown. Given it doesn't go live before December 2023, there's still time to fine-tune it, and do so I'm certain they will.

Google have updated their inactive accounts policy to explicity exclude accounts used for:

Android Enterprise bind
Zero-touch admin or owner accounts

And while the original help article hasn't updated to state this, the customer community calls it out instead.

Summarising the change

In short, as a holder of a Google account, if you have not logged in and performed an activity with said account within 2 years, it will be marked for deletion. Simply logging in is not good enough, unless that login is to a 3rd party solution supporting Sign in with Google, one of the following should be undertaken while logged in:

Reading or sending an email
Using Google Drive
Watching a YouTube video
Sharing a photo
Downloading an app
Using Google Search
Using Sign in with Google to sign in to a third-party app or service

The important current exceptions to this are:

Your Google Account was used to make a purchase of a Google product, app, service, or subscription that is current or ongoing.
Your Google Account contains a gift card with a monetary balance.
Your Google Account owns a published application or game with ongoing, active subscriptions or active financial transactions associated with them. This might be a Google Account that owns an App on the Google Play Store.
Your Google Account manages an active minor account with Family Link.
Your Google Account has been used to purchase a digital item, for example, a book or movie.

Not all of these are one-and-done. Using a subscription requires it remains active to secure the exception, for example.

Create-and-forget enterprise accounts

The problem for organisations quite clearly is the unlikelihood any of the above exceptions may have occurred. Frequently organisations will create a Google account at the time of binding an enterprise to their EMM, and subsequently forget about the account until it becomes necessary to manage an uploaded application's advanced settings, or manage the bind itself.

Arguably even if organisations sign in to the account, this may not be enough to trigger Google's activity monitor based on the requirements outlined above. This could lead to even more confusion for organisation admins that do go out of their way to keep an account active with infrequent intentional logins; those inactivity emails will land in the inbox associated with the account, and require the organisation to actively manually confirm the account is active.

What happens if the account responsible for the Android Enterprise bind is deleted?

When a Google account is used to bind Android Enterprise to an EMM, an enterprise ID (as developers see it), or Organisation ID (as customers see it) is created. Every policy, device, application, etc, is then associated to this enterprise ID, and the EMM is granted permission to manage everything within that enterprise ID respectfully.

That Google account becomes the primary account associated with the bind. Others can be added, and I'll touch on that shortly, but by default it is just the primary account used to create the bind in the first place that remains associated with it.

A feature request here would be to provide a means of adding multiple accounts to the bind during the binding process. There's no visibility today of the ability to add multiple accounts to administer the bind in the current setup flow, and organisations will only come to know this is possible if they actively log in and manage the bind through admin settings at a later time.

If this account is deleted, the enterprise - the bind - is deleted with it. Depending on the EMM this can result in anything from loss of management capabilities, with devices effectively stuck with the policy and state they are in at the time the bind is deleted, to an immediate wipe of the entire estate (and obviously an inability to re-enrol). These variances exist due to various custom DPCs, EMM logic, and of course AMAPI.

Beyond devices however, any uploaded applications become inaccessible, policies, web apps, or any other data associated with the bind are also unrecoverably deleted.

What can organisations do to safeguard against deletion?

Understandably with the devastation this can cause to an organisation - I actively oversee multiple 10s and a few 100 thousand unit deployments that would cripple company operations if they were to fall offline or completely reset - it's pertinent to undertake actions to ensure the continuity strategy doesn't entirely rely on Google making an exception to protect the bind. Here are some things you can do:

Add more owners to the bind management

Simple and straightforward, follow my FAQ to add more Google accounts to be able to manage the bind. Aim for at least two Owners for redundancy, including the original account that set it up.

If only one account manages a bind and the account is deleted, as above, the bind is deleted. If more than one account manages the bind, and any one of those accounts are deleted, the bind remains in place as there is still an owner associated. This obviously scales up to the number of accounts associated to the bind.

Use domain-based Google accounts

Not Google Workspace. Google doesn't support Google Workspace accounts managing the bind. Rather, when you sign up for a Google account, click the small link to use an existing domain, and set an account up using the corporate email domain of your organisation. Group mailboxes are a safe bet, offering multiple admins the ability to interact with the account even in high employee churn environments.

Again this won't work for organisations that lean on Google Workspace, so if it's not possible to create an account under your organisation's domain, ensure the recovery information is added, and again aim for a group/shared mailbox where multiple admins have access to avoid losing access to the Google account in future.

Ensuring emails Google sends out land in a monitored inbox drastically reduces the likelihood of:

Inactivity alerts being missed
Account recovery being impossible

Leverage an in-use account for the bind

Definitely not a personal account, but rather consider an existing group or departmental Google account that sees active use. One example may be a developer account used to publish to Google Play, as this also provides additional flexibility for managing private applications on a more granular level through the Google Play Console rather than the Google Play iFrame, avoiding bind lock-in should it be necessary to ever start afresh.

An active account will not be subject to the inactivity policy, naturally, though consideration must be given to who has access to what may be very important accounts in some organisations.

Bring on the solution

The above suggestions can and should be considered irrespective of the inactivity policy, but for those particularly concerned by Google's approach to this, hopefully the knowledge they're working on it will put minds at ease.

This is a reality of consumer policies impacting organisations which unfortunately does happen quite often given Google's size, consumer focus, and shared infrastructure between teams. Hopefully in time they'll continue to improve how they approach enterprise in the way they have with private application approval policies, Play Store policy escalations, and so on. One day they may even be able to hash these challenges out before the consumer team(s) make their announcements 🙂

In the meantime, go forth and protect your bind(s)!

Product files: Alternative form factors and power solutions

2023-05-30T00:00:00Z

Welcome to Product Files, a series of articles that touch on some of the more interesting aspects of running a product organisation for the last several years.

As this series grows, additional links will show up here:

I last wrote about my job back in 2020. I think it's about time to change that, so in this article I'll cover off a hardware project, one of the first I took on when I joined my OEM way back in 2019 in fact, having not built devices before.

This project was also my first taste of what non-traditional Android form factors could look like, and was equally the first ePOS both for me and for the OEM having only recently pivoted from consumer low-cost handset projects to bespoke enterprise hardware.

In fact, this project ended up being a first for a few additional reasons -

First device certified with Google's enterprise device licence agreement (EDLA) - more on this below.
First (and one of few) partner hardware integrations, and associated SDK development

It goes without saying I've got a reasonably comprehensive understanding of Android. Though I focus primarily on enterprise, I've been tinkering with the platform for over a decade; the Android build that would ultimately grace the ePOS therefore wasn't much of a concern, but getting up to speed on hardware was to be an interesting challenge.

There were however two contributing factors that made this a little easier. First, I had an experienced team of hardware professionals both internally and through the ODM partners who would build the device. Second, the design and functionality of the ePOS was initially largely driven by a rather well-known customer in the food delivery industry based in the UK. If you happen to pop into a restaurant that partners with them, you'll no doubt see similarities in design with units they already have in the wild. When I took over the in-house device portfolio, that customer had just pulled out due to a change of priorities, and so I adopted the project to release as an open market device to sell globally.

And here it is:

I've got a soft spot for the M10p. Even though the design is dated and the way it's built could be far more efficient, thanks in part to the initial project scope, what eventually landed with customers was a robust, performant device with a solid suite of core hardware features, and wicked extensibility.

Some aspects of this project that made it stand out include:

Ports galore

Customers purchasing ePOS devices often have peripherals from hardware being replaced. If they don't, they may prefer working with local partners for region or function specific peripheral hardware.

The goal for the M10p was to work with what customers want to work with. Could we have built scanners, cash registers, and payment terminals to bundle with the unit? Absolutely, but the strategy was that of compatibility and support, not lock-in.

When considering this, availability of ports was a priority.

Around the device you'll find 3 USB (A), USB-C, RJ11, RJ45, and RS232, amongst others. With them, the M10p acts as an all-in-one solution for payments, communications, and peripherals. It'll support many types of cash register, most external payment terminals, and with plenty of USB can be hooked into many other accessories as needed.

This wasn't simple to pull off, the MediaTek Genio 500 the unit is powered by - a strategic decision to further a close relationship with MTK's IoT division for long term support - is hardly a first choice for port support and a lot of these run from the USB2.0 and GPIO channels the SOC offers, but we made it work.

With all of those ports, though, this introduced another concern - keeping them clean and inconspicuous when not in use.

The original product design had them open to the elements, then a large all-or-nothing cover was added in.

(I appreciate it's not easy to see, zoom in on the picture, and you'll see the flap is open)

As you might imagine having one port in use requires the cover to be open, which again leaves all ports open to the elements.

I really aimed to achieve independent port access, and had a specific way I wanted them to function; rather than a simply spring-closed flap which can be fiddly and frustrating, I pushed for adding in a support that would hold the covers open when opened fully.

So we set out on a minor retooling of the housing to add supports for individual port covers, and ended up iterating a few times to get it right, but it was worth it for the resulting user experience.

The individual port covers use magnets to remain open against the metal housing of the print enclosure. It's a really nice, simple, considered implementation.

Continuing the trend of inconspicuous design, a lot of thought was also put in to avoiding unnecessary tampering. The M10p supports a full size SIM card and microSD (eSIM too, but that isn't user accessible either way). You wouldn't immediately know where these are looking at the unit, as they're hidden on the underside of the tablet behind an access port secured with a screw.

The same principle was applied for volume and the power button, which are recessed into the side of the unit and can only be interfaced with a SIM PIN (or equivalent). This was an intentional design decision as it's both inconvenient enough that the general populace won't have something to hand (like a Biro) to fiddle with it, while at the same time SIM PINs are cheap and reasonably standardised enough to allow for sourcing if customers lose the one in the box.

Custom APIs were also developed in software to allow for managing of device volume and tap-to-wake, so those buttons could be fully disabled under appropriate enterprise control, anyway.

The only concession made here was the inclusion of a USB-C port that handles host for Android debugging. I could have sunk my heels in on this, as ADB over Wi-Fi is obviously a viable option, but in testing and with the active customer base, debugging was challenging enough without introducing more complexity, and on reflection of 3 years supporting it, was the right move. Software handled access to this port also, of course.

Despite the presence of USB-C, unfortunately I couldn't lean on it for power, particularly with a power-hungry Seiko sitting in the bottom. Today this would likely be reasonably easily achievable. In 2019 and due to the routing of power and data between the tablet and print enclosure respectfully, not so much. On the upside, the 24v external power supply has enough juice to power the tablet, print enclosure, peripherals, and many types of passively powered cash registers.

Safe shutdown on power loss

Speaking of the external power supply, this is the sole means of powering the unit. There's no internal battery as it's a dedicated device designed to be fixed in place and attached to permanent power.

Considering the environments this device is intended to work within (high humidity, extremes of temperature, always on, running for 5+ years) shipping a battery is something I considered too high risk. Batteries fail, I didn't want this device to become a burden to customers, particularly in use cases such as food delivery, where units are remote, normally sat in partner establishments and going down can cost a day+ worth of missed orders.

There are implications to this product decision. First, with Google Play Protect (GMS) certification all certified devices must have a battery.

Further, in testing with customer environments, I was seeing unplanned power loss to be something of a reoccurring issue. Employees would often switch units off and on for app issues, devices would be turned off at the end of shift/work days, units would be moved around frequently(!), and other scenarios saw the M10p repeatedly shut down in an unclean fashion. This led to data loss and/or corruption and something I considered to be a significant problem.

Between the two, GMS was the larger - if ultimately temporary - issue for the business to be perfectly honest. Without certification the hardware couldn't run Google apps and services, and wouldn't support Android Enterprise. That would stifle the product's success tremendously.

My team and I worked through several options, including in-line UPS, hundreds-milliamp sized batteries accessible through maintenance panels for easy replacement, and more. Until it hit me.

Capacitors.

They hold charge, hold up in harsh environments, don't degrade in the way batteries do, and don't require user maintenance.

You see capacitors in use quite often today, consider things like the Samsung Galaxy stylus for example, but again back in 2019 it wasn't an immediate thought.

The M10p had the space within the housing needed to support them, and we sat them in-line between the PMIC - Power Management Integrated Circuit, the board that handles and distributes power to the rest of the device - and the external power supply.

We achieved 20 seconds of reserve power with the above configuration (the two large green cylinders wrapped in rubber), and while you might look at that insignificant number with confusion, this solved both problems:

On a technicality we were able to pass GMS applying the MADA (consumer) contract with the unit classified as a portable tablet (for MADA it's that or a handset).
The problem I set out to solve wasn't to keep the unit powered on with a loss of power, but to protect against data loss.

I coupled the capacitors with a system (Android) service that monitored for a power change, and gracefully initiated shutdown. With an average shutdown taking 16 seconds and including Android saving data to disk during the process, the M10p could now lose power without losing data.

I was elated.

Those familiar with capacitors may already know the minor trade-off we made with this configuration - cold boot takes 5-10s longer before the device powers on while the capacitors fill up. Cold boot only happens when the unit has been totally unplugged for a period of time though, giving the capacitors the opportunity to fully discharge over time. In temporary power loss scenarios this just wasn't an issue.

Migrating to EDLA

That battery technicality for certifying the M10p as a Play Protect Certified/GMS MADA tablet ultimately (and thankfully) wasn't needed for production, as during development of the device Google launched EDLA, the Enterprise Device License Agreement, as a replacement for MADA, the Mobile Application Distribution Agreement.

What these are could probably justify an article per acronym, but effectively:

All certified Android devices are governed by a MADA, for which there are multiple due to various competition and market restrictions around the world, EMADA (Europe), IMADA (India), TMADA (Turkey), and Russia which runs on a modified MADA.
These agreements define apps bundled, home screen layout, restrictions and requirements in addition to or in place of the public CDD - Compatibility Definition Document - and more.

EDLA was brought in with some key requirements changes based on feedback from ecosystem players like me who outlined problems with the traditional GMS requirements for dedicated devices. In summary, again for simplicity, EDLA devices amongst other things:

Can have displays larger than 18" (think kiosks, digital signage)
Can be headless (no display at all)
Can omit a battery entirely

The one primary requirement added was full transparency for software support, wherein a public page on the OEM website must state when the device is expected to go end-of-support, list releases, and so on. As you can imagine I had no issue with this at all. AER requirements demand the same and it's better for the ecosystem.

Evidently being invited to move the M10p over to EDLA from MADA was a big deal and put the device and it's capacitors back into the realm of absolute adherence as opposed to dancing around technicalities, so that was a relief, but to be invited to do so amongst the huge industry players like Zebra and co making dedicated devices was such an incredible accomplishment.

The M10p became the first EDLA-certified ePOS in the world, and I am super proud of that.

Wrap up

I could go into much more detail on this device alone - the printer integration, the hinged access, BYO eSIM support, the light bar.. and more (and perhaps I will another time), but for this article these were some aspects of building the product that stood out, either due to time and thought required, or the impact it had on the resulting device.

I hope you enjoyed this peek behind the curtains. If so, look out for more in the coming months!

What's new in Android 14 for enterprise

2023-04-20T00:00:00Z

Not too long ago Google announced the first beta of Android 14.

As these things tend to go, the likelihood now of major additions is slim, and so beta 1 marks a good opportunity to review what we're likely to see when Android 14 officially launches later this year.

Given the amount of lower-level developer content, I'm not going to cover everything in the API docs targeted to Android 14, so this will be limited to only the notable items. That said, let's go!

Want to keep your personal device a little more private when sharing your screen on a call? Android 14 now introduces the ability to share a specific app within the work profile, ensuring meeting attendees don't catch a glimpse of any personal applications or customisations (no judgement on your particular choice of wallpaper from me, either way!)

Default 6 digit PIN

Android 14 ups the default PIN from 4 to 6 digits, with their justification being one very commonly quoted by us in the industry:

Adding just two digits to unlock the device increases the number of possible PIN combinations from 10,000 to 1 million — reducing the risk of break-ins.

It's still possible to set weaker passwords, but is it really worth it?

Persistent screen-on during provisioning

If your Android experience is primarily centred around Samsung then this may not seem new, but for those of us who've spent time with most other OEMs in the ecosystem the screen turning off during provisioning is at minimum an inconvenience, at most the reason why provisioning or enrolment may fail.

Often, and I see this more with AMAPI (Intune, Mambo, Wizy, etc) than Play EMM API (custom DPC - ~~MobileIron~~ Ivanti, SOTI, VMware, etc), allowing the screen to time out and coming back to it a little later results in a failure to set up and a request to reset. In my use cases this isn't the end of the world. For large staging projects this would be beyond frustrating.

Well in any case, for non-Samsung (and other OEMs that don't already support it) devices, once Android 14 lands this will be a thing of the past.

Google had actually introduced in Android 13 a DPC extra to keep the screen on that customers could leverage: EXTRA_PROVISIONING_KEEP_SCREEN_ON. Clearly this was given some additional thought and bundled in instead, which is good, since most customers wouldn't have known about this feature otherwise.

Prevention of installation of older applications

Android 14 introduces a new restriction on app installation that cannot be overridden through management APIs.

If corporate applications target SDK 22 or earlier (Android Lollipop), installation will automatically be blocked with an error that resembles the following:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7

This only affects new installations of applications. Those already on the device when it updates to Android 14 will not be affected.

See this Google doc for more information.

A revamp to cross-profile behaviour & implementation

//-

Release update

Google has provided more information on the use of these cross-profile APIs, namely in the form of the applications able to access work contacts. In Android 14 all personal apps can see work profile contacts, and admins can now specify, via AMAPI, whether this is permitted, blocked, or blocked except system (13 and lower behaviour). An exemption list is available for the permitted/blocked options which blocks or permits applications defined respectively.

NB: AMAPI will default to permitting all applications, so if this is not something you wish to permit, update your AMAPI policies now!

-//

I normally wouldn't reference deprecations and replacement APIs in these updates because typically they're a little dry, but the apparent revamp on cross-profile functionality is interesting.

CrossProfileContactsSearchDisabled and CrossProfileCallerIdDisabled are being deprecated in favour of what appears to be a more specific ManagedProfileCallerIdAccessPolicy() and ManagedProfileContactsAccessPolicy(). Reading into the soon-deprecated APIs specifically, Google states:

Starting with Build.VERSION_CODES.UPSIDE_DOWN_CAKE, calling this function is similar to calling setManagedProfileCallerIdAccessPolicy(android.app.admin.PackagePolicy) with a PackagePolicy#PACKAGE_POLICY_BLOCKLIST policy type when disabled is false or a PackagePolicy#PACKAGE_POLICY_ALLOWLIST policy type when disabled is true.

The original APIs were a simple allow/disallow, while the new APIs lean on ALLOWLIST/BLOCKLIST (and another new ALLOWLIST_AND_SYSTEM, which as you might guess includes system apps by default as well as those explicitly defined by the DPC) to either generate explicitly permitted, or explicitly blocked applications being called on the device for the cross-profile functionality of caller ID and contact search.

DevicePolicyManager#setCrossProfileCalendarPackages and DevicePolicyManager#getCrossProfileCalendarPackages are deprecated. But this is because these types of API are going away all together.

In their place, applications will need to lean on the new Connected apps implementation, which expands scope beyond just calendar as the old API defines. Connected apps is early access at the moment, and looks like it has some - very justifiable - tight controls on what's approved vs not, since there's scope with these APIs to syphon data en masse from out of the work profile. The backup example they provide (which wouldn't be approved) highlights the very high-risk associated:

An app providing backup services that will sync work data to a personal profile account, or vice versa, would not be approved as it would send and log data from one profile to the other profile.

~~At the time of writing, the AMAPI API docs don't show anything relating to these changes, so it'll be interesting to see if we benefit from zero-day support later this year.~~

SIM management for COPE devices

This has been on my list of feature requests for years! The ability to manage SIM functionality, and direct it into the work profile has been an ecosystem-wide gripe with COPE (and lesser but still valid, BYO) for as long as I can remember.

But! It's not what I'd consider fully formed just yet.

In Android 14, organisations will be able to assign the SIM(s) on a corporate owned device to the work profile (so COPE only) as an all-or-nothing policy. This absolutely covers use cases where organisations provide a device and SIM for work while allowing personal use, but clearly doesn't cover the desired behaviour to associate 1 of multiple SIMs to the work profile, while the other is left to the parent profile; the ideal eventuality for BYO and COPE users.

A new related API is setDefaultDialerApplication, which permits the DPC to set an explicit dialler in relation to this SIM management API (ManagedSubscriptionsPolicy), which is handy. This also compliments the default SMS API introduced way back in Android 10.

Behaviour-wise, it meets expectations, per Google:

When a subscription is associated with the managed profile, incoming/outgoing calls and text message using that subscription would only work via apps on managed profile. Also, Call logs and messages would be accessible only from the managed profile.

So again, brilliant start. Hopefully by Android 15 this'll mature into a full-featured SIM management offering for COPE and BYO equally, and I can officially tick it off my AE feature requests list.

Correct saving of screenshots for work profile applications

In Android 14, the long-standing loophole for DLP controls, the humble screenshot, has been resolved. When a user takes a screenshot of a work app it will now be saved within the work profile, rather than in the parent profile.

If you're anything like me that'll be bittersweet; great for security in plugging a very obvious flaw with screenshots up to this point, but it's 100% something I've leveraged for years to overcome overly strict DLP policies preventing copy/paste, sharing outside the work profile, and so on.

Pausing the work profile

This change has been reverted

Check out this article for more information. The below no longer applies to Android 14, but may be instead re-appear for Android 15 (or sooner in a QPR - quarterly patch release - if it's ready).

This'll be updated at a later date.

~~In Android 14 Google are introducing the ability to pause, rather than turn off, the work profile.~~

~~Think of it like an aggressive do not disturb mode for work apps, everything is still on and running in the background, but you're not alerted to anything.~~

~~Why would you choose to pause a work profile rather than just turn it off?~~

Applications continue to receive notifications and data in the background, so you're not inundated by them when you turn the profile on. Work apps are immediately available when unpausing (no wait time, or sync required).
Update policies continue to apply, so they can do so in the background rather than when the profile is back on. Obviously apps shared between both profiles will update even if the work profile is turned off, but apps only in the work profile won't unless the profile is on, normally.
~~Cross profile contacts are identified, so you'll know you're getting a call from the boss while the profile is paused. When completely off the numbers aren't identified.~~

The question I don't have an answer for at the moment is how this works with the policies that require a work profile to be turned on after a period of time. If a user can pause a work profile but still be considered having it turned on, this seems like a simple way of getting around that compliance requirement.

~~(July 2023): The compliance requirement appears to be unchanged since this is a full replacement to turning off the work profile, and not an additional option to control it.~~

Direct work contact messaging

Likely leaning on the new cross profile APIs above, personal apps will be able to directly message work profile contacts in supported applications. Undoubtedly this will be subject to IT policy, so watch out for that!

Rolling out with Google apps in the short term, Google is showcasing a new, more cohesive user experience when switching between profiles.

This will be a drastic improvement on today's requirement that normally includes tapping into app settings or a context menu to switch to work, so I'm excited to see this!

UWB (Ultra-Wideband) support

UWB is having a bit of a moment recently, with a lot of attention from the media on the solution in the last few months alone. For good reason, too, as the applications from unlocking vehicles to indoor positioning, asset tracking and more make it a compelling solution across various industries.

UWB is a communications protocol that permits high-speed, short-distance, & low-energy communication. It sits alongside other radios like Bluetooth, NFC, Wi-Fi, etc.

Since it is a radio, and means of sharing data, it was a matter of time before a management API popped up to control it. Per Google:

Starting in Android 14, a device or profile owner can disallow UWB on an organization-owned device by applying the DISALLOW_ULTRA_WIDEBAND_RADIO user restriction with DevicePolicyManager.addUserRestriction().

Again this is a device control limited to corporate owned devices, so fully managed or work profile on company owned (COPE) devices.

Given its breadth of use cases and applications it may be tempting to pre-emptively prohibit its use.. just keep this in mind when users complain they can't unlock their BMW!

Disabling 2G

Snuck out between betas 4 and 5, Android 14 introduces a management API to disable 2G at the modem level. Originally launched in Android 12 as a user (and carrier)-configurable system setting, now organisations can benefit from fleet-wide security improvements by toggling it remotely for managed devices.

There's far more detail on this here

Native financing support

Enterprise related for implications it brings to the wider Android platform, it appears 14 is introducing APIs to declare a device as being under finance with isDeviceFinanced.

The finance use case has existed for a few years, originally only accessible to select partners holding a direct agreement with Google with the use of a bespoke DPC called Device Lock Policy, it appears this has graduated and become a little more available recently, as Device Lock is a suggested APEX preload in Android 14.

Also fun fact, while Device Lock is leveraged with zero-touch and AMAPI on the back end, it's actually against permissible usage to leverage AMAPI for device financing. I say this for the benefit of the 3 companies a week who reach out to ask me how they can use AMAPI for this use case!

More importantly..

Device Policy Resolution Framework

With Android 14, Google have potentially made the largest fundamental change to Android Enterprise since inception.

Historically it was permitted to have just one Device Owner on a device that wielded all power over the DevicePolicyManager APIs, the on-device APIs used to control and manage a managed Android device.

The Device Policy Resolution Framework has been introduced to handle conflicts when, in Android 14, more than one Device Policy Management Agent (an admin application) with the role DEVICE_POLICY_MANAGEMENT starts making calls to implement one of several (not all) policies on-device.

Only an OEM can grant this permission to an application, so rest assured this isn't going to be a return to the days of Device Admin, though there's certainly a whiff of familiarity here.

The obvious use case for this is financing, above, as the Device Lock application/APEX when preloaded by an OEM into a device works on the same DevicePolicyManager APIs as your typical EMM Device Policy Controller (DPC).

Of course because an OEM can grant applications the role of DEVICE_POLICY_MANAGEMENT, it's not infeasible to assume this may be leveraged in the future outside the two use cases already explained here. When an application is granted the DEVICE_POLICY_MANAGEMENT, here are the permissions it'll be able to leverage:

<permission-set name="notifications" />
<permission name="android.permission.BIND_DEVICE_ADMIN" />
<permission name="android.permission.MANAGE_DEVICE_ADMINS" />
<permission name="android.permission.NETWORK_MANAGED_PROVISIONING" />
<permission name="android.permission.PEERS_MAC_ADDRESS" />
<permission name="android.permission.USE_COLORIZED_NOTIFICATIONS" />
<permission name="android.permission.MASTER_CLEAR" />
<permission name="android.permission.WRITE_SECURE_SETTINGS" />
<permission name="android.permission.READ_PRIVILEGED_PHONE_STATE" />
<permission name="android.permission.START_ACTIVITIES_FROM_BACKGROUND" />
<permission name="android.permission.START_FOREGROUND_SERVICES_FROM_BACKGROUND" />
<permission name="android.permission.MANAGE_PROFILE_AND_DEVICE_OWNERS" />
<permission name="android.permission.INTERACT_ACROSS_USERS" />
<permission name="android.permission.INTERACT_ACROSS_USERS_FULL" />
<permission name="com.android.permission.INSTALL_EXISTING_PACKAGES" />
<permission name="android.permission.DELETE_PACKAGES" />
<permission name="android.permission.ACCESS_PDB_STATE" />
<permission name="android.permission.MARK_DEVICE_ORGANIZATION_OWNED" />
<permission name="android.permission.CHANGE_COMPONENT_ENABLED_STATE" />
<permission name="android.permission.SET_TIME" />
<permission name="android.permission.SET_TIME_ZONE" />
<permission name="android.permission.CRYPT_KEEPER" />
<permission name="android.permission.SHUTDOWN" />
<permission name="android.permission.PERFORM_CDMA_PROVISIONING" />
<permission name="android.permission.CONFIGURE_INTERACT_ACROSS_PROFILES" />
<permission name="android.permission.WRITE_SETTINGS" />
<permission name="android.permission.CHANGE_CONFIGURATION" />
<permission name="android.permission.LAUNCH_DEVICE_MANAGER_SETUP" />
<permission name="android.permission.INSTALL_DPC_PACKAGES" />
<permission name="android.permission.QUERY_USERS" />
<permission name="android.permission.UPDATE_DEVICE_MANAGEMENT_RESOURCES" />
<permission name="android.permission.QUERY_ADMIN_POLICY" />
<permission name="android.permission.TRIGGER_LOST_MODE" />

That's not an insignificant list of permissions. Some of them offering a lot of control.

What the DPRF does, then, is implement precedence for handling competing Device Policy Management Agents' policies.

For the most part the DPRF defaults to most restrictive, but this is not the case globally, as in some instances, for example managing disabled applications, it will combine policies to remove everything requested, while in other cases it will defer preference in the following order:

Device Lock
Device Policy Controller (EMM Agent)
Any other DPMA

Why does Device Lock, the finance agent, get precedence over EMM or other device agents? Because if a device is financed and the owner falls into breach of the financial agreement, Device Lock needs to be able to lock the device out without competing enterprise policies getting in the way.

There's substantially more to unpack on this change in Android 14, and I'm still digging, but this is a fascinating new approach Google are taking, one undoubtedly potentially open to abuse if it's not well monitored.

Other features

There are several other features that I haven't mentioned, but everything I've found so far is available in the DevicePolicyManager developer docs for further reading if interested.

This is looking to be a decent release!

Introducing Micro Mobility

2023-04-01T00:00:00Z

TL/DR I've published the first in a series of children's books. Jump to the announcement ⏬

As many of your reading this will know, I've been in the Enterprise Mobility Ecosystem for a very long time.

10 years, in fact, as of January just gone.

Although I started as a generalist, supporting Android, iOS, Windows Mobile (loved those CAB files), Blackberry.. it's quite clear at this point where I chose to hang my hat and invest my time & effort.

And it's paid off. Today I'm a well-known guy in the space, interacting with peers around the world on an almost daily basis to help with Android related issues. I've achieved great things with the Android Enterprise Help Community, various partner accolades, I contribute to successful mobility groups and organisations, and I've had the honour of working closely with Google on several initiatives in the last few years.

In my own career since, it feels like I've touched almost every aspect of the Android ecosystem; I've done support, consulting, product management, project management, programme management, (technical) marketing, advocacy, strategy, engineering, and I've done this broadly across most of the segments of the industry - carrier, MSP, OEM, EMM, private organisations, maybe more.. and that doesn't take into account those I've helped in my off-hours.

My humble website, here, is what I have to thank for where I am right now though. A right-time, right-place decision to start documenting my journey with Android for Work way back, when Google had little time and resource to do a considerable amount themselves, that gave me a real leg-up even on their own documentation and resources for organisations, and the rest, as they say, is history.

I've been thinking a lot about this recently, and it's become apparent very little I've achieved in my 10 years of Enterprise Mobility has given me the fulfilment and sense of pride I get from being able to help organisations - individuals, even - find their own path into the ecosystem with the docs and resources I've poured my evenings and weekends into for so long.

But still more can be done.

Folks coming into the ecosystem rarely do so intentionally; filling a generalist role between industries is the norm from which a passion for Enterprise Mobility starts to grow. I'm no different, I was doing compliance and system administration before I got the opportunity to bring my passion for Android to the workplace - again, right-place, right-time. I don't think I can say I know anyone who left education with the intention of a career in mobility.

I want to change that.

To address this, I am introducing Micro Mobility: Modern Mobile Management for the next generation of Mobility Experts.

With this new venture, I am taking my decade of Enterprise Mobility expertise, and creating a series of educational books for children that will expose them early on to the Enterprise Mobility ecosystem.

Daddy's Phone Can't Do That!

My first book in the series, illustrated by the extremely talented Laila Arêde, addresses the challenges organisations face with DLP and security management, and introduces the topic through a common situation between child and parent, asking to use their phone.

Daddy's Phone Can't Do That! takes the young mind through a journey of discovery of why a corporate phone can't do some of the things personal phones do by default, and explores the topic of Mobile Device Management through the responsibilities of Andy Admin, the IT wizard, and Big Boss Bill, the C-level who just wants to keep his corporate secrets safe.

Daddy's Phone Can't Do That! is available today through Lulu.com as an EPUB for £,$,€ 1.99. More distributors will come online over the coming weeks.

Buy EPUB

A PDF copy is available for download at no cost, but pay-what-you-want links are below to support the work (suggested: £1.99):

Download PDF

Pay £1.99 - PayPal | Monzo (UK only)
Pay what you want - PayPal | Monzo (UK only)

To come

This is just the first in this brand new venture, and I look forward to repurposing more of my content into high quality education over the coming years.

Are you interested in a printed paperback? With enough interest I'll find a publisher to make that happen. Let me know!

Android Enterprise: A refresher

2023-03-07T00:00:00Z

If you're working in a typical organisation, you're probably struggling to keep up with the ever-evolving world of mobile device management. With employees using their personal devices for work and the rapid pace of technological change, it's no wonder that many IT departments are feeling overwhelmed.

That's where Android Enterprise comes in. Android Enterprise is a powerful mobile device management platform that's designed to help organisations of all sizes manage and secure their mobile devices with ease. Whether you're a small business owner or the IT manager of a large enterprise, Android Enterprise has the tools you need to take control of your mobile device ecosystem.

But what exactly is Android Enterprise, and how does it work? In this article, I'll provide a closer look at this industry-leading platform and explore the benefits it can offer your organisation.

What is Android Enterprise?

I've covered this many times over the years, but here's a detailed overview. In summary:

Android Enterprise is a comprehensive suite of features built into Android that allows organisations to manage and secure their Android devices at scale. Since it's built on top of the Android operating system, it means that it's fully integrated with all the features and functionality that consumer Android users know and love.

With Android Enterprise, organisations can choose how they want to manage their devices, and do so with far more flexibility than alterntative mobile operating systems. Organisations can create separate work profiles on their employees' devices for example, which keeps work data and personal data completely separate and ensures employees can use their personal devices for work without having to worry about their personal information being compromised. On the opposite end of security and control, organisations can completely own and manage every individual facet of the Android OS, and lock it all the way down to a single-use device. Android Enterprise provides the sliding scale of control, security, and privacy features that allow organisations find the perfect configuration for their needs.

How does Android Enterprise work?

Android Enterprise is designed to be flexible and customisable, so organisations can choose the management approach that works best for them. There are three main management modes available in Android Enterprise:

Work Profile: In this configuration, an isolated work profile is created on the employee's device. This work profile is completely separate from the user's personal profile, meaning work and personal data are kept entirely apart. Work profile supports both personal ownership (BYOD) and corporate ownership (COPE).
Fully Managed: In this configuration, the entire device is managed by the organisation. This allows for complete control over the device and all its data and settings. Fully managed devices can be used both as knowledge worker, and dedicated devices (kiosk).

To compliment these deployment types, Android Enterprise offers a range of features and functionality to help organisations manage and secure their devices. These include:

App management: With Android Enterprise, organisations can manage and silently deploy apps to their employees' devices without the need of adding Google accounts, ensuring that everyone has access to the tools required to get their work done.
Device security: Android Enterprise offers a range of security features, including encryption, passcode protection, feature restrictions, and remote wipe. This ensures that all devices are secure, even if they're lost or stolen.
Data protection: With Android Enterprise, organisations can ensure that sensitive data is protected at all times. This includes features like app-level data separation and device-level encryption.

Why choose Android Enterprise?

There are many reasons why organisations are choosing Android Enterprise as their preferred platform for device management. Here are just a few of the benefits it can offer:

Seamless integration: Android is the most popular mobile OS in the world, and as enterprise adoption grows, so too do opportunities to integrate solutions. Managed configurations allow remote application configuration, many corporate tools come with complimentary Android apps, and IDP, productivity, communication, and many other corporate tools just work with Android.
Easy to use: Android is designed to be user-friendly and easy to use, since Android Enterprise is baked directly into the platform, the managed experience doesn't feel non-native; even non-technical employees can quickly get up to speed.
Customisable: Android Enterprise is highly customisable, which means that organisations can choose the management approach that works best for them.
Scalable: Android Enterprise is designed to work for organisations of all sizes, from small startups to large enterprises.

Conclusion

Android Enterprise is the future of mobile device management. With its flexible management modes, comprehensive security features and easy-to-use tools, it's the ideal solution for organisations of all sizes. If you're looking for a mobile device management platform that's powerful, customisable and scalable, look no further than Android.

What I'd like to see from Android Enterprise in 2023

2022-12-30T00:00:00Z

I last did one of these in 2019, and very little has come to fruition from my previous list.. so although most of that still applies, it's obviously time to do one again!

It's been a pretty quiet year for enterprise features in Android; not to suggest what was released wasn't welcomed (Wi-Fi features in particular were long-overdue!), but compared to years prior there were no big-hitters that really stood out.

I'm hoping 2023 is going to see a return of pace for the AE team, and although the Android 14 roadmap is pretty solidly laid out already, there's no harm in adding a few ideas into the mix for the wider services that run atop our favourite mobile OS (Play, AMAPI, etc), and perhaps reiterating a couple at the same time.

Granular app update management

Inspired by my mate Matt, who on a regular basis points out the struggles with managing apps via Google Play over on the Mobile Pros community, this is one I'm seeing lead to issues more frequently than ever as more orgs move to AE and a primarily-Play app management process.

Today's options for Google Play app update management include (for AMAPI, per app):

Default
Postponed
High priority
Min version code

Arguably if organisations struggle to keep up with application updates and the risk of breaking changes, you might suggest simply setting the particular app update policy to Postpone and expect the org to assign someone to test within the up to 90 days they have before policy reverts to Default (wherein applications update normally on a low priority).

But what about breaking changes?

Sometimes apps have to change (at least once a year in fact), and do so in a way that isn't compatible with the device or needs of an organisation. No amount of testing will lead to a resolution there; either orgs work with the developer directly to create a bespoke version, or they transition to a new solution for what they're trying to achieve. Both can take more than 90 days from start to solution, leading to potentially significant issues for a managed estate in the interim.

And what about the apps not defined by policy?

A recent example was an update to Google Play Services (22.44.16), which caused devices to reboot into recovery.

Another was Webview (108) causing considerable go-slows until patched shortly after (as reported here and here).

As more applications - system and public - are pushed from Google Play, organisations need more granular options for not only managing the known apps, but those included as system apps either from Google or the OEM.

Should organisations be expected to undertake regular system app audits, and roll out policies per manufacturer to manage this? Probably not, the overhead would be arguably worse than dealing with issues as they come.

Instead, more granular control over applications updated from Play are needed:

The ability to freeze applications on a particular version code, since version code detection already exists for compliance, for an extended period of time. This cannot conceivably be forever for the sake of security, but longer than the current 90 days - perhaps 6 months or a year. Zebra's DisallowApplicationUpgrade is a comparable OEM implementation for this.
App version rollback support. Play should offer organisations the ability roll back to n-1 for a period of time after an update for cases where updates cause issues, like a bad Webview update which has the ability to cripple an estate that relies heavily on webapps. Today this is reliant on developers pushing a new version code release to Play, and being held hostage to extensive Play Policy delays. Giving orgs the option to roll back a version, even if that meant uninstall & reinstall behind the scenes for devices, could prevent extended downtime.
Global app update postponement, combined with verbose app reports highlighting versions installed vs available to give organisations more data to work with
Special consideration for the DPC itself for update management, since a bad DPC update (they happen!) can cause considerable disruption to a managed estate.

Granular system update management

This came up in a conversation with Alex. For the last several years we've had pretty basic native system update management for Android -

Automatic: Updates and reboots a device as soon as an update is available
Windowed: Updates and reboots a device during a set time window local to the Android device
Postpone & Freeze: Options to temporarily prevent updates
Ad-hoc, pushing update files direct to Android 10+ devices where the EMM supports it (AMAPI does not)

By comparison, OEM solutions such as KNOX e-FOTA have provided substantially more control not only of when the updates happen, but the ability to lock devices to a version, granular control over the conditions under which updates apply, and more.

Many of these controls do exist pretty universally with OEMs, as many of the settings e-FOTA offers customers (not all) can be typically applied through configurations on the OTA servers the OEMs manage themselves. Take GOTA (Google OTA) for example, a product provided to certified partner OEMs for OTA management; some of the configurations which can be applied include:

Time limits on when to automatically download and install an update
Options for Wi-Fi only, temporarily or indefinitely
Mandatory updates during setup (some finesse to apply this to the enrolment flow would be needed)
Environmental restrictions (region, carrier..)
Device restrictions (IMEI ranges, storage required, build properties)
..and more

You could come to the conclusion that Samsung (and others) have simply productised their OEM OTA service, granting customers the ability to set these policies themselves, and then further built it out based on customer feedback.

In the same vein, Google could take many of these configurations and implement them as on-device APIs for organisations to leverage through EMM, offering far more granular control over when and how updates go out, and the conditions under which updates apply.

I'm not going to be one to advocate for long-term prevention of updates; in contrast with some in the ecosystem I prefer to see more updates, more frequently, and for far longer in a device lifecycle in order to best protect devices and the organisations that use them, but I do believe more control, more flexibility, and more options for update management would greatly improve the perception of managing system updates with Android Enterprise.

More control is a good thing, and I say that knowing Google's moves to reduce it under a veil of simplicity or privacy.

It won't fix the frequency, or number, of updates that some devices receive, and particularly won't help with devices that have been on a shelf for a considerable amount of time in reducing the number of updates required to get them up to date, but making that process smoother, until we have a solution that permits generating builds tailored to devices to get updated in as-few-as-possible, is a nice middle ground.

Ephemeral & multi-user support in AMAPI

Folks, it's been 4 years since this launched with 9.0, and I still can't define a shared-use use case with AMAPI.

A feature hyped so well with the 9.0 release, and justifiably so, yet it's barely mentioned today. I believe I last brought it up in 2020 in my Decade that redefined Android in the enterprise article, though it's been top of mind several times this year where customers have struggled to deploy a shared use case and AMAPI hasn't offered me the means to support them.

Work-arounds have included leveraging app data wiping on a regular (manually or API-automated) basis, full regular resets, policy switching (like data wiping but more aggressively) and a lot of generally sub-par accommodations for what is there, but not usable.

I understand many devices on the market may not be up to the task, considering multi-user support is heavy on device resources, but this can be clearly communicated and more can be done within GMS/CTS around the requirements for OEMs declaring multi-user support in an enterprise context than is done now. With feature flags declared, AMAPI can integrate support into compliance messaging for organisations and wonder about why it may not work well/at all can be communicated reasonably effortlessly.

Please allow 2023 to be the year I can finally configure the shared use case, including app caching and proper log in/out support.

Work & Personal SIM management (again)

Not a fortnight ago was I answering questions about SIM management for work profile deployments. The ability to assign individual SIMs in dual-SIM devices to work and personal profiles is a persistent feature request that's been in demand almost as long as work profile has existed; the fact it was in my list in 2019 already implies it was a common request among my customers and ecosystem circles.

More features around SIM management, dedicated dialler and call management features between the profiles, not massively dissimilar to the features released in 13 for NFC continue to be requested around the ecosystem, and this would be a lovely feature to have.

More AMAPI scopes (companion app control)

The companion app is intended to be the bridge between the still-limited AMAPI feature set and what EMM vendors want to be able to do. It could be a means for vendors to achieve feature parity with PlayEMM API vendors (AirWatch, MobileIron, etc) but unfortunately scopes remain few.

Above all else I'd like a scope to permit companion apps to invoke APIs on behalf of the Android Device Policy (DPC) so vendors could do things like add support for ephemeral/shared use next week if desired, but others I think would be useful in lieu of this include:

Package management (handling APK installations)
Full logging for debugging use cases (rather than limited logging currently offered with network & security)
Update management (primarily for manual system updates)

Compared to PlayEMM vendors, AMAPI vendors remain still fully at the whim of what Google opts to support, and when. It makes competing with the legacy behemoths difficult.

Make the Google Play approval process suck less

Re-linking an above example, but this is hardly unusual or isolated. The Google Play approval process is a nightmare; a black box of unknown duration, vague rejection messages, and overly aggressive policies unsympathetic to enterprise applications.

Yes, permanently private apps are spared most of the headache, but permanently private apps aren't always feasible.

Many corporate apps, or apps used by organisations are public, and don't fit the use case or can't meet the requirements of being made permanently private. These might be popular productivity apps, the EMM DPC, internal apps used by both customers and employees, OEM system apps, and several other use cases I won't dive into.

When an urgent issue arises, be it a bad update or a time-critical patch needing to be applied, public apps can sit in verification limbo for days on end. Some examples of issues I wrote already above, but another recent one I dealt with was a typo in an EMM application that went out to customers and caused enrolments to fail. This was patched same-day, but was then subjected to an accessibility permission policy violation that previously wasn't an issue, and persisted across 10s of app iterations over a couple of weeks attempting to adhere to the vague wording of said policy.

As Google embarks on #bettertogether and drives organisations back to identity-based Google account management across Android, Chrome, and their other products, it would be great to see the teams come together to offer a solution that eases some of the stricter policies and lengthy approval processes for validated organisations deploying public applications explicitly for enterprise.

Chrome Custom Tabs (CCT) configs

Reasonably straight forward - CCT config is pretty non-existent today and offers users a means of engaging with Chrome in ways that would otherwise not be possible on a managed device.

The only CCT config available today is a TOS skip, which is useful because that's an annoying popup, but organisations should have more control over the look and feel of CCT, and the options CCT presents to prevent unwanted tinkering by end users.

It's fine and reasonable for the Chrome team to want the CCT to look like a Chrome experience, but at the same time it should be possible to lock it down to prevent URL interaction. Hide the menu, prevent sharing, etc.

App launch after enrolment

Pretty simple one, and could probably be handled via DPC scopes, but it's another one of those dedicated device use cases with managed apps that require launching at least once to do what they need to do.

MAERGA!

Android Enterprise Recommended lost one of the greatest defining requirements of the recommendation when Google dropped the minimum update commitment. Today the requirements list for knowledge worker devices feels more like a checkbox exercise validating a proper GMS implementation of AE than anything else, though rugged requirements do at least still keep the bar a little off the floor.

AER has the potential to mean something again, and would benefit from a fresh injection of commitment from Google to properly hold OEMs accountable.

Bring back minimum update requirements. In 2023 is less than 5 years of security updates and two letter upgrades even worth considering?
Commit to better policing OEMs
Better communicate models/SKUs validated
Lean on best practices/optional preferred implementations in GMS as requirements
Cycle out older or irrelevant devices on a regular basis
Permit ecosystem feedback directly into the programme for catching OEMs not maintaining AER adherence.

Going into 2023 I'd look to phase out/archive everything on the directory to date, and work towards building up a new list of devices against a much higher standard of AE support and product commitment. No device should remain on the list after end-of-life (or support) and arguably anything not launching the latest version of Android on an annual basis shouldn't remain on the list either. If Google is recommending hardware, it should be worth it.

Multi-work profile support

It's a staple of my wishlists, more details here.

What do you want to see?

With more time and reflection I'm sure I could come up with a few additional requests for Google to fulfil, what would you want to see Google bring to market for Android Enterprise in 2023? Share this post and @me with your comments.

Thoughts on Android 12's password complexity changes

2022-12-19T00:00:00Z

The password complexity changes Google announced here and here with Android 12 for WPoPOD (work profile on personally owned devices) are rolling out to mostly-unsuspecting organisations as EMMs begin targeting API level 31 with their DPCs.

I'll be honest, I didn't consider this to be much of a big deal. Having caught the announcement back last year I assumed it would be logically, thoughtfully implemented with reasonable defaults, and wouldn't have much of an impact on organisations.

I was wrong.

Unfortunately, just one version release after they introduced and subsequently killed off work profiles on fully managed devices (I'm still not over it) in the space of a year, Google have opted to once again force through changes with little thought or consideration for the many organisations already leveraging Android today, and have done so in a way that harbours frustration and fragmentation with managed estates.

What's changed?

The technically inclined may find it interesting to read through the developer docs for Android 12 here and a reference to changes with AMAPI here, but to summarise it:

Google's newest password complexity APIs replace the traditional, decade+ old password complexity options with a solution that is intended to simplify password management and free organisations of the tyranny of choice.

Rather than selecting one of the existing complexity options, such as complex numeric combined with a minimum number of required digits, or alphanumeric and optionally defining a minimum number of letters, numbers, and special characters, Google has created three buckets that offer pre-defined and uneditable complexity options that create a "complete" password complexity policy simply by selecting it. These are as follows:

COMPLEXITY_LOW
Define the low password complexity band as:

pattern

PIN with repeating (4444) or ordered (1234, 4321, 2468) sequences
This sets the minimum complexity band which the password must meet.

Enforcement varies among different Android versions, management modes and password scopes. See PasswordQuality for details.

COMPLEXITY_MEDIUM
Define the medium password complexity band as:

PIN with no repeating (4444) or ordered (1234, 4321, 2468) sequences, length at least 4

alphabetic, length at least 4

alphanumeric, length at least 4
This sets the minimum complexity band which the password must meet.

Enforcement varies among different Android versions, management modes and password scopes. See PasswordQuality for details.

COMPLEXITY_HIGH
Define the high password complexity band as:

On Android 12 and above:

PIN with no repeating (4444) or ordered (1234, 4321, 2468) sequences, length at least 8

alphabetic, length at least 6

alphanumeric, length at least 6

via

As can be seen, all flexibility of custom policy definition is removed in favour of the above pre-determined options that Google suggests are acceptable for modern Android management.

Problems with execution

Putting aside the complexity bucket definitions I find very much contestable (4 digit PIN as "medium"?), let's look at some of the frustrations this is causing organisations based on the conversations I've had over the last few weeks.

It introduces policy fragmentation

The new complexity options apply only to BYO (work profiles on personally owned) devices, and only the device password. The work profile password (work challenge) still relies on password complexity.

Fully managed (including dedicated) devices aren't impacted by the change, and COPE (work profile on company owned) devices are out of scope at the moment; Google intends to expand to these at a later date as referenced in this doc, but with no public ETA that is subject to change, if it goes ahead at all based on ecosystem feedback so far.

So Google have deprecated existing password complexity options in favour of new, simplified offerings, but they only apply explicitly today to the device password on a personally owned device running a work profile. Every other aspect of password management across AE deployment scenarios still mandates the use of the old complexity options.

This fragmented approach to password policies arguably does more to increase overhead than the intended reduction Google touts as motive behind the changes, and honestly even if they were consistent with the new options across Android, these complexity buckets sit at odds with the password policies of other OSes Android once aligned with. Fragmentation on top of fragmentation.

Organisations don't have a choice

Personally owned work profile devices running Android 12 that are either newly enrolled, re-enrolled, or see policy changes after enrolment will be automatically algined to conform to Google's new buckets. The existing password requirements in place in an organisation will be subsequently ignored if they've not been updated to use the new complexity requirements (how often do password policies get updated?), leading to discrepancies between policies within the EMM and behaviour on-device - potentially only a subset of work profile devices as well, since those already enrolled will still abide by the already-set password policies once the EMM's DPC targets Android 12. Here's a demo of the differences between an older device and one running the latest version of Android with a standard numeric complex policy (no sound, apologies):

https://youtu.be/_3Vo7Zh3Wa0

Moreover, for the many organisations leaning on a 6 digit complex numeric password today, the closest bucket is considered medium, permitting end users to set 4 digit PINs instead of the required 6 by traditional password policies. Google suggests organisations shouldn't worry because they've had decent brute force detection in place, but that doesn't in any way make me feel better about arbitrarily reducing password security.

To echo my views on WPoFMD, this should have been an option, not a requirement. I'm sure some organisations, especially those Google have been trying to target over the last few years with little to no experience with Enterprise Mobility, may see these new complexity buckets as something useful, but the many more established organisations have taken the time to develop their security policies, have them rolled out confidently across their estate, and will now be subjected to an unnecessary and unjustified overreach by Google of their BYOD security policy.

Closing thoughts

The biggest frustration I have with this is the loss of choice. A theme I fear is popping up too frequently for an OS known and marketed for it's flexibility and ability to adapt to how people want to use it.

Google could have added these complexity offerings as an additional option, but has chosen to deprecate and replace instead.

Alone, complexity buckets will undoubtedly add value for inexperienced or blissfully ignorant organisation admins with a purely-BYOD estate who want a quick, low-effort password policy to enforce on devices, but that's where the usefulness of these buckets stops.

Going forward when I'm engaging with deployments, not only do I lose the flexibility to define the password policy for devices I want to - given the fixed nature of these buckets - but I'll have to explain why every OS and Android deployment scenario provides a reasonably consistent password policy experience except work profiles on personally owned devices, which has to be defined & configured separately. Wild.

Google Play target API requirements & impact on enterprise applications

2022-11-12T00:00:00Z

Update 12/22

Google has since relaxed the timeline for when the November changes take place. Developers now have until 31/01/2023. Furthermore, permanently private applications, such as those made private in the Play console, as well as those uploaded via the API or managed Google Play iFrame, are exempt from this policy change.

It's no secret many organisations struggle to keep pace with Google's Play Polices, often relying on applications built years prior benefiting from few updates to maintain minimum viable compatibility, eventually either breaking for newer devices, or having updates rejected for policy violations corresponding to app behaviour that was never an issue when the application was first uploaded.

Equally common are how these applications have historically been distributed; through EMM solutions as APK files pushed to devices, rather than leaning on Google Play.

In the last few years however, use of Google Play with it's many benefits for application distribution has been on the rise in enterprise; be that through the use of the Play Console directly for established developers, the EMM-integrated Google Play iFrame (which is yet still to support app bundles, Google), or the Custom app publishing API for simplified uploading of private applications with substantially fewer policies to adhere to. That said, some policies do still apply, and minimum targetSDK is one of them.

Play policies around minimum targetSDK version have been around for a few years, but this year marks a significant change to the behaviour of applications that fail to keep pace, that will significantly impact app deployment for managed estates.

As described in this blog post and this help article, applications that do not target API level of 30 (Android 11) or higher in 2022 (and going forward year-on-year, maintain at minimum n-2 target SDK) will no longer be available to newer Android devices.

What does that mean?

If an application targets API level 29 or lower as of ~~November 2022~~ February 2023, it will no longer be discoverable or installable through Google Play (the on-device Play app) for new users with devices on Android 11 or above, and therefore distributing an application with a lower targetSDK will simply never turn up on new devices. What this means in practice for applications distributed for enterprise is -

Existing devices remain unaffected
New devices enrolled running Android 10 or lower will receive the application without issue
New devices enrolled running Android 11 or later will not receive the application, and will not see it within managed Google Play either
Permanently private apps remain unaffected, ie those uploaded and targeted to an organisation if via Google Play console, or anything uploaded through the managed Google Play iFrame

When debugging the app installation, or lack thereof, logs should show failure to install due to a compatibility issue.

It's by no means uncommon for applications to simply not turn up on devices, often this is due to a geo-restriction set by the developer, a permission issue (where an app may require a camera on a device without one), or a genuine compatibility problem (32bit apps on 64bit OS, for example). This latest change simply adds one more reason as to why an app may not be installing on-device.

What can be done?

This timeline has been well-publicised throughout the year, so hopefully any applications relied upon by the November deadline have been updated to align with the new policy. If this isn't the case, and deployments are being affected, the immediate workaround for scenarios where productivity grinds to a halt on newer Android devices would be to apply for an extension within the Google Play console, per Google:

If you need more time to update your app to target API level 31 or above, you can submit an extension request for your app to continue being discoverable to all Google Play users until May 1, 2023. Check your Play Console Inbox Messages for links to each of your app’s extension forms.

It looks like this:

And once granted (almost immediately):

If that is rejected for any reason, or the timeline of the 6 month extension is not quite enough to get applications up to the standards Google requires, distributing the APK via EMM directly where supported - as reluctant as I would be to recommend it - is still a viable option for organisations that cannot wait for an app to be updated. Do bear in mind some of the caveats:

If an application is considered incompatible or fails to install, an EMM will often retry, sometimes indefinitely, to push the APK to the device. This can incur immense fees on data usage over time
Apps pushed as a single APK are often larger and not optimised for individual device-types or OS versions

The obviously recommended resolution is to update the application to target a modern API level, though understandably additional considerations need to be evaluated -

What new policies or requirements exist for the new API level vs the current targetSDK (there are likely several)
How is the app affected by targeting a newer API level (the addition of explicit permission requests for example)
What features may be lost by targeting a newer API level? Particularly pertinent for older device admin-style applications still clinging on to deprecated functionality
.. and more

Bringing an application up to a modern targetSDK can be frustratingly non-trivial, in spite of the security benefits and additional functionality (whether relevant or not to the application's use case), but it is a necessary undertaking to maintain a healthy, compatible enterprise application. As Google marches on with ever-stronger policies for app security and compatibility, organisations leaning on Google Play for app distribution must take Google's policies seriously, plan well ahead, and keep on top of application development to avoid issues in the field.

Sunsetting Discuss comment platform

2022-11-02T00:00:00Z

After a bit of thought, I've decided to shut down the Discuss comments platform.

My intentions were to build a community site with Discourse hooked in to the main website to both act as a comments platform for the posts and docs I publish, and slowly become a bit of a standalone forum for general discussion and support.

After a few years and admittedly very little promotion of the platform on my part, the costs of running another server separate from the main website just for this no longer make sense.

Going forward I'm not planning on implementing a comments system back into the main website since people can and do reach me on various forms of social media or via email on a regular basis, and there are better communities to find me lurking for support than my forum, such as:

Android Enterprise Help Community
EMM.how
Mobile Pros Discord Community
Reddit
You can also ask for content or raise issues with docs/etc on GitHub where I keep the source to this website

All user data on the Discuss site will be deleted, I do not plan to migrate to anything else at this time.

Google publishes differences between Android and Android Go

2022-10-25T00:00:00Z

I've been on a bit of an Android Go tangent recently, after a string of customer and ecosystem interactions really shone a light on the lack of public information Google has provided and the issues this is causing in enterprise deployments.

Just a short several weeks ago I wrote:

Starting with more transparent, public documentation akin to the CDD about exactly what Go devices can and cannot do would be a massive, low-effort change that could clear many uncertainties up immediately and help ecosystem partners better understand what it takes to make sure their solutions are Go-supported. It'd equally help customers to decide up-front if Android Go is suitable for them, rather than the current approach of test-before-deployment that seems to be in relied upon currently.

It's probably little more than coincidence that I've been raising the lack of transparency with Google quite frequently over the last few months, but seemingly in tandem with the launch of Android 13 Go edition Google have also published a few documents to highlight the differences between Android and Android Go.

First, a blog series for developing applications for Android Go, which shines a light on some of the limitations of the flavour, as well as it's minimum requirements: https://android-developers.googleblog.com/2022/09/optimize-for-android-go-lessons-from-google-apps-part-1.html

And more recently, the Android Go guide has been updated to show (some of) the differences between the two Android flavours: https://developer.android.com/guide/topics/androidgo#differences-from-android

This isn't by any means the full picture, as there are other restrictions - including the inability to draw over apps mentioned previously, lack of widget support, and automatic dimming, amongst others - but it's a jolly good start and should help organisations better evaluate the Android flavour before committing to the otherwise very affordable hardware associated with Android Go, especially as the 2GB RAM requirement and some of the better features of full-fat Android (such as mainline support) continue to trickle over.

Android Go & EMM support

2022-08-12T22:42:00Z

Android Go edition has been around for a while. Launched way back in 2017 as a successor to Android One as the One programme underwent it's own evolution into what we have today, Android Go took over as the flavour of Android for low-end devices. While originally memory requirements to qualify for Go were very low - anything under 1GB - today any device launching with 2GB RAM or over can only be certified for Go (as of Android 13).

In spite of common misconceptions, certainly not aided by folks like the NCSC publishing incorrect information, Android Go does in fact support Android Enterprise. But not fully by default.

🟢 Fully Managed
🟢 Dedicated (COSU)
🟠 Work profile
🟠 Work profile on company owned devices (COPE, WPoCOD)

Due to the memory constraints associated with Android Go devices, the work profile deployment scenario in the past has been recommended against, and since Android 12 is optional (factoring in the increased memory requirements), and therefore dependent on the OEM for implementation.

In addition, since late 2020 Android Go has also supported zero-touch by default, which was also previously opt-in for OEMs prior to ZT's integration with Google Play Services.

Not only then has Android Go supported Android Enterprise for many years, but it has improved over time.

With that said, recently VMware announced support for Android Go with version 22.06 of their Intelligent Hub DPC (the on-device VMware agent), and I opted to probe a bit into exactly why EMMs are making claims to support, or not, Android Go in the market today.

Because Android Go does limit functionality, and the behemoths of the EMM world like functionality, it appears to be less to do with Android Go supporting Android Enterprise, and more to do with EMMs not being able to hook into the permissions and services they need to enable their functionality.

VMware in this case now officially claim support for Android Go where they did not previously. They've taken the time to review the platform, understand the outstanding issues their product(s) have in supporting Android Go, and have applied greater focus on their testing and development efforts in order to now offer - albeit limited - support in line with what Android Go customers should expect.

Caveats do exist, notably at time of writing limitations apply to Workspace ONE Launcher - which seems primarily due to the Draw over other apps permission requirement not being enabled on Go - and some product provisioning features, which are perfectly reasonable considering the restraints on resources available. Those aside, for the customers looking to deploy exceptionally low-cost, limited-use devices in their WS1 UEM managed organisations, there's nothing technically now preventing that.

But when you look at some of the other vendors, the effort still isn't being applied.

MobileIron reference AER for device selection, which isn't particularly useful if your budget only affords Go-level hardware (though the AER plug is a good one nonetheless), before continuing on to incorrectly state WP is not supported, rather than optional, and then finishing with MobileIron's actual stance: "possibly works doesn't mean officially supported".

Meraki incorrectly claim as recently as July that Android Go doesn't support Android Enterprise at all, following customer complaints of enrolment failures.

SOTI, IBM, I couldn't see any solid view one way or another in public docs.

Established EMMs aside, some of the more modern solutions running on the Android Management API (AMAPI) all appear to support Android Go fine, including Microsoft Endpoint Manager (Intune), Wizy, and several more. Arguably of all the testing I'd done, enrolling into my company's Intune environment with all of the app policies, conditional access, suite of non-Go applications and more was the most taxing, and the Android Go device I have handled it perfectly fine.

Overall I think Android Go support is a bit of a sore point for the ecosystem today. There's clear misunderstandings in what can and can't be supported with the lighter Android variant, and not a lot of visible effort to put that right.

Perhaps this is something for Google to turn their attention to in the not-too-distant future, as I'm sure Go's expansion to the 2GB memory threshold is only going to grow the Go footprint around the ecosystem.

Starting with more transparent, public documentation akin to the CDD about exactly what Go devices can and cannot do would be a massive, low-effort change that could clear many uncertainties up immediately and help ecosystem partners better understand what it takes to make sure their solutions are Go-supported. It'd equally help customers to decide up-front if Android Go is suitable for them, rather than the current approach of test-before-deployment that seems to be in relied upon currently.

Relaunching bayton.org

2022-08-06T21:41:00Z

Welcome back!

Every few years I like to roll out sweeping changes to this website. Whether that's to keep up with modern design trends, to apply a fresh coat of paint, throw in usability improvements, or just to wipe clean and start again without the accrued bloat of years of tweaking, it's a nice opportunity to look at the platform from the ground up and re-assess what I want this thing to do.

For this release, it's primarily about the back-end maintenance & functionality; my goal here was to get off of WordPress, which is a fine platform by all regards, and switch to something static. I landed on a combination of Eleventy and Cloudflare Pages which, in addition to leveraging CF's global network to improve latency and load times to my biggest - but most distant - audiences (up to recently all served from London), took my hosting costs from ~£15/month to £0.

Let's get into the changes.

The new theme

For version 6 I wanted to focus on white space, easily consumable content with minimal distraction, and a site that loads quickly with little unnecessary media. Articles will of course have the uploads they have (as above) but the structure around the content should load very quickly on non-media-heavy pages. This has been reflected in the removal of most stock imagery, featured images, topic-based-icons, and more, and leaves a mostly text-based result that I think works well (it's of course subjective).

The site has been reduced from several page layouts and is now split across two: single-column and dual-column. Pages and the home page work single-columned, while articles and documentation leverage a two-column layout to support page contents and contextual navigation. If there are any special cases, such as the multi-column layout of /android or the like, these are now done in-page with a bit of specific styling, therefore reducing the complexity of the overall design and template-for-edgecase approaches used previously on WordPress.

The main blogroll (articles) now live under /blog as this was much easier to manage from a content-organisation point of view, and follows how documents are stored also.

The footer is still a work in progress, but it's functional for now.

A new logo

After a good 7+ years with the old logo, it's time I think for a change. I opted for a simple stylised signature, and I'm really happy with it:

I've coloured it purple above to suit both dark and light themes when viewing this post. It'll likely remain only black/white unless a mood strikes.

This logo will start showing up on my downloadable content and everywhere else over the next few weeks.

Dark mode reintroduced

Dark mode has come and gone a few times over the years, and has had caveats with every implementation. The last time I posted about it was in 2017, but since then I've tried a few iterations I hadn't ultimately been happy with.

That's changed in v6 (v5 in fact, but that didn't make the cut), as modern CSS and browser support has allowed not only for dark mode to be implemented in a much simpler manner (I'm not a javascript fan by any means, and they often rely on this), but allows me to leverage media queries to automate dark/light based on user preference automatically as well. The CSS incorporates a simple @media (prefers-color-scheme: dark/light) {} query that handles all of the automation there. It's nice.

WordPress Eleventy powered

This site has been WordPress powered since inception, and it has served me well. As time has passed however and I've dabbled with plugins, themes, customisations, and more, it has bloated out from a minute site into a behmouth that's simply a pain to manage. Add to that the need to pay for hosting over the years, VM security, system management, and it's all a bit of a farce.

Not wanting to spend more for managed hosting than I do on VMs is one reason I didn't offload the site to a managed WP cloud provider or switch to WP.com, the other being loss of control and the limitations on underlying services that would cause incompatibilities with how the site is deployed. A multitude of reasons have popped up over the years, and I've rebuilt the site from fresh copies of WordPress multiple times (as much as I'd like to say I've upgraded the one WP install from 2.x all the way up to today) to attempt to reduce technical debt, but I've had enough.

In addition to reducing overhead, I've wanted to push all of my content to GitHub for a few years. As a hub of information all about Android Enterprise and the desire to keep producing content, maintaining the changes Google introduces so frequently can be a bit of a chore. Things like when Google updated branding from Android for Work, to Android enterprise, to eventually Android Enterprise, or all twenty-eight names for COPE they've come up with so far and the associated acronyms (😉). Each change required the manual edit of up to 100 articles and docs, or in one case a direct database find & replace, which is not ideal.

There are obviously the community/contribution benefits to being open source as well, meaning organisations I work with can directly contribute their logo to my logo folder for display on the site, contribute their own DPC identifier or zero-touch DPC extras without filling in a form, raise issues on outdated/incorrect content, and more. Blimey, I may even consider a doc/article or two with attribution if it's decent.

Over the last year I had started building a new PHP CMS from the ground up (I know enough to be dangerous) with another custom theme, v5, still hosted up on the beta site at time of publishing, but a few weeks ago I was introduced to Eleventy by my UX Engineering colleague and honestly, it made far more sense.

Remaining on a PHP-backed solution would retain the need for hosting, even if only minute, and even if all content lived up in GitHub, which would continue the systems management overhead I don't really want to do. Eleventy allows me to develop and build locally, and combined with ~~CloudFlare Pages~~ Netlify integration with GitHub for automated deployments, it means I don't need any self-managed infra in place to keep the site up.

Today I can knock up my markdown-based post in whatever text editor (or GitHub.dev if I'm not using my normal setup), push it to GitHub, and minutes later it appears on bayton.org. Magic.

WIP

The new site isn't fully finished, and I'm working through an issues list that's getting smaller by the day. Over the next few weeks I expect to get everything sorted and 1:1 with the old website. You'll notice for example on mobile at time of publishing there's no menu for the global nav, and if you've used RSS to pull content in the past, you won't have seen this come through yet. It'll get there soon enough.

Some of the content has been shifted around. Things like the Android docs now living under /android and not /docs/enterprise-mobility/android as I shift away from the wider EMM content strategy and continue to specialise in all things Android. /docs over the next few months will likely disappear, but all content has redirects in place so nothing is lost. If you do link to me from your own internal or external resources, give that a courtesy glance when you get a moment, but rest assured I believe I've handled all forwarding (and I'm watching 404's daily).

If you find issues with the website, please feel free to raise it on GitHub and I'll add it to the list. I think most of the bigger issues affecting site usability are resolved as of now though.

If there's an issue with content, you can either raise an issue, or contribute an edit directly, as so:

(I'm back to using a Mac as my primary machine, so GIFs are absolutely coming back to my content more often).

If you've been visiting the site for a while, I trust you'll find the new site as usable as ever, and hopefully moreso. If you have feedback or suggestions, you know where to find me 😁

AER dropped the 3/5 year update mandate with Android 11, where are we now?

2022-01-11T17:58:00Z

Continuing on from losing my bet with Google, I’ve been spending some time with the Android security transparency report and ended up taking a long, hard look at the impact of dropping the Android 10 & below requirement for devices to receive 3/5 years of updates in order to be recommended by Google.

For those who missed it, the AER requirements for Android 11 changed from a minimum update term, to the following:

Google never publicly published the 3 year mandate for knowledge worker devices – for reasons unknown – but it was there nevertheless. The new requirement would make a great addition to mandated update support in requiring more transparency, but alone it’s pretty weak.

As mentioned in my previous post the transparency report data ceases in September of 2021, so until the next update it’ll be difficult to understand what impact dropping the 3 year support requirement on AER models from Android 11 will have on ecosystem stats overall (considering the number of AER devices is getting pretty sizeable!) though it’s clear Google’s work in improving 90 day update support across MADA-compliant devices within the ecosystem is working, and Android hardware is in a much stronger position than even 3 years prior, where less than 60% of devices were declaring security patches within the prior 90 days.

It’s unlikely Google will track further out than 24 months so the transparency report will only offer value to a limited extent in monitoring overall longevity of update support; instead properly understanding how long devices will be supported will require a lot more work in tracking the OEMs themselves, either through Google’s AER directory or on the OEM website directly, once such example is HMD Global’s Nokia Smartphone Security Maintenance Release Summary (No guaranteed Security Patch updates after):

When filtering the solutions directory to show devices guaranteed to support security updates through to January 2025 (three years from buying a device today that would fall within the 90% of 90 day declared security patches) returns only 10 units for Knowledge Worker (ie, non-rugged, phone only), and they’re all Samsung.

Rugged phones add an additional 12 units to the mix but these include devices that fell into the 5 year security update support requirement Google mandated up to Android 10, also dropped with 11. Rugged devices also benefit from much better lifecycles generally, with the likes of Zebra working really hard to keep devices up to date, but they’re hardly suitable for all types of deployments wherein knowledge worker devices are a better choice.

Falling back to September 2024 as a minimum declared end of support date adds 8 non-Samsung units, all of which launched in 2021, for a total of 20 models guaranteed to see updates for 3 years from launch. 11 additional devices were added to the AER list in 2021 that offer far less software support, such as the Moto G Power (2022) that’s only recently been released, and loses support already in November 2023, or the TCL 20 R 5G, with only 23 months of support committed.

Of the >900 models declaring 90 day update support in September 2021 then, Google can recommend 20 of them in the knowledge worker category – the SKUs of which requiring additional validation by the customer purchasing them as not every version of the same model (geo, carrier model, etc) is supported to the same degree – to handle a minimal 3 year lifecycle, dropping immediately to 10 through 1 OEM if wishing to buy a device and expecting at least 3 years of support from today.

How Google could conceivably grant enterprise recommended status to devices losing support so soon after launch is beyond me, but this is a direct, obvious result of them dropping the support mandate in favour of inclusivity, and puts far more onus on customers to go back to the days of needing to verify the devices they purchase themselves for suitability – something AER was supposed to render mostly unnecessary, and could have continued to incrementally improve over time; pushing OEMs to meet lifecycle longevity across the ecosystem more akin with Apple from the perspective of “Android” as opposed to “Samsung“, “Point Mobile” and other individual OEMs that push to extend product lifecycle support alone.

Closing thoughts

I am and continue to be impressed by Google’s commitment to the shorter-term prevalence of security updates across the industry and imagine we’ll get to a point where almost everything (never everything) is meeting the 90 day or better security update schedule. Combined with the continued push of Mainline to modularise and update system components through Google Play, it goes without saying Android security has really never been in a better place than today.

That said, the barely-viable two-year support mandate from Google for GMS today is less than ideal from a consumer perspective, and basically a non-starter for enterprise and the typical hardware lifecycle expectations there. The AER program had an opportunity to boost this standard for devices intended to be enterprise-targeted, with positive consumer trickle-down, and then gave up. Shifting the responsibility back onto OEMs to declare transparently what they’ll support in order to recommend them, vs making them meet a minimum viable standard to be considered massively devalues AER from my point of view.

Hopefully that’ll be reconsidered when the AER requirements are re-assessed in one of the next major releases, and we can get to a place as an ecosystem where organisations like Fairphone, or devices like the Nvidia Shield (I know it’s Android TV) aren’t seen as outliers for continuing to support their hardware for so long.

Here's a quick survey

Loading…

I made a bet with Google (and lost)

2022-01-11T17:57:02Z

The year is 2020. The topic? Update prevalence & support within the Android ecosystem.

Google had not long dropped the requirement mandating three* years of security updates for AER devices in favour of OEM update transparency statements – which is still a bad idea in my opinion – and I found myself expressing displeasure at the thought of long term support akin to iOS and desktop operating systems rapidly returning to little more than the pipe-dream it had been for so long.

Around the same time, Google published their annual Android Security Transparency report showing an ever-improving percentage of ecosystem partners publishing security updates within 90 days (around 80% across over 800 models with >100k units in the wild) and given the AER news I struggled to imagine this improving far beyond without big changes made by a select few historically problematic OEMs that made up a growing proportion of devices on the market at the time.

*AER has technically always mandated two years of security updates, with a further year of critical update support as needed, but nevertheless.

That isn’t likely I assumed, given Google’s typically softly-softly approach to making ecosystem partners fall in line, as evidenced through a history of proposed CDD changes ultimately dropped before release due to pushback or reigning their enthusiasm back in, but Mr. G was adamant it’ll continue.

So we made a bet.

Either it stagnates/decreases resulting in a static or downward trend, or it grows through the 80’s and into the 90’s over the following months, showing an upward trend. Loser buys a steak dinner. It’s not a 1:1 of the issue I took originally with the ecosystem dropping updates for supported hardware sooner, but it’s a decent ecosystem indicator nevertheless.

Looking at the transparency report today, it would appear I owe Mr. G a steak. Although it peaks and troughs in line with devices being added to and dropping off the list as they launch/fall outside of the 24 month window, there’s a clear upward trend that’s steadily grown since Dec 2020 when the bet was made through to when data stops in September.

That means consumers and organisations who’d purchased devices launched in the last two years of Sep 2021 are highly likely to be receiving regular security updates, though for how long is now entirely down to the OEM and no longer guaranteed or enforced by Google.

So what of extended support?

This is looking less impressive, and is covered off in detail here.

Product files: Building Android devices

2020-12-26T18:21:12Z

Welcome to Product Files, a series of articles that touch on some of the more interesting aspects of running a product organisation for the last several years.

As this series grows, additional links will show up here:

As 2020 comes to a long-overdue close and we head into what anyone can hope will be a slightly less chaotic new year, it also edges closer to what will soon be two years leading product with Social Mobile. With the results of all the hard work now materialising, I think it’s interesting to reflect on the last >18 months, what it’s lead to, and what’s next.

Note: The following is a personal take on a work-related topic. For normal Android Enterprise content, please head here.

The leadup

I’ve spent many years on the consumer end of Android, from devices purchased for my own use over the last decade, to those I’ve reviewed in an enterprise context through my efforts on Android Enterprise. I have, and still continue to engage with OEMs in the ecosystem for devices I test on a reasonably regular basis, pointing out issues with implementations, random bugs, offering advice where asked and so forth, but that’s typically where it stops; once I’ve said my bit the feedback is taken internally and tends to fall into the ether of internal triaging. If I’m lucky, a few weeks to a couple of months later I’ll get a ping to say a software update addresses previous concerns, but more often than not that doesn’t happen.

With the lack of transparency also comes a few other common experiences – OEMs move slowly. Their engineering teams are inaccessible or don’t speak to outside parties. Enterprise concepts and/or best practices are either not known or not prioritised, and so on. Today in fairness it’s substantially better than it used to be through the education and motivation provided by programmes such as Android Enterprise Recommended, but I could still earn a decent living consulting for OEMs if desired.

In any case, after years of telling OEMs how things should be done with zero experience of the processes on the other side, I’d often wondered what could really be involved in building Android devices, and if I could easily translate my knowledge of Android – both Enterprise, including best practices, custom APIs, device management, etc, as well as exposure to several years of communities such as XDA flashing ROMs and learning what tweaks to various rooted devices do what – to give me a solid rolling start on the parts I knew less about – GMS, certifications, hardware requirements, testing, building from AOSP, etc.

An opportunity for change

Back in 2019 I’d reached something of a plateau working at an MSP. I knew where I wanted to be in my career and how I wanted to spend my time, but there wasn’t enough ongoing business to justify the wage of me being selective on the work I undertook. Android deployments were scattered amongst other, less interesting but oh-so-repetitive installs, customer support was poking around networks and analysing server logs, MSPs generally began shifting towards Microsoft hard and I wasn’t feeling it.

When the opportunity arose to pivot, I left the last MSP I’ve worked for as an Enterprise Mobility & Android Enterprise SME after several years of the same kind of role and headed into a completely different, though more than tenuously linked, industry – device manufacturing.

I say more than tenuously as it’s a different approach to the same end-goal, contributing to the evolving Android ecosystem. Rather than spend my days supporting Android device deployments (as well as iOS, and more), going forward I got the opportunity to be mostly making the devices, the services and shaping user experiences for others to support.

Not as easy as it looks

It turns out I wasn’t entirely lost coming into this, as my general understanding of the platform and how many things should work helped significantly. That said, a decent amount of what I’d known applies to the last mile of making Android devices. Everything before that, from SoC support to component availability, camera tuning to performance optimization, aligning to GMS, a whole slew of NDA aspects of being a MADA partner, and more, were brand new, if certainly not insurmountable challenges.

I’d been very much blissfully ignorant to a lot of this when previously raising an issue with an OEM, assuming patches should be available with relative ease and with a quick turn-around given they all have teams of engineers at hand, or questioning why support ended early for hardware, or focusing purely on the OEM for opting not to support a new OS release because they didn’t want to dedicate the engineering effort. In some cases sure, OEMs are lazy, but in others there are legitimate limitations not controlled entirely by the OEM (and not strictly the SoC vendor killing support). Who knew? This is potentially a topic I might explore in future.

Diving in

When I joined Social Mobile, it was intentionally timed for me to take on a brand new project, building the company’s first own-brand portfolio of commonly-requested devices. With it came the opportunity not only to give the hardware its own brand (Rhino) but also to define for the first time the software experience against a set of requirements not laid out by a customer.

SM is not a typical, consumer-driven, annual-refresh type of OEM, but an enterprise-first, B2B OEM specialising in the dedicated and bespoke solutions not typically available off a shelf, with extended periods of support and availability. Very commonly devices only come to be when an engagement from a customer kicks off, and following 6-9 months of design, testing, software bring-up, optimisation, manufacturing, and more, and with that come things like minimum order quantities and upfront non-recurring engineering (NRE) costs.

Devices built have historically been private-label – under the brand of the companies that engage to bring up Android solutions, so it’s understandably scarcely a name one would see when browsing devices, despite a significant number of carrier customers in the US at one point having a device made by the company.

The portfolio marked a shift in strategy and an ability to target market segments that normally go for the lower-volume, easily available hardware over something bespoke, the SMBs and mid-tiers. For me it offered an opportunity to push a roadmap, dig deep into the Android CDD and GMS requirements with which to align, and more than anything to get hands-on with every aspect of creating new devices; a perfect opportunity to learn on the job with the support of a production team well-versed in device manufacturing ensuring nothing could slip through the cracks.

Why RHINO?

A lot of potential names were thrown around with the team. It came down really to what just sounded decent. Fruits are well done, Space themed led to a few decent options if a little corny, but it was ultimately Animals that came back most frequently and ended up between Rhino and another; since Rhino has connotations of strength and durability, we settled on that.

The result

The result of 18 months of ground-up research and development has led to the introduction of four new devices, the Rhino T8, Rhino C10, Rhino M10p and Rhino T5se. Two tablets, a hand-held, and a POS.

Rhino T8

A simple, 8″ tablet powered by MediaTek in a 32/2 configuration. Launched on Android 9.0 with Android 10 expected early ’21. The T8 offers an affordable solution for lighter workloads.

Rhino C10

A higher spec 10″ FHD tablet running 8 cores in a 32/2 configuration. Also on 9 with 10 planned for Q1 ’21. The C10 is noteably more performant and capable for mid to heavier workloads.

Rhino T5se

A 5″ handheld featuring a slim yet powerful integrated Honeywell barcode scanner, powered by an 8 core MediaTek SoC in a 4/64 configuration. Launching on 11 in early ’21.

Rhino M10p

A first-of-kind certified EPOS with cash register compatibility, an integrated Seiko thermal printer and a nice, long LED light bar on the front for clear visual alerts in loud environments. 8 cores in a 32/2 configuration and a boatload of IO on the back. Launched on 10 with 11 in ’21.

All of the above, as well a few more in-progress devices, including a 27″ kiosk and a couple of larger Android powered displays, are available now or coming soon, and I’m super excited to get them out into the wild.

One might think “tablets aren’t dedicated devices”, yes and no. Though tablets are portable with integrated batteries, these are built specifically for fixed use, particularly concerning power management where they live connected 24/7 to a power source. Customers can leverage included docking options or opt for any universal tablet mount solution. There’s flexibility to be had in adopting existing form factors for alternative usecases.

As the devices are both enterprise-grade, and products influenced by my own experience and biases, they’re aligning with what I’d consider an expected lifecycle currently, in supporting least one major OS version upgrade and from 3 to 5+ years of security updates depending on the device. Furthermore, because they’re built with component availability prioritised from the get-go, they should be available to purchase for around three years also from launch, far longer than most consumer kit.

That isn’t intended as a sales pitch so much as a goal and a standard I’m driving Social Mobile towards as one cog in the wider ecosystem-driven machine working towards progressing the normalisation of longer device lifecycles across the industry. One of those initiatives has included the partnering with MediaTek’s AIoT division for long term SoC support (LTS), and I’ve looked on with excitement at what Qualcomm are doing as of late also.

Those who’ve read what I write here, on Twitter, or on LinkedIn will have undoubtedly seen the occasional frustration at OEMs who kill devices off too soon given the perpetual perception of Android security and fragmentation already, and with SM I get to contribute to the changing of this.

What’s next?

I’ve focused a fair bit on hardware here, which is a given considering that has been the primary goal over the last 18 months, to build the portfolio, but hardware isn’t the focus, or certainly won’t be for much longer.

With the hardware out of the way, by which to say properly road-mapped, hardware revisions strategised and so forth (more form factors are on the way), the focus instead turns to the experience; the next steps that transform individual devices into a suite of products and services. Some of this includes:

OEMConfig

Technically already under way, and picked up by a few outlets in the process once it was whitelisted by Google (sorry folks, it’s going to change), OEMConfig so far has been a mix of APIs across a few of the available devices. Going into ’21 a lot of engineering effort will be devoted to unifying APIs across all devices running the Global SKUs, and building out many more than are currently available today.

OEMConfig, as I’ve written about many times before, is a revolutionary solution to enable the extension of Android Enterprise APIs for bespoke features and advanced usecases.

APIs are created based on demand, valid industry use cases, and occasionally good ones adopted from bespoke projects, since custom APIs are a very normal request and part of the software solution offered as a custom device is brought to life.

Android Enterprise Recommended

Due to the cut-off on OS versions for AER device submission and the long bring-up time for the portfolio to date, AER has been a top of mind but not feasible in spite of aligning with the recommendations and requirements of AER by default across all devices.

That said, as products either upgrade or receive their final production software ahead of launch, everything currently eligible for AER will be submitted over the first few weeks of ’21. With any luck that alignment will pay off and the devices will sail through without a problem.

Long(er) term support and upgrades

Maintaining the one OS version upgrade and 3-5 years of 90 day security updates as implemented today would be more than acceptable within the current ecosystem, but doesn’t align with the longer strategy of device lifecycle support I’d like to achieve, especially when thinking of the life of a dedicated device: one job, fixed in place, often connected to a corporate network, and often also a point of interaction between an organisation and a user.

The 90 day cadence for one can be improved, and though a 30 day cadence is currently a significant undertaking, it won’t be in future as Social Mobile continues to grow. This extends to major OS version support; 1-2 today is more than possible, but as our partnerships with SoC vendors and component manufacturers continue to flourish, and we’re less impacted by SoC EOL, the aim will be to support three to four major OS version upgrades in future through the entire device lifecycle (this won’t be soon).

On updates

There’s something to be said for frequent updates and the pushback occasionally associated with larger organisations for managing them. As a short term compromise for these organisations, additional update control over and above Android Enterprise is planned before cadences change. Longer term though my view is more frequent, smaller, incremental upgrades are often safer than maintainance releases with more drastic changes. Not only due to the limited scope of change and lower effort in testing ahead of rollout, but also the update sizes and the impact on corporate networks supporting hundreds to thousands of devices; even when deploying OTA files internally via EMM (when supported, please and thank you VMware, others).

In achieving a more rapid security update cadence, having a means of reducing the perceived work effort for organisations is top of mind. Having the benefit of working directly with some very large organisations as opposed to through resellers will be instrumental in progressing this, of course I’ll be talking to the wider community also.

Advanced management

Once OEMConfig is matured and well-rounded, attention will begin to shift to extending management of Rhino APIs, both existing and out of box, via an in-house configuration platform. With existing customer engagements I’ve already had feedback requesting means to prevent device setup without a network connection (a limitation of zero-touch), closed-network style provisioning options, preloaded network options and the ability to receive devices in a particular state of limited/locked down functionality ahead of device enrolment, these use cases and more will be targeted with a new service.

This type of solution isn’t new or revolutionary, OEMs already offer this in the market today. I’ve long been a fan of non-EMM configuration tools and am excited to see where one built in-house can be taken.

And more…

…but I can’t give everything away today.

In summary

I’m extremely happy with what’s been achieved so far, and the experiences had getting to grips with developing solutions from the ground up powered by the most versatile OS on the planet.

It’s been eye-opening, extremely educational, and incredibly rewarding; I can’t think of any other role with any other company where I’d get so close to the end product, never mind being able to define every aspect of it!

It’s offered opportunities to deploy devices to some very interesting customers and engage on some fascinating use cases. With a considerable amount of devices pushed out just leading up to Christmas, and with hundreds of thousands more in the pipeline for next year, a whole new set of challenges and opportunities for collecting feedback, growing the offering, undoubtedly fixing issues here and there as things scale, and more will come to light as increasing numbers of deployed devices introduce further scrutiny of the product from both customers as well as Google.

I can’t wait.

Google announce big changes to zero-touch

2020-11-10T15:09:22Z

Google today dropped the most significant update to zero-touch since its introduction with the Google Pixel back in 2016!

Rolling out over the next several months, all GMS certified Android devices – new and existing – running 9.0 or above will support zero-touch by default, with no additional OEM effort required.

Why does this matter?

Zero-touch, Google’s equivalent of Apple’s Device Enrolment, Samsung’s Knox Mobile Enrolment, and Microsoft’s Autopilot, allows for the assignment of a device to a customer-defined EMM platform before it’s even taken out of the box.

It means I as a customer can purchase devices from a zero-touch reseller, have them added to my zero-touch customer account as part of the purchasing process, and ship them directly to my end users without any hands-on effort required – zero-touch, if you will. It’s a pretty powerful tool and removes a lot of overhead from IT, including the need to hand-hold during user-led provisioning, as well as the time and effort associated with in-house staging. More of the benefits of ZT can be found here.

The limitation to date has been device selection; that’s not to say there aren’t many device models supporting zero-touch today, quite the opposite with a few hundred devices available to date, but the solution is ultimately opt-in and it has remained that plenty of devices – whether due to choice or lack of awareness by the OEM, or OEMs having equivalent solutions such as KME for Samsung.

Does that mean..

Yes, this change does also include Samsung devices! Samsung estates as well as any other Android 9.0+ device under management can now all fall under one provisioning service rather than needing both ZT for everything else, and KME for Samsung.

Samsung will undoubtedly expend effort playing up to the strengths of KME, as they rightly should given the flexibility and provisioning options KME provides surpass zero-touch, but if all organisations require is a simple and centralised provisioning service, migrating devices into ZT will be the logical next step.

Zero-touch isn’t the only thing Samsung have embraced with today’s announcement, however.

“We are excited to welcome Samsung Galaxy smartphones and tablets to the Android Enterprise Recommended program building upon our longstanding partnership to deliver great mobile experiences to businesses,”

David Still, Managing Director of Android Enterprise, Google

With Samsung’s support of zero-touch, it should come as little surprise Samsung’s devices are now also officially join Android Enterprise Recommended (though none show in the Solutions Directory at time of writing).

While the announcements go into little technical detail, it’s long been a prerequisite for devices to support zero-touch in order to be considered for AER validation. With Samsung’s reluctance to add ZT support in the past being really the only obvious technical requirement missing for said validation, given their otherwise recently decent track record for security updates and Android Enterprise support, the addition of ZT in GMS Core to enable this functionality was likely the remaining technical tick in the box.

The politics of “competing solutions” between KME/ZT and Samsung’s previously held views of AER given their dominance in enterprise also played a big role in how long it’s taken to get to this point, of course, but that’s now evidently water under the bridge.

Before diving in

While every certified 9.0+ device will support zero-touch going forward, it’s worth pointing out that doesn’t automatically validate every device for ZT provisioning; there are still OEMs out in the wild today, particularly amongst the lower-end of the market, that won’t automatically support Android Enterprise either due to lack of interest or technical challenges.

Although ZT will now be available on these devices, other issues, such as Wizard crashes, an inability to enrol the device after provisioning, or issues managing devices generally may remain.

This announcement therefore should not change the way organisations approach device vetting before committing to a particular make or model, unless said device is already AER validated.

Do I need to do anything?

For resellers, check out the zero-touch partner portal for details on how and when reseller accounts go live.

Customers, get in touch with your resellers to discuss your options, including retrospective import of devices where supported by resellers.

OEMs – carry on as always, if you bundle Oobconfig.apk for devices today, keep doing it. If you haven’t, it should still just start working regardless, but do take the time to give it a bit of internal testing to avoid disappointing customers!

That’s not all, folks

If universal support for zero-touch wasn’t enough, Google have also introduced EMM zero-touch integration following an announcement earlier this year at the partner summit; this allows for EMMs to more directly hook into zero-touch via APIs to enable the management of zero-touch configurations without customer interaction, removing the need to interface two separate portals.

It has long been something of a pain to manage zero-touch configurations due to the need to fiddle with JSON code for DPC extras, to the degree I’ve been maintaining my own resource to assist customers in quickly and easily locating the right JSON to use for different EMMs, although naturally EMMs individually hold this information as well.

With the integration, the need for manual JSON editing should vanish with EMMs able to generate configs through the respective zero-touch APIs, and because it’s an iFrame, customers will equally be able to manage configurations and devices themselves, directly within the EMM.

EMMs will be starting to go live with this integration from today, though as always, some will get it sooner than others. Speak to your EMM vendor for more information on this.

And finally

One other notable change is to the information and filtering options available in the Solutions Directory.

From today, the following changes take effect –

The zero-touch filter is no more, so only Android Enterprise Recommended devices will be shown on the directory
Google have added more details concerning security updates, including (provided by the OEM):
End date of security update support
Security update frequency
Additional certifications have been added, including ioXt & Common Criteria

These changes should add more transparency around software/security update support, and help to better set expectations when devices are purchased just how long they’ll be under support; hopefully avoiding a common complaint of organisations buying recommended devices mid-lifecycle only to find they’ve potentially far fewer than the 3 years of security updates advertised given few organisations validate when devices are released before purchasing!

VMware announces end of support for Device Admin

2020-10-01T15:23:07Z

This week, VMware announced their intention to end support for Device Admin based Android management.

A topic I’ve covered in depth since Google’s announcement way back at the end of 2017, this has been a long time coming (so long), and trends with the wider ecosystem adoption of Android Enterprise over the last few years as Device Admin functionality has slowly but surely eroded away with each major Android release.

3 years on from that announcement it’s clear however DA isn’t going away as rapidly as some would hope; whether that’s due to slow device refresh cycles (some industries take years to swap out hardware), organisational reluctance, device choice (GMS-free devices, regional restrictions) or a lack of education (my What is Android Enterprise doc still sees significant traffic on a monthly basis!), when many organisations enrol new devices today, irrespective of OS version, it’s still via Device Admin.

It goes without saying, given VMware’s (AirWatch’s) history and longevity, they have a not-insignificant share of those DA-managed devices today, and a fair amount of work ahead in realising their Android Enterprise-first strategy. This is a big step in the right direction.

What end of support means

Ending support itself possibly isn’t as immediately disruptive as it may sound; for devices running 9 and below still in 2022 it will continue to be possible to enrol Android devices into Device Admin for existing customers. What the end of support rather means is simply when customers reach out to VMware with an issue relating in any way to Device Admin management, it won’t be supported. Customers therefore are on their own should they choose to continue management of Android devices via DA.

In fact, the changes happening before this, as early as November 2020, referenced in the announcement and linked here, will be more disruptive as they’ll prevent all new customers from leveraging Device Admin, and all current customers from enrolling new Android 10+ devices as Device Admin. Those devices on 10 or later coinciding with when VMware’s Intelligent Hub switches to targeting API level 29 per Google Play policy referenced here with more detail here.

Because the technical ability to continue managing existing Device Admin devices isn’t going away, those customers who feel confident in their ability to self-support the management mode may continue to do so effectively until something on the platform ceases to work correctly. Unfortunately, given that lack of support and development, this pivotal point could be years – or months – and therefore would be an ongoing risk until devices are migrated away.

The inevitable

It’s well documented that Android Enterprise is simpler, more secure and more flexible in its approach to Android management, and for organisations the world over is the best way to manage devices. VMware’s push not only to ensure new customers leverage modern Android management by default in the near future, but to actively route customers to Android Enterprise as the only supported option for Android management in in the next few years is bold, yet not without consideration of those organiastions who have struggled with the obvious limitations of device management in Google-restricted countries or devices without GMS as is often a problem with legacy fleets in some industry sectors.

VMware’s announcement is one of many I hope to see over time across the ecosystem as we transition fully from a Device Admin to an Android Enterprise-only world, and while some may not like the path ecosystem partners are taking, it is the inevitable, and brighter, future for Android management.

Google launch the Android Enterprise Help Community

2020-07-16T23:11:07Z

Today Google announced the public availability of the Android Enterprise Help Community, a community resource tied to the Android Enterprise Help Center.

Driven primarily by community experts (Google Product Experts), the Help Community offers the wider ecosystem of partners and customers a place to discuss all things Android Enterprise, whether EMM issues, device questions, zero-touch queries, deployment or in-life support concerns, best practices, tips or really anything else. As long as it’s AE, it’s fair game.

The community has been up and running for a little bit, and a few customers have stumbled upon it no doubt while perusing the Help Center articles, which has given GPEs like myself a bit of time to become familiar with the platform and a taste of the types of questions to come.

They. Are. Varied.

This is a great initiative by Google to get the experts out of the private Android Enterprise Google-run communities and into the public domain, and from now on you’ll find me spending time a fair bit of time there!

Check it out

Watch: An Android Enterprise discussion with Hypergate

2020-07-16T21:45:15Z

In planning since before MWC was cancelled, myself and Alessandro of Hypergate finally got to sit down and chat a bit about Android, enterprise mobility and the current situation.

https://www.youtube.com/embed/tsJSwE6dHsA

If the above doesn’t display, here’s the direct link. Don’t want to see our faces? Catch it on soundcloud instead!

It was a pleasure to be Hypergate’s first guest on their new Mobile Security Talk series. Until next time!

Listen again: BM podcast #144 - Jason Bayton & Russ Mohr talk Android!

2020-07-04T00:52:07Z

Join myself (with a cold), Jack Madden and Russ Mohr as we talk all things Android and Enterprise Mobility in BM podcast #144:

I offer my thanks to Jack for hosting me, Russ for the engaging topics of conversation, and I look forward to doing more of these in future!

This content was originally externally hosted. Given the recent complete obliteration of BrianMadden.com and the whole back-catalogue of incredibly informative articles, videos, and indeed, podcasts, I’m mirroring it here.

Google's Android Management API will soon support COPE

2020-07-01T22:40:27Z

The COPE deployment scenario has been long sought-after in AMAPI, absent after most of the rest of the EMM market had adopted it in one way or another and even still following the unexpected news of the imminent change to how COPE is deployed in Android 11 (for comparison, the only other really significant change to Android I’d consider is Device Admin, which is still ongoing almost 3 years after that announcement).

Earlier this month at the Android Enterprise Partner Summit (recaps: 2019, 2018) Google announced upcoming support for the Android 11 implementation of COPE in AMAPI, work profile on company-owned devices, and just yesterday publicly announced it also.

In a surprise twist however, Google actually take this a step further by extending the implementation to as far back as Android 8.0, offering support effectively from when the original COPE, work profile on fully managed devices (WPoFMD), was introduced.

To be absolutely clear, AMAPI will not support WMoFMD running 8.0-10, but instead have backported, through an undisclosed, but likely similar approach to what’s been done before with things like device-wide unknown sources, the ability to offer cross-profile capabilities to replicate Android 11’s work profile on company-owned devices. When a device is upgraded to Android 11, a migration will still occur, however it’ll be seamless when compared to WPoFMD.

What to expect with work profile on company-owned devices

This has been covered mostly in the evolving Android 11 COPE changes doc, though to summarise the capabilities available for administrators, the following will be available with work profiles on company-owned devices:

Asset management tools
Personal usage policies
Full device reset
Personal app allow/block list
Factory reset protection management
Hardware management
Block work profile removal
OS features like telephone, connectivity, and location
System update management
Work profile max pause duration
Device-wide security logs

Some of the key benefits over deploying a typical work profile (or, what would in future be referred to work profile on personally-owned devices) today include:

The ability to fully reset the device – bearing in mind personal data will be irreversibly removed if not backed up. On a typical work profile deployment today, only an enterprise wipe is available, meaning additional work is required after removing the work profile to prepare the device for re-deployment

Factory reset protection (FRP) – one of the biggest annoyances with work profile deployments to date, if the device is reset in an unauthorised manner with a personal Google account in use, it’ll invoke FRP, requiring in some instances for the device to be sent off for repair to wipe the FRP bit. Like a fully managed deployment, FRP can now be controlled to avoid this.

Max pause duration for the work profile – previously entirely at the whim of the end user, admins can define for how long the work profile can be paused at a time to ensure those pesky emails and work notifications can’t turned off indefinitely.

App management – not akin to WPoFMD, where admins could see all apps installed on a device, push apps to the personal profile, and had granular control overall, the ability to define allow/block lists for app types (like video) or apps individually, without visibility of whether those apps are actually installed, is still an improvement over a work profile deployment alone, considering there’s no control at all over this in work profile deployments today.

And, of course, the ability to provision the device out of the box directly as a corporate owned device, so no need to fumble through the wizard to get a work profile set up.

The benefit of consistency

There’s little doubt Google could have implemented WPoFMD for devices running 8.0-10 in AMAPI, and for undoubtedly many customers the additional functionality and granular control would have been welcomed, but it’s understandable why they went this way.

Not taking into account the enormous privacy push that’s been ongoing within Android and AE for a long time, which undeniably drives decisions like these in a big way, choosing to implement COPE as one unified deployment method for all 8.0+ devices, in a way other EMMs on the market simply cannot, means for AMAPI customers – be that via Microsoft or any number of smaller EMMs – the way to deploy and manage COPE is consistent across the whole estate, and the approach is far less complicated for those who don’t spend a lot of time deep-diving into Android management to the degree people like myself do.

Given there’s no future for WPoFMD from Android 11, consistency now will guarantee fewer headaches in future, and those just coming into the world of AE, or looking to deploy COPE for the first time, ultimately benefit.

Vendor work under way

Unsurprisingly, the first vendor to announce development is Microsoft, who announced a few days ago that it’s under way for a preview in the near future. Though it’s not expected to be a complete implementation, it’ll offer an opportunity for Microsoft customers to get a taste of what’s to come.

For the rest of the AMAPI market, support will undoubtedly trickle in over the next several months.

I look forward to testing it!

Android Enterprise in 11: Google reduces visibility and control with COPE to bolster privacy.

2020-02-27T18:38:38Z

Google dropped the first developer preview of Android 11 on the world last week out of the blue, and along with it, some very interesting public announcements about the future of the work profiles on fully managed devices deployment scenario.

There isn’t one.

It’s worth noting there’s some terminology that needs to be understood in order for this change to make sense.

COPE – Corporate Owned, Personally Enabled is not an Android Enterprise deployment scenario, it is a use case that extends out across the wider enterprise mobility ecosystem. The same can be said for COBO, COSU and BYOD. Although these are used interchangeably when discussing Android Enterprise deployment scenarios/solution sets, it is entirely possible, and not uncommon, to see:

COPE used with fully managed (normally considered COBO) by permitting the mix of work and personal applications within the same profile (not typically recommended).
COPE used with work profile only (normally considered BYOD), where the organisation has already given up the requirement to fully manage a device and provides the device to be set up normally with a work profile inflated during enrolment.
COBO used with a kiosk or custom launcher (normally considered COSU), where this is deemed the best means of adequately locking down a device to the extent required, while still permitting access to some device settings and multiple corporate applications.

In the context of this article, COPE is simply a use case, and how it’s implemented with Android Enterprise is changing from inflating a work profile on a fully managed device where the DPC is both a device and profile owner, to inflating a work profile on a non-fully managed device where the DPC is a profile owner only, but gets additional management capabilities within the parent profile when the enhanced work profile experience is triggered during zero-touch or QR provisioning (unfortunately still not supported for DPC identifier or NFC provisioning methods).

I’ve had some hands on with 11, but via TestDPC have yet to see any real change between 10 and 11 on what can be configured with the enhanced work profile experience. I’ll update as required when this changes.

What’s happening

Google are no longer supporting the use of work profiles on fully managed devices (WPoFMD) in Android 11. Instead, they’re working on something they’re calling an enhanced work profile experience (what I’ll refer to throughout for simplicity and differentiation as enhanced work profile).

The key difference between the two is how they’re provisioned

Today AE COPE provisions the device fully managed, then inflates a work profile for corporate apps, leaving the managed parent profile available for personal use. It’s still a fully managed device and so IT have equivalent control and visibility to any other fully managed deployment scenario.

Enhanced work profile, like a normal work profile, sets the device up with a work profile only, just as if it were enrolled manually by an end user enrolling an already setup device having gone through the Android first run wizard. Utilising ZT or QR in this case simply shortens the time to enrolment, and offers organisations the opportunity to flag the device as corporate owned, which in turn expands the set of policies permitted to enforce on devices.

Enhanced work profile is said to offer all the benefits of a work profile deployment in having a separately encrypted, isolated profile for work apps and data, but with the addition of many of the policies available on a fully managed device available to the EMM admin, while removing any policies that may potentially infringe on user privacy (numerous).

Android 8-10 remains completely unaffected, but on upgrading the estate to Android 11, organisations are faced with two options for devices utilising work profiles on fully managed devices:

Convert the device to fully managed in order to retain full visibility and control over the device, but in doing so will lose the COPE use case in favour instead of COBO.

Migrate to an enhanced work profile in which the organisation will lose device-wide visibility of the hardware they provide to employees, as well as some of the controls available to organisations for the parent profile leveraged today.

For newly enrolled devices, depending on how they’re provisioned the device will either again be able to deploy as fully managed or, if the EMM vendor supports work profile provisioning via QR/ZT introduced with Android 10, provide the option to provision the enhanced work profile in lieu of the WPoFMD deployment scenario.

The enhanced work profile should offer several new parent profile restrictions and policies previously impossible to enforce with a work profile deployment, including what appears to be app black/whitelisting for the parent profile amongst other things (no public announcement on available policies as yet), bringing it some way towards a replacement for the deployment scenario being binned off, although the two won’t be directly comparable.

In any case, for end users the UX should remain basically unchanged and as such the need for end user training ahead of migrating enrolment processes from WPoFMD to enhanced work profile will be unnecessary – unless DPC identifier or NFC provisioning is utilised, in which case organisations will need to switch to QR or zero-touch provisioning instead.

In the name of privacy

Work profiles on fully managed devices have, since their introduction with Android 8.0, offered the most comparable experience to legacy Device Admin management available with Android Enterprise; the organisation separates and protects all corporate data within what would have been a container, now a work profile with AE, while maintaining full visibility and control over the device the organisation has provided to employees.

Generally with COPE employees are happier as they are given a corporate device, in some cases something they wouldn’t buy themselves due to cost where the organisation offers high-end devices, and one they can optionally utilise for their own purposes. Organisations are happier having devices they approve, provide and manage being actively used rather than shoved in a drawer as is often the case with COBO-style knowledge worker deployments.

Where things get murky however is how personal use is handled. This can vary by region and organisation, and opinions sit at opposite ends of the spectrum.

Many offer personal use as an optional extra provided by the organisation, but offering personal use doesn’t imply privacy; the device doesn’t belong to the employee, the employee is unlikely to pay for the usage (cellular) of the device, it is deployed as a fully managed device and thus is treated by the organisation as such, something that is often outlined in a mobile device policy employees sign when joining the business or when devices are rolled out (I’ve signed one for every British and US firm I’ve worked for to date).

This is the side of the fence on which I sit. If I’m deploying devices to the business I have no issue with employees using them personally within reason, however if it’s lost or stolen I want to be able to track it’s location, if I get an enormous data bill I want to understand what may be contributing to this as it’s unlikely to be corporate apps causing it. I’ll push out MTD on the parent profile to maintain device-wide protection, so on. It’s a business asset so is looked after as such.

That doesn’t mean I’m looking at app install logs to peruse what employee #309’s interests are; EMM privacy is enabled, and solutions that monitor app usage and risk can do so in a way that doesn’t identify the app itself, only the genre, meaning I know that “streaming apps” have consumed 30GB of data, or “gambling apps” are posing a security risk. It also doesn’t mean I’m not able to see SMS messages, call logs, personal app data, etc, which is a common misconception with device management still today.

Similarly, as a user, I’ve turned down the opportunity for personal usage on a device in the past because the organisation does sync full app lists, or in the DA days has had the ability to directly interface the device filesystem.

Google clearly don’t agree with this approach. Instead, they fall in line with the organisations and regions of the world that consider any personal use offered by an organisation being subject to unquestionable privacy, allowing employees to do whatever they wish with the device without any visibility offered to the organisation.

For regulated orgs that want to allow some personal use COMP was ideal and Google should maintain both

From an MSP

Google advertise the replacement of COPE in its current form as a big win for IT, giving them (or us, since I fall under this umbrella with my managed estate) the ability to “confidently extend the same privacy protections to a company-owned device that people have come to expect from the work profile on a personally-owned device”, which is super, where that is desired, but equally in many circumstances having restrictions imposed by a 3rd party on how a corporate device is managed is absolutely not desired. I’ve made similar comments on how MobileIron limit WPoFMD management according to their own view of how a device should be managed, as opposed to simply supporting the deployment scenario in totality and leaving organisations to manage their own estates.

Neither view is right or wrong, justifications can be provided for either side of the fence on which you sit, however Google have chosen to make it harder for those who don’t desire abject privacy with no wiggle-room.

An un-Android approach

Android revolves heavily around being a flexible OS designed for everyone. It is baffling therefore to see Google seemingly saying we don’t like how it’s being used and removing a management scenario many organisations want to leverage.

Importantly, this is not just a case of privacy or no privacy. The work profiles on fully managed devices deployment scenario is leveraged for more than simply COPE.

We use AE COPE as a dual managed-container solution, we don’t know what we’ll do from Android 11

From an organisation

While it’s not necessarily a popular use case, utilising WPoFMD as a means of providing two managed profiles (parent and work) which hold different applications and data has provided a key benefit of utilising Android over another OS for some customers.

Some choose to define what personal use means for their devices by heavily limiting the applications, accounts and features that can be leveraged in the parent profile.

Others choose to deploy services like MTD into the parent profile and otherwise remain completely hands-off, with no app information collection within the EMM, which is very much a possibility with many EMMs for organisations enforcing their own privacy policies.

In any case, however organisations are choosing to use COPE, however they define personal use, and whatever corporate policies are in place, this is all possible due to the flexibility of WPoFMD.

Restricting all Android customers for the sake of some which Google feel get privacy wrong is taking a sledgehammer to a staple and flies in the face of Android being for everyone.

It’s worth pointing out equally how easy this is to bypass for organisations wanting parent profile visibility. Just as with a work profile (BYOD) deployment, organisations can mandate the installation of an app (MTD is again a frequent example) manually by end-users in order to comply with corporate policy. In a flash end-users lose some of the privacy Google sacrificed WPoFMD to achieve.

There are multiple parties involved here. If users don’t like the terms under which personal use is permitted, they don’t have to use their corporate device for personal use. If an organisation isn’t transparent in how a device is managed then that becomes a matter to be taken up through the appropriate channels as regulations exist to handle breaches of privacy where consent isn’t provided.

The cost of enthusiastic adoption

Speaking to EMM vendors the feeling is consistent, those who went out and implemented support for WPoFMD are less than pleased with Google’s abrupt decision to remove an entire solution set. The time, effort, and the amount of backtracking that’ll be required after development of documentation, marketing and more of the support for something few vendors adopted can’t be understated. Once a source of pride and differentiation, for those who’ve launched support this is now a significant burden.

We’ll need to be more considerate in how and when we support features going forward

From an EMM vendor

These vendors now have plenty of work ahead to support this change and avoid a situation where an explicit WPoFMD enrolment doesn’t succeed if attempted in 11.

Other vendors yet to implement the deployment scenario are naturally less impacted by it, but it still invalidates the months of work undertaken getting closer to being able to support the deployment scenario.

Intune, the beneficiaries of my doesintunesupportaecope.info website are one of the few Android Management API-based vendors of which WPoFMD support was not even a possibility given Google’s AMAPI itself has yet to get around to implementing it. With the Android 11 announcement this clearly makes sense; despite statements made at the partner summit back in May 2019 (already a year after the launch of COPE) AMAPI has continued to drag on implementation, and probably won’t now that there’s justification not to.

It’s not just EMM vendors of course; independent folks like myself, MSPs, VARs and other outlets who’ve advocated WPoFMD as the best deployment scenario offered by Android Enterprise since 8.0 for more than two years, talked to countless organisations about it, written about it extensively, now have to equally backtrack on education and recommendations, while also pointing out the alternative isn’t direct replacement depending on the use case.

Knowing some organisations spent an extortionate amount of time on fully managed, waiting to go switch to a COPE use case, only potentially to have to go back to fully managed (if the available policies don’t meet requirements) with the next major Android version sucks.

There have equally been many organisations sticking with device administrator until their EMM supports WPoFMD. Learning from 11 the deployment scenario aligns less closely with legacy DA may further delay migrations to Android Enterprise, the last thing the ecosystem needs.

A better way

None of this is to say many organisations won’t be happy with the news of enhanced privacy of course, There are examples of organisations today who go out of their way to collect as little non-work relevant data on devices as possible through already-present EMM privacy settings, and having that responsibility pulled into how the OS functions by default will be a reassurance. There are undoubtedly equally those on DA today who will be more enthused to switch to enhanced work profile than they would have been for WPoFMD.

While I’ve no doubt enhanced work profile will work perfectly fine for many, it would have been so much better and would have been accepted far more enthusiastically by the ecosystem if enhanced work profiles were a new, additional deployment scenario in 11, and not a replacement for WPoFMD.

If Google provided more flexibility, and not less.

There’s a growing community of >150 Android Enterprise Experts around the world who’d know when to apply WPoFMD, and when to apply enhanced work profiles. There are even more MSPs who equally know Android Enterprise appropriately even without an expert badge.

Enhanced work profile as a standalone solution set is an excellent deployment scenario that fills a nice gap for the many organisations who appreciate the hands-off approach of the work profile with the option to extend management capabilities a little more than can be otherwise achieved without having to consider privacy implications.

Many organisations only care about work data, meaning WPoFMD is overkill, but will benefit greatly from being able to handle FRP properly or ensure some very basic security is enforced which isn’t always easy with an unenhanced(?) work profile only deployment.

Yet, Google forcing the ecosystem into a vision of what COPE should look like at the cost of flexibility and capability rather than embracing all of the potential usecases Android solves over the competition seems like one step forward and two back.

It’s going to be interesting watching the ecosystem now take on the unnecessary challenge of swapping out WPoFMD with enhanced work profile, and the customer stories that arise from having to make the switch themselves in the next few years.

Ahead of 11, here’s an updated graphic with the newly recycled COPE deployment scenario:

I won’t miss the absurdly long name though.

What’s your view of the change? Are you a user happy with the increased focus on privacy? An IT admin frustrated by the loss of capabilities? Sound off in the comments, on LinkedIn or Twitter

The decade that redefined Android in the enterprise

2020-01-20T20:00:00Z

2019 and, indeed, the decade has now drawn to a close; as the 20’s have now roared in, what better time to take a look back at how the 10’s saw the most popular mobile OS in today’s world evolve from being mostly unsuitable for enterprise to an obvious choice?

From the days of Device Admin management, manually provisioning devices, dealing with Google accounts, devices that weren’t guaranteed to offer any more than basic Exchange account support (which in itself was a stretch for some), the inconsistent management experiences between EMM solutions, and everything else the admins, consultants and engineers of the EMM world have put up with over the years, to OEMs like Samsung and Zebra taking matters into their own hands to offer solutions for enterprise, and Google eventually turning their focus to enterprise and security with what would become Android Enterprise.

It’s been a pretty fascinating decade.

With that, here’s a look back across the last 10 years bundled with a smidge of my experiences as well as thoughts from a few friends in the ecosystem thrown in for good measure! I’ll preface this with a heads up that I’ve covered a lot of these topics in detail over on /Android, so those who’ve followed my content before may see some familiar themes.

Way back when

Android and Windows Mobile

Back when I first started out I was used to seeing Windows Mobile devices widely used in enterprise. From logistics to field forces, knowledge workers to dedicated. Windows Mobile was everywhere.

Honestly, if Microsoft hadn’t ruined everything with Windows Phone and instead maintained focus on iterating with Windows Mobile, the landscape today might be different. I was an avid Windows Mobile user, from 5 to 6.5 regularly and later alongside Android, before fully abandoning the platform once Windows Phone came along (I do however still have a Lumia in one of my drawers for testing Continuum when that was a thing).

The mistakes Microsoft ultimately made gave Android a huge leg up on the market to provide a drop-in alternative (literally in some cases. Anyone remember the HTC HD2? That thing ran everything. Even my HTC TyTN II ended up upgrading to Android after spending enough time with Android to deem it a worthy change) and I’ve watched with interest as rugged and dedicated OEMs slowly moved away from Windows to embrace Android with open arms.

It’s no surprise given Android was originally targeting the Windows Mobile market. It was just as well they rapidly pivoted to instead more directly compete with iOS (more touch, fewer buttons) as it certainly wouldn’t be the OS it is today without a bit of modern competition.

Windows is still in use in organisations today, not necessarily Windows Mobile so much as CE and modern versions of the OS; Microsoft has by no means been eradicated, but it’s share of the enterprise space is being slowly and reliably eroded, as Google pointed out at the Summit:

Samsung or no one

Before Android Enterprise, managing devices typically for most organisations meant buying and supporting Samsung, and only Samsung. Of course OEMs like Zebra in the more specialised/rugged deployments were a dominant force of their own, but for the day-to-day device management for knowledge workers the options were to typically choose from a selection of Samsung devices the company was able offer and guarantee support.

Samsung and the Knox platform have come a long way; it happened to be Samsung tablets with which I got my first taste of device management combined with MaaS360, then under Fiberlink’s ownership! Being one of few OEMs who control pretty much their whole supply chain, Samsung have been able to be truly innovative in security throughout the entire device, hardware and software.

Fun fact – Samsung were even going to be the partner to help bring the first iteration of Android Enterprise, then Android for Work, to fruition before Google took it in a different direction.

As Android Enterprise has evolved, so too have Samsung, with their integration efforts to build their management platform atop Android Enterprise rather than alongside it.

They still won’t support zero-touch though. It’s KME (Knox Mobile Enrolment) or nothing. No matter how much Samsung and Google talk up initiatives like the Common Integration Library, for customers, it’s still two portals and unnecessary overhead for absolutely no reason other than, presumably, politics.

In any case, tools like KME, Knox Configure, Samsung’s extensive collection of restrictions and much more have clearly inspired Google over the years. Samsung were and continue to be a huge driver behind Android’s success in enterprise, and have marketed Android as an enterprise leader (they run adverts featuring enterprise use with Knox!) far more publicly than Google.

EMM management left a lot to be desired

Remember containers, those per-EMM proprietary solutions that separated work and personal data? Good (bought by BlackBerry), MobileIron, AirWatch (VMware) and others still have these solutions up and running today, but they don’t compare to the native work profile implementation with Android Enterprise. Jack Madden has his own thoughts:

Work and personal data separation has always been a key issue in enterprise mobility. Before Android Enterprise, app-based separation features were the only viable route. During this time, there were at least a dozen attempts to provide Android devices with separation features built in directly at the device or OS level, but none of these early efforts took off. App-based solutions still have their place, but it was Android Enterprise work profiles that finally achieved the goal of a standard, device-based work and personal data separation framework that’s compatible with any app. This is a big deal.

Jack Madden, Executive Editor of BrianMadden.com

It of course wasn’t just work and personal data separation, I’ve talked about the fragmented approach to device admin management at length in various docs and articles, and how budget, time constraints, and opinions impacted heavily on what EMMs supported what features, particularly with so many bespoke APIs from so many OEMs to choose from.

If you had a selection of LG devices, for example, perhaps you’d go for SOTI or VMware, for Huawei maybe MobileIron or someone else. The relationships held between vendors and OEMs really heavily impacted ultimately how well these devices would be supported. Even Samsung, pretty much supported by all EMMs (as if they had a choice) would be better supported for some features by one EMM than another.

The introduction of Android Enterprise and those consistent management APIs really made things a lot easier for EMMs, but there were additional developments to come much later that truly puts the cherry on top.

Since MobileIron began managing Android devices with Froyo way back in 2010, we’ve witnessed a true sea change in the way Android devices are managed thanks to the introduction of Android Enterprise with Android 5.0.

Russell Mohr, Director of Sales Engineering, MobileIron

The F-word (Fragmentation)

The word gets batted around still today, overwhelmingly more for clicks than anything else by the big tech sites, but when considering where Android is now compared to where it was even half a decade ago, there’s no comparison.

Sure, it’s easy to point at the distribution dashboard and feel like it makes the point by itself, but there’s always been more to it than just the reported major OS version.

Things like security updates (below) maintaining the safety of a device as much as 3 versions behind the latest Android release, Google’s separation of apps and services from Android’s core, allowing for Play Store updates at any time, or the recent introduction of Project Mainline to further modularise and update system components through Google Play.

For enterprise, adding Android Enterprise into the mix took the fragmented, no two OEMs (or even devices) the same management experience and streamlined it across all certified devices around the world.

Before Android Enterprise, the biggest challenge with managing Android devices was the fragmentation and lack of continuity between manufacturers. Standardizing the Android Enterprise platform across OEMs has enabled enterprise customers to deploy the devices they choose with the confidence that they will all work together.

Kevin Murray, Senior Product Manager, VMware

For enterprise, admins are often hesitant to embrace major version updates, not least without extensive testing that isn’t always easy to accomplish. Guaranteeing apps and services across a fleet of mixed manufacturers and their unique quirks can be a daunting task. Even if Android Enterprise brought with it management consistency, how individual developers build applications can lead to all sorts of problems when the OS version updates.

In my recent survey in fact, 8.5% of respondents say they either never want to see a letter upgrade, or don’t expect one. As long as the device continues to get security updates.

Organisations can’t stay on a particular Android version forever of course, as a pending major upgrade will often block the continued rollout of security updates, but certainly where a major upgrade isn’t a likelihood, the devices can remain protected for up to 3 years.

Gradual improvements

The introduction of security updates

Frequent security updates today are not only pretty much guaranteed across the big players in the ecosystem, they’re expected. With over 82% of respondents of my recent enterprise survey mandating updates within 90 days, and just under 39% (38.7%) of those requiring devices are updated monthly.

It wasn’t too many years ago, however, that security updates, or updates in any capacity, weren’t all that common, and in some cases organisations were lucky to see any updates at all depending on when in the device lifecycle chosen devices were deployed. The thought of a deploy-and-forget approach to Android is an uncomfortable one, but for many years – and even today, with >20% of organisations admitting to still managing Android 4.4.4 & lower, especially with rugged/dedicated devices – this is not unusual.

Google’s introduction of security updates was pivotal to the success of Android in the enterprise, offering backported support for up to 3 letters back and as such, ensured devices both new and old remain secure.

Since then Google have continued to further decouple components of Android for smoother, more frequent and more reliable updates, notably in Android 10 with project mainline offering the ability to update various modules of the OS via Google Play previously requiring system updates.

It’ll be super interesting to see what the next decade brings to the table concerning updates, and if Google one day get to a point where even major Android versions become unimportant, delivering new features through simple background updates that render full system updates mostly obsolete.

Big OEMs moved to Android

As Android (and iOS as this naturally contributed also) continued to grow, competitors opting to run other operating systems saw their market share gradually decline into insignificance as the consumer market shifted. This video (from 1:27) demonstrates this wonderfully (and provides source for the comments below):

https://www.youtube.com/embed/MMyMB4zm9so?start=87

By 2012 both PalmOS and WebOS had fallen out of the spotlight. WebOS is still about, most recently I saw it in use on LG TVs, but doubt it’ll make any dramatic comeback. Palm today (under a different company licensing the Palm name) are using Android.

By 2014 Symbian, the once dominant mobile OS used by a number of OEMs, most notably Nokia, had dwindled into significance. Nokia’s devices business, later purchased by Microsoft, had already dabbled with the thought of Android on their Lumia line before Microsoft ultimately swooped in, bought them and ran them into the ground trying to make Windows Phone work, while other OEMs simply switched to Android.

The iconic Nokia brand didn’t stay away for too long, however. The smartphones you see today are now manufactured by Finnish company HMD Global, a company consisting notably of ex-Nokians and a few other folks, who license the Nokia brand for their devices. They’re doing extremely well in the market after opting, uniquely, to go all in on the Android One program and all of the benefits it brings.

From its start in 2016, HMD Global has focused on offering a pure Android experience with only the HMD camera app, and My Phone app for user support added.

In addition to benefits such as simple Out of Box Experience for enrolment and a strong battery life that is expected from a Nokia device, this has enabled Nokia smartphones to be the fastest to receive new Android OS versions across all devices, and to guarantee monthly security patches for all price points.

Andrej Sonkin, GM Enterprise Business, HMD Global

BlackBerryOS fell off the radar in 2017. BlackBerry went to the brink but bounced back with a renewed focus and devices (now made by TCL) running the Android OS. They also had another OS, QNX, on which BlackBerry 10 was based. This OS seems to have found a place in the IOT space.

Windows Mobile is still holding on with a 0.01% market share in 2019, though as mentioned above this is being slowly eroded.

These OEMs, and so many of the others across consumer, enterprise, rugged, and more who over the years have embraced Android as their OS of choice for the hardware they develop, have had an impact on the ecosystem not only through contributing to Android’s dominant global market share, but in the contributions back to the Android (open) source, the opinions and influence on the direction Android should travel and more. An open platform like Android is driven as much from outside as inside, and the experience industry behemoths have bestowed upon the platform cannot be overstated.

Encryption by default

If you care to check your Android device (Settings > Security & Lockscreen > Encryption & credentials or thereabouts depending on your device) you’ll undoubtedly notice the device is encrypted.

If you fancy digging deeper, hook your device up to your computer and via ADB run:

adb shell getprop ro.crypto.type

If it returns block it’s Full Disk Encryption (FDE), whilst file is File Based Encryption (FBE). The more you know!

In any case, this wasn’t always how things were. It took until Android 6.0 before Google mandated encryption – FDE at the time (it was attempted with 5.0 but due to performance related issues this was pushed back). With Android 7.0 Google then introduced File Based Encryption, offering a much better UX for devices able to support the overhead at the time (far less of an issue today, unless you’re running very low-end hardware).

Today all devices should be encrypted out of the box. The better OEMs/hardware will leverage FBE, but at minimum FDE is required.

On-device security, Play Protect

Google’s Play Protect suite of solutions includes the world’s largest anti-virus service, analysing 500,000 applications, and scanning over 50 billion on Google Play, on-device and crawling the web every day.

Considerations for choosing Android in the Enterprise

Google have had security solutions and services built into Android for a number of years, in 2017 though we saw the first steps towards turning everything from SafetyNet & PHA scanning, to consumer features like find my phone into it’s own, marketable product.

Google Play Protect.

As with all solutions built on machine learning Play Protect’s capabilities have grown stronger over time, and with Google’s formation of the App Defense Alliance alongside market leaders in the MTD space, Play Protect will only continue to get better still.

Play Protect has helped to improve the negative perception of Android Security, and is often brought up in marketing and presentations.

Project Treble

Talking of major updates higher up in the article, I would be remiss if I failed to touch on the profound impact Project Treble is having on major Android upgrades.

Introduced with Android 8.0, then tweaked for Android 9, Project Treble enabled the rapid development of version upgrades never before seen on the platform.

Disassociating the vendor layer from the Android framework meant where previously an OEM would need to update both the vendor implementation and the framework simultaneously to deliver an update, today the vendor implementation can remain untouched, offering OEMs easier, more rapid deployment of upgrades.

I quipped in my writeup of the Android Enterprise partner event 2018:

Again [Project Treble] is not new having launched with Android Oreo, but was thrust squarely into the spotlight at IO this year [..] when the launch of the Android P beta came to multiple devices at once for the first time in the history of Android.

It’s a significant achievement showing just how groundbreaking the feature is, bringing updates to devices faster and easier than ever before, whilst improving the overall security of devices in the process by isolating low-level components [..].

Me, Android Enterprise Partner Summit 2018 highlights

Of course that’s just my take, Google however back it up with facts:

In late July, 2018, just before Android 9 Pie was launched in AOSP, Android 8.0 (Oreo) accounted for 8.9% of the ecosystem. By comparison, in late August 2019, just before we launched Android 10, Android 9 (Pie) accounted for 22.6% of the ecosystem. This makes it the largest fraction of the ecosystem, and shows that Project Treble has had a positive effect on updatability.

Android developers blog, All About Updates: More Treble

Android developers blog, All About Updates: More Treble

Project Treble may not bring Android upgrade speed and distribution in line with iOS, but it has offered significant benefits to the platform which will undoubtedly only continue to show as Treble matures.

And, of course, Android Enterprise

It’s only with Android Enterprise that we started considering Android as a viable platform for developing mobile security solutions.

Alessandro De Carli, Founder, Hypergate

Touched upon in various places already, Android Enterprise has had an indescribable effect on how the OS is perceived and used in enterprise over the last few years.

Android Enterprise has transformed Android from a typically perceived cheap, insecure device into a budget-scalable, flexible, customisable and trustworthy device in the enterprise world. The segregation of data, or containerisation is making its acceptance through security processes and by security officers much less painful that it used to be. Android Enterprise is, by far, the first recommendation we provide to our customers.

Jean-François Rigôt, Sr Tech. Consultant Mobile IT @ mobco

It wasn’t an overnight success by any means, starting out as an optional implementation in Android 5.0 (and an app before this.. but we won’t talk about that), it wouldn’t be until 6.0 that it started to become somewhat reliable, before reaching a reasonable maturity with 7.0.

There’s so much that can be said about Android Enterprise alone that it deserves it’s own doc, like this one, which I’ve been updating frequently since 2016. To summarise the incredible impact AE has had on the platform, solidifying it’s status as an OS for enterprise as much as anywhere else, here are some highlights:

A consistent UX, reliable management

When comparing Android to almost any other mobile OS on the market it was clear how managing the platform could be challenging. While iOS and Windows Phone benefits from integrated management wholly designed and implemented by Apple and Microsoft respectively, Android had always relied on individual OEMs to figured out their own enterprise strategies.

Before Android enterprise, it was hard to predict what experience our customers might have when managing a diverse population of Android devices, but the consistency AE provides allows us to provided an elevated experience while reducing support costs because the outcome is now much more predictable.

Russell Mohr, Director of Sales Engineering, MobileIron

With the various management APIs available across OEMs, several proprietary provisioning flows and a general lack of consistency from one device to the next (even within OEMs) obviously one of the core objectives of Android Enterprise would be to fix this.

Google’s aim was to have every certified Android device on the market look and behave consistently when put under management.

Whether picking up a Pixel or an Xperia, a Galaxy or a Nokia, though the UI may have differed here and there, the underlying provisioning flows, the way a work profile is set up or how a device undertakes the disabling of the camera. It all happens using the same APIs, it’s reliable, it’s familiar, and it’s a million miles away from the management of old both for customers and EMM vendors.

With a standard set of APIs to use across any OEM, implementation is greatly streamlined for new functionality

Kevin Murray, Senior Product Manager, VMware

As Kevin states, the consistency and simplicity of Android Enterprise has equally had a profound impact on the vendors who implement these universal APIs; rather than having to work with each OEM independently, vendors now work directly with Google for the most part. With well documented APIs and simple escalation points the EMMs starting out today will have a tough time imagining how it used to be.

Unsurprisingly with customers being able to pick up most devices on the market and know they’ll work exactly as they need, the mandate for Samsung in enterprise as the only viable OEM has diminished:

Since the push forward with Android Enterprise gained momentum, I’ve noticed a marked decrease in the number of times I’ve heard “We only allow Samsung Android devices.” [Google’s] dedication to providing full management suites for both company owned and BYOD devices, as well as a middle ground (COPE) are admirable, and truly innovative for MDM/UEM.

Matt Shaver, Knowledge and Content Manager – MaaS360 by IBM

Not entirely though, although Google have successfully brought a base set of management capabilities to all GMS certified Android devices, they have equally encouraged differentiation; Samsung, along with Zebra and others are well known for their custom APIs, and in recent years have worked to fully integrate them to sit atop Android Enterprise. These continue to be available both as profile/policy options integrated into EMM consoles, and through newer initiatives such as OEMConfig (below).

No more Google account management

Google accounts suck. They always have and they always will. The thought that so many organisations across the world were (and still are, stop it please) creating and managing accounts just for the sake of installing apps (including the DPC/EMM agent) on the device is crazy.

Not only for the fact that creating accounts is a pain and unnecessary overhead, but the myriad of caveats that go along with it:

You can’t have more than 10 devices enrolled per account
In reality you could and organisations did (do? I hope not any longer but it’d be ignorant to assume) do this, only to abruptly and with no warning find the account suspended. Whether that was after 20 devices or 2000, it was a real pain. I’d always mandated customers create an account per employee, or have the employee create it against their corp address and look after it themselves (on the basis it could be recovered by the org if required) but ultimately customers don’t list, or forget or any other reason.

If you share an account, you share more

I remember vividly getting a support request from a frantic field manager once upon a time who’d used the same Google account across a not-insignificant-number of devices and was calling to report that calendar invites, emails and more were being shared across the team fleet of tablets. It was around this time, in fact, that the rapid research into and deployment of an EMM solution – not that this would have been prevented by EMM necessarily, it was more the realisation of an obvious lack of visibility and control the IT department at the time.

FRP is easy to trigger, difficult to overcome

Since devices set up with device admin lacked the ability to disable factory reset protection (or whitelist accounts for it), all too often end-users would add an account not owned or controlled by the business only to have FRP enforced on its eventual return. Unfortunately there remains little to do other than sending the device off for repair in almost all cases, though through the years I’ve leveraged a few now-closed workarounds to avoid this in older versions of Android!

I reached out to my group, MobilePros, for any interesting DA Google account issues, Scott’s was with FRP:

We had a major issue with FRP locked devices, so much so that our recycling program was suffering pretty badly – this also caused an inventory issue for being able to redeploy devices to the field from stock. In the last two years after implementing Samsung KME and more recently AFE, we have nearly doubled our recycling for and of life devices and we’ve been able to be more picky about which devices can get redeployed to our users.

Scott, via MobilePros

Android Enterprise totally revamped the Google account experience, taking it entirely out of the hands of customers and making it just another step of the enrolment process.

Managed Google Play accounts are still, in effect, Google accounts. The difference is however:

They aren’t authenticated (no user/pass to worry about)
They’re created and deleted by the EMM automatically through the bind established between the EMM and Google
They enable the silent, automatic installation of applications from Google Play
They can be set as user or device accounts, with the latter overcoming the 10 device limitation

Read more about managed Google Play accounts.

Provisioning a device is a piece of cake

Not even referencing zero-touch (which as of Android 10 is actually less zero-touch than ever before for end-users, but I digress). The provisioning methods gradually rolled out to Android over the last few years have transformed how corporate-owned devices are setup from out of the box (or a factory reset state):

Android 5: NFC
Android 6: DPC identifier/managed Google account
Android 7: QR code
Android 8: Zero-touch
Android 10: Zero-touch for work profile devices

The days of working through the entire setup wizard and, depending on the OEM, myriads of extra screens and account setup prompts, including the setup of the Google account, before landing on the home screen, opening Google Play, finding the relevant agent, downloading it and enrolling finally, universally (because some OEMs were working around this with proprietary setup flows), came to and end with the introduction of Android Enterprise.

When zero-touch later launched with 8.0 it once more drastically simplified provisioning by offering a true out-of-box experience for the devices that supported it. It certainly wasn’t an overnight success getting OEMs on board given even today zero-touch is optional for non-AER devices, but thankfully the ecosystem saw the vision and hopped on board pretty rapidly over the following two years.

DEP, Autopilot, and KME customers would understand the impact of being able to set up a zero-touch config to have devices find the right EMM and even fully automatically enrol straight out of the box, but even into 2020 this is still an unknown concept to many.

Also importantly, the introduction of zero-touch added a simple, persistent means for ensuring devices remained under management after a factory reset. This was already possible with some OEMs through various means but as with every other aspect of Android Enterprise, it brought the same capability to the wider ecosystem in a way that was easy to deploy and manage without individual EMMs or OEMs having to implement a means of supporting similar functionality. No longer could devices simply be reset/reflashed in an unauthorised manner to get out of management.

The only downside to zero-touch is it’s archaic reseller requirement. Samsung’s KME, Apple’s Enrolment Program, Windows Autopilot all support the grandfathering, or manually adding of devices, into the relevant portals.

Despite there being overwhelming support for the removal of this unnecessary restriction in the wider community, going into 2020 Google haven’t budged; a shame because I think it very much hinders adoption of the provisioning method globally.

Check out my docs on provisioning methods for more details on how these can be leveraged today.

Deployment scenarios galore

As touched on above, before Android Enterprise organisations were forced to push a square peg through every other shaped hole. Bring your own device? Full device admin management. Corporate? Full device admin. Corporate with personal use? Full device admin.

EMMs have come up with some very nice solutions over the years for separating data, preventing personal use and more in combination with OEM APIs, but it wasn’t until Android Enterprise there was a system-level differentiation between a device that is user owned with access to secure corporate data, a device that by default prevents personal use, including the removal of non-vital apps, a device for dedicated (kiosk) use and the flexibility to offer personal use on fully managed devices.

I’ve gone into detail on the different deployment scenarios, but for reference, here’s a handy graphic I use to explain it:

The two deployment scenarios I want to touch upon in particular are work profile and COPE, officially called work profiles on fully managed devices (which is still a rubbish, overly long name for COPE. Shortening it doesn’t really help either – WPoFMD hardly rolls off the tongue, and even playing with the order of the letters, which sort of defeats the purpose, only got me to FMWP, pronounced “fuhmewp”).

Work profile

Today when a personal device is onboarded, the end-user can know without a doubt their personal data, apps and other things they do with their devices remains private, while the work data sits completely separate, uniquely encrypted and protected within its own profile, the work profile.

When they’re finished working, users can turn the whole work profile off in one go, no need for the support of quiet hours within individual work apps, or to silence the whole phone to avoid disruptions from work. All apps suspend and consume zero resource on the device until reactivated when the work profile is turned back on.

The work profile offers one of the best features to come to enterprise for personal devices to date, and not only for end-users.

From the organisation’s perspective, it’s possible to ensure the device has a screenlock, to add a screenlock both to the device and the work profile separately (and uniquely), to ensure unknown sources can’t be enabled and that debugging is turned off. These few restrictions available offer just enough control for an organisation to determine the device secure enough to access corp data (and enforce best practices!) while not overstepping the privacy boundary.

Is it perfect? No.

Users are limited to one work profile, so not viable for contractors or those who are otherwise forced to use multiple EMMs
The UX concerning the split between work and personal apps was pretty confusing pre-9.0, and still gets people today (two apps, one with a badge and one without, it raises questions) in spite of the mostly-supported app launcher split
There’s still limited overlap across profiles. Apps like Gmail can jump in-app between work and personal profiles without having to actively switch between the two versions of the app, while Google Contacts and Google Calendar support cross-profile search/visibility, these are but a few of the many enterprise apps in use today however
Dual SIM management within the work profile is entirely non-existent, which is a odd when considering BYOD devices can have a secondary work-provided SIM that continues unhindered when the profile is disabled.

It is, regardless, so much better than an organisation holding complete control of a personal device, with visibility of many things done on the device any time of day or night. Privacy simply couldn’t be guaranteed with device administrator enrolments.

Work profiles on fully managed devices (COPE)

Despite being the closest deployment scenario to legacy DA management with corporate containerisation available, it took until Android 8.0 for work profiles on fully managed devices – or COPE, or COMP, or managed work profiles, or whatever else the deployment scenario has been called over the years – to debut on Android Enterprise.

Benefiting both from full device control due to it’s fully managed state, and profile-level separation of corporate data, WPoFMD offers the perfect deployment scenario where personal use is permitted on a corporate device without the DLP risks of mixing work and personal apps in-profile as would be the case if personal usage was permitted on a fully managed device.

It’s unfortunately still not supported universally today, over two years later, with a number of known EMM vendors in the ecosystem. The likes of SOTI, MaaS360, Intune and even Google themselves with their Android Management API still don’t support COPE, leaving organisations around the world needlessly waiting, or working around the requirement by opting to deploy work profile only and forego device-level management.

Those EMMs who do support it could improve the UX more still by following in the footsteps of Citrix to enable support for enterprise wipe, or offering the ability to migrate between fully managed and WPoFMD, a feature that should be easy enough to implement, but is yet to see traction.

Android Enterprise Recommended

In 2018 Google launched Android Enterprise Recommended. Initially for devices and later rolling out to EMMs, MSPs and at some point soon may expand it once more to Carriers.

AER takes all the work Google have put into the ecosystem to date, and invites partners to apply for the opportunity to have their devices, solutions or companies validated to align with Googles recommendations, requirements and best practices. I’ve written about it in more detail here.

It adds further credibility to the validated entity, essentially saying yes, Google recommends this as an enterprise-ready device/platform/company and it has had an extraordinary effect on the market.

HMD Global undertook a study in 2018 that demonstrated the importance of AER to organisations, with 56% of respondents mandating a device should be Android Enterprise Recommended:

HMD Global B2B Smartphone Purchase Survey 2018

In my own survey in 2019, 72% of organisations who took part considered AER to be important or very important when purchasing devices. 44.2% consider AER status of an MSP or VAR to be a deciding factor (16.9% of that 44.2% consider AER mandatory in order to work with an MSP), and 48.6% of respondents agreed that in gaining AER status, their EMM has improved feature availability, management reliability and more.

However you choose to look at it, be that customers who feel they get the best experience by seeking out an AER device, or EMM vendors who improve their solutions to meet Google’s recommendations and requirements, the Android Enterprise Recommended program has, and continues to raise the standards across all ecosystem partners.

OEMConfig

This feature is one of the best gifts that Android Enterprise could offer to MDMs. It takes off a lot of work from our hands because we don’t need to spend time developing features for various vendors anymore.

Public statement by Vipin Govind, Android Systems Engineer, Hexnode

Undoubtedly my favourite Android Enterprise feature to date, the implications of OEMConfig on the entire ecosystem are incredible. I’m absolutely not alone in my feelings towards the feature, as when I asked a few people for their opinion on the best feature of AE to date, I received the following:

OEMConfig has been a game-changing feature that has allowed MobileIron to get out of the game of supporting custom API’s from many different vendors and freeing us up to focus on truly important aspects of Android management like delivering a world class end-user experience.

Russell Mohr, Director of Sales Engineering, MobileIron

Without picking [a feature] that’s at the very heart of AE like Fully managed mode, I think Managed Configuration and specifically OEM Config will make the biggest impact across the entire ecosystem. As Android moves more towards native functionality, the ability to differentiate becomes increasingly important for device manufacturers and EMMs. Providing a standard way to implement differentiation for OEMs allows customers to get features more quickly while each other player in the management of the device can focus on what they do best.

Kevin Murray, Senior Product Manager, VMware

It absolutely makes sense that EMM vendors are excited about OEMConfig, but OEMs benefit as much if not more by moving from the legacy approach of EMM API integration to a wholly owned and controlled alternative.

When working with EMMs there are always time constraints, budget restraints, PMs who have their own priorities and opinions on what should and should not be incorporated into their solutions. Before EMMs are finished implementing one set of APIs, OEMs are working on new and updated features.

It’s slow, cumbersome, very likely frustrating also.

OEMConfig takes so much of this burden away from both sides. The EMMs no longer have to implement bespoke APIs, and the OEMs have complete control over what APIs are available to all EMMs, universally, who support managed configurations (and nested configurations). OEMs can add new features daily if so inclined, and as soon as the OEMConfig app is published, customers across the world see it almost immediately.

It is utterly incredible the impact this will have on the ecosystem, or arguably already is having given Zebra, Samsung, ~~Sony~~, DataLogic, Honeywell and undoubtedly many more all support OEMConfig already. Even OEMs who in the past may not have wanted to dabble with custom APIs may choose to do so now that it’s so simple, without any of the legacy overhead of years gone by, and in doing so it fulfils Google’s ambition to embrace value-added functionality over and above Android Enterprise base APIs.

It is an absolute win for all involved.

The Android Enterprise ecosystem impact

Without Android Enterprise the ecosystem would be drastically different. Few OEMs would be singing from the same hymn sheet, fragmentation would have remained rife for support across EMM/UEMs and just a few market leaders would dominate the enterprise space with little competition.

Not to mention the perception of Android would likely still be suffering around security and usability, PHAs would have far more control over modern devices on permission-based attacks (my reasoning being without AE, DA deprecation wouldn’t have happened) and probably more.

How did we close out 2019?

Version stats

As Google’s official distribution dashboard has been broken for about 20% of the decade in itself, there’s no really good data to show how Android 10 has been adopted over the last few months.

Turning to other sources though, like the stats from my own site over the year, it has similarities to other recently published stats the wider internet has been talking about recently.

Pie is dominating the chart (green) with 52% of all mobile visits this year, which in itself is incredible; equally impressive however is Android 10 (darker blue, top) contributing 6% of visits.

6% might not seem much, but it sits higher than all versions below Nougat (also at 6% with 7.0, 9% if including 7.1) and Oreo 8.1 (but not 8.0, interestingly).

That Android 7.1 (which officially dropped out of security update support last November) and lower contributed to >18% of visits doesn’t fill me with joy, but the numbers of old devices are slowly decreasing.

Back to Android 10, compared to years gone when the latest version of the OS is in the single digits more than half a year after release, as opposed to nearing double digits in only 4 months, the work of initiatives like Project Treble have had immense influence over how rapidly devices receive the newest letter upgrades.

Desserts are no more

With Android 10, the last release of the decade, Google opted to forego desserts in favour for a simple, straightforward number going into 2020.

While Google have confirmed letters would still be used internally, all future updates to Android will be number based. No more quirky desserts!

Device Admin APIs are deprecated

After over two years of talking about it, DA APIs were officially deprecated in 2019. The so many issues associated with DA will slowly now become a thing of the past as Google continue to deprecate APIs.

But more than this, the deadline for Android Enterprise Recommended EMMs to bump up minimum supported API to Android 10 (API 29) was by January 2020. At that point any Android 10 device enrolling into these EMMs would no longer be able to properly manage legacy enrolled devices.

At the time of writing, both MobileIron, who have really led by example for Android Enterprise support of features over the last few years, and Softbank’s Business Center EMM have updated their DPCs to target Android 10. No doubt others will soon follow.

The sooner DA goes away, the better. Going into 2020 however that is still a very distant future!

The days of building a custom DPC are over

Google are super intent on pushing forward with the Android Management API (AMAPI), despite it’s late development and lack of features. Visiting the EMM community registration page for the Play EMM API shows it’s no longer possible to even register with the EMM community for a custom DPC based solution.

That would be a non-issue if AMAPI was a drop-in replacement for Play EMM APIs with comparable features and flexibility, but it isn’t as yet. AMAPI is getting there but still has so far to go and means we’ve probably got a long wait before it comes close to being on-par with the custom DPC leaders (VMware, MobileIron, etc). We lack COPE (work profiles on fully managed devices), granular control of cross-profile sharing intents, proper location control, ephemeral user support, system app management, and undoubtedly plenty more I haven’t had use cases for to learn they aren’t supported.

The end-goal is great, AMAPI offering all the benefits outlined in many other articles and docs I’ve written will do wonders for the future of Android management – the minimal vendor development, zero-day support for new features, the native look and feel of a device managed through AMAPI, and more.. Until then, though, we sit and wait while Google pop out incremental updates on a monthly basis while lacking basic features custom DPC solutions have offered for years.

Hopefully in 2020 it’ll get to a point where choosing between AMAPI or Play EMM API – for existing vendors at least given that choice has now been taken away from the wider ecosystem – will be a no-brainer, and AMAPI will rapidly get far ahead of Play EMM API in functionality. It goes without saying that by the time the 20’s draw to a close most will likely forget there was even a time when anything other than AMAPI was used.

More devices than ever before are patched and secure

It is extremely likely your Android device, whether bought for business or as a consumer, is benefiting from the enormous drive to get OEMs patching more frequently and for longer.

If you’re using a Nokia, counterpoint research shows you’re also most likely to be running the latest version of Android.

With the likes of Android Enterprise Recommended requiring 3 years of security updates, the Android One program requiring them every 30 days, and more and more OEMs taking the enterprise market and it’s requirements far more seriously over recent years, the knock-on effect is a more secure, more frequently updated ecosystem for everyone.

To the next decade

It has been fascinating to watch Android evolve over the years and the influence so many ecosystem partners have had on it, even more-so given the profound impact Android has had on my career over the last 10 (and longer) years; without Android I’d still probably be doing Disaster Recovery!

As can be imagined there are so many topics I haven’t touched on, be that fully or at all. As much as I’d like to carry on rambling, I wouldn’t be able to cover off all of the topics readers would be expecting to see if I tried!

Finally, if 2020 is the year you’re thinking about adopting Android, take a look at why Gartner have ranked Android highest in the category for security controls, kernel security and more the last couple of years, and check out this article on why Android is the perfect OS for business. If you’re looking to move away from device admin with your existing legacy-managed fleet ahead of Android 10 adoption, check out my doc on considerations when migrating.

Here’s to the next decade, and a very belated Happy New Year!

Why Intune doesn't support Android Enterprise COPE

2019-10-24T16:15:25Z

Does Intune Support COPE?

Literally everyone.

It’s one of the most frequent questions I get. So much so that a year ago I created a resource dedicated to answering the question, DoesIntuneSupportAECOPE.info, which has seen up to 500 visits in a month this year.

The answer, if it wasn’t clear already of course, is no. Intune doesn’t support COPE today, along with several other EMMs on the market such as MaaS360 and, surprisingly given their Android legacy, SOTI.

This isn’t through lack of desire to do so on the part of Microsoft, as they’re fully aware of the need to support arguably the best, most flexible Android Enterprise deployment scenario available today for offering the closest experience to legacy device admin management of whole-device management plus containerised corporate data.

Unfortunately however, unlike most other EMMs on the market who don’t feel compelled to support COPE through lack of desire or constraints on time/budget, the choice to support COPE isn’t solely Microsoft’s to make.

What is the Android Management API?

Announced at the partner summit in 2018, the Android Management API (AMAPI) is Google’s attempt to bring the management of the many Android Enterprise APIs in-house under one native-feeling management experience.

Unlike most EMMs on the market who’ve built their own custom DPCs (Device Policy Controllers, EMM agents) from the ground up based on Play EMM APIs, AMAPI offers the ecosystem the opportunity to build Android Enterprise support into their EMM with relatively little effort complete with an already-existing DPC, the Android Device Policy.

The benefits of AMAPI for new EMMs are unmatched, with advertised zero-day support for Android Enterprise APIs as standard, but it comes at a cost.

If you build your own custom DPC, you define your own priorities. You choose what to support, when, and can roadmap accordingly. With AMAPI you’re held hostage to the pace of Google’s development, which has been unbearably slow for a number of features custom DPC EMMs have had for years, including COPE. If you want something new or currently unsupported you ask for it. Then wait.

As an aside, you also succumb to decisions they make over what APIs to deprecate, such as the recent decision to deprecate the dedicated statusBarDisabled API for blocking access to the notification bar to instead roll it into the locktask policy, which is crazy.

So Intune uses AMAPI?

Yes. Well, both AMAPI and Play EMM APIs actually. For work profile deployments, Intune’s custom DPC guides users through the enrolment and setup of a work profile, but if you’d like to support dedicated devices, the newly-supported fully managed deployment scenario, or in future COPE, this is pushed through AMAPI and Google’s Android Device Policy.

Intune is one of Google’s top AMAPI partners today, and with the clout of Microsoft the fact COPE is still missing in AMAPI two years after it’s introduction with Oreo is telling; it offers little hope for other AMAPI ecosystem partners thinking they can compel the AMAPI team into supporting COPE any sooner.

Could Intune support COPE, fully managed and dedicated through their custom DPC? Yes. It’d be no different to MobileIron, VMware or BlackBerry who all support COPE today. At this point though, it’d probably take longer to get it up and running than simply sitting on their hands while Google gets on with it. COPE is in the works according to the AMAPI team, who provided a little insight into what they’re doing with the deployment scenario over 5 months ago.

In any case, the next time Intune’s support for COPE comes up in conversation, rather than the typical berating of Microsoft for their lack of pace to bring a feature to fruition, consider in this case it’s entirely Google holding up both them, and every other AMAPI EMM on the market.

That is of course until Google releases COPE, then it’s all on Microsoft.

VMware WS1 UEM 1908 supports Android Enterprise enrolments on closed networks and AOSP devices

2019-08-24T22:01:17Z

Last week VMware released WS1 UEM 1908 with a surprising new feature, Android Enterprise enrolment for devices without the ability to leverage GMS apps and services.

https://www.youtube.com/embed/zmFgocI27zM?start=305

WS1 release video, 5:05 onwards is the brief Android mention.In the short overview above (starting at 5:05) a simple explanation of the feature is provided:

We’ve added support for enrolling work-managed devices without Google Play Services. With this feature you will be able to configure Android Enterprise on devices running on a closed network which has no internet access or without Google Mobile Services (GMS)

Roger Deane, VMware

On first glance I took this to mean, perhaps, Google had introduced an answer to challenges faced by organisations where Google services aren’t available, such as in China (where GMS cannot be used due to the country blocking access to Google services) and VMware were simply first to leverage it; however on checking it out, it’s instead an option provided by VMware to exploit a technical possibility Google aren’t keen to encourage.

Enabling AOSP enrolment

This feature is enabled at the Organisation level within settings. For orgs without an AE bind in place already, a checkbox appears with a warning when ticked:

For those with a bind in place, simply click on the Enrollment Settings tab, Override if required and switch the work-managed enrollment type to AOSP/CLOSED NETWORK

The (obvious) caveats

Effectively all that appears to be happening is a typical Android Enterprise enrolment (provisioned however it makes sense to do so for your organisation) without the creation and assignment of a managed Google Play account.

Without said account, you lose access to Android Enterprise features which rely on this, primarily:

No silent app install via Google Play, providing access to apps in Google Play or deploying managed configurations for public apps. The only means of pushing apps is sideloading APKs.
No OEMConfig for public apps (relies on Play API)
Any account-based features

VMware does support deploying managed configurations and OEMconfig through XML profiles, though with that you’re still required to take any public apps you want to support, locate an APK from a trusted source and manage it accordingly for all device types and architectures. It’s not something I’d advocate.

Arguably in closed networks none of this would be a concern, and a number of other features equally wouldn’t be available without access to Google anyway.

One side-effect to consider also, when provisioning a device using DPC identifier, the process of removing the placeholder account and swapping it out was not undertaken, so all devices provisioned in this way will be left with an “Android Enterprise” account on the device, which may cause issues.

Why this works

Google only supports Android Enterprise on GMS devices, those aligned with the CDD (Compatibility Definition Doc, which defines how an Android device should function and what it should support in order to be considered compatible with the wider Android ecosystem).

Prior to gaining GMS certification the device is considered AOSP, but in aligning to the CDD and preparing for GMS without undergoing GMS certification, the APIs for Android Enterprise are already there and pretty much guaranteed to work. (OEMs that don’t align with the CDD are more likely to ship with poor support for AE, mind you, so can those who supposedly do qualify for GMS!).

Therefore, technically, AOSP devices can leverage Android Enterprise management, without GMS and thus managed Google Play, Android Management API, etc compatibility. Only the restrictions work.

As mentioned above, it’s not something Google actively encourage.

It didn’t work too well for me

I attempted an enrolment with the AOSP setting selected, and via two separate provisioning methods (NFC, DPC identifier) Hub crashed out and refused to open on an Xperia 10.

It turned out to be due to a requirement for an agent update that wasn’t well-publicised, and since updating has resolved the crashing issue.

VMware aren’t the first to introduce this

As it happens when I realised this was a VMware-implemented feature, it reminded me of what Miradore have had for a few years.

They offer a completely free tier with very basic management capabilities; Android Enterprise restrictions are included in this tier, but managed Google Play accounts and the associated Google Play features require an upgrade.

Miradore aren’t the only ones either, with SOTI also supporting enrolment without the creation of managed Google Play accounts, they just don’t make a lot of noise about it.

Encouraging non-GMS enrolments

What’s concerning with VMware’s implementation is wording it in a way that actively targets non-GMS devices. While perfectly valid for OEMs like Zebra who offer a GMS-restricted mode on otherwise GMS licensed devices, when targeting AOSP as a valid option for AE management, organisations are far more likely to run into problems with devices that can’t be certified.

By pushing this as a solution for AOSP device management it encourages organisations to stray from GMS Android and into the murky realms of AOSP; cheap devices sourced from ebay or further afield, those by manufacturers with no intention to support not only enterprise capabilities, but aligning to the standards of GMS to begin with.

I know this, because I’ve already had these types of questions land in my inbox, with references to unknown OEMs and how they may suddenly be viable for organisations who’d typically stick to GMS.

To conclude

VMware are clearly thinking outside the box in bringing solutions to market where Google are dragging their heels (closed networks, China), but it’s less thrilling to see it actively promoted as a solution for uncertified devices.

If I was marketing this myself, I’d have focused purely on closed networks and left those who can put 2+2 together to realise the implications for non-GMS devices. As is stands I foresee the potential for trouble ahead. Especially with device admin deprecation pushing organisations to figure out how they’re going to adapt in future.

Time will tell.

The Bayton 2019 Android Enterprise experience survey

2019-08-20T00:50:45Z

I’ve worked with Android in an enterprise context for more than 5 years (10 outside of enterprise!), and have watched it grow from something minute to literally the biggest mobile OS in the world.

In the last three or so years I’ve been focusing my attention directly on Android Enterprise, have written about it extensively since publishing What is Android Enterprise in 2017 and have helped hundreds of organisations embrace modern Android management across the world. It’s been quite the journey!

I have my own experiences with Android, but as we look forward to Android Q, the deprecation of Device Administrator APIs and a future of Android Enterprise as the default and only means for managing Android devices in the enterprise, I’m super interested in knowing how the experiences of the wider community compare to my own.

With that, I introduce the Bayton 2019 Android Enterprise experience survey!

What it is

It’s a comprehensive survey aimed at anyone within an organisation managing Android Enterprise devices. It’s also suitable for MSPs, system integrators or other ecosystem partners who manage devices on behalf of other companies directly (ie, managed service).

The goal

This is something I’ve been working on for a while, and am keen to get as many responses as possible; the resulting report I hope will offer one of the most transparent, extensive insights into experiences and perceptions of Android in the enterprise available. It should highlight pain-points, top features, deployment trends, diversity of management and gauge the general understanding of some key Android Enterprise concepts.

Take part

There’s a fair bit of content within the survey so please do grab a cup of your preferred beverage if you’d like to take part, and I look forward to watching the responses roll in!

The survey is embedded below, but if it fails to load, here’s a link.

Android Enterprise Partner Summit 2019 highlights

2019-06-09T12:30:03Z

Much like 2018, I’d been waiting for the Summit to come around all year. It’s by far my favourite event not only for the content, but the ability to sit down with Googlers, with partners and everyone else in the Android Ecosystem to have proper, in-depth conversations about Android in (and out of) the enterprise.

One of the overall highlights is meeting folks who’ve followed my content over the years. From Europe to the US, JAPAC and more, there’s no event where I shake more hands and get to talk with more people who’ve leveraged my content to bring their own projects to fruition. It’s truly humbling and incredibly motivational!

To preface the following, it’s taken a good while for me to put something together primarily because I’d been waiting on the slides and content promised for release the week following the summit to arrive. They still haven’t, nor have I been able to get hold of anything outside of official channels. Because I’d missed a few sessions given the split of GTM and Technical, the highlights I post are based primarily on what I saw.

Google also worked hard to make clear what was NDA this year, including, for whatever reason, the Android Enterprise stats I shared last year. As such, some of the stuff that I’d normally refer to in order to show how incredibly well Android Enterprise is doing in the industry I cannot. Go figure.

With that out of the way, lets get into it!

It wasn’t all new

As expected sitting on the bleeding edge of Android Enterprise, there was a fair bit of content I’d already seen or written about over the year. That isn’t to suggest the content wasn’t new to many others (my LinkedIn feed was blowing up!), but topics around zero-touch, the Play iFrame, DA migration, Samsung’s OEMConfig and so on were all very much covered through the year.

In fact, if you’re not familiar with my documentation, please take an opportunity to head on over to /android for a gander, you’ll arguably get far more information out of those docs than this recap of the summit!

But plenty was

Android Enterprise continues to grow at an incredibly rapid pace. Despite not being able to share the newest slide that offers little more than the upwards indicator (I refer back to last year’s “10x growth” of something) to back up my statement, Android as a platform has increasingly dominated the enterprise market over the last year and the uptick in AE adoption is an obvious side effect; one of those reasons I can state is the rugged market which Microsoft still has a stake in, as demonstrated by the slide:

As 2020 approaches and more organisations finally, with full justification, give up on Windows 10 Mobile, Windows Phone, Windows CE and other versions of Microsoft’s Mobile OS, Android is the clear choice. Why?

Form factor
Budget
Flexibility

Android fills the void left by Microsoft very well, and subsequently improves it in almost every way.

Stats

Android patching: In Q4 2018, 84% more devices were patched compared to the same time a year prior. 2017 already being a pretty good year for patches with a 30% increase on 2016, it’s extremely telling just how much energy has been directed towards this space. Through programmes like AER, Android One and a generally wider acknowledgement of how important patching is both in the enterprise and consumer space, the stats now speak for themselves.

Play Protect: Now protecting 2.5 billion devices, Play Protect continues to analyse 500K and verify 50 billion applications every day.

Admittedly the rate of infection has increased over 2017, however the figures are still impressively low. This is and always will be a moving target, so depending on when the stats are collected this can be higher or lower, the Android Ecosystem Security Transparency Report goes into a lot more detail on these stats.

Zero-touch growth: In the last year the number of zero-touch resellers has grown to 116, with many more still to come in 2019. The big news in the reseller space was the introduction of the common library with Samsung back at MWC. The number of devices that support zero-touch now dwarfs the 30-odd last year also.

Growth in awareness of Android Enterprise Recommended: Google leveraged a report undertaken by HMD Global (Nokia) in 2018 available in full here to demonstrate how well AER is doing just a year after launch:

With 18 OEMs and 75+ devices, the AER devices programme has grown too! AER also launched for EMMs and MSPs, with the Android Enterprise Experts validation program boasting 133 validated experts in the first run:

The Android Management API

AMAPI was an enormous focus of the event, taking up a good bit of my time across the two days. In a nutshell:

AMAPI is now out of beta: With its rapid pace of development and the fact there’s little front-end marketing of AMAPI within EMM solutions, it would have been easy to assume AMAPI left beta a while ago, but no! AMAPI came out of beta during the summit.

COPE support is coming soon: A huge deal not only for AMAPI itself (finally, only 2 years after Oreo) but all of the EMMs today waiting on said support. Intune is definitely the biggest name to embrace AMAPI today and the MS team there must have been as pleased as me to get confirmation.

It’s going native: AMAPI is ditching the dedicated app icon on the launcher for an integrated feeling within device settings. Combined with becoming a part of GMS-optional (a list of optional applications OEMs can bundle on a device alongside Core GMS apps), AMAPI is going to feel almost as native as Windows and iOS.

Being Android it’s still app-driven, and will continue to receive updates through Google Play, but irrespective of this, when users look to understand the policies enforced on the device, as well as the privacy impact of said policies, it’ll all be available by navigating to Settings on the device.

Wider SSO capabilities: To further assist vendors in developing as little as possible when integrating AMAPI, it has been expanded to support authentication through multiple IDPs.

Supporting differentiation: I’ve had plenty of conversations about AMAPI and in implications of going all-in. “How do we stand out?”. AMAPI will support extensibility to promote EMM differentiation by allowing vendors to build out custom features. Some of the examples offered were custom compliance policies, geofencing, and more.

Vendors will no longer be limited by Google on when (if ever) some functionality will be supported, with support for extensibility vendors can jump right in and build something themselves. It’s very much like the OEMConfig of AMAPI.

Smart system app management: Google see system app management as a chore. Something that’s difficult to manage, rarely consistent across OEMs and generally in need of improvement. They’ve introduced smart system apps to automatically “enable the right system apps for every device”.

I like the idea in theory, but frankly system app management has rarely been an issue for me (in the wider context of deployments I’ve undertaken over the years), and I’d much rather have manual control than rely on some algorithm to determine what to enable on my behalf. I’d super appreciate if Google would just give me the fine-grained control I’ve had with Play EMM API for years. Please and thank you!

Improvements to managed config

Managed config is one of the best features of Android Enterprise. That a developer can expose settings to be configured remotely that automatically appear within an EMM for admins to configure is pretty marvellous!

But it’s not perfect.

Managed config offers little in the way of feedback, has been occasionally unreliable on some devices in some situations, failing to update configs pushed out any more.

Google offered a nice few announcements on how this will improve.

App feedback channel: A limitation of managed config to date has been the one-sidedness of it all. An admin will add and distribute configuration, and then it probably applies. I say probably because unless you have the device in front of you it’s hard to say.

The app feedback channel offers a means for bidirectional communication. Admins can query the state at any point and get a response to confirm a managed config has executed, whether that’s an app or OEMConfig.

Update broadcast: Equally trying over the years has been the perception that managed configs just don’t update in a timely fashion. I’ve personally had situations where it can take hours for a change to reflect in Gmail for example. Update broadcast should help.

Rather than waiting for a managed config to arrive eventually, update broadcast will directly ping applications to say there’s a new managed config to apply irrespective of app state in a much more direct and reliable fashion.

Timeline update for DA Deprecation

As Device Administrator Deprecation with Android Q nears, Google were nice enough to offer a much clearer picture on the timeline of true DADEP:

While technically Q deprecates DA features, the reality of it, as I’ve outlined already is far from the immediate, breaking change the likes of Apple are going for with iOS 13 and deprecation of unsupervised restrictions!

As above, the main milestones for DADep are:

AER EMMs targeting API level 29 (Q) with their DPCs by 2020
Google Play enforcing the minimum API level in mid 2020 for new apps, and late 2020 for updates.

Based on the clear timeline above, I went ahead and changed my own countdown to align with the AER EMM requirement of by 2020. It’s quite possible AER EMMs will target API 29 before this deadline, so I’d very much encourage orgs to reach out to vendors for a clear date in the diary to align with. Nobody should be sitting around waiting to see what deprecation will break though. Take a look at my considerations doc and get planning!

Android Enterprise Recommended

Finally, we got a glimpse at what’s to come for AER across the board, including the long-anticipated AER for Carriers (and one the obvious requirements they’ll need to meet).

AER for devices: In Q, one of the most interesting requirements from my point of view is the new setup flow, as it’s flown mostly under the radar so far. I’d touched on it in my post dabbling with Q enterprise as both very good from a user education perspective, but equally the side effect of it slowing down provisioning. I’ll be testing it again with beta 4 in due course.

The requirement for the work tab is excellent. Too many devices today still don’t leverage it in Pie (some equally can’t manage to get a folder on the home screen either!) and given it’s improved usability it should absolutely be prioritised.

File-based encryption is great to see also. It’s popped up here and there over the last few releases but Google weren’t able to make it mandatory. Starting its enforcement through AER is a great stepping stone to mandate it in R (or later) globally.

AER for EMMs: Both mentioned ecosystem projects are exciting to see! First is support for OEMConfig, which though plenty of EMMs say they support, could definitely be improved.

The second is COPE, or COMP, or fully managed devices with work profiles, or work profiles on fully managed devices, or now personally enabled work devices..

Whatever it’s called, BlackBerry UEM adding support for COPE this week still brings the grand total number of vendors to support it to 3 across 4 EMMs. 2 years after Oreo’s release introducing this capability it’s incredible how few EMMs have integrated the solution set. I cannot wait for a mandate to come into force.

AER for Carriers: Long anticipated, AER for Carriers will require, amongst other things:

Zero-touch enrolment
Rapid approval for security maintenance releases

Disappointingly on the latter, limiting it only to SMRs means major platform upgrades will still likely be delayed by carriers I feel should have limited involvement with OS releases in the first place; it still makes sense therefore for organisations to opt for world wide SKUs where possible.

I look forward to seeing another uptick in zero-touch resellers coming on board as part of the AER validation process though!

![](https://cdn.bayton.org/uploads/2019/06/image-27.png

AER for MSPs: No big announcements here, as the requirements for 2020 won’t be out until July. However it does look like we’re on course to see the Experts program opening up to more people in the not too distant future! I look forward to seeing more experts validated!

Android Enterprise Partner Program

Finally, as someone who’s been asking Google for partner status for years through the work I do on the site, the AEPP is a sight to behold! While I won’t hold my breath on getting partner recognition despite the organisations around the world I happily help on a daily basis, one can live in hope!

In any case, for partners who can’t get Recommended status for for one reason or another, the AEPP offers a means to still get listed in the directory and thus recognition through Google.

It will help build out the ecosystem of partners even further, which is only a good thing.

Final thoughts

Again most of my highlights here reflect what I personally saw at the summit. There were certainly other interesting announcements, one of which being the demo generator to aid in pitching Android Enterprise with pre-made content and topics to cover. It’s a great idea for partners needing a little inspiration or simply collateral.

In any case it was once more a fantastic event, that would only have been better if I was allowed again this year to liveblog!

I look forward to announcements finding their way into releases and getting hands on with a whole slew of new features. Until next time!

Photos

The Huawei ban and Enterprise: what now?

2019-05-29T23:37:00Z

Update 01 July

Over the weekend Trump announced a back-pedal of sorts which allows Huawei to regain the ability to license Android GMS and purchase from hardware vendors they rely on.

🙄https://t.co/b9a3XiporA

— Jason Bayton (@JasonBayton) June 29, 2019

How this will impact Huawei’s plan to offer an alternative OS in the market is yet to be seen, but given the damage Trump caused by adding Huawei to the entity list to begin with, I’d be surprised if Huawei went back to acting as though nothing has happened.

At this point most people should be aware of the situation surrounding Huawei; the subject of global news for a few weeks now, with partnerships all over the world critical to Huawei’s mobile business either temporarily or permanently cutting ties with the world’s #2 OEM in something of a domino effect.

For all intents and purposes of the following, it appears the situation is still very much fluid. While ties are indeed cut right now, Trump has alluded to the possibility of the situation being repaired should a trade deal with China work in favour of the US:

If it wasn't clear as day before, Huawei is just a tool.

Trump's like: Huawei are a grave and terrible threat to humanity but hey China, give me favourable trade terms and maybe Huawei are fine after all.https://t.co/Zz4ZQO02MM

— Jason Bayton (@JasonBayton) May 24, 2019

Given the fluidity, the following is part what I know and part what can be expected. It is based on information available online, knowledge of how some of these moving parts go together and some informal chats with relevant people a little closer to the action than myself.

If indeed Huawei remains on the entity list, here’s how it’ll impact enterprise.

Before continuing..

Very clearly to start with, if organisations are evaluating, piloting or otherwise preparing for a deployment consisting of Huawei devices right now, stop.

Talk to your account managers or resellers about switching to another OEM. The Android Enterprise Recommended list offers several other options which will ensure consistency and reliability of management going forward.

Nothing will happen until August

First and foremost, the ban initially placed on Huawei was eased until August while everyone works out what to do next. That means until then, updates will continue to push without issue and Google will continue to work with Huawei directly.

After August

If no solution is in place by August, things take a somewhat more uncertain turn. As it stands:

Devices should continue to work

Huawei and Google have together stressed multiple times Huawei devices available today will maintain access to Google Play and GMS services. Nothing stops working. Warranties and support will be unaffected also.

Essentially what works today will continue, what doesn’t may not be fixed (including the work profile issue, unless fixed before August on all affected devices) if it requires more than a security update.

Despite the very public break-up of Huawei with various organisations, they’re pretty confident in their ability to continue:

Recently, a handful of standards and industry organizations have put some aspects of collaboration with Huawei on hold in response to political pressure. We are disappointed by these decisions, but they will not have an effect on our daily operations. We will continue to provide our customers with top-quality products and services.

Huawei

In other words, if organisations aren’t facing issues with devices right now, they should remain pretty much in this state for their shelf-life.

Certified letter upgrades will cease

Before a letter upgrade (Oreo, Pie, Q.. ) is ready to roll out, it must first be GMS recertified. This is typically a painless process as the device will already have undergone GMS certification to go to market.

With the GMS license revoked, any upgrades would not be permitted with GMS applications (Gmail, Play, Chrome, etc). While Huawei could push an uncertified upgrade and remove the GMS applications in the process, that’s unlikely.

As Huawei are seemingly almost ready to launch their new OS based on Android, it may be possible in future to manually flash (if no opt-in OTA is provided) over to the non-GMS alternative and benefit potentially from more active development, though understandably enterprise management will suffer as a result.

Security updates should continue

Unlike letter upgrades, Huawei should be able to push security updates via AOSP to existing devices to keep them patched. While typically SMRs would also be recertified, Huawei seem to suggest they’ll be able to get around this, though details are sparse.

In a statement to various online sources, Huawei said:

Huawei will continue to provide security updates and after sales services to all existing Huawei and Honor smartphone and tablet products covering those have been sold or still in stock globally. We will continue to build a safe and sustainable software ecosystem, in order to provide the best experience for all users globally.

Huawei

Android Enterprise

Though removed from Android Enterprise Recommended, this doesn’t automatically mean Huawei devices can no longer be used in the enterprise; AER validation is based on more than simple hardware requirements and standardised validation tests to be considered for AER, and Google made the appropriate choice to delist Huawei on these other factors.

Android Enterprise does and will continue to work for as long as the devices currently GMS certified remain so. Should an update in future remove GMS applications, Android Enterprise will suffer as a result (all Play API features will be removed with it). This however is not planned, nor would it make sense to do so for Huawei.

No reason to panic

Organisations with existing, mature deployments will not necessarily be in a position to swap their estate for another OEM. Technically however as mentioned above the devices should continue to work until a hardware refresh can be budgeted and undertaken. Nothing should simply cease to function.

My chief concern would be the implementation of security updates, which I’m yet to see any real clarity on. Without security updates (or partial security updates, because we don’t yet know what these look like) devices may be left open to vulnerabilities, so I hope to see a solution on this sooner rather than later.

Unless Huawei, the US and China come to some agreement by August, the best course of action would be to plan a thoughtful migration as devices reach scheduled end-of-life, but equally have a new OEM lined up to take the place of Huawei should devices fail ad-hoc.

In any case, organisations who ultimately deployed Huawei did so following pilots or proof-of-concepts which demonstrated suitability for use, and this suitability should not change any time soon.

Keeping tabs

I’ve got a few recent Huawei devices to hand, including the Mate 20 Pro which is new (and flagship) enough to receive focus from Huawei on whatever is coming next. I will be following any developments closely.

As more information becomes available, I’ll also update this post as and when relevant.

Dabbling with Android Enterprise in Q beta 3

2019-05-08T17:32:17Z

Yesterday Google announced Q beta 3 for 21 phones across 13 brands, an incredible increase on the 11 devices last year with Pie.

I happen to have several devices on hand (but no Pixel!) thanks in part to my device testing, and of them all, Sony probably has the slickest, most straight-forward opt-in through their Xperia Companion desktop app.

All I needed to do was plug the XZ3 in while switched on, hold down Option (Mac, ALT on Windows) and click software repair. It gave me a few warnings and such, then just got on with it.

Moments later, Q.

I’ll preface all of the following with a small disclaimer: everything below was tested on the first public, non-Pixel beta and reflects only how Q behaves on the Sony Xperia XZ3. There may be aspects of the below which work well on Pixel, Nokia or other OEMs.

Starting with provisioning

There’s a new provisioning flow with Q which adds more contextual information, and offers end-users a clearer indication of what’s happening during provisioning.

This appears to come at the cost of provisioning speed, however, as demonstrated in my typically rubbish demo video:

https://www.youtube.com/embed/5wBAJuQnxDM

XZ3 with Q on the left

At 1:10 in the video the Nokia is already finished, ready to go. It took another 20 seconds and a couple more taps to get to the same outcome with Q.

On the one hand I like how thoughtful Google are being about end-user perception and setting expectations, consider this following screen which seems to change depending on provisioning method/type:

On the other hand, I want my corporate devices provisioned with as few taps as possible, and introducing more contradicts that.

I wasn’t able to test NFC or zero-touch provisioning as they’re not supported in beta 3 on the XZ3 it would appear, however I did quickly whiz through DPC identifier provisioning to check one thing:

The Google services prompt is still present in Q, unfortunately it looks like we may go another year skipping through it.

There are also a few new screens with work profile enrolment:

EMMs don’t function well, yet

In the enrolments above I opted for an AMAPI based solution as this is the only solution I tested that managed to successfully enrol the XZ3.

Both MobileIron Core and Cloud agents locked up as soon as they launched following provisioning, and VMware Workspace ONE UEM force-closed both during and after provisioning. After setting up the device normally and attempting to enrol using a work profile the same happened, with neither MI nor WS1 able to complete the creation of a work profile.

Is this surprising? Of course not. There were a few new features introduced with Q surrounding provisioning which EMMs clearly won’t have implemented yet, as well as the fact that betas are such for a reason.

Other items of interest

Cross-profile calendar access

While poking around I did find a couple of other things worth note. To start with, the new cross-profile calendar access feature, which I noted was forced to enabled with both the failing EMMs and AMAPI:

As it happens Google Calendar doesn’t support this yet, so nothing was shown, nor is it clear if this is working already as a feature. In any case, it should probably default to disabled given the privacy implications of exposing calendar entries.

Subtle passcode setup change

I also noted during normal setup, there’s a change in how passcode is presented to users. While in previous Android versions passcode has been opt-in, in Q the passcode and fingerprint is presented as if it’s part of the setup flow:

It can of course be skipped, but I do very much like this approach and wonder how this will impact passcode adoption. I also noted how much faster it was to set up a fingerprint, though this is likely nothing to read into just yet.

QR code WiFi connection

Connecting to WiFi via QR code, another feature introduced with Q, is also so incredibly slick; with the exception of cert-based WiFi, I’ve never connected to a network so rapidly:

### New permissions prompts

Finally I also got a bit of a taste of the revamped Q permissions system, and I have to say I like it, though perhaps the big blocky overlay could be adjusted to look a little nicer.

I also learned today MobileIron asks for both the ability to manage phone calls (normal for IMEI info etc) and view call logs, the latter WS1 does not (this isn’t new, I just hadn’t paid attention having not actively compared EMM permission requests before!).

Conclusion

It was interesting to dig into Q a little, though by no means does this really mean an awful lot. The beta will change rapidly as we approach official release and so I likely won’t spend much more time in the nitty gritty until closer to the end of the beta cycle.

That said, once I get set up with the Nokia 8.1 and Pixel 3a, I’ll likely do a bit of compare and contrast on beta 3 just to see if there are large disparities between the OEMs.

Why I moved from Google WiFi to Netgear Orbi

2019-05-08T15:13:08Z

Mesh networking has been an interesting topic to me for a while; having always essentially run one router with a mix of wired and wireless access points, I mostly had the coverage even out into my odd bolt-on extension, but with none of the benefits of a mesh network, mainly:

Reliability: Without wiring up every access point (that is to say, running cable through the house, which is a pain in old brick buildings) all the wireless access points would do is repeat whatever signal they were able to get, meaning the connection was often unreliable in the kitchen despite a strong WiFi signal.

Mesh aids this by maintaining a more consistent connection across multiple satellites, aided further with a dedicated backhaul that doesn’t interfere with network traffic for mesh communications.

Management: From the point of leaving the router, I effectively lost most monitoring and management capabilities with access points. I’d occasionally reuse the odd DD-WRT based router as an AP and naturally got a little more flexibility with that, however even then it was multiple disjointed management portals, so left room for improvement.

With the mesh network in place I’m able to monitor each satellite from the main management portal, as well as easily seeing what devices are connected where, this comes in handy on occasion when a device doesn’t want to disconnect from the office satellite while I’m in the living room for example, and allows me to take action. I’m equally able to run diagnostics, push updates and more.

There are other benefits of mesh networking, but the above were the drivers for my network.

Google WiFi seemed like an obvious choice

Having a house literally full of Google gadgets – a Home in almost every room, Android devices up to my ears, Chromecasts, Chromecast audios (RIP), Android TV and more it made sense to look first at Google WiFi.

And it worked! For the most-part. I snagged a 3 node kit on sale and went to work decommissioning my PFSense linux router (powered by the fitlet-RM I’ve had kicking around now for many years with absolutely no problems still to this day!). Once up and running I then had to configure it via the Google WiFi app as there’s no local web portal (that I’m aware of at least).

Generally things went well, until it came to forwarding ports for external access to my hosted services. Google WiFi mandated that, in order for port forwards to be applied, a DHCP reservation must be in place.

For servers already using static IPs.

Despite that being utterly unnecessary I did so because I had to, then went about creating the forwards and everything went pretty smoothly for a while.

Though entirely app-based, I quite enjoyed using Google WiFi, and appreciated the several tools in place for managing the network, devices and more:

I also liked parental controls, the various tools for troubleshooting (testing mesh, network speed, individual wifi speed of devices connected), and integrated home control, if a little unnecessary having the home app already on my devices already.

The WiFi app is a great example of mobile-first administration that I wish more companies embraced (the Orbi app lacks a considerable amount of options, instead requiring I fall back to the web interface instead, which I’ll cover shortly).

On the hardware itself the puck design is small and compact. While I chose to hide them out of the way they’re by no means offensive. I also appreciate that any node can be primary.

If everything had remained like this it would have been perfect and I’d not be comparing products in this post.

Completely let down by the software

Unfortunately things started going downhill before Christmas, when I noticed I’d regularly lose access to my servers from outside the house.

It didn’t take long to figure out what happened; effectively Google WiFi was dropping servers randomly into an “inactive” state, and once that happened, the DHCP reservation switched to “unavailable”. killing the port forward.

Often times the whole Google WiFi network required a reboot to get it to pick up my servers again, and as this progressed it got to a point where I’d have to reboot the network entirely, and SSH into the affected servers to generate traffic in order for Google WiFi to detect them, multiple times a day.

I logged a ticket, but also started tweeting about it:

For context, #GoogleWifi requires a DHCP reservation even against servers with static IPs.

It isn't possible to create a port forward unless this is done (no port > IP basic functionality here).

Once a reservation is made, you then select it to create a port forward.

— Jason Bayton (@JasonBayton) January 5, 2019

Manually logging in became tiresome, so on the main server handling most of my traffic (HAProxy) I set up a cronjob to automatically pull down ISOs in order to keep the connection “alive” between the server and Google Wifi (NB, it’s a wired server):

*Is this enough traffic? Google WiFi didn’t think so8

Meanwhile a ticket with Google support wasn’t getting me very far, with them focusing more on the fact the satellites were on a different IP range (class A network) than the hub, an issue caused because Google WiFi wouldn’t offer the customisation I needed for DHCP, at one point I was even told Google WiFi doesn’t support class A networks, but didn’t receive any documentation or further clarification when I asked for where this is stated in the manual.

Once they’d tired of me reiterating my network was fine, they then turned their attention to issues they detected with Virgin Media (ISP), and asked I raise a ticket with them (for Google WiFi forgetting devices?). VM subsequently confirmed my broadband was fine (I humoured the request), and so back to Google it went.

Eventually during more troubleshooting, a bug was identified with the priority feature, in that on their end it was showing devices given network priority despite the app showing no such thing, and troubleshooting couldn’t continue until this was fixed with a factory reset.

As Google WiFi offers no means for backing up or restoring config, I figured if I’m going to spend an hour setting up my network again, I might as well try another product.

From my few months of use I found myself more frustrated by Google WiFi’s unreliability than any other product in recent history.

Enter Orbi

After reaching out to Netgear on Twitter, they were kind enough to send over a 3 node Orbi kit as a like-for-like replacement of the Google WiFi setup:

Orbi right off the bat offered an upgrade, boasting AC2200 over Google WiFi’s AC1200; I looked forward potentially to slightly better WiFi performance.

Unlike Google WiFi, the Orbi app offers fewer features and instead diverts users into an admin web interface most who tinker with routers would be familiar with.

Would it be nice if the Orbi app offered improved functionality? Yes, but things like speed tests, network checks, and visibility of connected clients are all present and accounted for, with a little additional functionality gained through another of Netgear’s apps, Genie (though I rarely use it).

Netgear also partner with 3rd parties for some of the functionality offered, which is built-in with Google WiFi, in particular Disney for parental controls (yet to test!) and Speedtest.net for monitoring the speed of the ISP.

I’m also rather appreciative of the traffic monitoring capabilities, but do wish the settings for limits were a little more granular, and traffic monitoring in general was a little more advanced in telling me what sort of data was being used (streaming, etc)

Legacy or not, the web interface offers everything I need and more; in particular features missed from Google WiFi, such as assigning port forwards based on IP rather than a DHCP reservation (honestly would have never thought I’d be describing this as a feature).

Orbi unboxed with a slightly older firmware version and didn’t appear to want to update to the latest (no updates detected) but as a typical Netgear product, fully supported manual updates.

As recommended, I updated the two satellites first, then the hub last with the two separate firmware packages. The network went down for a few minutes but was up and running once more in no time. Further updates were managed automatically and didn’t require this process.

The only issue I had, much like Google WiFi, was assigning a DHCP range I was happy with. For whatever reason Orbi had three of the four octets greyed out when selecting a range, despite otherwise fully supporting my class A network.

The fix for this, because I was not going to be forced to utilise the same range as the router sat on for DHCP, was to break out Chrome Devtools, re-enable the disabled octets, update the range from X.X.X.10-254 to X.X.100.10-254, and click save.

Once saved and the page refreshed, the interface appears to once more show a limited range, however on the backend, which I later confirmed with a quick telnet session, the IP range had updated and everything was working perfectly. I raised this with Netgear and my feedback was sent to engineering for consideration.

In testing I find the connection to be stable moving through the house, and though clients do still like to remain connected to satellites when moving about, as soon as a satellite goes out of range it picks up another rapidly.

I find range to be roughly similar to that of Google WiFi, but generally a little faster.

One other feature I’d have liked to see is cert-based authentication for WiFi, which Orbi (nor Orbi Pro!) features today. With Android Q around the corner I’ve been eager to test cert-based WiFi auth in QR & NFC payloads, however don’t yet have the infrastructure to do so. This was also fed back to development, so hopefully may be supported in future.

One other feature Orbi lacks is support for DNS over TLS. My Android 9 handsets are all configured to use CloudFlare’s 1.1.1.1 secure DNS service, but I’m unable at the moment to leverage this on a network level.

On the hardware side I don’t have any particularly strong feelings aesthetically. The Netgear nodes are a fair bit larger than Google WiFi but still pleasant enough to look at. This opinion comes from someone who at one point ran a network on a beaten up old Dell Optiplex though, so everything today seems pretty inoffensive by comparison!

Netgear assign a master and satellite with their 3 node kit, which means unlike Google’s WiFi it’s not a case of picking any to be a master and the others to run as satellites. I don’t know why Netgear took this approach but in honesty it’s not really a concern.

Both products offer the capability of adding more nodes/satellites for larger homes or increased coverage, though it definitely appears Netgear have a leg up on Google in terms of extensibility:

I don’t need a dedicated satellite for WiFi in the garden, but I certainly want one!

Conclusion

Neither product could necessarily be considered perfect for what I want, but the unrelenting software issues I faced with Google WiFi, for such an expensive product, was simply unacceptable.

For most I imagine this wouldn’t be an issue, after all Google have over-simplified everything about WiFi seemingly as far as possible to make it a great out-of-box experience for the majority of internet users wanting to dabble with mesh networking.

For me though, nothing beats a router I have shell access into, and the comparably advanced (in reality pretty standard) networking features I’ve come to rely on mean I need a more traditionally-approached mesh network product. Orbi fits the bill.

While Netgear perhaps falls short on the mobile-first side of things, they certainly make up for in technical capability and extensibility.

If only they had a satellite with Google assistant, I’d be sticking them everywhere!

Orbi can be purchased on Amazon:

Many thanks to Netgear for making this post possible.

I'm joining Social Mobile as Director of Android Innovation

2019-04-09T17:37:23Z

As many reading this may know, I’ve worked incredibly hard over the last few years to create the best central resource for Android Enterprise online. Starting as a few blog posts, it quickly became clear the resources I create should have their own dedicated area on the website (which I talk about more here and here), and from then to today I’ve spent my evenings and weekends building what you see over on /android.

The benefits related to this have been extraordinary (and honestly, I can’t encourage writing about your topics of choice enough; if you need a platform and work in enterprise mobility, you’re welcome to contribute to the Mobile Pros blog and build a following there), but while through this website I’ve been able to offer advice, services (such as device testing, EMM reviews, plenty more) and directly contribute towards the better support of Android Enterprise across both OEMs and EMMs, my day job has remained pretty static over the last 6 or so years, focusing on EMM deployments and support.

A new focus

The more involved I’ve been with the website, the more I’ve felt I could be better leveraging the experience and knowledge gained to date in a role where I directly contribute to the development of products and services, rather than simply implementing and supporting what’s already on the market. It’s one thing to offer feedback, it’s quite another to direct changes based on feedback.

With that said, I’m excited to announce that in May I’ll be leaving my role as Senior Consultant at CWSI to join Social Mobile as their Director of Android Innovation.

Social Mobile offer a few things:

Bespoke, private-label dedicated devices for a number of brands (large and small) around the world. As they’re private labeled it wouldn’t be obvious, though this should change in the near future. Devices are designed, specced and built to order based on customer requirements. I’m excited to get involved both with the whole manufacturing process and an aspect to the Android ecosystem that I’ve not had a massive amount of exposure to (GMS, CDD, MADA, more).

An in-house, Android Management API-based EMM – Mambo – which perfectly compliments the Android Enterprise supported & zero-touch enabled dedicated devices where an organisation may not already be leveraging an EMM (or looking to migrate!).

Consultancy and complimentary services which allow Social Mobile to be a one-stop-shop for a number of mobility needs, including device protection & insurance, reverse logistics (RMA & Repair), 3rd party logistics, connectivity and more.

What I’m doing

One of the priorities of the role, and what I’m particularly excited about, will be working with the team to develop a range of dedicated devices we’ll put through the AER programme and keep available, an off-the-shelf offering if you will. Social Mobile customers will equally benefit from the extensive device testing I do for knowledge worker devices (and a few rugged) before launch and every major update across a range of EMMs for all the devices.

Beyond this I’ll be acting as the face of the company in many respects, a point of contact for anything and everything Android Enterprise.

I’ll also be looking after public content, including whitepapers, website content, communications and more.

.org remains independent

Social Mobile, like many organisations working with or deploying Android Enterprise based solutions today, found me through my website. They fully appreciate what I’m doing through bayton.org and encourage me to continue with it.

On the devices front I’ll continue to test anything and everything I can get my hands on, and report issues with the Android Enterprise Implementation as I always have.

Likewise for EMM solutions I’ll continue to closely monitor the market and write about releases, advancements and anything generally interesting that involves Android Enterprise. Social Mobile may have an EMM, but the devices will work with any modern EMM solution supporting Android Enterprise, and it’s in my best interest – as it always has been working for an MSP – to maintain good knowledge and understanding of how various EMMs function.

The documentation I create will be utterly unaffected, beyond potentially covering broader topics in the Android ecosystem as I’m exposed to more of the inner workings of an OEM!

Onwards

I’ve had a super interesting career to date, starting out in a call centre in Amsterdam for Adobe, before moving to desktop/server support, Managed File Transfer solutions, compliance, Disaster Recovery and, for the last several years now, settling on Enterprise Mobility.

I’m excited to see what this next chapter brings! If you’re interested in following along with the Social Mobile journey, keep an eye on the corp website as it’s relaunched in the near future.

Android Enterprise in Q/10: features and clarity on DA deprecation

2019-03-29T18:00:16Z

Google recently announced the first beta of Q for Pixel devices (including the original Pixel!) and there’s a fair amount of material to get stuck into. I’ll focus only on things I find interesting for one reason or another below, everything else can be found in the links above or online!

This will be a bit of a living post for a while as betas continue to appear, so do check back for updates!

Without further ado..

Consumer features

RIP Android beam

Source: Digital Trends

There were murmurs about Android beam, the sharing option for simple transfers with an NFC bump, being removed last year, however it would appear with the first beta of Q, this has now become reality.

I will sorely miss the option to natively transfer data via NFC, it’s a feature I’ve relied on heavily in my device testing, general documentation and more. Could I achieve the same with Bluetooth? Yes. But it’s not as quick and efficient as Share > Beam > Bump.

I’ll be looking out for a 3rd party solution in the short term to fill this gap (recommendations welcome!)

Native screen recording

Source: 9to5Google

I’ve been leveraging screen recording in Android for years. From the early days of requiring root (!) to more recently developers leveraging Google Cast as the Android platform has matured. Today I rely mostly on AZ Screen Recorder and MNML. AZ has the benefit of inbuilt GIF conversion and trimming, though it’s not perfect.

I have three thoughts on native support:

Finally.
Will it be possible to leverage screen recording during the setup wizard with it natively supported? I’d hope so, I’d love to provide video provisioning guides alongside my existing screenshot-based provisioning guides, but recording a device with a camera is pretty rubbish.
In the enterprise features I saw no reference to APIs for differentiating between screenshot and screen recording. In reality it’ll likely be the one restriction for both as has been the case for iOS. Also it’s pretty raw and looks very much unfinished at the moment, so may yet be removed before final release (though hopefully not!).

Source: 9to5Google

Super useful as a consumer to allow for sharing WiFi details quickly, easily and slightly more securely than is currently possible, it’s now possible to simply tap a share button to generate a QR code with the relevant connection details within.

I do however, from an enterprise perspective, very much hope this can be restricted; there’s likely more information to come, but in an office environment I wouldn’t want employees freely offering up QR codes to scan for networks they shouldn’t normally provide access to.

Improvements to Android permissions

Source: 9to5Google

Similar to what we’ve had with iOS for a long time, Android has finally caught up in offering more advanced location permission controls in Android Q, and Google have equally upped their game on permissions generally.

Ultimately I’m not sure this will lead to much in the way of changes on the enterprise side; organisations often either want location enabled or disabled for an application (or device-wide) so the additional control is far more applicable to personal applications and the potential for unvetted apps to abuse the permission.

Desktop mode

Source: XDA Developers

Also something we’ve been hearing about for a while, desktop mode in beta 1 is currently not readily usable, but it shows Google is thinking about convergence and Android’s expanding use as a core device across multiple form factors.

I’ll be running an experiment on this very idea in the near future with Samsung, DeX and an array of docks; it’s very exciting to see native support thrown into the mix and as with Android Enterprise, I look forward to seeing a future of more consistency and reliability in picking up any Android device and having a desktop mode supported.

Enterprise features

Work profiles on company owned devices

Not to be confused with work profiles on fully managed devices, the oft-referred corporate alternative to work profiles offering control over both the parent profile (device) and the work profile in kind (aka COPE).

This is not a new deployment scenario, but rather instead the introduction of corporate provisioning tools for organisations opting to leverage only work profile on their corporate devices; a deployment scenario that accommodates almost no corporate management outside of a bit of basic security.

I couldn’t help but wonder why work profile, treated and seen by most, including Google up to now, as a BYOD solution:

…would be propelled into corporate-owned deployments with these new capabilities.

One consideration at least, given a lot of features in Q are reactive to the industry, is the continued lack of availability of COPE; almost two years after the release of Oreo, still only MobileIron and VMware support the deployment scenario at time of publishing – it’s even absent from Google’s own Android Management API. This is a point I’m keen to make as it was in my 2019 wishlist, yet entering month 4 of 2019 I’m yet to see any new EMMs gain support!

In my own experience where COPE has not been possible, be that due to EMM or Android support (8.0+), organisations desiring personal use will gravitate towards work profile, despite it’s questionable suitability for many organisations struggling with the idea of losing so much control of the device, in lieu of COPE as an alternative to fully managing devices.

My experience is somewhat reinforced by other professionals in the industry:

A question to the #EMM, #MobileSecurity industry deploying #AndroidEnterprise for customers allowing personal use:

Where the EMM, historically or currently, has NOT supported AE COPE, which deployment scenario do customers more often select?

Reasons in the replies please!

— Jason Bayton (@JasonBayton) March 28, 2019

There’s certainly justification for making the process of deploying work profiles on corporate devices simpler and quicker for the above alone, but that’s just one reason.

My friend Arsen quipped:

This is probably useful where COPE will not fly due to compliance/privacy rules/regulations, and makes the whole ecosystem more uniform.

Arsen, Android Q Enterprise Features for EMM Admin

And to that I’d agree, there are undoubtedly situations concerning privacy where work profile may be considered the only feasible deployment scenario on a platform level to avoid syncing personal app inventory to an EMM.

Wherever work profile is deemed suitable and ultimately chosen as the deployment scenario for corporate devices, there are clear benefits to integrating with existing provisioning methods. These are:

Leveraging DPC extras – as the device is provisioned it pulls down the DPC (agent). Whether it then responds with either the fully managed or work profile enrolment process (which amongst other criteria, appears it can be triggered by an additional field in DPC extras), it can equally pass through the DPC extras specified in the QR/NFC payloads or zero-touch configuration. This will make enrolment simpler for end-users not needing to know which server, enrolment token or anything else that would otherwise normally need to be input manually.

Preinstallation of the relevant DPC – with the corporate device registered with zero-touch, whether the device is factory reset or handed out brand new, the overhead associated with setting up the device and pulling down the correct agent from Play can be removed. This will shorten enrolment guides, and provide a more consistent, simpler UX for all corporate devices, as Arsen pointed out above. It also reintroduces some ownership, automatically prompting users to enrol after a factory reset or when new out of the box, something that wasn’t possible in earlier versions of Android.

Consistent UX – Android Enterprise is all about consistency, managing various different devices in the same, reliable, way. Providing corporate provisioning capabilities to devices destined only for a work profile, if this is what the organisation so desires, brings consistency – particularly in a mixed environment of deployment scenarios – and offers the same provisioning experience irrespective of how the device will ultimately be managed; one process for everything.

But there are still challenges to be overcome despite these. I had an ardent phone conversation with another good friend in the industry, Jordan, in which we identified two very fundamental issues to overcome for utilising work profile for corporate-owned devices:

Work profile is inherently – arguably intentionally – more challenging to manage due to its privacy-first design; the end-user has full control over the profile, both whether it’s switched on/off or removed entirely.

There’s really nothing preventing an end-user from disabling or removing the work profile entirely, leaving the device effectively unmanaged. An organisation desiring only to wall-off their corporate data with little concern for what an end-user does with the personal side will no doubt at the very least want to ensure it’s not immediately removed once provisioned. A policy to prevent removal of the work profile for devices known to have been provisioned or otherwise identified as corporate-owned would address this, but it must not enable organisational overreach for genuine BYOD usecases.

Factory Reset Protection has been the bane of existence for many organisations managing legacy fleets, and could be a pretty annoying, potentially costly issue to deal with for work profile deployments.

FRP is not normally a challenge with a work profile deployment as the devices would not typically be corporate-owned and thus wouldn’t be handed back. In order to address work profile being a viable solution for corporate-owned devices, it must be possible for FRP to be disabled.

What is Factory Reset Protection?

Want to know more about Factory Reset Protection (FRP)? Check out Feature spotlight: Factory Reset Protection

Ultimately the idea appears to be offering a simpler, more consistent experience which puts organisations in control of corporate devices running a work profile. It’s not a recommendation by Google to start deploying work profile in lieu of fully managed or COPE, but where its use is justified (however the organisation justifies it), it ultimately won’t be more difficult to adopt because of that choice.

Given it’s down to EMMs to implement however, one can only guess how long it takes for this capability to emerge in the wild.

With that out of the way, what is definitely, 100% useful is the added information now available when undertaking a work profile deployment, including secure-hardware-attested:

Serial
IMEI
MEID

Any additional information to better validate the devices undergoing provisioning can only be a positive thing. These do require TEE/SE and device-ID attestation (as well as support for zero-touch) so will ultimately be OEM dependent.

Before moving on, one further snippet caught my eye:

Work profile devices provisioned with a QR code will prompt users to add their personal account before returning them to the home screen. Work profile devices provisioned via zero touch or NFC won’t be prompted to add their personal account.

Android Developers, What’s new for Android in the enterprise

There’s no justification or reasoning for this mentioned, and it’s rather curious that on a work profile device the only provisioning method to prompt users to add their Google accounts as part of the enrolment flow is QR, though there’s undoubtedly potentially a technical reason as to why this may be the case, temporarily or otherwise.

Having dealt with my fair share of COPE deployments to date, one frequent complaint is the fragmented means in which users are directed to set up their devices after provisioning and enrolment; often a device will display a prompt either in settings or as a notification to finish setting up your device which then brings up the relevant aspects of the device wizard to input accounts, restore apps, etc. This doesn’t always happen though. It’s odd to see an issue in the same vein may now impact work profile deployments when provisioned with zero-touch or NFC.

Being the first beta, my hope is this will change before release, and brings similar improvements to the COPE experience.

Cross-profile calendar access

In Q it’ll be possible to permit the sharing of work calendar details into the personal calendar, not dissimilar to how contact sharing works today –

You can see the event in the personal calendar
If you attempt to edit it, you’re redirected to the work calendar

As someone who’s run a work profile consistently for the last couple of years on my personal devices, I can’t stress enough how much this will improve my workflow. All too often I’ll schedule a personal event and have to jump in and out of the personal/work calendars to ensure there’s no overlap. Expanding profile switching capabilities now available in Gmail and other applications can help, but only so much.

There is no information explicitly specified on the level of detail permitted to be shared, whether that’s as much as everything or as little as free/busy only, but the information is seemingly hidden in plain sight.

The following APIs are defined:

EXTRA_EVENT_ID
EXTRA_EVENT_BEGIN_TIME
EXTRA_EVENT_END_TIME
EXTRA_EVENT_ALL_DAY

Which suggests calendar entry details won’t be available and will require redirection to the work calendar, but even event ID, which I take to mean the title in this case as the documentation isn’t super clear, can give away more information than desired!

There are interesting privacy implications to exposing calendar entries outside of what could be a passcode-protected work profile, so anyone untoward gaining physical access to the device could well see something they shouldn’t via the personal app rather than potentially requiring secondary authentication to look at the work calendar.

Limiting input methods

This is a welcome addition. There have been times where customers have expressed interest in preventing third-party keyboards from interacting with corporate data, and for good reason!

It only takes one PHA masquerading as a fancy new keyboard to consume every keystroke and gain access to untold information – usernames, passwords, conversation histories.. the list goes on.

Unfortunately up to now whitelisting input methods was a global action, which means the whole device was limited only to the specified keyboard, which may not be considered desirable despite the benefits for security.

With this feature in Q, only the profile is targeted, so end-users can opt for the keyboard of their choice on the device, and only be limited to the organisation-defined input method when interacting with work profile applications. Win-win (assuming there is no masquerading PHA of course, then it’s only a win for the organisation!).

Manual system update installation

Following the introduction of 90 day-deferral for system updates in Pie, this feels like a considered iteration to Android system update management.

From Q it’ll be possible to further control updates as follows:

Test an update on a small number of devices before installing them widely.
Avoid duplicate downloads on bandwidth-limited networks.
Stagger installations, or update devices only when they’re not being used.

My personal favourite is the ability to download an update once, store it on the network and push it out to any/all devices as required, without said devices all attempting to download the updates individually from the internet. Obviously this requires devices be on the network to benefit, but that’s when it’s going to matter most in any case – fleets of warehouse devices, or POS kit. It’d be far more efficient.

I’m also fond of staggering installs. It’s all well and good scheduling updates for between 12am and 6am every night as is currently possible, but you’ve no guarantee the device(s) will be switched on. Pushing an update on idle is a nice way of ensuring the device is online and not actively in use for the 10 or so minutes it could be unavailable (or, simply for a reboot in the case of dual partitioned devices).

There’s no information on how manually pushing updates will affect a deferral policy currently in place, though my hope would be it is respected until the 90 days is up in order to maintain consistency.

EAP WiFi provisioning & keystore changes

In Q Google have made a change to how the keystore functions, namely no longer requiring a passcode is set in order for certs to be stored.

While arguably this might raise an eyebrow or two, it was deemed a necessary compromise for the enablement of capabilities like EAP WiFi support during provisioning.

Now, devices will be able to scan a QR/bump with NFC and obtain the relevant details and certificates to authenticate with an EAP WiFi network, meaning connectivity is automatic and silent! Perfect for bulk provisioning and far more efficient than having to type in credentials or input them plaintext within the payloads.

Furthermore, there are many situations in the industry where devices simply don’t utilise passcodes. They may be single-app or otherwise kiosked, POS, or utilised in other dedicated scenarios where a passcode either doesn’t fit the workflow or causes issues in other ways.

Clarity on DA deprecation in Q

For over a year I’ve been talking about DA deprecation with the upcoming Q release. I, like others, have said many times broadly once devices update or ship with Android Q, device admin management will no longer work.

With Q now rapidly approaching, it’s time to set expectations on exactly what to expect.

DA deprecation very much happens with Android Q, however in order for the referenced APIs being deprecated to no longer function, the application(s) on the device will need to target the Q API level.

This means, in fact, should a device update to Q right now, DA management will continue to work. When it stops functioning depends on a few things:

When the EMM DPC is updated to target Q
When Google state the minimum API level of Google Play is increasing to Q
Any additional factors, such as AER for EMM requirements changing

Based on what we’ve seen to date, Google likely won’t be setting the minimum API level of Play to Q before 2020, as it’s increasing only to Pie this year.

Any changes to the AER for EMM requirements may happen in the next few months, however having only recently launched there may yet be a period of quiet whilst in-progress EMMs get validated and through the door.

This leaves option 1, when the EMM opts themselves to target Q.

In order to leverage Q features, such as those I’ve mentioned above and all the ones I haven’t, the DPC will need to target the Q API level. It’s therefore in their best interest to do so as quickly as possible, but every vendor is different.

With that in mind, there’s no hard line in the sand at the moment on when DA deprecation will impact every organisation (in 2019 at least), but rather it’ll be a case of confirming with EMM vendors directly their plans and timelines.

I must admit the thought of a hard deprecation with the upgrade to, or new devices with, Android Q was somewhat appealing. It offered a clear view and timeline for which to meet (or have customers meet) and lit a number of fires in the ecosystem to get moved from DA to AE.

Instead what we have is both a small buffer for those who haven’t yet made the jump, and an air of uncertainty as to how long after the official release of Q vendors will target the new API level.

With that said, this should not impact any existing plans to migrate from legacy management to Android Enterprise, as the many benefits I’ve outlined in various documents should justify the switch irrespective of whether or not there may be a few more weeks/months of wiggle room. If organisations get to a point of deploying Q without Android Enterprise environments already in place, there is a very real likelihood of DA deprecation adversely affecting the business when it does come into effect.

For those looking to set up a PoC today, check out the links above, as well as Google’s DA-AE migration bluebook.

Conclusion

Just as last year I’ve only scratched the surface of new features, but those above are what I’ve personally taken an interest in. I’m always open for a chat should any other new features and their potential implications warrant a discussion!

Android Q, compared to Pie, feels like a nice incremental upgrade full of changes that compliment existing tools and features, there aren’t necessarily any major changes, like Pie’s dramatic work profile UX changes and improvements, the user management for dedicated devices. It’s something of a sign of maturity, which is only a good thing.

Unfortunately it doesn’t appear my wishlist items made it into Q, but given Q features were likely locked in last year already, anything that did happen to show up would have been coincidental! I’ll look out for them again in R.

What do you think of the new enterprise features in Q? Anything you’re excited about? Anything missing? Feel free to leave a comment, or find me on LinkedIn and Twitter to discuss!

MWC 2019: Mid-range devices excel, 5G everything, form-factors galore and Android Enterprise

2019-03-22T19:25:40Z

I was incredibly lucky to have been provided the opportunity once more to visit MWC this year; without Sony sponsoring my exhibitor ticket for the 2nd year in a row and work covering the AirBnB, it wouldn’t have been possible to make the trip again.

So after last year I wasn’t quite as taken-aback by the dominance of Android at MWC as I’d expected a similar show. Google were out in force once again in their white uniforms demonstrating the capabilities of the Google assistant, Android devices were launching left and right – though those I really wanted to be there for, including HMD Global, did everything the day before I arrived on the 24th! (and I still haven’t received a Nokia 9 yet!) – and I finally (well “finally” got to see some new Android form factors up close and personal in the Huawei and Samsung offerings (though, they certainly weren’t the highlight in form factors for me, more on that to come).

Here are a few highlights of my 2 days!

The rise of affordable devices

The Xperia 10 & 10 Plus

Not necessarily limited to MWC as this trend has been growing for a while, but MWC really started to bring it home.

Affordable phones are getting better all the time, coming down in price and more often than not offering decent, usable alternatives to the £1000 flagships for a fraction of the cost.

Most of Nokia’s range for example can be picked up for under £300 with a couple of exceptions. They all (excluding the Nokia 1, Nokia 2 and 2017 editions) run Android One, guaranteed with 2 letter upgrades (those launching with Pie will get R, most launched with Oreo in 2018 so will get Q) and three years of 30 day security patches. Not to mention almost all models come in an Android Enterprise Recommended spec with at least 2GB RAM and 32GB storage. The new Nokia 9 Pureview, though not bleeding edge, still runs flagship hardware for under £600.

It’s not just Nokia though, Motorola’s G series is a formidable everyday device that can be had for around the £200 mark, their Motorola One meets the same expectations as Nokia above as they’re running Android One also (though it’s been out a while) and they take pride in offering a clean, almost vanilla Android OS.

Sony, alongside the Xperia 1 and L3, launched the Xperia 10 and 10 Plus, gorgeous devices with less bloatware and a more polished, clean feeling than I’ve seen them produce ever before – again, £300/350 respectively for perfectly capable phones in a unique 21:9 form factor which has to be tried to be fully appreciated.

The list goes on, the number of smaller OEMs I walked past on my travels during MWC, including Wiko, Nuu Mobile, and many, many others was equally eye-opening. These brands, irrespective of how well they’re known today, are pushing the envelope on what can be sought for a comparably low amount of money.

It’s as big a win for enterprise also, lower cost for good quality devices with guaranteed software support means organisations can rely on a device being supported for 3 years, with money spare to fill a back room with extra stock in order to reduce downtime should devices fail for any reason.

Generally, I’ve seen both Android One and Android Go adoption increase over the last year, and this was reflected at MWC.

Form factors are interesting again

Samsung Galaxy Fold

Huawei Mate X

You know I’m going to mention folding phones, so I’ll do so immediately.

They were at MWC, both Samsung’s Galaxy fold with the visible crease down the middle, and Huawei’s Mate X with the plastic external wrap-around screen that’s going to get so scratched to bits within days of using it I’d be afraid to take it out of the house (or possibly even out of my home-office, given I’ve got a 4 year old running around who enjoys playing “hide the phone”).

Yes, folding phones are impressive. They’re exciting.

They’re also Gen1 and ludicrously expensive for a bendy tablet with good-enough software support (but with room for improvement!); while I enjoy being an early adopter normally, I’ll take a hard pass on foldable phones until Gen2, possibly 3.

I might eat my words before then, and if so then it’ll be because foldable devices improve faster than I’m anticipating. We’ll see! Until then, there were other form factors to enjoy at MWC.

HTC showed off their 5G Hub, a small wireless 5G mifi, or mobile WiFi device supporting up to 20 connections complete with 5″ screen and running Android Pie.

Photo by Tom Warren / The Verge

In a form factor that resembles something akin to a small Google Home Hub, it comes with the added benefit of running full Android and a tablet-esque battery capacity of 7,660mAh. Not enormous considering the impact tethering can have on a device, but certainly should be enough when moving between locations.

On the subject of batteries, Energiser launched a collossal 18,000mAh battery phone, while not 5G, it could certainly tether for a bit longer than the hub above if so desired.. or really any other task longer than anything else on the market.

There were also a number of rugged/semi-rugged (pro-sumer?) devices littering the halls, most notably CAT for me as I’d made time to have a chat due to an existing relationship through my device testing efforts, where I got to see them demonstrating the strength of their devices through an installation in the floor I’d already unknowingly trodden on:

The CAT lineup underfoot

Though even just up the hall there were other brands showing off their own with their own installations (it was pretty clear devices “submerged in water” actually weren’t in some cases though. Tsk tsk.)

The most exciting form factor for me, however, was the F(x)tec Pro¹ which I was invited to check out by the founders at a private event just outside MWC.

The F(x)tec Pro 1

Designed by the team responsible for some earlier Nokia sliders, the Pro 1 felt oddly familiar yet modern, and despite BlackBerry’s many attempts at a QWERTY Android phone, none of them pique my interest in the way the Pro 1 does, why?

Vanilla Android with zero bloat, only very carefully considered modifications to improve the vanilla landscape experience

Landscape slider! The BlackBerry Priv came close to something I’d consider if it wasn’t flawed in so many ways, but I won’t sacrifice screen real estate for a QWERTY device, which is exactly what the BlackBerry Key series asks. I’ve longed for a landscape slider since the HTC Desire Z, so I’m super excited about this.

It runs the SnapDragon 835 prevalent amongst 2017 flagships, but benefits from flagship-level spec in other aspects, and F(x)tec have promised software support for the device (a requirement for Android Enterprise Recommended, just saying).

When it launches in a few months, it’ll 100% become my daily driver, if for no other reason than to help support the company towards building a Pro 2!

Android & 5G

Netgear and their 5G mifi devices

Did you know? Android is the first mobile OS to support 5G.

With support from Samsung with their Galaxy S10 5G, the Huawei Mate X, the LG V50 5G and more (with more pre-announced) 5G and Android went almost hand-in-hand at MWC.

5G was also a topic at MWC 2018, though between then and now the industry has seemingly burst into life around it. From devices, to networks, IoT to networking, it was almost impossible to move from hall to hall without seeing something related to the technology.

And for good reason, it has far-reaching implications for almost every aspect of connectivity. AR/VR, and automotive (amongst others) will benefit immensely from the low latency, consumers and enterprise alike from the huge boost in speed and more. I’m excited to see what’s to come, though still cautiously resisting the hype as we’re still a way off yet.

Other aspects of networking I discussed were WiFi 6, which I’m particularly looking forward to (5G or not, my LAN isn’t going anywhere!) due to improvements in efficiency, capacity and speed, while potentially improving battery life (and with few advancements in battery tech, any improvement is welcome!)

Android Enterprise

Finally, of course, I attended primarily to talk Android Enterprise with as many folks as possible!

Between OEMs with an outstanding AE presence already such as HMD Global who were not only showing off their Android Enterprise Recommended badges, but were actively and openly talking Android Enterprise confidently and enthusiastically on their stand, to an increasing number of OEMs who definitely knew what Android Enterprise was, even if they couldn’t discuss the intricacies right there and then when stopping by.

There were of course OEMs who still had no idea what I was asking about, but that number has certainly decreased in 12 months, based on my entirely-unscientific analysis!

The difference this year in particular was the OEMs who reached out, either in advance or at the event, to discuss their plans for Android Enterprise support, question Android Enterprise Recommended or seek assistance with testing. I’m pleased to see enthusiasm grow as OEMs see increasing value in supporting AE well.

On the subject of support, Samsung announced official support for OEMConfig! I wrote about that in an earlier post so won’t go into too much detail, but after years of working with and relying on EMMs to implement their APIs with varying levels of success it’s fantastic to see Samsung take ownership of how their immense number of manageable features will be presented to customers, of all EMMs, with a consistency and real-time control they’ve not necessarily had before.

Going forward it’ll be much easier for everyone involved.

Until next year

It was yet another fantastic experience full of insights into things to come, and I look forward to seeing how the year progresses!

Thanks to all who took the time to chat, demo their products or answer my many, many questions!

Until next year!

UEM tools managing Android-powered cars

2019-03-12T16:57:55Z

Last week, Volvo’s performance EV brand Polestar launched the Polestar 2, one of potentially many vehicles in the pipeline to be powered by Android, following Volvo’s partnership with Google some two years ago.

This evolution of the Android Auto most of us are familiar with now extends to controlling “basic functions like heating and cooling, seat position, or opening and closing the windows,” according to The Verge. In the years since then that could well be more, though it’ll remain separate from critical safety systems, something better left to manufacturers generally anyway.

With the level of control over vehicle systems available to Android, and today’s capabilities for advanced device management, it begs the question:

How far away is centralized, remote vehicle management?

It’s not like this is a new idea, Windows has found its place in many a machine, often managed through the same standard tools as the laptops and desktops the organizations also roll out, so this certainly isn’t a particularly far-fetched idea. And while Android Auto is the focus here, this could apply to many other types of devices.

Think about the use case: Imagine walking into the office car park, picking a vehicle and authenticating with your (managed) mobile device for access and a customized experience; you could have your seating position, mirrors, climate control, radio stations (or other media), and more all set to your preference when you get in, and automatically reset when you’re finished for when the next person came along.

Vehicles could leverage advanced user management introduced with Android Pie to allow organizations to authorize and provision temporary or persistent users with set applications, vehicle restrictions, and more.

Imagine the possibilities! From the same UEM platform organizations manage their field tablets or PoS systems today, they could set restrictions on:

Top speed (software speed limiter)
Geofencing
Vehicle insights
Multi-user support, with apps and configs pushed OTA
Compliance alerts, remote disable
Remote log collection
Preventing disabling of traction control, regenerative braking, access to diagnostic ports
Limiting charge rate or maximum capacity
and undoubtedly so much more

Add in standard AE enticements like no personal Google accounts required (Android Auto does already offer this, but it isn’t managed) or permitted, a managed Play Store for only whitelisted Auto applications, and more; it’s a fascinating idea.

But hold on, I hear you say. No UEM today is going to implement vehicle-based restrictions, particularly manufacturer specific.

Well, to that I’d say you’re certainly making a valid point, at least partly.

Ultimately Android Enterprise solution sets will evolve with new features and functionality to reflect how Android is used, programs such as Android Enterprise Recommended for EMMs allow Google to mandate features to be implemented to remain compliant, so it could happen.

Where I doubt we’ll see any particular traction is in proprietary features by individual manufacturers, but that really doesn’t matter because we already have solution in place today:

OEMConfig.

Fresh in the minds of those following Samsung over the last few weeks, OEMConfig allows for zero-day support of features with zero implementation for UEM vendors. Utilizing Android Enterprise managed configurations, organizations could set all of the above mentioned restrictions and more as simply as configuring Gmail.

Some UEM vendors already have the industry vertical-specific policy templates available, so templates for vehicle policies wouldn’t be that far off. Or, they could go as far as building industry-specific consoles, like Microsoft has done with Intune for Education.

If vehicle manufacturers wanted to take this a step further, they could build home-grown management portals based on the Android Management API, maybe incorporate zero-touch support so vehicle systems automatically enroll into management based on the the company purchasing or leasing them.

The tech is already in place to support this right now, it’s just a case of fathoming how to leverage it. It’ll all need to begin with Android Auto supporting Android Enterprise; this could already be closer than we know, but if it is, Google are being awfully quiet about it. In the future, however, it should be inevitable.

Joining the Android Enterprise Experts community

2019-03-07T20:26:08Z

I’ve been involved with Android since the very beginning, and have watched it evolve from the competitor to Windows Mobile it was originally destined to be into the most popular and secure mobile OS on the planet.

7 years ago I had the opportunity to take an active interest in utilising Android within a corporate context; my first deployment was locking down Samsung devices for use in a field marketing environment and I can say, with confidence, it was not the buttery-smooth experience we have today. Back in the days of Jelly Bean, a couple of years before the introduction of Android for Work and the shift in Google’s mindset towards Android security, it was a different animal.

Today, 100’s of deployments, presentations, training sessions, over 20 documents, countless articles both here and for the likes of TechTarget covering Android Enterprise later, I feel fairly confident in saying I know a few things about Android, even with so much still to learn.

With the program now public, I am excited to be able to say I join a select number of people across the world who have undertaken and passed the Android Enterprise Expert validation, a requirement for MSPs who wish to gain Android Enterprise Recommended status to show they know how to sell, deploy and train on Android in the enterprise.

Open only to AER MSP professionals, I was lucky enough to be selected as one of the first independent (non-AER MSP) individuals in the world to take part in the validation, which is a huge honour!

The validation currently runs in two tracks, implementation (AIX) and support (ASE) with plans to merge into one in future. Having completed both tracks I’m validated to cover Android deployments end-to-end, from pre-sales and planning through to BAU support. My hope in future is to see a validated trainer programme, as this feels like the next logical step.

In becoming validated, I also join the Android Enterprise Experts Community, a private group for experts to collaborate, discuss topics and recommend solutions to everyday situations, and together improve Android Enterprise understanding and awareness across the world. Information is light on this at the moment as it hasn’t yet launched, but more details will be published in future.

It’s been an incredibly busy 12 months, and I look forward to continuing my work to promote Android Enterprise through this site, working with new and existing customers through my day job, and building the best Android Enterprise communities on the planet!

Correction: After Google confirmed I was the only non-MSP individual to undertake validation and approved my original statement on March 7, I was contacted on March 13 to say there had been a mistake and I was instead one of a few, which is no less incredible! I work extremely hard to always ensure I share only accurate information about every aspect of the Android Enterprise ecosystem, and will continue to do so. Apologies for any confusion!

Note (because I know I’ll get asked!)

If your MSP is looking to nominate professionals to become validated Android Enterprise Experts, you’re welcome to leave your details on this form I’ve created and I’ll aim to help where and when possible. Make sure everyone nominated has completed the Android Enterprise Professional course before you do though – androidenterprise.training (you’ll need to log in to see courses).

February was an interesting month for OEMConfig

2019-03-03T10:36:17Z

One of the more important announcements at MWC for the Android Enterprise ecosystem was the introduction of Samsung’s official support for OEMConfig, something they’d talked about with me in the past, but offered little in the way of firm dates (it certainly didn’t seem like something I’d see in 2019!).

Before getting stuck into the finer details of Samsung’s implementation, this wasn’t the only OEMConfig news in February, on that note..

Sony discontinues work on OEMConfig

One of the earliest adopters, Sony, has quietly pulled the plug on Configuration Extension, their own OEMConfig implementation in what looks like an ongoing shuffle of priorities at the Japanese behemoth.

This follows the shuttering of Xperia Configurator Cloud already this year, a long-standing service for light device management offered directly by Sony for a number of years.

Sony’s evident step back from enterprise is a disappointment, and as an OEM investing time and budget into bespoke features and UI in a market responding increasingly well to those pushing stock experiences with little to no bloat (such as Android One), considering how untapped the enterprise space is, I’m not sure B2B services are what I’d sacrifice.

That said, the Android Enterprise Recommended programme is continuing to feature Sony devices (going forward) based on what I saw at MWC, and enterprise is therefore still something of a focus even without value-adds such as OEMConfig.

There’s also no doubt Sony still creates attractive, well-built devices across a range of budgets as recently seen at MWC with the launch of the Xperia 1, Xperia 10 and Xperia 10 Plus featuring their newly simplified naming scheme, replacing the previous XZ and XA naming conventions.

We’ll see how this pans out, and I hope they’ll pick up where they left off in future.

Back to Samsung

It was only a few days before the announcement that I’d become aware of Samsung’s Knox Service Plugin (Samsung’s OEMConfig implementation), and while I had the intention to post something ahead release, MWC got in the way!

Samsung sums up the need for and benefits of OEMConfig similarly to how I’ve outlined it previously:

Samsung’s Knox Platform for Enterprise (KPE) APIs that reside on device are currently used by Enterprise Mobility Management (EMM)/Unified Endpoint Management(UEM) partners and others to integrate support for KPE’s unique security and management features. However, support for specific features is inconsistent across Samsung’s partner ecosystem, and few partners are able to provide zero-day support for all new features upon release due to lengthy development cycles.

Samsung’s announcement, emphasis mine

To echo my feelings on this as posted to LinkedIn a few days ago:

OEMConfig is one of those things when you stop to wonder, you ask what took so long?. This whole approach of OEMs working with individual EMMs to integrate and/or validate API support is crazy inefficient, fragmented and generally not very good.

With Samsung developing OEMConfig, they put themselves in control of feature availability and zero-day support in a way I’d imagine excels even what they’ve had with SDS. Expect faster, consistent and reliable management independent of EMM in future. It’s going to rock.

And I’ll reiterate once more, Samsung going all-in on OEMConfig is a huge win for both the programme – due to the credibility they will bring with them, legitimising this new type of simplified cross-EMM feature availability which will surely encourage other OEMs to follow – and Samsung themselves as this will undoubtedly mean faster, simpler updates, zero-day support for new features without the to-and-fro with multiple EMMs for every development cycle in future and more.

With everyone involved saving so much time and effort, who knows what the additional bandwidth could lead to for both OEMs and EMMs in future.

I’ll be getting hands-on with Samsung’s implementation over the coming week or so, and will publish a hands-on as I did earlier with Sony, for now though here’s a quick glance at what Samsung are offering through their implementation. It’s already pretty impressive:

Just high-level headings here, most of the configs are hidden

I only wonder how Sony feel about their decision to exit just as Samsung jumps aboard.

Will you make use of Samsung’s OEMConfig implementation? Is it what you expected? Let me know what you think in the comments, on Twitter or on LinkedIn.

Google launch Android Enterprise Recommended for Managed Service Providers

2019-02-25T21:36:07Z

Almost a year after AER for devices was launched and mere weeks after AER for EMMs, AER for Managed Service Providers (MSPs), the 3rd expansion of Google’s Android Enterprise Recommended promgramme is officially live.

What is it?

Android Enterprise Recommended for MSPs aims to provide a reliable, consistent means for organisations to select a service provider that holds the required knowledge and expertise to undertake all aspects of an Android Enterprise project. Google says it perfectly themselves:

As organizations increasingly turn to Android as their enterprise mobility platform, we want to make sure they can easily identify partners with experts who are best equipped to support them.

Google blog

As AER for EMMs and AER for devices before it, MSPs may opt in for validation against a set of requirements and recommendations which demonstrate their capability in working with Android Enterprise. These requirements include:

80% of Sales validated up to Professional via the Academy.
At least 4 certified Android Enterprise Experts, 2 in ASE (Support) and 2 in AIX (Implementation) increasing in number for organisations present in multiple regions.
Demonstrable experience in deploying Android Enterprise.

The requirements are described in-depth in the glossary here, and an overview is available here.

Once validated, an MSP will then benefit from the following:

Access to a Partner Escalation Desk (PED)
A closer relationship with Google, including an assigned account manager
Ongoing training and resources provided by Google
The associated marketing and financial benefits of being a Google-recommended partner.

As I read them, the bar for entry doesn’t appear to be low at all, in fact I think there’s potentially MSPs small enough not to have the headcount to meet the requirements of 4 experts with 5 years of experience; whether there may ultimately be exceptions of flexibility available on these requirements (possibly with an asterisk?) is yet to be seen.

Hang on a moment..

AIX? ASE? Android Enterprise Expert? I’ve had a number of people asking about these already, so here’s a little more information:

To become an Android Enterprise Expert, you’ll need to be certified against AIX (implementation), ASE (support) or both. Once AER for MSPs opens up for new submissions (it has literally only just launched after all, so isn’t quite there yet) part of the process will include MSPs putting forward employees for validation.

Certification is an annual process, and like most certifications can be lost if knowledge is not kept current and up to date.

The importance of Android Enterprise Experts within an AER validated MSP really cannot be understated; without them, or enough of them (depending on the size of the organisation), an MSP could lose AER status.

This could well increase the value of workers with Android Enterprise Expert status in future, and would be an important certification to keep current.

Launch partners

Google launched the programme with a number of well-known MSPs in the industry across the world, including Mobile Mentor, Accenture, Cognizant, DXC Technology, Econocom, Tech Data and Vox Mobile.

Unlike the interesting situation with EMMs, there are no asterisks against any of the MSPs in the AER directory, and each listing equally shows the regions in which they operate:

Vox Mobile operates in the Americas (screenshot cropped)

Final words

A year after the first launch of Android Enterprise Recommended for devices it’s great to see the programme come full-circle and I look forward to seeing how the programme as a whole matures over time.

It’ll also be interesting to see how AER for MSPs affects customer choice as it has already done with devices and likely will do with EMMs; for organisations newly entering the Android ecosystem (or mobility in general) it’d make sense to go directly to MSPs on the AER list. Will those already with an MSP look at moving? How important will organisations consider this programme in future?

Time will tell, but I think it’ll make waves.

What do you think of the MSP programme? Are you an MSP? What do you think of the requirements? Is the bar for entry to high or low? Let me know in the comments, on LinkedIn or on Twitter

Migrating from Windows 10 Mobile? Here's why you should consider Android

2019-02-04T00:28:11Z

The writing has been on the wall for a very, very long time. Without an ecosystem and an ever-dwindling user base, Windows 10 Mobile couldn’t have lasted forever. Now officially dead, Microsoft recommends switching either to iOS or Android.

Both platforms have strengths and weaknesses, naturally. But particularly in the context of moving from Windows Mobile, I’d like to present a few reasons why you might consider Android over iOS for your enterprise needs.

Android is secure

The perception of Android security being subpar has long been proven incorrect. From Google’s pivot to enterprise in Android 5.0 Lollipop to today, security has been a key focus of every release.

Not convinced?

In 2016 & 2017, Gartner ranked Android higher than iOS in a number of areas, including kernel security, exploit protection, network security, workspace isolation and more; the results of which can be found in this report (2017) should you have a Gartner subscription, if not here’s an overview:

Source: Gartner, December 2017. Thanks to Samsung for making this available on the public internet!

Let’s dive a little deeper into Android security:

Corporate/personal data separation

The two deployment scenarios that make use of the work profile are the aptly named work profile (BYOD) and fully managed devices with work profiles (COPE). In both scenarios, work data is securely isolated and separately encrypted on disk.

iOS may have app sandboxing, but so does Android with each application running as it’s own user ID (UID), with the added benefit of profile isolation providing a separate user space from the parent profile as well! Applications within each profile by default cannot communicate with one another, offering far greater work/personal application isolation than app sandboxing alone.

Architecture component isolation

Android is built up of six major components:

Applications
Android framework
Native libraries
Android runtime
Hardware Abstraction Layer (HAL)
Kernel

Each of these components are isolated, running in their own domains, meaning should any vulnerability be exploited in one component, it will not grant access to the others by default.

Combined with such capabilities as verified boot, downgrade protection and more, devices are constantly monitored for unauthorised changes and will prevent a boot accordingly, ensuring the device remains secure.

Monthly security patches

Android benefits from a monthly security patch cycle to maintain high levels of security against exploits and vulnerabilities discovered in the wild.

In 2017 over a billion devices were receiving security patches, this will only have increased further in 2018 following the introduction of Android Enterprise Recommended; devices in the Android Enterprise Recommended programme are mandated to push these updates within 90 days of Google’s release, with the Android One programme complimenting this further by mandating a security update every 30 days.

Play Protect

Google’s Play Protect suite of solutions includes the world’s largest anti-virus service, analysing 500,000 applications, and scanning over 50 billion on Google Play, on-device and crawling the web every day.

Play Protect is always-on, and will take action on any known potentially harmful application (PHA) found on a device, as well as any known bad websites via the Safe Browsing service to proactively warn users of danger.

Play Protect of course isn’t infallible, and I’d support organisations who augment Play Protect’s capabilities with an MTD solution, however it’s an ever-improving service utilising machine learning to evolve over time, and does a pretty good job for most use cases. Combined with options to prevent installation of applications from unknown sources, USB debugging and more, a corporate device can safely and successfully avoid PHAs.

Open source

Android’s open source nature allows anyone, anywhere to access the code that makes up the Android operating system.

Vulnerabilities and bugs therefore aren’t dependent on Google for discovery, but can be found by anyone who takes the time to dive into the repositories; the source remains under constant scrutiny by the wider community which leads to a stronger OS.

Android is evolving

Some years ago recommending an Android device in the enterprise may have raised an eyebrow. Prior to Android 5.0 security was not perceived to be a priority and management (outside of Samsung at least) was hardly reliable.

A lot has changed since then.

GMS certified devices since Android 6.0 are mandated to support the Android Enterprise solution sets, guaranteeing a reliable, consistent user experience across OEMs.

The days of bringing devices on board and hoping the exchange profile applies successfully are very much over.

Even today things are improving still, with the introduction of OEMConfig OEMs can extend on the base set of Android Enterprise APIs in order to deliver bespoke management capabilities in a way that’s faster and more reliable than ever before. OEMConfig offers zero-day support for new features and capabilities without EMM vendors having to lift a finger.

Did you know?

OEMs such as Samsung and Zebra have >1000 APIs available in addition to fundamental Android Enterprise capabilities for incredibly granular management. Through OEMConfig, these APIs can be (and are for Zebra) exposed for simple, zero-day support of every new feature published. More and more OEMs will build out their unique management capabilities as OEMConfig evolves.

Check out the linked article to understand how OEMConfig will transform Android management.

Android is flexible

Organisations demand flexibility; in process, use-case, form factor and budget. Android is the most versatile mobile OS on the planet.

Management scenarios

Considering BYOD? Dedicated? Something in between? With four individual solution sets to choose from, Android offers a management scenario to suit all applications.

From: What is Android Enterprise and why is it used?

The in-depth document What is Android Enterprise and why is it used? outlines these deployment scenarios and their applications, while this infographic offers a deep-dive on each deployment scenario specifically.

Whether your organisation wants to permit personal devices whilst managing corporate data on a secure, isolated, separately encrypted profile, or desires full control over the device, Android Enterprise offers all of this in a way that is quick and simple to manage.

Provisioning methods

Perhaps devices are primarily located in a warehouse or other close-proximity situation where it makes sense to utilise a master device to provision devices with a bump, or perhaps devices are shipped directly to end users and should be set to provision over the air. Android can accommodate these scenarios and more.

There are a number of provisioning methods available for Android devices, including:

NFC bump
QR code scan
DPC identifier
Zero-touch enrolment
Knox Mobile Enrolment (KME)

As above, an NFC bump makes sense where many devices are located in close proximity, while QR code and DPC identifier offer a means for remote provisioning in ways that are easy to understand.

For newer devices (8.0+) to be ready to provision straight from the box, zero-touch enrolment provides the ability to pre-configure devices before they’re even taken out of the box.

For Samsung devices running Knox 2.8 or higher, the very same is supported through Knox Mobile Enrolment (without the 8.0 requirement).

More information of provisioning methods can be found in What is Android Enterprise and why is it used? and this handy infographic.

Form factor

Are phones and tablets too.. consumer? Does your organisation rely on fixed endpoints, smart phone systems, bespoke logistics or warehouse scanners, specialised interactive displays, or something else?

Not only has Android shipped on phones and tablets in screen sizes ranging from the minute to the enormous, Android can be equally found on rugged devices, smart displays, point-of-sale endpoints, projectors and many other specialised hardware types.

If a form factor doesn’t exist that suits an organisations needs, one can be developed with any number of specialist hardware manufacturers.

No matter the application, there is – or can be – a form factor to suit. Android isn’t limited to only phones and tablets in a couple of sizes.

Budget

Like Android’s flexibility in form factor, the same is true for budget.

While Apple continues to inflate the prices of their product lines to numbers which far exceed the budgets of many organisations (to their detriment), an Android Enterprise Recommended, GMS certified and enterprise-suitable device can be picked up for as little as £70, cheaper still with carrier-arranged hardware funds.

Organisations can of course opt for flagship handsets and pay the premiums associated with these feature-rich devices, however there’s no obligation to do so.

Those purchased on the mid-range scale benefit equally from security patches, OS upgrades, excellent battery life and more. These days budget doesn’t mean poor quality.

Android is simple to manage

Taking Gartner’s research into consideration, highlighting Android’s clear lead in security controls over iOS, here are some examples of how Android excels in simplicity of management:

Managed Google Play

A corporate version of Google Play permitting only applications approved by administrators; the primary Play Store on fully managed devices, or the badged Play Store for work profile-enabled devices.

Managed Google Play offers complete control over the applications permitted on a managed device without affecting the native look and feel of the device.

In conjunction with managed Google or Google Play accounts, applications can be distributed silently and simply, updated automatically, restricted from uninstallation and more.

Add in the ability to create, manage and deploy in-house applications with only a few clicks, and a similar process for deploying web applications for direct access to corporate sites and resources, and managed Google Play becomes a one-stop solution for all forms of quick, simple application management.

What’s more, organisations can take application distribution a step further with managed configurations; inputting within the EMM the relevant details, these applications can be preconfigured on installation, meaning far less work for end-users setting up their devices.

System and application updates

System update control is critical in enterprise, administrators need the control to be able to force updates on devices, postpone updates, and schedule them for outside of working hours.

Application update control may be just as important, whether to update immediately, over WiFi only, not at all or during a scheduled time slot.

Android does all of this, providing complete, granular control over when and how updates occur for managed devices to ensure devices remain secure, or to offer a little extra time for testing before initiating a corporate roll-out. Samsung’s e-FOTA service takes this a step further, offering the ability to target a particular OS version until such time later versions have been validated by the business.

Android supports work/life balance

It’s not all about how a device is managed during business hours, employees may be glued to their devices 7 days a week! Providing tools to promote a stronger work/life balance by encouraging downtime and trust amongst employees is crucial to ensure a happy, healthy and productive workforce. Here’s how Android can help:

Turning off the work profile

Downtime is an important aspect of modern life. Being always-on, always connected can be detrimental to employee health and well-being, so providing tools to quickly and easy fully disconnect from work is an incredibly important feature, one which puts end-users in control as much as administrators.

The work profile can be turned off with a simple toggle of the quicksettings tile, or within the app drawer (OEM launcher support required) at any time. All corporate applications will temporarily disable and no notifications, sync or any other related activities will be performed until the profile is turned back on.

For countries with laws around the right to disconnect, EMM policies can automate this functionality as required, where supported.

Promoting privacy

Another key benefit of the work profile over legacy, full-device management for BYOD deployments is privacy.

When an Android device is enrolled into a BYOD programme, the organisation creates a dedicated work profile on the device in which corporate applications and data reside; there is little device-level management the organisation can enforce, but more importantly, there is almost nothing an organisation can see in the parent profile (device) from a personal data point of view.

The apps users install, the data users generate, it is all completely invisible to the EMM solution managing the work profile, as the EMM agent (or DPC) sits within the isolated work profile it creates and not within the parent profile – or device-wide as it would be on other platforms.

For end-users, hoping the organisation is opting not to sync personal data up to the EMM console is not good enough. Choose a platform that doesn’t permit this to begin with: Android.

Check out this dedicated article about BYOD and privacy for more on this topic.

Conclusion

With the above in mind, hopefully the case for Android in the enterprise has been adequately made, but this is only scratching the surface. For more details on Android Enterprise, the modern management solution for Android devices, check out the vast selection of documents, guides and articles located here: Android.

Are you a Windows Mobile/Phone customer/user still? Are you planning a move from the platform in light of its abandonment? Let me know in the comments, on LinkedIn or @jasonbayton on Twitter.

AER expands: Android Enterprise Recommended for EMMs

2019-01-18T20:22:59Z

The Android Enterprise Recommended programme, originally launched with Android handsets back in 2018 before later expanding to rugged devices and tablets, has recently once more expanded beyond devices and into EMM solutions as previously promised:

Throughout 2018, we will also be applying the Android Enterprise Recommended framework to additional partner types, including OEMs of “dedicated” and rugged devices, mobile carriers, enterprise mobility management (EMM) providers and systems integrators.

– The original AER announcement

Although a little later than the above timeline suggests, due undoubtedly to just how much effort was required to bring EMMs up to the level required for validation, Google have worked incredibly hard to bring AER to other areas of the Android Ecosystem since 2018, and I’m very pleased it’s now come to fruition!

What is it?

As we transition away from device admin management and toward Android Enterprise this year, looking across the EMM landscape there are still examples of EMMs who don’t fully support the solution sets, don’t actively advocate Android Enterprise first with their customer base or simply don’t know very much about modern Android management in general.

We’ve definitely come a long way compared to how it was some years ago, with EMMs picking and choosing which OEM APIs to support based on customer demand or, often also likely, taking a gamble on what might be useful to customers, but there has definitely been a fair amount of fragmentation – even between top-tier vendors – in the industry which Google has aimed to address with AER.

Just as AER for OEMs set out to create a benchmark against which devices should meet or exceed in order to guarantee a consistent, reliable experience for management, AER for EMMs aims to do something similar.

To summarise the requirements for EMMs:

Support advanced management of two of the three widely utilised deployment scenarios (COPE isn’t included, yet)
Clearly demonstrate knowledge and capability of supporting the solution
Proven ability to deliver advanced security and management features
Offer a consistent deployment experience, with admin consoles that simplify set-up of Android Enterprise

The requirements are described in-depth in the glossary here, and an overview is available here.

In a nutshell, Google are going to validate EMMs who demonstrably put Android Enterprise front-and-centre over legacy management, have a healthy install base and can lean on excellent product knowledge, useful collateral and confidently sell the solution to the market. The obvious difference when compared to AER for devices is that it isn’t purely about feature support as such, even though that certainly forms part of the wider validation, but the whole experience of working with an EMM.

I’d seen first-hand some of the background work going into AER prep in the second half of last year, where EMMs were – as if by random – adding features available as far back as Lollipop, knowing AER was on the horizon, it wasn’t too difficult to connect the dots!

How are AER EMMs identified?

EMMs validated can be found here. Each validated AER EMM can be identified by the AER badge, those yet to pass validation are equally listed, but go without the little green shield.

There is a comparison function which is quick and easy to make use of, though I hope to see improved to display more information about the individual APIs/features the EMMs support, as currently it’s rather vague without clicking into each vendor:

In any case clicking any of the EMMs will offer an in-depth breakdown of features supported. While the breakdown is quite informative, I would very much like to see it more aligned to the solution sets, referencing each in the numbered list, and potentially linking off to more details. It may look less visually appealing, though would be far more useful. As an example for SOTI’s work profile implementation:

Could instead be:

DEVICE SECURITY

Set lock screen restrictions (2.1)
Set lock screen restrictions for work profiles (2.2)
Set advanced passcode restrictions (2.3)
Configure Smart Lock settings (2.4)
Wipe and lock work data (2.5)
Compliance enforcement (2.6)
Disable app installs from locations other than Google Play (2.7[.1])
Disable debugging (2.7[.2])
Check device integrity (2.9)
Enforce Verify Apps by default (2.10)

(2.8 doesn’t apply to work profile, in case you wondered)

All I’ve done there is reorganise the items as they’re displayed on the relevant solution set, and linked to each item for further information. It’s these sorts of small touches that encourage readers to seek out more information, and in turn form their own conclusions towards how an EMM aligns with the solution sets Android Enterprise offers (and perhaps if Google decides not to, I’ll do something similar based on data available on the vendor pages!)

Launch partners

Google are launching with a number of initial partners, namely Blackberry, Google Cloud, I3 Systems, IBM, Microsoft, MobileIron, Softbank, SOTI, and VMware (in alphabetical order).

There are a few expected names in that list, MobileIron and VMware for sure given there’s little doubt they’re leading the way for Android Enterprise in the market today – not only due to COPE support, but things like VMware’s video series, MobileIron’s blogs and whitepapers and the general AE-first approach the vendors are taking. No one would disagree with the likes of IBM and SOTI (who’s dedication to Android management over the years has been incredible) either!

There are a couple of AER partners on there that you may not expect though; if seeing Microsoft surprises you, you’re not alone! I ran a poll on Twitter to garner the views of the wider community on technical capability alone and the results speak for themselves:

Should Microsoft qualify as an #AndroidEnterpriseRecommended #EMM today?

– Yes, they support enough of the solution sets for customers
– No, they're missing too much functionality to be considered recommended

Please RT #enterprisemobility #androidsecurity

— Jason Bayton (@JasonBayton) January 16, 2019

Unlike AER for devices however, technical capability on its own, as mentioned above, isn’t what Google are relying on to validate EMMs. On that, Microsoft are joined by Google Cloud Identity in being the only two solutions with an asterisk (*) beside them, and this is for a very simple reason:

They’re not quite up to scratch just yet.

These partners have validated solutions or will be launching their offerings throughout 2019

– Will Ro, AER EMM announcement

Google are keen to highlight that although these two vendors are potentially passing with flying colours other aspects of validation, their feature set support is not yet at the level Google deem acceptable for AER, hence attaining only standard and not advanced across the board:

The asterisk is intended to suggest they’ve committed (ie. roadmap) to meeting Google’s requirements and recommendations in the near future, and will continue to develop their product through 2019.

Speaking for Microsoft (as I can’t for Google Cloud), they are the first big vendor to adopt the Android Management API (AMAPI) as I’ve pointed out before, they’re also incredibly active in the ecosystem and despite a late start, are working around the clock with Google to bring missing features to fruition. In fact, COBO support just launched in preview.

It would appear as such Google are giving both of these vendors the benefit of the doubt and have brought them into the programme with the very clear caveat there’s work still to be done.

Until fully validated and the asterisk removed, These vendors should not actively use the badge, so any concern of this causing confusion from an EMM marketing standpoint is suitably subdued.

That said, the wider industry will take from seeing these vendors in the list what they want, and I’ve more than enough examples already from customers to partners, carriers and other vendors to suggest this could have potentially been far more clearly explained. Hopefully this article will go some way to helping with that!

Final words

The programme is definitely an eye-opener into the capabilities of EMMs broadly; particularly for me having neither the access nor the capacity to be constantly jumping in and out of various platforms for testing, being able to pop on over to the partners site and pull up what vendors do and don’t support without needing to find a tenant is very useful. Hopefully it’s frequently updated to maintain this information.

As Google continue to expand the programme, it really can’t be overstated how important Android Enterprise Recommended is for the ecosystem.

From the profound difference AER for devices has made over the last year for device selection – whether how OEMs support and market their devices, customers select them or MSPs recommend them – AER has improved this process across the board by adding clarity, setting expectations and instilling confidence in what was once a process laced with uncertainty.

I believe AER for EMMs will do the very same, offering more consistency across the management ecosystem, providing more control to Google in ensuring the management experience continues to improve (they set the bar for AER, after all), and ultimately resulting in the best management experience for organisations and providers alike.

With that said, I’m looking forward to seeing far more EMM players in the market begin to show up, and perhaps even AER subcategories might be considered in the future – some EMMs will focus entirely on dedicated devices for example, such as Wizy or Shoonya, others MAM or BYOD, like Appaloosa; these vendors may never opt to apply for AER because they don’t fulfil the broader requirements, irrespective of how well they support the devices of their chosen solution set or meet other requirements for validation.

So, with AER both for devices and EMMs now publicly available, it’s only a matter of time before MSP validation turns up. I’m very much looking forward to that one!

How do you feel about AER for EMMs? Is it what you were expecting? If you’re a customer, does AER have any impact on EMM choice? For vendors, how do you feel about the validation? Let me know in the comments, @jasonbayton on Twitter or /in/jasonbayton on LinkedIn!

What I'd like to see from Android Enterprise in 2019

2019-01-07T09:00:44Z

I’ve been advocating/evangelising and talking about Android Enterprise for a couple of years now, and have mainly focused on what’s present and available.

For a change, I thought I’d cover off a few things I’d like to see in the AE ecosystem in 2019 that I haven’t as yet.

To be clear, this isn’t simply a list of features for Google to implement in the solution set(s), because there are plenty of APIs available no one is making use of as yet. Rather I’m taking a bigger-picture view of the ecosystem as a whole as I see it right now (I’m going to start with a few feature requests though).

Let’s get started.

AE activation stats

Android Enterprise has been a thing since Android 5.0 🍭, yet beyond a few finger in the air style graphs of Android Enterprise growth over the years, Google remain tight-lipped on actual figures around activations.

At the Summit I quipped:

Over the last 12 months, Android Enterprise activations have grown 10x […]

10x as many devices sounds significant, and while I’m sure it is, we don’t know how much that really is as Google won’t release figures publicly.

Perhaps the number of activations isn’t huge. Perhaps the figures show a disproportionate number of one deployment scenario over another and that’s a reason to wait, or maybe something entirely different.

I think there’s almost an expectation the number of activations won’t blow anyone’s socks off, many orgs I talk to still today don’t know what Android Enterprise is. If the number is low, own it. It gives folks like me incentive to work harder raising awareness. If the numbers are great, it’s an opportunity for a bit of a boast. Win-win to me.

Therefore I’d like it if Google were transparent with stats and offered:

Total activations
Activations per year
Deployment scenarios
Market sectors (health, finance, logistics..)
Android versions under management

Maybe more, where available.

That sort of information would be incredibly handy to have to hand when I’m writing docs or other collateral, in meetings with customers (“Android Enterprise has proliferated in your market sector Mr. Customer” is an easier sell than “lots of my customers use it” I think).

If nothing else, it gives me something to talk about and work with on what is otherwise a bit of an unknown quantity. Please and thanks, Goog!

Native Per-app VPN

Android supports only one active device-wide VPN connection at a time. Per-app VPN is possible, but requires the VPN be running (optionally set to always on) and capable of dynamically routing or allowing traffic to bypass. If the VPN app on the device doesn’t support per-app (because it isn’t supported natively), it can’t be used.

I want to see this fixed on a system level, and 10 years into Android I really wonder why it hasn’t been tackled yet.

On a related note, I often come across situations where an organisation makes use of a VPN connection for connecting back into the corp network in order to access corporate resources, while at the same time utilising something like an MTD solution which will also rely on VPN to manage traffic; the resulting two VPN networks on the device will clash and continuously bump each other off if both are in use.

While I wouldn’t expect multiple concurrent VPN connection support, perhaps some form of precedence would be useful to ensure the prioritised connection is maintained.

Toggle system apps after provisioning

A very nice feature G Suite supports today is the ability to dynamically toggle system applications on or off (enabled or disabled), once saved the system applications will either appear or vanish in real-time.

For all other EMMs on the market, that’s a flag set during the provisioning stage and if done incorrectly, requires a reset and reprovision to correct it.

It’s such a simple feature, but I think it would be very well received generally if this was possible to implement on a wider scale.

Multiple work profile support

I’ve spoken to Google about this before, and I understand it’s technically rather difficult to implement, but even so I’m still listing it.

Picture this – you’re a consultant, a doctor, a contractor or any other profession where you may move between multiple organisations performing your various duties. You use your own device because it makes sense to do so. How many corporate devices would you be carrying around on various days otherwise?

Today, the first organisation with an EMM would likely have you enrol as a BYOD user to get your corporate apps and data securely, separately encrypted and isolated on disk in a work profile.

What about the other organisations? You may not be permitted to add multiple accounts within a work profile (nor should you, as that’d be mixing corporate data from multiple organisations!) so you’re a little stuck.

If you’ve ever tried to enrol your BYO device into multiple EMM platforms, after the first, the second will generate a prompt to say there’s already a work profile present and would you like to remove it.

Imagine if you didn’t have to.

Granted I see how complex this could get, even as an end user how would you differentiate between profiles just looking at multiple badged copies of Gmail. Maybe badge colours?

(Can you imagine!)

And what of security? Would the organisation be able to enforce the requirement for a separate passcode to any of the others on the device? There are many aspects to take into consideration that I’ve likely not thought of yet, but I can fully understand why this is complex.

In any case, the number of times I’ve had this type of conversation with industry folks tells me there’s clear demand for the capability (and I’d certainly welcome it also, given I have my corporate EMM, lab/testing EMMs, customer EMMs when replicating issues and more), so I’d love to see something come to fruition here one day, though maybe not 2019.

Wallpaper management

A common and recurring request I get from customers is how do I set a custom wallpaper for our devices?

Particular for organisations who’ve migrated from DA to AE, this functionality likely was there previously, and suddenly is not.

I’d very much like to see this introduced into Android Enterprise this year, whether via a Google Play Services update as the recent blocking of unknown sources was, or even in Android Q.

Data management

Another less frequent, but equally interesting feature request I’ve had in the past was more control over data management on devices.

Android devices can already report on estimated data usage and organisations with an EMM that supports it could potentially create policies that do something based on the data reported back, but it’s a little limited.

Being able to set a limit on-device and restrict network capabilities if that limit is surpassed, with the option of whitelisting applications which may continue to work for business activities or otherwise, would be pretty powerful and is one of the enticing features of products like Wandera that use a gateway (which isn’t supported on AE devices currently) to achieve the same sort of control.

For example, I could set a 3GB cap and only permit Gmail, Slack or other work applications to continue using data, while all others would only connect once connected to WIFI, or when the cycle resets.

Taking that a step further and being able to pull reports of app usage within the EMM console would be pretty neat also.

Work profile SIM management

A number of people use dual-SIM phones in the enterprise, that way they can use their own devices, but benefit from a separate business line so as not to need to use their personal number.

While corporate apps and data reside securely in a work profile for both BYOD and COPE deployment scenarios, on the phone side of this, any calls or SMS messages received are shared between the work and personal profiles on the devices.

I think it would be excellent to be able to allocate a SIM to the work profile, meaning any calls of SMS messages would go only to the work phone/messages apps, and therefore add in that final level of isolation between work and personal.

Furthermore, when the work profile is toggled off, the device should automatically forward work calls to voicemail.

This seems like a really obvious feature missing from the work profile experience today, and I believe it’d be incredibly valuable for anyone leveraging dual-SIM capabilities!

Greater enforcement on OEMs not supporting AE

Last year I came across a few OEMs who either aren’t doing a great job of supporting Android Enterprise on their handsets, or downright don’t care at all. Xaiomi, OnePlus, to name a couple I wrote about, but there are naturally more that I haven’t gotten a hands-on with as yet.

Android Enterprise support has been mandatory for GMS certified devices since 6.0, and forms part of the CDD. The fact that there are devices on the market today which can’t even provision as a fully managed (work-managed) device on 8.0+ is shocking.

While I’m sure they’re already doing a tireless, thankless job of telling OEMs to sort themselves out, clearly when a huge name like Xiaomi openly demonstrates they’re not that bothered about enterprise, while expanding into more and more regions around the globe, Google need to bring the hammer down and put them in line. If not, eventually people are going to end up using them in an enterprise context and find they’re out of luck.

Every OEM that doesn’t properly support Android Enterprise threatens Android in the enterprise as a whole. The industry needs reliable, consistent management across OEMs, otherwise more orgs will hit issues and start doubting the product.

Zero-touch customer device uploads

Apple have allowed for the grandfathering of customer-owned devices into DEP for a long time now, as has Samsung with KME, and this has been a long-standing request I’ve had with Google.

One of many threads with Google on this functionality!

Zero-touch is the only offering today that utilises a restrictive reseller-only model. I understand why this is, as in the wrong hands it could naturally cause problems, however if Samsung and Apple can do it, the big G themselves should be able to figure something out.

I’ll continue to mention it, hopefully this year we’ll get to a point where zero-touch enrolment could become as easy administratively as it is technically!

Ubiquitous Fully managed devices with work profiles support

With 8.0+ adoption increasing to 21.5% as of October 2018, any EMM/UEM vendors that don’t support fully managed devices with work profiles (COPE) today are stifling customers.

While three major platforms (MobileIron Core, Cloud and VMware WS1 UEM) support it as of January 2019, that leaves a pretty large gap for customers utilising the likes of SOTI, Intune, IBM, or really anything else.

One feature I definitely want to see this year is migration support between fully managed and COPE. I can’t begin to imagine the number of organisations who opted for fully managed (work-managed) in the absence of COPE only to find out they need to wipe and re-provision devices for fully managed with work profile support, especially given Google support this capability and have done since its introduction.

Vendors I’ve spoken to have suggested – in contrast to Google – that it’s not super simple to implement, with teams of developers I can’t see it being that difficult if it was prioritised. It would be so good to see this implemented.

Support for native kiosk in Pie

A whole slew of features were introduced in Pie for dedicated devices. A newly improved native kiosk experience, ephemeral users and more.

Right now I’m not aware of a single EMM that’s implemented these features to be leveraged by organisations (beyond a couple of APIs here and there, at least). With proprietary options like Microsoft launcher, WS1 launcher and MobileIron Kiosk there’s clearly no pressing need to do so (from the vendor perspective), but this year I do expect to see support creeping in, particularly as Pie adoption greatly exceeds Oreo in the same time period thanks to Project Treble.

Continue the march towards AE first

I finished 2018 dabbling with a few different EMM platforms I don’t often get hands-on with, and was surprised to see on one platform not only was Android Enterprise not actively promoted over legacy device admin, but it required manual, per-user flags set to enable AE enrolment!

Device admin is going away this year. EMM vendors should absolutely be encouraging customers to move to Android Enterprise as soon as possible, even if only to prevent a hoard of support tickets floating in once Android Q starts showing up in EMM device lists!

As an organisation, if your EMM vendor or MSP partner isn’t actively and openly discussing how best to migrate to Android Enterprise, should they be continuing to support your device fleet?

That’s up to you to decide.

But I’m hoping to see announcements left and right from vendors across the industry pushing Android Enterprise this year. It needs to be done!

Android Management API adoption

Currently the only big player I’ve seen doing anything seriously with the Android Management API (AMAPI) is Microsoft. This year I’d like to see that grow.

Whether leveraging AMAPI for zero-day support of new features, or making use of it for effortless DPC migrations enabling the movement of managed devices from one EMM tenant to another (be it the same vendor or different), AMAPI seems to me like the future of Android management, and I’d like to see it leveraged this year far more.

Zero-touch availability

Zero-touch enrolment resellers were popping up all over the place in 2018, and it was incredible to see. Even I got in on the action and got CWSI validated as a zero-touch enrolment reseller towards the end of the year.

That said, there are still nowhere near enough zero-touch enrolment resellers in the wild, and while I know of many currently undergoing the process, they’re moving far too slowly.

This year I very much hope to see far more distributors, OEMs and carriers signing on across the globe, so the frequent conversations with folks in the EMM community I have about resellers not being available in a region or to them specifically due to strict approved vendor lists happens far less often!

The process for ZT is very straightforward, the validation is a walk in the park. Potential resellers on the fence about implementing the APIs and such shouldn’t fret, while that’s in progress handling devices manually is simple and straightforward until ready to transition (and if KME/DEP are already integrated into PoS, it’ll be easier still).

Organisations around the world are sat on their thumbs waiting for zero-touch resellers to become available; I very much hope this will happen this year.

OEMConfig adoption

Following the announcement of OEMConfig at the Partner Summit last May, I made a bold statement:

OEMConfig is very likely the most exciting announcement of the event for me as the implications are incredible.

This very much still stands as I write today, though despite early promise, and the recent induction into the AppConfig community, I haven’t seen a significant amount of adoption to date.

That doesn’t mean there hasn’t been any of course, Sony came out with their Configuration Extension which showed an excellent start (if a little lacking on breadth of capabilities), Huawei are working on an implementation, and a couple of other OEMs are looking at it also.

This year I’d like to see more OEMs publishing their own OEMConfig offerings, with a focus on the proprietary features so often unmanageable via EMM today (examples might include Huawei backup, Sony dynamic vibration, Nokia PureDisplay, etc).

Android One adoption

2018 felt as though there was a staggering rise in the adoption of Android One devices. A lot of this comes down to HMD Global who shipped several through the year, though we also saw offerings from BQ, Motorola, Xiaomi and more.

Android One offers an experience that very much compliments Android Enterprise Recommended, taking the security patch mandate up from 90 to 30 days, an additional letter upgrade and provides a wonderfully bloat-free experience which is consistent across OEMs.

Android One devices are simple, reliable and easy to manage. I really want to see more OEMs offering either Android One devices, or Android One editions in 2019 (I’m looking squarely at you, Sony and Huawei).

Samsung ❤️ Google

I don’t think there are many at this point who don’t know of the tension between Samsung & Google over the last couple of years. This year I’d like to see them finally come together to bring zero-touch support to Samsung devices (as opposed to choosing KME or ZT) and introduce their lineup to Android Enterprise Recommended.

I can’t stress enough how many times I’ve seen Samsung excluded from the running because customers want to support multiple OEMs through one automated provisioning service and/or have decided only to select devices from Google’s AER list.

It’s time for that to change.

What do you want to see?

Those are my requests for 2019. What do you want to see come to Android Enterprise or the ecosystem this year? Sound off in the comments, on Twitter, or on LinkedIn!

My top Android apps in 2018

2018-12-31T19:14:02Z

It’s been a couple of years since I last did a top Android apps post, mostly as my app usage remains pretty static; I only occasionally source new apps to solve a problem or out of curiosity.

With that said, here are the apps I’ve used the most this year in alphabetical order:

Action Launcher

I’ve been a Nova launcher user for several years and very much appreciate the 3rd party launcher support for Android as a saving grace against the heavily skinned UIs a number of OEMs force upon consumers.

As someone who changes devices often, I also benefit massively from the ability to backup and restore layouts across devices very simply. What’s lost in native launchers (Google app integration, advanced multitasking in Pie where supported) I gain in gesture support, extremely granular customisation and more.

But I grew a little bored of Nova, so decided to see what else the market had to offer.

Action Launcher has been one of those launchers I’ve been aware of as a direct Nova competitor, and as such one of the first I checked out. Granted, I don’t take advantage of some of the advanced customisation on offer (shutters, covers) but AL does provide a pixel-like (vanilla) experience on otherwise skinned OEMs, gestures, a “Quickdrawer” with apps listed alphabetically and an additional widget pane named “Quickpage” which provides access to fixed widget on any homescreen.

It isn’t perfect, not supporting the creation of a work folder or offering Android Pie’s split work/personal apps when provisioned as an Android Enterprise device, but hopefully this will come in time.

Action Launcher is free to download with a $5 in-app purchase to unlock additional functionality. It’s worth a shot if you’re tired of the system launcher!

Androidify

If you’ve read any of my documentation, LinkedIn posts or even took a gander at the featured image of this post, those delightful, customised Android robots are all the doing of Androidify.

It’s a very simple app, that also has a web app version on androidify.com, and allows for advanced cusomisation of outfit, accessories and more.

I wish there were more options around exporting (transparency, vector, custom animations, etc) but I’ve managed fine with it so far.

Androidify is free on the Play Store.

Audio Recorder

Audio Recorder is a creatively named Sony app that offers free, easy to use audio recording with an optional paid transcription service.

The app offers settings for mono/stereo recording and audio quality, providing some flexibility in the resulting recording, but for my use, leaving it on default has been perfectly fine.

Audio Recorder is free on the Play Store, and is not limited to Sony devices.

AZ Screen Recorder

I’ve done plenty of screen recordings over the year for various reasons (though mostly related to my Android documentation) so have tried a number of screen recording apps.

AZ has the benefit of offering GIF conversion in-app, as well as editing tools to ensure the resulting export is perfect without additional tools. The fact it works without root is pretty good also.

AZ Screen Recorder is free on Google Play with an in-app upgrade to Pro for advanced settings.

Emby

I’ve been using Emby for a number of years, however with Kodi on my Android TV as the front-end to the Emby server back-end, I haven’t had a need for any other means of access until earlier this year.

The Emby app is one of a number of options available, but it’s my favourite due to having an Emby premier license already (if I didn’t, I’d explore much cheaper options).

The app is free on Google Play, though frequently provides reminders to upgrade for advanced functionality. Upgrades can either be performed in-app, or via a server upgrade the app is connected to at login.

Files by Google

Originally called Files Go, the file manager came to be as part of Google’s Android Go edition suite of applications.

As development continued it appears to have flourished into a pretty decent file manager with such features as app sharing, storage management for types of files (memes, junk, etc), cloud service integration and more.

It hasn’t become my default file manager as yet (that title remains with Solid Explorer) however I do find the occasional reminders to delete accrued pictures and other things taking up space valuable.

Files by Google is free on Google Play.

JuiceSSH

I’ve mentioned JuiceSSH in the past. No matter how many terminal type apps I install, I always come back to this app to handle the task.

With such features as encrypted cloud sync between devices, saved snippet support, simple multi-session support, plugin support and more, it’ll likely remain my go-to for a long time to come.

JuiceSSH is free on Google Play, with a small fee to upgrade for additional features (which I recommend!).

Solid Explorer

When I last recommended Solid Explorer it was the classic version, since then the app has been redesigned and relaunched. It’s better than ever.

I like Solid Explorer for a number of reasons, but primarily the UX; it’s so easy to use, with the dual-panels, ZIP support, network file share support, multiple file type preview support, lightning fast search and batch tools, I use this app extensively for pushing and pulling files to/from remote shares and on-device storage management almost daily. Add in the material design UI and it’s the perfect file manager for me.

I really can’t recommend it enough! It’s available on Play as a 14 day trial, after which will need to be purchased. It’s on sale at the moment, so grab it while you can!

Do you have an app recommendation for 2019 I should know about? Let me know in the comments, @jasonbayton on Twitter, or on LinkedIn

Year in review: 2018

2018-12-29T23:15:49Z

With 2019 just around the corner, I thought I’d take some time to reflect on the past year, and do a bit of in-the-moment analysis as I write to fully digest the many aspects of the last 12 months that I’ve really not properly thought about.

It’s been a busy one! Between the work I’ve done here, the contributions to external sources, events attended and more, I’m not sure I’ll even scratch the surface, but I’m going to give it a try regardless…

1. 170k visitors

Just as last year, I’ll start off with a few metrics! In 2018, bayton.org was visited almost bang on 170 thousand times.

Again, compared to mainstream sites which quite easily get that amount of traffic in a week, it’s really not a massive number. To me though, that’s 170K times someone, somewhere has stopped by to read something (or multiple things) I’ve written, and that’s pretty darn nice.

It also continues an upward (mostly) trend since I began collecting stats in 2012, and reflects the time and effort I’ve continued to invest in my website and social presence (chiefly LinkedIn) since late 2016.

After surpassing 100K in 2017, my goal was to hit 150K this year – this was seemingly not a problem, so I’ll have to be more ambitious for 2019!

Of all visitors, it is once again USA in first, followed by UK, Germany and France. Exactly like 2017:

While US and UK leaned more towards enterprise documentation, Germany and France seemed to focus more on my posts surrounding open source and Linux, and in that, the three most visited articles (docs/posts combined) this year are:

As social referrers go, LinkedIn jumped from 5th to 1st this year, followed by Twitter in 2nd and Reddit in 3rd.

Given the continued focus on LinkedIn throughout 2018 this isn’t a surprise. Last year I quipped:

I used LinkedIn only really for the occasional post, job search or profile update and got very little out of the platform (despite landing my last 3 roles through it!). Using it as a primary platform for enterprise topics (with Twitter in 2nd place) has been very rewarding despite the lower referral rate.

Everything in 2017 was clearly only laying the groundwork for a very successful 2018 on the platform! Twitter has equally benefited from almost default cross-posting from LinkedIn also. Reddit despite making top 3 isn’t really a platform I’ve invested in, it’s mostly from others sharing my content so that’s nice to see!

2. Android Enterprise

I’ve had a massive year with Android Enterprise, working with a number of partners, vendors and Google directly in order to continue advocating the platform and modern Android management. Here are a few highlights:

2.1. Documentation

Last year I created /docs as previously announced on this introductory post. While there are areas for an array of topics, in 2018 I focused almost entirely on Android Enterprise with respect to new content, with a 170% increase in Android Enterprise content YoY.

One of the goals of documentation was to maintain rather than just create new, and I’ve kept myself busy continuously iterating on docs throughout 2018 also!

What is Android Enterprise and why is it used? for example was published in 2017, however was last updated in November, taking the number of revisions up to 55 over 20 months. The same applies to Android Enterprise device support which I last updated this month, marking its 132nd revision.

Over the year I’ve also created some pretty nifty infographics:

I didn’t ultimately create the one per month I was planning, but what lacks in quantity is made up for in quality!

I’ve also updated resources, like my Android version evolution graphic (complete with PPTx, so please feel free to modify and redistribute at will!)

There’s still plenty more to do here in 2019, including making use of the new WordPress editor, Gutenberg, to once again redesign the Android landing page (and likely others!), adding more docs, possibly an ebook/whitepaper or two.. who knows. On the subject of ebooks…

2.2. External contributions

If you’ve read MobileIron’s Android is ready for the enterprise whitepaper, you’ve been reading my content. That was a super interesting collaboration which I hope to be able to do again next year with a UEM, OEM or other vendor in the space (really, get in touch if you’re interested)

Beyond this I’ve contributed a few articles to BrianMadden.com over the year, continuing what I started in 2017:

And in 2019 may be contributing to other outlets in the TechTarget ecosystem also!

Finally, as a founding member of MobilePros it’s been an incredible year for growth! The community, boasting a huge number of enterprise mobility experts in vendors, partners and administrators alike, has increased to over 400 members and continues to flourish.

If you’re working in the EMM space, feel free to stop by any time for help & advice across a range of solutions and products, or just for a friendly chat!

2.3. Device testing

I’ve mentioned in the past I try to avoid buying devices as I’d go bankrupt, so I’m truly grateful for the OEMs who’ve seen value in loaning devices for testing, whether one or ten, for a week or six months!

In particular HMD Global and Sony have been incredible to work with this year, they truly value the feedback I provide and promptly investigate any issues/niggles I’ve brought up and kept me up to date with progress.

Huawei have also been fab, and though you won’t see them on the validation page right now, CAT came out of the blue with a handful of rugged devices for testing, so it’s been super interesting tinkering with those also!

I finished out this year testing the new Nokia 8.1, which has passed my validation with flying colours. The Nokia is one of over 30 devices tested this year, and I’ve fed back well over 120 issues where things don’t work as expected, or could be improved, bettering the Android Enterprise experience for organisations the world over!

2018 also marks the first year I began publishing public reports for OEMs who show little or no interest in Android Enterprise support, for these devices I have made some exceptions through the year and purchased them due to their increasing popularity:

There’s an Honor Play to come also.

With the Android Enterprise Recommended program I wondered if there was value in continuing to test devices this year, but based on the number of issues raised against one or more EMMs/the AE experience in general (even on some AER devices), I believe so! I’ll therefore carry on doing so next year.

I’ll also work to update and improve on the transparency of my testing results, likely redesign the layout and will potentially publish the exported EMM profiles I use so others can perform the same level of testing on their own devices.

If you’re an OEM looking for feedback on your implementation, either generally with AE or against any particular EMM, get in touch! I’m particularly interested in testing LG, Motorola/Lenovo and Honor next year, as well as some country-specific OEMs like the BQ I tested earlier this year. Smartphones, tablets, rugged, or anything else (fixed phones, point of sale, anything GMS certified running Android 6.0+) is all welcome! I don’t charge for testing or the reports generated after.

If you’re a reseller/distributor interested in helping me with loan devices in return for a mention on the page, let me know! We can work something out.

2.4. Events

I managed to get about a fair bit in 2018, starting with Mobile World Congress which I wrote about in March, where I got to meet the AE team face to face for the first time, to doing my first ever liveblog on the site at the Android Enterprise Summit, the first to ever do so that I know of!

After that came MobileIron Live and more recently, I attended my first ever launch event as a member of the press for Huawei’s Mate 20 series launch.

There’s a bit of refinement to do on the liveblogging side of things; as I do more I’ll likely write less and hone in on the important updates, which will make it far easier to do. Look out for my next liveblog at the 2019 Android Enterprise Partner Summit (if Google allow it!).

I also attended and presented at Wandera’s Level event:

https://www.youtube.com/embed/OxreOz3PQBM?feature=oembed Here’s the presentation

And of course I attended a number of vendor events, sat on the committee of the first DroidCon Android Enterprise Summit and did a good few sessions through the year with Google, too!

It’ll be tough to beat next year, but I’m going to try anyway!

5. Industry mentions

I’ve had a pretty good year when it comes to mentions around my industry, besides being a regular in Jack Madden’s posts, here’s where else I’ve popped up:

And a few of my favourite tweets:

Take a look at why #WorkspaceONE is leading #EMM / #UEM for #Android Enterprise. Great article from renowned Android expert, @JasonBayton: https://t.co/E8AvKDOTUB pic.twitter.com/CXKR9FZOpn

— VMware Workspace ONE (@WorkspaceONE) November 7, 2018

Great article @JasonBayton! "BYOD & privacy: Don’t settle for less than Android Enterprise in 2018" https://t.co/QZRQifmVmM via @jackmadden

— Bhavesh Kumar (@bhaveshkk) August 6, 2018

Big Thank You @JasonBayton for all the work you have done explaining @Android Enterprise.All entities using @MSIntune within KBC Bank group have adopted AE & your website:https://t.co/QhOwIhiRFX played a big part in the preparation of our internal document.Keep up the great work!

— Gabor Nyers (@gabor_nyers) July 9, 2018

NEWS: A new program called OEMConfig could make #Android more palatable to businesses: https://t.co/xdtqmemZrI (by @AlyssaLaura22) w/ insight from @JasonBayton @eakleiner & more

— sMobileComputing (@MobileCompTT) August 20, 2018

I'll write more about these case studies, but for your questions, I'd recommend some resources here: https://t.co/qlk9VgC6rp
And especially @JasonBayton's awesome set of guides: https://t.co/od9UiP3GE4

— Jack Madden (@jackmadden) July 25, 2018

3. Still blogging

Despite the focus on docs this year, I’ve still published 22 posts covering everything from new releases to events, device reviews and more. My top posts were:

There are indeed posts there still from 2011 ranking high for views to this day, which is pretty incredible.

4. Discuss comment/forum system

After Disqus started injecting ads into my website despite my opting out, I felt it was time for a change. Contemplating a few options, I ultimately wanted to try something a little different: Discourse.

Discourse is forum software, or the modern equivalent of it, but with tight integration with WordPress it offered an opportunity to both replace my existing comment system, and offer something of a discussion board for both my topics and anything related I hadn’t covered on the site.

Today it’s handling comments well, and acts as the foundation of my liveblogging. Next year my hope is more folks stop by for a chat, or use it as a support hub and hopefully I’ll see it grow! Time will tell.

ß5. Another redesign

In the quest to put content front and centre before anything else, my site themes visually have gradually gotten simpler and simpler. This year I designed a theme that properly works with my documentation, and ported it across to the normal blog-type articles I write also, bringing consistency across the website that previously lacked.

I’ll no doubt continue iterating in 2019, though I’m always open to feedback!

Until next year!

I’d like to thank everyone who stopped by the site to have a read or say hello this year, to all the ecosystem vendors and partners I’ve worked with and all the folks I’ve met along the way.

Happy new year and all the best in 2019!

MobileIron Cloud R58 supports Android Enterprise fully managed devices with work profiles

2018-12-22T01:03:33Z

Following the introduction of Android Enterprise fully managed devices with work profiles (COPE) 9 months ago with Core, I was wondering how long it would take for the SaaS counterpart, MobileIron Cloud, to also implement it. With their December release of R58, now we know!

Historically both platforms have had their own schedules and priorities, with one getting new features sooner or later than the other, so a bit of a wait was expected, but considering I was anticipating next year for a good while, this was a nice surprise!

They didn’t quite get it out in time to claim first and second place in the race to gain COPE support, since VMware released 1810 a little ahead of MobileIron Cloud, but they still managed to get both supporting it before heading into 2019. Not bad.

How does it compare?

After a bit of a rocky rollout, quite literally the first thing I wanted to check was how it compared to Core.

Core’s implementation is fine, though areas I think it could improve on are:

The layout of the various restrictions available
The artificial limitation of restrictions in the parent profile
Manual steps required for work profile creation during enrolment

The good news is Cloud resolves one of these, offering a much better UI that’s far clearer:

The list of restrictions continues down the page

What it doesn’t improve on however is allowing admins to determine how best to manage their fully managed parent profiles reserved for personal use. MobileIron are still limiting the restrictions available to COPE devices which are otherwise available for fully managed (COBO) deployments, something I noted VMware does not do.

Also, though improved, enrolling a COPE device still requires additional taps to initiate the creation of a work profile, something I feel (and which is fully supported by AE APIs) should be automated. I don’t understand the justification for this, as it feels less efficient and more likely to result in a call to IT for clarification. In the COPE enrolment demo below you’ll see what I mean:

https://www.youtube.com/embed/S4i5Ih3-VKM

In any case, COPE support is fantastic to see, and fills a rather large gap for MobileIron Cloud customers who’ve up to this point been stuck between opting for a work profile deployment that doesn’t permit device management, and a fully managed (work-managed) deployment that isn’t designed to support personal use. COPE offers a happy medium and closely resembles the legacy deployment scenarios associated with the soon-deprecated Device Administrator deployments of old.

How to enable it

As of R58, a new system Android Enterprise configuration should be present, but should(!) not be assigned by default:

Highlighted in red

This system policy is designed to take precedence over the work managed configuration when assigned to the same groups, so enabling COPE on your MobileIron tenant is as simple as assigning this configuration:

You will of course also require a restrictions configuration in order to lock the COPE devices down:

Considerations with COPE

As with Core, there are some things to consider when deploying COPE, basically all but G Suite (which recently changed policy) still applies to Cloud, so do take a look.

Also, keep in mind COPE is still Android 8.0+ only, devices running anything less will not be able to take advantage of the deployment scenario.

Other changes

Deploy Google accounts

R58 also introduces support for pushing Google accounts to devices, another feature Core has had for some time already. Where an organisations makes use of managed Google (G Suite) accounts, this is a nice, simple means for pushing those accounts to the devices in a managed way.

iFrame improvements

Not tied to R58 specifically, the Google Play iFrame recently allows for both the free upload and distribution of private in-house applications directly from the EMM, and the ability to push web apps to devices!

The web apps in particular are clever, by creating a web app within the iFrame you’re actually creating a simple webview application which imports and deploys to devices as any normal application would; this solves the problem of Android Enterprise not supporting shortcuts natively, and it’s entirely backwards compatible, not something that would normally be so with a new feature.

For in-house app upload, this means organisations no longer have to pay the $25 fee for a developer account, and need only provide a name and the APK. The long-winded process of uploading apps to Google Play is no longer necessary! A caveat, however, is these applications will remain forever private, and cannot therefore be made public in future.

Conclusion

I wrote in my article on Core supporting COPE that this is potentially the most important of all deployment scenarios for the non-rugged market and stand by that still.

As support has widened this year, so too has interest in COPE from first-hand experience, and I don’t see that slowing down!

With three market leading UEM platforms now supporting the deployment scenario, I’m only really looking at MaaS360 (~early 2019) and SOTI (…?) to cover pretty much all the big names. (“What of Intune” I hear you cry, they are yet to even support fully managed (work-managed, COBO) so still a fair way behind everyone else currently).

Even lesser known, but great EMMs such as Miradore are following closely behind the major players in bringing COPE to market after a solid year of Android Enterprise focus, so it definitely won’t be too long before it’s pretty much universally available. Keep an eye out for more vendors next year!

Hands on with the Huawei Mate 20 Pro

2018-11-07T09:40:10Z

I was lucky enough to get an invite to the launch event for the Mate 20 series back in October and have been using the Mate 20 Pro as a daily driver since! It is an incredibly powerful device with some truly innovative features in a market that has felt like it’s plateaued a little in recent years.

That said, and no doubt due a little to early adopter syndrome, there are a few pain points with EMUI I’ve found which I hope to see addressed.

Lets get started.

Hardware

The Mate series is no slouch when it comes to hardware generally, and the new Mate 20 Pro is no exception. The Pro naturally benefits with a spec bump vs the Mate 20, however they’re not a million miles away in terms of core hardware.

With a 6.39″ quad HD curved display, it’s a welcome upgrade over the full HD screens of previous iterations. The display curves gently into the sides of the device, which Huawei claim are the thinnest on any device on the market today.

Under that display is the first mainstream implementation of an in-display fingerprint sensor. Allowing for unlocking without picking the device up (when the sensor is on the rear) or taking up valuable screen real-estate (when the sensor is below the screen), in-display sensors offer the best of both worlds with one caveat – it’s not quite as fast at unlocking vs a traditional sensor; not to the point of frustration by any means, but you may notice it if not when unlocking, definitely when registering your fingerprints.

Thankfully and unique to the Mate 20 Pro (vs the others in the series) above the display, or.. cut into the display is a selection of front-facing cameras, in another stated first Huawei also include a 3D depth sensing camera system into the array; a good deal more secure than the standard 2D camera recognition systems most Android devices ship with. The device unlocks incredibly quickly with this enabled, and with the option to skip swiping the lockscreen after a successful unlock, can be on the home screen literally in the blink of an eye.

There are reports online that even with the 30,000 reference points it checks for it can be fooled, so do take that into consideration.

You pay for this functionality with a much larger notch than is present on the Mate 20 and Mate 20 X, but it’s still nowhere near the landing strip the Pixel 3 ships with.

Powering the display is the Kirin 980, which is the first 7nm chip of its kind in a phone today, delivering both improved speed and efficiency (having our cake and eating it, too!) and works in tandem with a sizeable 6GB RAM.

There’s a 4200mAh battery on board, and I’d just like to take a moment to appreciate this; with a sea of devices trying not even making an effort to get close to the 4K club, Huawei are setting an example everyone should be following. I can easily get more than a day of usage out of the device with no attempt to take advantage of the various battery saving capabilities both in Android and those Huawei have added into EMUI.

With wireless charging, topping up the battery is reasonably quick and convenient, at 15w (compared to the 7.5w of the iPhone) it’s nothing to be sniffed at, though doesn’t come close to the speed when connecting the device to the included 40w charger – admittedly it did look more impressive at the event however in reality it’s not bad at all.

The real innovation on the wireless charging front is the Mate 20 Pro’s ability to reverse wireless charge, offering a much-needed boost to devices running out of juice with no ability to get to an outlet. The feature needs to be enabled and will disable after a period of inactivity automatically; it may not be the fastest but definitely helps in a jam.

Stereo speakers are onboard, via the top front-facing speaker and, interestingly, out of the USB C port on the bottom (!). Sound is decent, clear, gets certainly loud enough for me and I appreciate a stereo setup even if it isn’t front-facing.

Generally the device looks stunning, with a focus on symmetry and the twilight colour option seen on previous Huawei devices, it’s clear a substantial amount of time has been invested into trying to make the Mate series the best looking on the market.

Camera

This is the Mate 20, with a fingerprint reader on the back

The Mate 20 series ships with a triple camera system on the back, with the 40MP main shooter sat alongside an 8MP telephoto and 20MP ultrawide offerings.

The photos are good.

I find myself mostly impressed with the AI, choosing for me the best mode to take a photo with nothing more than pointing at the target I want to shoot. I adore the night mode in particular as it really brings photos in poor light to life, but I’ve made good use of the macro mode and ultrawide modes also.

Take a gander at some of the results:

More photos can be found in my album, here.

Software

EMUI is an experience.

Being a big fan of vanilla Android (think Pixel, Android One, Motorola, etc) coming to a UI that still today looks influenced by iOS is not overly appealing to me. This extends to their bloatware and unnecessary fiddling of the underlying Android OS.

With that said, they do make an effort to offer a launcher experience closer to what you’d expect on an Android device by permitting the app drawer, and when I pick up a Huawei device it’s usually the first thing I do (before ultimately switching to a 3rd party launcher like Nova or Action, anyway).

Outside of first impressions the experience is familiar Android so it’s certainly not a learning curve, and they do add a bit of useful functionality here and there also, such as:

Screenshot a full page:

Hide the notch:

Though more and more I find usability challenges more than useful additions, for example:

On the lockscreen normally Android devices allow for the notification bar to be swiped down. It’s not possible on the Mate 20 Pro which means I need to fully unlock the device to be able to glance at notifications (since the lockscreen only shows a couple at any one time)
Huawei ditch Pie’s pill gesture navigation in favour of their own entirely gesture-based nav (no buttons to speak of) but the gestures don’t always work consistently (I can’t swipe back out of the app drawer, only swipe to go home), and the rotation button added in Pie is full-stop not supported for whatever strange reason.
Other Pie features like slices, suggestions and for enterprise, the work/personal app drawer split are seemingly just not present.
When switching between apps, if I don’t bring the app I want centre-screen (as in, try to tap an app preview on either edge of the screen) the task switcher closes without switching.
Then there’s the whole security issue of enabling unknown sources by default for a number of applications out of the box…

I don’t understand why OEMs actively remove features of the OS, or swap them for custom implementations that don’t work as well; it offers a poor UX and really only leads to confusion and frustration when things don’t work as expected.

With such incredible hardware I really long for an Android One edition of basically any Huawei device on the market right now, but particularly the Mate series would be a dream running vanilla Android.

Enterprise

Huawei are a bit of a mixed bag with enterprise support, and it again ties in to the fact they customise Android so heavily. The Mate 20 Pro does have some niggles at the moment which I’m keeping a list of, but in terms of raw Android Enterprise provisioning and standard management capabilities, this device is probably the best-supported Huawei I’ve tested out of the box.

The Mate series is also Android Enterprise Recommended so has passed Google’s validation. Whether you’re an enterprise decision-maker or a regular consumer, this is a very good thing; as an AER device it is validated to support both Pie (the version it shipped with) and one letter upgrade to Android 10 next year.

What you also get are 3 years minimum of guaranteed security updates (those monthly patches that address vulnerabilities and issues on the device) within 90 days of release from Google, at least 8 hours of battery life and, should you ever as a consumer wish to take it into work as a BYO device, you can know it’ll have full Android Enterprise support.

If being considered for deployment at scale I’d certainly first test them within the environment they’re being deployed into before signing any contract, however Huawei should be a relatively safe choice.

Oh, and the issue with unknown sources is not a problem when provisioned as a fully managed (work-managed) device, so no need to worry about that.

Conclusion

The Mate 20 Pro is an incredible piece of hardware let down currently by a software experience that needs a bit more refinement and QA. Still, it’s very much a device to beat in many ways, and introduces some real innovations.

The camera is fantastic, the AI capabilities are genuinely very impressive, and I’d be surprised if it’s not considered one of the best on the market.

The Mate 20 Pro is available now already from many of the usual places on the high street, as well as Amazon and other online retailers.

Do you have the Mate 20 Pro already? Are you considering it? What are your views on the device? Let me know in the comments, Twitter or find me on LinkedIn.

Workspace ONE UEM 1810 introduces support for Android Enterprise fully managed devices with work profiles

2018-10-29T15:20:33Z

For the last 7 months, MobileIron has been the only UEM vendor to support the newest of all Android Enterprise deployment scenarios: work profiles on fully managed devices. Also known to some as fully managed work profile, managed device with work profile, corporate owned managed profile (COMP), work-managed work profile and honestly probably more, it is essentially COPE (Corporate Owned, Personally Enabled), offering personal use on an otherwise fully managed device.

VMware have had an awful lot of time to refine their offering, and release it in tandem with the replacement of their iconic AirWatch Agent in favour of the new Workspace ONE Intelligent Hub, seemingly completing full VMware-ification of the AirWatch platform.

Was it worth the wait?

The console experience

For testing I created a new organisation group and headed to Groups & Settings > All Settings > Devices & Users > Android > Android EMM Registration > Enrollment Settings:

Overriding the settings, I then toggled Fully Managed Device Enrollments over to Corporate Owned Personally Enabled.

Job done! Really, that’s it. This is naturally an organisation group-level change and so for environments with fully managed devices in use already, it makes sense to separate these into different organisation groups, something not necessarily required when mixing the other deployment scenarios.

As COPE makes use of both the fully managed device and work profile restrictions, attention was next turned to the Restrictions profile.

Something I dislike about MobileIron’s Core implementation of COPE is just how cluttered the lockdown policy has become with all of the new options. By comparison, VMware have clearly put a lot of thought into how best to display work-managed and work profile restrictions generally, and it has really paid off in terms of being clear and easy to understand:

An earlier version of this UI showed non-configurable options as greyed out which I personally preferred, but this still looks great

What’s abundantly clear whilst scrolling through is just how granularly the device can be locked down. The restrictions shown above are applicable to both work-managed and COPE devices, meaning the parent (personal) profile on the device can be just as restricted as an equivalent fully managed device, if the admin so desired.

As an administrator I much prefer this; while I appreciate what MobileIron are doing by artificially limiting the restrictions available on the parent profile of the device, I’d personally rather make my own decisions on how much personal use is permitted on what is still a fully managed device.

With the new Restrictions profile distributed, I enrolled a device.

The user experience

I provisioned an Android One device with a QR Code generated by heading to Devices > Staging & Provisioning > Staging > Configure Enrollment > Android > QR. The wizard is a nice touch, if you’re able to remember where to find it:

Enrolment

Enrolment, generally, is notably smoother with fewer taps required than I’m used to when enrolling a COPE device, this is primarily due to VMware opting to take Google’s suggestion of removing the work profile user interaction during setup, and for good reason.

On a work profile device intended for BYOD or similar, it entirely makes sense for the user to be prompted with the work profile setup wizard; it’s a device with no other management and thus in creating the work profile users are then guided through the various steps, T&Cs and so on.

With a fully managed device however, the user has already granted permission during provisioning for the device to be managed, and due to this, the work profile setup prompts can optionally be skipped.

This is best demonstrated with a video:

https://www.youtube.com/embed/QSJu3xFzjMw

As can be seen, after authentication Workspace ONE UEM mostly handles everything automatically, give or take a few taps for privacy, whilst MobileIron runs through the whole work profile setup flow.

It’s a nice feature that once more shows VMware have put some thought into the user experience during enrolment.

Beyond enrolment

Following enrolment, the experience is pretty much as expected with applications automatically downloading into the work profile.

The obvious differences lie primarily in the restrictions imposed on the parent profile, given so much more can be locked down in Workspace ONE UEM.

There is one thing that bothers me though.

When opening **non-**managed Google Play in the parent profile, I’m greeted with the managed Google Play Store.

This isn’t something you’d expect to see in the parent profile as it’s intended for personal use, however this actually happens because Workspace ONE UEM, for reasons yet to be discovered, adds a managed Google Play account to both the work profile and the parent profile.

Heading into Settings > Accounts on the device demonstrates this:

Managed Google Play accounts are primarily used for app management, so you can draw your own conclusions on why that may be there, but there’s nothing I’m seemingly able to do with it within the parent profile right now.

In any case, as an end-user I’m used to being prompted to sign in when opening the Google Play store on a personal parent profile, so to be greeted with a managed Google Play UI offers poor UX and will be confusing for many, no doubt resulting in questions back to IT as to why users can’t get to the “proper” Play Store (or users will eventually figure out it’s possible to switch accounts within Play after adding their own account).

Still, this change may be worth it in the end so I’ll reserve judgement for now and see what comes next.

Touching on app collections

One other recent feature I was made aware of is the introduction of app collections in managed Google Play.

Administrators now have the capability within the Google Play iFrame not only to approve applications, but to customise the layout of the applications also!

This feature is backwards compatible to any version of Workspace ONE UEM or AirWatch that supports the iFrame, which means most organisations can make use of this new feature already:

The usability of this is greatly improved over manually categorising every app imported, making it much faster and easier to approve, organise and deploy applications whenever required.

To conclude

I’m extremely pleased to see wider adoption of COPE for Android Enterprise, even if it has taken well over a year since its introduction with Android 8.0 Oreo.

Being the best of both worlds between management and freedom for many organisations, this should be welcomed with open arms and I look forward to seeing this further aid in the increased adoption of Android Enterprise going into 2019!

VMware have done a great job with this implementation and have even added a little suspense over what’s to come with the addition of a managed Google Play account within the parent profile, so I’ll be keeping my tabs on what they’re up to over there!

1810 and the new agent are currently rolling out now, if your organisation is waiting on COPE it should only be a matter of weeks, however get in touch with your VMware representatives for more information if required.

The question now is, which will be the next UEM to support COPE?

Have you been waiting for COPE? Are you happy with how VMware have implemented it? What, if anything, do you feel could be improved? Let me know in the comments, Twitter or LinkedIn!

G Suite no longer prevents Android data leakage by default

2018-10-29T13:17:45Z

On September 19th, Google introduced a change to the default app settings for Android management on newly-created tenants which may lead to data leakage for organisations.

Google explains the change as follows:

Currently, you have to actively whitelist apps to make them available to your users. Starting on September 19th, users with company-owned Android devices and work profiles will be allowed to install any app from the managed Google Play store by default. If you don’t want your users to do this, you can choose to restrict app availability to whitelisted apps.

Making it easier to set up Android devices as company-owned

What this means

On the face of it this appears innocent enough, however in reality this will now allow end-users to install any application, without restriction, within the corporate work profile or onto a work-managed device unless a G Suite administrator actively reverts this to approved applications only.

As it happens, the option to allow installation of any application from the Play Store has been there for some time, but administrators have been required to opt in to this capability. Google’s change simply reverses this process and in doing so, makes Android deployments less secure by default.

Why this matters

The reason this is dangerous is simple: by allowing any application to be installed from the Play Store rather than limiting it to approved applications only, end-users could quite easily install chat apps, cloud storage services and more alongside corporate applications and data, with no restrictions on data being moved from app to app.

This change flies very much in the face of best practices and recommendations across the industry, breaking the work/personal barrier UEM solutions have been putting in place with containerisation for years before Android itself brought about the work profile and managed Google Play for tailored app deployment.

Existing tenants are unaffected

Thankfully this doesn’t affect organisations who have connected an external EMM/UEM platform for device management, nor does it appear to have been implemented on existing tenants, and thus the chances of a change happening on a live environment without adequate notice is slim (though I’d never rule it out with Google).

How to revert the change

For those who create a G Suite tenant after the 19th however, the fix is quite simple, requiring only the click of a radio button to return expected, basic security:

This page should be found here once logged in

Conclusion

The question though is why Google would intentionally make this change; who decided enabling data leakage for the the sake of what I can only imagine is convenience for organisations who don’t wish to prevent end-users installing their own apps is more important than ensuring the organisations who want security by default get it out of the box?

I certainly hope this doesn’t catch any organisations out, but I’m almost certain it may.

Are you a G Suite customer? How do you feel about this change? Reach out to me on Twitter, LinkedIn or in the comments to let me know!

Live: Huawei Mate series launch

2018-10-16T12:34:48Z

Today Huawei are set to launch their Huawei Mate series live in ExCeL London.

Follow along below, or for live updates be sure to head over to the Discuss topic!

How to sideload the Digital Wellbeing beta on Pie

2018-10-01T22:23:50Z

Installing apps from unknown sources is dangerous

The following discusses the installation of an application from outside of the Google Play Store. Installing apps from unknown sources is 80x more likely to result in a Potentially Harmful Application (PHA) and should therefore be avoided. The source of the APK in question is hosted by APKMirror, a source I trust knowing its background, however this is an exception rather than a rule.

Not running a Pixel as my daily driver, but having Android Pie for a little while both via the developer preview and more recently the official launch for the Nokia 7 Plus, I’ve been struggling to get my hands on Digital Wellbeing.

Reading online, the 7 Plus is supposedly able to get the app, however I found despite joining the beta and waiting a number of days, the Play Store simply would not offer it up.

So I tried other means.

Normally if I need an APK for an application, I’ll lean on friends or colleagues with said app already installed to export it with something like MyAppSharer. There is then no doubt about the legitimacy of the application as I know it has come from a trusted source – Google Play.

However, with Digital Wellbeing in limited beta it seemed easier to head over to the only external source of APKs I trust, APKmirror.

At first I figured it’d be a bog-standard install via Chrome on Android, however after downloading and attempting to install it, I found Play Protect actively blocked the installation due to it being from an unknown source; this is the first I’ve seen of this type of block as I’ve only known it to pop up for PHAs previously. My theory is Google has perhaps added it to a blacklist to reduce to the likelihood of their beta being sideloaded given I was able to install other APKs perfectly fine, but that’s speculation.

Instead, I nipped over to my PC, downloaded Digital Wellbeing from APKMirror once more and connected my device via USB. Using ADB I was then able to install the application with:

adb install com.google.android.apps.wellbeing.apk

As simple as that.

Not on Android Pie yet? No worries! Check out this simple guide to get upgraded, or come back once the OTA has appeared on your device.

How to manually update the Nokia 7 Plus to Android Pie

2018-10-01T22:21:44Z

Backup before proceeding

Upgrades aren’t guaranteed to succeed, to ensure you can restore your device in the event of a failed update, please backup your device before proceeding.

Just before the end of September, HMD Global made good on their promise to release Android Pie for the Nokia 7 Plus.

The only thing is currently, it’s only rolling out to select markets and at a cautiously slow rate; the UK as well as many other countries around the world are as such not able to get their hands on it just yet.

To avoid the wait and get Pie immediately, it’ll need to be sideloaded. Here’s how:

\1. Grab the OTA download

The nice folks over on XDA have managed to capture the OTA link from devices currently getting the update. Download it directly by clicking below:

WW 3.22C September 2018 [TA-1046, TA-1055, TA-1062]

(NB, this will not install if you’re running the October security update. To get around this, I’d recommend identifying your currently active partition via the bootloader, swapping to the inactive, rebooting into recovery and attempting the below steps again).

\2. Connect the device to a PC with ADB

Depending on the operating system you may need to install drivers for the Nokia 7 Plus, and validate ADB is functional. Once confirmed, reboot into recovery:

adb reboot recovery

Once confronted with the Android laying on its back, hold the power button and press volume up. It may take a few attempts to get this right.

\3. Start the install

Select Apply update from ADB in the recovery menu by using the volume keys to go up and down through the menu, and power to confirm the selection. Once confirmed, the device will await the update package via ADB.

On the computer, run the following command:

adb sideload yourdownloadedOTAfile.zip

Where yourdownloadedOTAfile.zip is the name of your downloaded zip. Make sure you either add the full path, like C:\Users\Example… or /home/user/example…

The process will now start, transferring the OTA from your computer to the device. The device will show the installation in progress and let you know when it’s complete, after which selecting reboot from the menu will power the device back up into Android Pie.

Since you’re now running Pie, perhaps you’ll be interested in How to install the beta of Digital Wellbeing also.

Are you upgrading your device to Pie early? Are you going to wait until it rolls out to your device? Let me know in the comments!

Hands on with the BQ Aquaris X2 Pro

2018-09-27T16:58:56Z

Announced at Mobile World Congress earlier this year, the Aquaris X2 Pro is one of two Android One devices Spanish OEM BQ have brought to market in 2018.

While you’d be forgiven for not recognising BQ as a manufacturer considering their primary market has been mainland Europe (though you’ll find them on Amazon UK at inflated prices if you’re looking), they’re an OEM to pay attention to.

Hardware

The device is, like most premium examples in 2018, a mixture of aluminium and glass, with the only exception being a thin plastic border around the 5.65″ 18:9 FHD+ screen which also branches into the less-than-subtle antenna lines.

The device comes in three colours, Midnight Black, Deep Silver and Glazed White. The Glazed white to me, depending on the light, looks like it could have either a rose or gold tint on the aluminium, it’s quite nice.

Unsurprisingly it’s also a bit of a fingerprint magnet because of this and a little slippery in the hand compared to devices with metal or plastic backs; sentiments again echoed often with this choice of material; in fairness though the white model BQ sent over does a pretty good job of hiding them.

General build quality is fine; there are some very minor niggles here and there I noticed where it sandwiches together, but I had to pay quite close attention to even see this, so it’s unlikely to be a concern.

All of the exciting ports sit at the bottom of the phone, including a USB C port capable of Qualcomm Quick Charge 4+ (though there’s only a QC3 charger in the box), a 3.5mm jack (thank you) and a loudspeaker.

Volume and power buttons on the right of the phone are very clicky and feel suitably premium, with the SIM tray sat on the opposite side housing dual-SIM slots.

The fingerprint sensor on the back is well placed (unlike recent Sony XZ models) and reasonably quick; it isn’t the fastest I’ve seen, but not far off.

The loudspeaker on the bottom isn’t too bad, it goes loud enough to fill a smaller room without becoming tinny and combines with a loudspeaker in the speaker grille to form stereo sound. Still, it partially shoots out of the bottom of the phone, so there’s certainly room for improvement when compared to devices with stereo front-facers.

Spec

CPU: Snapdragon 660
4/6GB RAM
64/128GB Storage, up to 256GB microSD support
3100mAh battery
12 + 5MP rear camera, 8MP front camera
Dual SIM (in the absence of a microSD)
NFC
Fingerprint Sensor

Camera

For the record, I am not a great photographer. That said, I found the camera to be pretty good in both normal and lower light situations, however don’t take the following samples as a single source of truth:

BQ’s camera app is simple, clean and straightforward to use. The automatic settings do most of the hard work, but additional ad-hoc options such as brightness adjustments are a nice touch. It also includes manual, portrait and panorama modes, and will take video up to 4K once enabled in camera settings.

I prefer the BQ camera over the Nokia 7 Plus currently (pictured above, losing its copper accent with a wireless charging pad plugged in to add that missing functionality).

On the subject of wireless charging, given its glass back I’d have liked to see that feature added also. Alas, that may have been too big of an ask for the price point.

Software

Out of the box the Aquaris runs 8.1 Oreo. There are plans to upgrade to Pie however at time of writing I’ve not seen so much as a beta just yet. Since BQ have been leveraging Project Treble for some time however, it shouldn’t be too much longer.

As this is an Android One device, the software experience is pure, stock Android with only a couple of approved BQ apps (the camera being one of them).

Running vanilla Android means the clean UI and reliable UX made it really simple to switch from my Nokia 7 Plus to the BQ, and later from the BQ to the Xiaomi A2 without any grief whatsoever, it’s a delightful experience that could only be improved with a faster means of making that switch; the Pixel 2 supporting migration via USB for example is super convenient and saves a good deal of time vs cloud restore alone. Android One has the capability to bring this as a standard for all participating devices and should do.

Without any pre-installed bloatware or skins there was literally nothing for me to do following setup. Compared to the time I’d take on other OEMs disabling all of the rubbish forced upon me (AV, games, OEM apps, etc) and switching to a cleaner home app, it was very simple to set up and gives me the freedom to choose the apps I want on my device rather than those the OEM is given kick-backs to include.

This is but one of many reasons to consider an Android One phone, in addition to quick updates, great performance (even on mid-market specs) and more.

As this runs a Snapdragon 660 I’d like to make a point of stating there are no performance issues in daily use; it handles all of the applications I throw at it (many concurrently) and runs games pretty well too. Like the Nokia 7 Plus, the BlackBerry Key2, the MI A2 and other devices with the 600 series CPUs within, they perform well and shouldn’t be snubbed solely because they don’t use 800 series chips.

Enterprise

As well as being an Android One device, BQ recently had the device validated against the Android Enterprise Recommended programme. Now whether you’re an enterprise decision-maker or a regular consumer, this is a very good thing; as an AER device it is validated to support both Oreo and one letter upgrade to Pie. BQ being Android One will probably support one further letter upgrade also but this is mostly speculation on my part.

What you also get are 3 years minimum of security updates (those monthly patches that address vulnerabilities and issues on the device), guaranteed 8 hours of battery life (though the X2 boasts much better than that) and, should you ever as a consumer wish to take it into work as a BYO device, you can know it’ll have full Android Enterprise support.

For enterprise, I’ve validated each deployment scenario personally against my validation criteria and can say it’s one of the best-supported handsets I’ve tested so far, not hitting a single snag during testing – including zero-touch support and COPE.

Compared to the amount of issues I’ve found in other AER validated OEMs (irrespective of how quickly they’re resolved), it’s a breath of fresh air to have nothing to report back to BQ which suggests to me their QA is rigorous, and other OEMs could certainly take a leaf from that book.

I am also pleased to see the inclusion of NFC, something which is often left out of devices around this price-point for some reason, and as such benefits from Google Pay as well as additional enterprise provisioning capabilities.

On that basis, irrespective of whether you’re a consumer bringing the X2 Pro into an organisation in a BYOD capacity by leveraging the work profile which empowers both privacy and a work-life balance, or an enterprise looking for a device to deploy to your organisation, the BQ would be a good choice.

Conclusion

The Aquaris X2 Pro feels like a bit of an underdog over here in the UK, and I’d like to see it gain some real traction as it’s certainly warranted.

With great build quality, premium materials, a wonderfully clean UX and all the bells and whistles (plus a headphone jack) you could want, the X2 Pro offers a great device for the €389.90/€459.90 it retails at.

It is however in direct competition with the likes of the Nokia 7 Plus which offers a slightly larger screen and wider band support, but I think it likely comes more down to personal preference. Here’s a comparison of the two.

Opting for Android One was a strong move also, there’s clearly a large demand for clean UIs and fast updates; the likes of which larger OEMs simply can’t always compete with. Long may this trend continue!

The X2 can be purchased from BQ directly, or if you’re in the region, places like Amazon DE also.

One more thing..

As a side note, I also just want to take a moment to appreciate the SIM pin presentation:

I like to keep my SIM pins in their boxes, using them and putting them back often as I switch devices frequently, however with the mix of weird slot configurations some OEMs adopt, or just taping them in, this stood out to me as a nice, elegant solution that keeps it in place. Nice to see BQ paying this level of attention to their presentation!

Are you a BQ device owner? Are you planning to be after reading this? Would you consider the X2 Pro as an enterprise device? Let me know on Twitter, LinkedIn or in the comments below!

Hands on with Sony OEMConfig

2018-08-26T14:48:44Z

Configuration Extension has been discontinued

Sony unfortunately no longer support this once-promising OEMConfig implementation and the app has been removed from the Play Store. More details.

One of the most exciting announcements at Google’s Android Enterprise Summit back in May was OEMConfig; a new and exciting tool developed in partnership with Zebra for providing zero-day support for beskpoke OEM management APIs which sit over and above standard Android Enterprise APIs without requiring UEM vendor integration; everything is managed via an app, making use of managed application configurations via the Play API.

I’ve covered off the basics of OEMConfig both above and via a recent Search Mobile Computing article with fellow voices in the industry if you’d like to read more.

On Friday, Emiliano over at Sony shared an update mentioning the general availability of their OEMConfig implementation, Sony | Configuration Extension.

Weird naming of OEMConfig aside (a pretty common OEM thing, I guess), this is significant; being the first (I’m aware of) OEM after Zebra themselves to implement OEMConfig and in a way that shouldn’t be too complex for UEM platforms to display means this is ready to be adopted basically immediately (more complex implementations will require UI changes to accommodate in UEMs, for context).

Lets see how it works! Starting with MobileIron and a work-managed Xperia XA2:

Creating a label

Labels offer a simple and powerful means for grouping devices

This is a Sony application and will only work with work-managed devices; the app validates the device is work-managed, or errors as follows:

This is not a work-managed device

Due to this, it makes sense to create a label that:

Only targets Sony devices
Only targets work-managed devices

This is what I’ve created in the GIF above, naming it OEMConfig Sony WM/WMWP (where WMWP is Work-Managed Work Profile, my short-hand for work profiles on fully managed devices, or COPE).

Defining the configuration

While it doesn’t match the breadth of configurations offered by Zebra, Sony does add some useful options

Sony have out of the box created a number of useful configurations to apply to their devices. With support from Android 6.0+ and all devices across their lineup, OEMConfig can be utilised without having to worry about what can apply where.

At the same time, there’s a fair bit of replication on basic configurations you’d find in most UEM platforms, such as WiFI whitelisting, app black/whitelists, radio control and roaming settings.

In the above image I’ve opted to disable the home button, keep the screen on at all times, prevent shutdown/reboot and prevent access to settings.

What should be clear for anyone who has made use of managed application configuration to date is how familiar this process is. Like you’d configure an ActiveSync URL and credentials for Gmail, OEMConfig is configured in exactly the same way; the UEM queries Play APIs and displays all configuration options made available through the app. When a new version of the app is published with additional capabilities, they will show up automatically without any additional work required by administrators. Very powerful for zero-day support.

I would have liked to test the APN config options as they’re a pretty useful feature to have for pre-Pie devices! Unfortunately I don’t have a test APN to use, so I’ll come back to that in future.

If the GIF above isn’t clear enough, here’s a screenshot of the config in MobileIron:

Distributing the configuration

Applying the application to a label is required for the app to deploy

With the configuration saved, I now assign the app to my dedicated Sony WM/WMWP label. As it’s a standard Android Enterprise application I’ve already enabled silent installation and automatic updates. The app will now push automatically to the XA2 within a few moments.

(Temporary) manual activation

This will disappear soon enough, but two taps are currently required

Currently once the app is installed on the device, the end-user must tap on the app and activate it, much like many mobile threat defence (MTD) and similar applications today. This requirement will be disappearing in an update coming soon, meaning activation will be automatic and silent!

I was initially caught off-guard by the disappearance of the app, assuming maybe it’d stick around and within it I’d get a summary of enforcements (feature request!). The app likely won’t show up like this at all in future, but I do hope there will an area within settings that tells me what’s being enforced.

One thing to keep in mind, once the device administrator permission is granted (unlike DA deprecation, this uses APIs that won’t be affected next year), it cannot be revoked. This means the app can no longer be uninstalled and in fact, when I attempted to do so via MobileIron it resulted in a forever-loop of “this app has been removed” (but not really) notifications that ended with me factory resetting the device.

Results

Power off, restart, even turning off the screen: all blocked.

As soon as the app has the necessary permissions, configurations are immediately enforced. In the above GIF I was experimenting with some other restrictions such as disabling the back and recents buttons, as well as power/reboot and screen-off restrictions.

All together pretty successful! Something to note with MobileIron in particular: it can be pretty bad at applying config changes once the apps are deployed (I tend to uninstall/reinstall the app to force this, or else have to wait). As the OEMConfig app cannot be removed once activated (and activation will be automatic in future) any configuration changes will take a rather long time to enforce, potentially only sped up with a device reboot. It will eventually work though, and hopefully MobileIron will address this sooner rather than later. AirWatch, SOTI and other UEMs don’t seem to have the same problem.

The Workspace One UEM experience

With the app already added to my WS1 UEM console, all that remained was assignment. As can be seen, the WS1 layout is similar, if a little prettier, to MobileIron; one very big difference though being that while MobileIron will allow blank configurations, WS1 prefers they’re either configured or removed (X) which is why I spent time intentionally disabling some of those configs and outright removing others rather than leaving them unmodified.

A very similar result, working as expected:

BaytonAP is not a whitelisted WiFi network, so blocked from use.

Does it work with work profiles on fully managed devices?

No.

Despite it being targeted at work-managed devices, of which the work profiles on fully managed devices (COPE) certainly qualifies (and thus why I included it in the original WM/WMWP label), because the app is pushed into the work profile and not onto the device, the app complains and only offers uninstallation.

On a whim I installed the OEMConfig app manually outside of the work profile, however although it does allow me to activate it, as the config is only pushed to the work version of the app this has no effect.

As a corporately owned device it can be argued OEMConfig restrictions should be able to apply device-wide on COPE devices, and I’d certainly like to see some capabilities here.

Thoughts

This is a brilliant beginning to what I believe will fundamentally change how organisations manage Android devices in future, with that said there are definitely some areas of improvement for Sony specifically:

App management seems superfluous given that’s a basic UEM capability. The same goes for WiFi network settings and some of the restrictions currently offered.
Based on my own testing here, it’s not unlikely the app will be either accidentally or purposefully removed from devices in future, and that caused quite an interesting, less than ideal result.
There’s a distinct lack of Sony-specific restrictions in place. I was really betting on seeing management capabilities around Xperia backup, dynamic vibration, Sony themes/wallpaper/etc settings and much more.

Particularly on the last point, the whole idea around OEMConfig is to provide management capabilities on top of the base Android Enterprise solution as an OEM value-add, and proprietary solutions such as dynamic vibration or Xperia transfer which cannot be controlled via UEM policies today are perfect candidates for the OEMConfig solution.

In any case this is an exciting result! I hope this shows just how incredibly easy it is to configure devices with OEMConfig, pushing out a configuration as you would any other Android Enterprise application that supports them; with the power OEMs have over what APIs are exposed via OEMConfig and when, it’s really so much more powerful than the historic approach of hoping UEM vendors would implement APIs per OEM, and will really help level the playing field going forward.

What do you think of OEMConfig? Would you make use of it? Would the capabilities available via OEMConfig influence your purchasing decisions? Let me know in the comments, via Twitter or find me over on LinkedIn!

The state of Android Enterprise in 2018

2018-08-10T15:48:00Z

It’s been only seven months since publishing my take on the state of Android Enterprise in 2017, but a lot has changed already. With the release of Android 9.0 Pie, it’s a good time to take a look. I’ll cover new management features and programs from Google; how vendors, hardware OEMs, and customers have responded; and where this is all going. If you haven’t read my previous article, you might want to get caught up, but otherwise, let’s dig in!

Device admin deprecation

This is huge news for the industry: from what should be Android 10/Q in 2019, device admin APIs (the basis of legacy Android management) are being deprecated, and Android Enterprise management will be the only means for management. This will not impact devices running Android 9 Pie or older, however all new purchases and devices that are upgraded to Android 10/Q will not support device admin management.

What will be impactful, however, is the new Google Play requirement to align all applications to API level 26 (Android 8 Oreo). This went into force for new applications on August 1, and all updates to existing apps will need to align by November 1. With this change, unified endpoint management/EMM vendors (UEMs) will no longer be able to enforce admin-defined passcodes for example, as this was deprecated in Android 7.0 for security reasons, and will be the first device admin API to completely disappear in 2019.

For organizations managing Android devices, this means Android Enterprise should now be a priority; even if there are no plans to refresh the Android estate immediately, I advie having the foundations and experience in place sooner rather than later.

OEMConfig

With legacy Android management, UEM vendors had to integrate proprietary OEM APIs before customers could use them, which could be a pain. For example, it’s taken nearly seven months (so far) for some vendors to integrate Samsung’s latest Knox APIs. This is the problem OEMConfig sets out to fix.

Where Android Enterprise originally leveled the playing field to give all OEMs the same management capabilities, Google has repeatedly stated the AE APIs are only a base, and OEMs are welcome to add their own value-add APIs on top. The trouble is that history may repeat itself, with UEMs only supporting the proprietary APIs from the biggest OEMs, whilst the smaller OEMs get the cold shoulder.

With OEMConfig, the tables are turned: OEMs can easily publish their APIs into UEM solutions via managed Google Play configs. This uses one OEMConfig app that sits on the device, and one that is pushed to the Play Store. OEMs can provide zero-day support for all new management capabilities, and UEM vendors don’t have to lift a finger (well, beyond extending their managed app capabilities so that OEMConfig displays properly within their solution, but this is a walk in the park).

It’s a really significant solution I hope to see widely adopted soon, and I know that a few OEMs are already testing it.

New enterprise improvements in Android 9 Pie

As with every version of Android since Android Enterprise was introduced, Android 9 Pie has a healthy set of improvements.

A better work profile experience: Today both work and personal applications are mixed within the app drawer, and it often leads to questions from end users about why their applications are duplicated. With Pie, this changes. Technically, applications are still duplicated, but now they’re presented to users in dedicated work and personal app drawer tabs, which makes far more sense. There is also a new way to turn the work profile on and off, via a toggle in the work app tab.

Additionally, new APIs allow switching between personal and work accounts within apps without having to come out of a personal app and open the work profile, and vice versa.

Improved QR provisioning: QR provisioning for work-managed devices remains popular. In Pie, Google has built the QR reader into the device, and you can embed Wi-Fi details in the QR code. This means you don’t have to connect to Wi-Fi and download a QR before provisioning, saving a lot of time.

APN configuration support: This will be welcomed by organizations that rely on private APNs to connect to secure mobile networks, or to route traffic through an MTD solution.

Granular update control: If postponing updates by 30 days wasn’t enough, with Pie, organizations will be able to postpone them for up to 90 days, with 60-day cooling off periods between.

Shared device support and COSU: COSU support in Android up to now has been… well… manageable. With Pie however, Google is unleashing a massive update to how devices manage and support multiple users. In addition, there’s new native kiosk functionality that far exceeds what we’ve seen previously—many organizations may even opt for the native Android implementation over the custom EMM kiosk implementations we see in frequent use today. Time will tell.

Android Enterprise Recommended

Over the years, many organizations have asked for device recommendations, and more often than not it was an uncomfortable experience, because I couldn’t test every device on the market for compatibility with enterprise management. With the introduction of Android Enterprise, Google created the perfect environment for a new validation process to ensure that devices support it properly.

The resulting program, Android Enterprise Recommended (AER), has already made waves across the ecosystem—I have customers who now forego any device that isn’t part of it. As of June, the program had 39 devices from nine OEMs; it includes tablets as well as phones, and rugged devices, too!

There’s more to AER than just devices though, and later this year we should start to see similar validation for the wider partner ecosystem, such as UEM vendors and solutions integrators (this tying in with Android Academy, another recent Google effort).

Android management API

Launched in late 2017, the Android Management API (AMAPI) takes all of the complexity of Android management and rolls it into an always up-to-date cloud-based platform.

With only a Google Cloud project and a few API calls, it’s possible to have an AMAPI solution in place offering simple, flexible Android management and zero-day API support without needing to build out a whole UEM solution around it.

There was a lot of chatter at the Android Enterprise Summit around this, with UEM vendors interested to see how they could effectively leverage it. Microsoft is one of the first big players I’ve seen to bring a solution to market, integrated with their platform.

Partners are onboard with Android Enterprise

Now, let’s turn to the partner side. Many UEMs and OEMs have supported Android Enterprise for years (though some have only come more recently.) What have they done in response to the latest features?

MobileIron became the first (and still, the only as of writing that I’m aware of) UEM to support work profiles on fully managed devices, the coveted middle ground for Android management that I’ve been eagerly anticipating. (I even worked with MobileIron on their official announcement.) They’re also promoting Android Enterprise first during the first-run wizard in MobileIron Cloud.

VMware rebranded AirWatch to Workspace One UEM, and with it, introduced their Android Enterprise-first vision. All new customers will be prompted to set up Android Enterprise, with legacy device admin only available by explicit opt-in. VMware’s leadership in the UEM space adds a lot of weight behind Android Enterprise.

As I mentioned, Microsoft finally jumped all-in on the Android Management API to bring COSU support to Intune, which previously only supported the work profile. Work-managed (COBO) support is on the way as well.

OEMs like HMD Global are pushing really hard on Android Enterprise, with support built into their entire range of devices and everything from the Nokia 3.1 up to the 8 Sirocco being Android Enterprise Recommended.

Samsung, the most dominant Android OEM in the world, especially in the enterprise space, announced back in January that with the introduction of Knox 3.0, their unification with Android Enterprise was complete. This is significant! The support of a major player speaks volumes as to the importance of Android Enterprise going forward. (However, they’re still not onboard with programs like Android Enterprise Recommended, zero-touch enrollment, and OEMConfig.) As of writing, UEM vendors are completing their support, and AE-based Samsung capabilities are ready to be leveraged without fear of device admin deprecation.

Project Treble seeing real-world use

Another important OEM-centric innovation is Project Treble. Last year, I wrote: “With the introduction of Project Treble in Android 8.0, we should begin to see devices updated more frequently and for longer periods.”

Nothing demonstrates this capability any better than when Google debuted the Android Pie developer preview not only to their Pixel lineup, but also to several other OEMs as well, back at Google I/O in May. This has never happened before!

It was all made possible thanks to Project Treble, and has continued to impress with every developer preview that followed. At one point, it took Sony only a few hours following Google announcing beta 2 (DP3) to push out an update, other OEMs only a few days; that speed is almost unheard of and is only possible thanks to Project Treble.

As OEMs become more comfortable with Project Treble and blistering time to market for updates, you can imagine the effect on fragmentation (which can still currently cause problems) and version support this will have.

How customers have responded

Android Enterprise is still a new concept to many, but is really starting to pick up. In my last state of Android Enterprise article, I covered Project Treble, zero-touch enrollment and aggressive adoption by OEMs. So far, that’s all living up to my expectations.

I see it with customers and I see it with peers; the amount of interest my Android Enterprise documentation receives is increasing and the engagement I’m seeing over on LinkedIn, Twitter, and elsewhere when I post about Android Enterprise continues to grow.

It’s not too surprising; the announcement of the deprecation of device administrator APIs with Android Q/10 has certainly made some in the industry sit up and take notice; organizations want to know what they’ll need to be doing differently from next year, and a 10 times growth of Android Enterprise deployments (which Google announced back at the Android Enterprise Summit in May) reinforces this; the market is starting to pay attention.

Add to that the Android Enterprise-first approach the industry is taking and the continued growth of programs like zero-touch (with over 20 resellers, just under 20 UEMs, multiple OEMs, and over 30 devices supporting it today), quickly becoming a viable program for organizations across the world wanting seamless, hands-off, out-of-box enrollment of their Android estate, it’s clear to see why momentum is building.

Looking towards the future, I think we’re going to see a lot of usage for the Android Enterprise Recommended program. In addition, I think OEMConfig will lead the the rise of bespoke APIs. Without the previous hurdles, OEMs will take it into their own hands to provide unique and interesting new ways of managing their devices. Lastly, as more UEMs beyond MobileIron support work profiles on fully managed devices, we should see it push rapid AE adoption, as COPE is such a popular method of managing devices today.

Final thoughts

Again, everything in this article has happened in the last seven months, which I think speaks volumes in terms of Google’s commitment to Android Enterprise and the well-overdue sunsetting of legacy management.

There are many areas Android Enterprise can improve still today, feature parity being one of those, but the solution is rapidly maturing and has already been ready for adoption for some time.

I previously said there’s no reason Android Enterprise shouldn’t be the default for Android management in the not-too-distant future. Today, I’d say unless you’re actively waiting on COPE support from your UEM, there’s no reason you shouldn’t be investigating a migration to Android Enterprise right now.

As always, I’m excited to see Android Enterprise continue to evolve!

Want to learn more about Android Enterprise? Check out the documentation I’ve been writing on the subject or find me on LinkedIn and Twitter, where I talk all things Android most days.

BYOD & Privacy: Don’t settle for legacy Android management in 2018

2018-08-03T15:35:00Z

A lot of what I write about Android is geared towards corporate IT, CxOs, and other policy makers, to help them better the understand how Android enterprise can save time and money whilst offering a generally better experience for everyone involved. In this article, however, I’d like to focus on those arguably most impacted by corporate mobility strategies: the end users.

In 2018, users that take part in corporate bring your own device (BYOD) programs should no longer accept legacy device administrator management, due to the privacy and ownership issues associated with this outdated management model.

Legacy for a reason

Next year, Android management will be changing forever with the deprecation of device administrator capabilities in Android Q/10. Jack has written about this here on BrianMadden.com, I’ve written about it, and you can read Google’s official announcement, too.

The following summarises the main problems you face with legacy management as a BYOD user bringing a personally owned device full of private applications and data into a business environment.

But before we go any farther, an important note:

The following points are based on multiple conversations with UEM vendors (Unified Endpoint Management, which may also be called the EMM or MDM server, or similar) and my own experience. It’s not intended to incite fear, uncertainty, or doubt—rather only to provide awareness.

The likelihood of the following actually affecting you or your device remains low, and it’s highly likely exactly what can be seen and done with your device will be explained in a corporate mobile device policy

However, knowing the power you hand over to administrators should reinforce why legacy management should no longer be accepted.

All or nothing management

As I wrote in Google is deprecating device admin in favour of Android enterprise:

The device admin API is based on an all-or-nothing approach requiring full device administrative permissions in order to manage a device. This applies to both corporately-owned devices and BYOD, which is hardly ideal.

What this essentially means is when you enroll your personal device into a corporate UEM server, you are granting the administrators of that server full, complete control over your device.

They may lock it down more than you feel is acceptable (where did the camera go? Why is Bluetooth disabled?), wipe the entire device either accidentally or on purpose, prevent you from removing device management, reset your passcode, and more.

Because legacy device administrator management requires granting the UEM administrator rights over the whole device, once you’ve granted this power, it may not be easy (though it can be) to remove it again without resorting to a factory reset if permitted, or a reset via recovery if not.

This same logic can also apply to other apps such as email. By completing email account setup on the device, you’ll see the app request administrator rights.

Once activated, even the email app can wipe your phone, either via the UEM server or the Exchange server.

Administrators see a lot

Although UEM solutions offer privacy settings to prevent it, it’s entirely up to the administrators as to what information from a device is synchronized. Privacy-conscious organizations may have combed through the settings to ensure only device details used for minimal identification and management are synced, and some may even choose to anonymise the devices and only base their management on device posture (the device has not been rooted, and there are no potentially harmful applications (PHAs) installed, etc.).

On the other hand, UEM solutions with full administrator rights can theoretically suck up a considerable amount of personal information from a legacy-enrolled device, such as the following non-exhaustive list:

Full application list sync: Application sync is a basic feature of all UEM solutions. It can be used for good, such as for detecting PHAs, but it can also be bad. For example, if you happen to have private health or lifestyle apps you’d normally never discuss in a work environment, the UEM administrators can see them and potentially learn a little more about you they wouldn’t otherwise know.
Remote control: Depending on the UEM, under management it can be possible to silently view and control your device without your express permission. This can also extend to accessing the filesystem, something I’ve experimented with myself on test devices.
SMS/Call logging: Multiple UEM solutions can pull call logs from a device, and few can also do the same with SMS messages.

Once again, before you accuse me of spreading FUD, it’s important to note that just because the above can be done doesn’t mean it will be done. Your device could be one of hundreds or thousands under management in your organization, and there’s very little need to assume IT have the time or inclination to monitor your device over any other. Again, this is just to demonstrate the capabilities you are enabling by enrolling your device into legacy management.

Not everything works

Unless you’re bringing a Samsung into work, there’s no guarantee your device will be fully supported by the UEM. You may struggle to get email working on your native client; some policies may not apply or may cause unusual behaviour; and when there are issues, the organization may not be comfortable troubleshooting your device.

This is because the differences between OEMs are great enough that IT won’t be trained to understand every single model and device. As a result, it’s common to see organizations adopt a supported devices list, and if yours is not on there, you’re on your own when things go wrong.

With so many exceptional alternatives across all budgets from the likes of Sony, Huawei, and HMD Global (Nokia), it shouldn’t be required to knee-jerk towards the first Galaxy you see, but the chances are this may be required with legacy management.

A better way

With an Android enterprise work profile, all of the above concerns are no longer relevant. Why is this?

User privacy and control comes first

In What is Android enterprise and why is it used?, I wrote:

Android enterprise is able to create a managed user profile that although sits entirely separately encrypted on disk (and as of Android 8.0, utilises completely different encryption keys for work/personal), integrates directly with the current user on the device in order to provide both personal and work applications in the same app drawer – the latter indicated by a briefcase.

In other words, when you enroll your BYO device into a UEM solution that supports Android’s modern set of management features (called Android enterprise), instead of it taking complete control of your device, it creates a separate, work-only space (this is called the work profile). The UEM management policies are confined to this isolated area, and you’re free to use the rest of the device as you like.

There are exceptions, such as the enforcement of a passcode on your device, monitoring for a signs of compromise, and other arguably reasonable capabilities ensuring basic security, but the most important ones (factory reset, app sync, remote access, etc.) are simply not possible on your personal apps and data, and instead are limited to the isolated work profile (i.e. all your work apps) that the UEM manages.

Prioritising the work/life balance

One additional benefit to the work profile, over and above the obvious privacy and ownership benefits, is the focus on work/life balance. You can simply turn it off during evenings, weekends, and holidays, which means you are able to completely disengage from work with the tap of a button.

On a recent holiday I took, I used the opportunity to turn my out of office into another means for demonstrating this message:

Thanks for your mail,

I am not in the office this week and my Android enterprise work profile has been switched off to promote a healthy work/life balance, so emails will not be seen.

You can learn more about Android enterprise and how to promote a similar healthy approach to work here – bytn.uk/ae

Please forward your email to support for a faster response.

A little cringe? Perhaps. But it certainly demonstrates the capability of simply clocking off and enjoying life without the interruption of work when you’re not in the office, and I think more people should do the same.

A unified, consistent experience

Whether you pick up the latest flagship phone or something a little more budget-friendly, you can guarantee your device will work and behave the same way. There may be some visual differences in the UI (skin) of each OEM, but the actual flow? Reliable and consistent. If you’re on a budget, previously, the only choice may have been a low-end Samsung, but now you are able to widen your search to a far greater selection of devices with no concern.

The Android landscape

Right now, roughly half-way through 2018, over 66% of all Android devices in the wild are running Android 6.0 Marshmallow or greater.

Android platform distribution, July 2018, via developer.android.com

Why is this important?

From Android 6.0, which came out in October 2015, Google made Android enterprise support mandatory, so 2 in 3 devices currently in the wild already support it. (Arguably, this number is even higher if you count the so-so capabilities of 5.x, but I would avoid Lollipop in 2018).

In other words, there’s really no reason any modern device you pick up today with a reasonable spec won’t support the necessary functionality to support a dedicated work profile.

There are some exceptions—if you buy a no-name device from eBay, or something that is very low end (like with less than 1BG of RAM, or something that isn’t GMS certified, it might not work with Android enterprise work profiles. However, in 2018, for most BYOD users, encountering this situation should be extremely rare.

But is my device supported?

If you want to undertake due diligence before making the case to your employer for work profile support, there are easy ways to test this for yourself without needing to enroll your device into a UEM platform. Generally speaking, any GMS certified Android device running 6.0 or later with more than 1GB of RAM will be supported by default. A non-exhaustive list of examples can be found here, but just in case you wish to test for yourself:

Devices supporting dual app functionality: If you use a OnePlus, Xiaomi, Huawei or Samsung device (as well as some others) you may have noticed features such as Dual App mode or App Twin that allow the creation of multiple versions of an app such as WhatsApp for multiple account support on one device. If your device supports this, work profile support will be pretty much guaranteed. (Note that if you’re actively making use of this app cloning capability, you may find some UEM solutions will error during enrollment, telling you there’s already a work profile in place. To get around this, you’ll need to forego your cloned applications in favour of the UEM-managed work profile instead (sorry).)
Try the Android Test DPC: The Test DPC will allow you to emulate a device under management. Once installed from the Play Store, simply follow the on-screen instructions to create a work profile. When you’re done, the profile may be destroyed either in-app or via Settings > Accounts > Remove work profile. This is a little more technical, so don’t worry too much if you’re not able to make it work as it doesn’t necessarily mean your device doesn’t support a work profile.
3rd party solutions: Alternatively, take a look at applications like Island, as these can be used to achieve the same functionality (see “God Mode” in the above link).
Android Enterprise Recommended (AER): This is a validation program Google runs to confirm devices on the market are fit for enterprise use. While devices that aren’t Android Enterprise Recommended may also work fine in the enterprise, this is hands-down the easiest way to ensure your device is fit for purpose. If your device happens to be one of over 40 devices on the list, you’ll be ready to support the work profile. If you’re looking for a new device, it’s generally not a bad idea to check this list regardless, as it ensures your device will have have a reasonable spec. Don’t worry if your device isn’t in the list though, checks such as those above can be done also.

Speak to your organization

Enabling Android enterprise on any of the leading UEM solutions today takes only a few steps, after which IT need only create some basic configurations to define how the work profile functions, and then push out applications. They may decide you aren’t allowed to take screenshots within work profile apps, or share data from a work app to your personal WhatsApp account, for example.

Compared to legacy management, Android enterprise setup is a breeze, but if there are concerns, feel free to point your organization to my Android enterprise technical documentation to learn more about what it is any why it’s used.

Conclusion

It should be clear that legacy Android management is no longer suitable for the modern BYOD workforce when an obviously superior option is available, and as of 2018, now widely supported.

If your organization doesn’t support Android enterprise today, ask them why! With the minimal effort required in enabling it and the vast improvements to user privacy and device management (not to mention the upcoming deprecation of legacy management) all organizations should be seriously looking at Android enterprise.

Until that point, ask yourself if you’re willing to forego the privacy and control you currently have over your device to access email or internal business resources. I certainly wouldn’t enroll my own devices into legacy management today, instead opting for a corporate-owned handset which can be as locked down as the organization desires until Android enterprise becomes available.

Are you enrolled in legacy management today? Have you heard about Android enterprise already? Is your organization embracing or fighting the change? Let me know in the comments, Twitter or connect with me on LinkedIn. Feel free to reach out with questions across any medium also!

Connecting two Synologies via SSH using public and private key authentication

2018-07-16T10:48:38Z

Contributing author

This is one of a series of posts contributed to bayton.org by guest authors. Click here to learn more about Joel.

A Synology is basically a linux system in a small case and with a nice web interface that does most basic tasks. For the tasks which do not run by default from the web interface, SSH can be used. This tutorial demonstrates how to set up passwordless SSH between two (or more) Synology boxes. This is very useful for automated tasks, such as backups.

In this tutorial we will have a local Synology and a remote Synology. The local Synology will be able to connect over SSH without a password, to the remote Synology.

Prerequisites

Two Synology devices
SSH client installed on computer
- SSH is pre-installed on Mac and Linux
- Install Putty when running windows.

1. Enable SSH

On a Synology SSH is disabled by default, both because most users don’t require the service and because it offers one additional attack vector if otherwise unused. SSH must be enabled on both Synologies.

Sign in to the interface, open the configuration panel, scroll all the way to the bottom and click on Terminal & SNMP. Here you can click to enable SSH.

Warning: If you plan on accessing your Synology over the internet, instead of just over the network, I suggest you also enable autoblock once you are finished with this tutorial. I experience more than 1000 sign in attempts from unknown sources, per day.

You can verify if you did this successfully by connecting via SSH. Open the terminal and enter the command below. The username should be replaced with the username you use to sign in to the Synology. The IP address should be replaced by the IP address of the Synology.

ssh admin@192.168.0.2

If it asks for a password, you know you’ve succeeded with the first step.

2. Enable homes

User homes need to be enabled, because the private and public keys, which we are about to generate, will be stored in the homes of the users. User homes must be enabled on both Synologies.

Open the control panel, navigate to User, click Advanced, scroll all the way down and select Enable user home service.

### 3. Generate a public and private key pair on local Synology

You will now generate a private and a public key on the local Synology. Later on we will copy the public key to the remote device. The private key should never leave the local device. If someone gets hold of your private key, they can access the remote device.

ssh admin@local-synology

Generate the ssh key pair. Do not add a password on the key. Just hit Enter for every question that the program asks. Do not enter a password. Now a public and private key pair are created!

ssh-keygen -t rsa

4. Adjust file permissions on local Synology

Because a person with SSH access can do a lot of damage on a linux based system, SSH is very careful with the rights on SSH keys by default. As a security mechanism, SSH will not work without the correct rights assigned.

sudo chmod 755 /var/services/homes/admin
chmod 700 /var/services/homes/admin/.ssh
chmod 600 /var/services/homes/admin/.ssh/id_rsa

5. Copy public key to remote Synology

Stay signed in to the local device. Copy the public key to the remote device with the following command.

ssh admin@remote-synology "/bin/cat >> /var/services/homes/admin/.ssh/authorized_keys" < /var/services/homes/admin/.ssh/id_rsa.pub

6. Adjust file permissions on remote Synology

Again, the file permissions need to be set, but this time on the remote device. You can stay signed in to the local device, but this is not necessary.

ssh admin@remote-synology
sudo chmod 711 /var/services/homes/admin
chmod 700 /var/services/homes/admin/.ssh
chmod 600 /var/services/homes/admin/.ssh/authorized_keys

7. Adjust config file on remote Synology

Now the sshd file must be edited to accept public keys. By default this can only be done with vi. This is a complex editor, but you can also install the nano editor which is a lot easier to use, if desired.

ssh admin@remote-synology
sudo vi /etc/ssh/sshd_config

Three lines are important, which are shown below

RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

8. Restart ssh on remote Synology

Sign in to the web interface of the remote Synology. Navigate to Terminal & SNMP, uncheck SSH, apply. Check SSH and apply.

You should now be able to SSH from the local device to the remote device without a password!

Uses for passwordless SSH

There are a few great uses for passwordless SSH. First of all, it makes signing in easier, if you do this often. Also it is very useful for automated tasks, such as automated backups and system status dashboards.

Are you using passwordless SSH? What do you use it for? Let me know in the comments!

How to update Rsync on Mac OS Mojave and High Sierra

2018-07-09T09:53:01Z

Contributing author

This is one of a series of posts contributed to bayton.org by guest authors. Click here to learn more about Joel.

Out of the box, Mac OS Mojave ships with a 12 year old version of Rsync. The reason for this is that Apple doesn’t include anything released under GPLv3 or similar licenses.

Luckily, it’s relatively quick and simple to update Rsync using Homebrew.

Homebrew is a package manager not dissimilar to Yum on Redhat or Apt on Debian. You can follow the instructions in the above link, or just copy and paste the commands documented as follows.

Open the terminal and paste the command:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Homebrew will link most software to /usr/local/bin. However, the terminal may be looking in other folders first, so lets make sure that /usr/local/bin is the first line in our path list.

sudo nano /private/etc/paths

Now you are ready to install the new Rsync version, and can do so as follows:

brew install rsync

Once completed, you should sign out and back in to MacOS.

When entering the command below, you will see now that you are using rsync 3.1.3 (at time of writing), instead of rsync 2.6.9. You are no longer running a 12 year old version of Rsync!

rsync --version
rsync  version 3.1.3  protocol version 31

As simple as that.

Intune gains support for Android Enterprise COSU deployments

2018-07-08T14:42:45Z

This week, Microsoft edged a little further into the world of modern Android management with the introduction of COSU support for Android Enterprise deployments.

Up until this announcement, the only available options for organisations leveraging Intune were legacy management (device administrator) or work profile, an entirely BYOD-focused Android Enterprise deployment scenario only offering organisations management of a dedicated work profile on the device, and not the device itself (with a few security-related exceptions).

What is Android Enterprise?

For information regarding Android Enterprise, including what it is, the deployment scenarios stated below and how it can benefit organisations, have a read of What is Android Enterprise and why is it used?

Improved Android Enterprise support has been a long-requested feature for Intune and although this announcement will only quell those looking for kiosk-type deployments today, it’s an important first step towards wider work-managed (COBO) and fully managed work profile (COPE) deployments that’ll be developed next.

Few EMMs are opting to leverage the native Android kiosk solution today as it’s somewhat lacking in features and functionality. Much like MobileIron and ~~AirWatch~~ Workspace One UEM, Microsoft are no exception; rolling their own COSU launcher developed by the same team responsible for the consumer Microsoft launcher, it should offer a pretty good experience for end-users. With P around the corner it’ll be interesting to see if the custom launcher approach fades given the effort gone into improving the native experience, likewise if EMMs currently maintaining custom launchers will eventually switch to native and thus adopt a universal UX for COSU deployments cross-EMM. I’m not holding my breath, but it’s an interesting thought.

Interestingly, Microsoft are also the first I’ve actively seen utilising the Android Management API (AMAPI) to bring COSU support to market. AMAPI offers a simple, feature-rich solution for EMMs who can’t or don’t want to spend time building out a custom DPC for Android Enterprise management, and it makes sense that Microsoft, with only work profile implemented up to this point, would leverage it in order to have zero-day support for new functionality directly from Google, as well as benefits like Android zero-touch support out of the box.

What is Android zero-touch enrolment?

Learn more about the future of out-of-box provisioning for Android Enterprise work-managed devices: What is Android zero-touch enrolment?

While Microsoft aren’t listed on the zero-touch portal at the time of writing, it won’t be too long before Intune can be selected from the DPC dropdown when creating a zero-touch configuration, they’ve even got their DPC extras ready to go:

{
"android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED":<strong>true/false</strong>,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { 
"com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "<strong>YourEnrollmentToken</strong>" 
}
}

The above DPC extras may look different to Microsoft’s own, which is because at the time of writing they appear to be re-using the QR-based DPC extras, stipulating download location of the agent and such, which is not required. I’ve also added the system application toggle to the above, which is a useful option to configure.

Once again, a great start and I’m looking forward to seeing Microsoft build out the work-managed deployment scenarios further; with COSU sharing the same basic work-managed device implementation as COBO and COPE, it shouldn’t take too much longer to extend their offering, thus making Intune a viable player in the modern Android management ecosystem.

I get a lot of Intune related queries both in and out of work, and have had to understandably divert a lot of organisations away from Intune due to the lack of work-managed support for devices up to now. While COSU won’t suit all organisations, those who need it will finally no longer have to look for alternative solutions, temporary or otherwise.

This update will be rolling out to tenants as features normally do. For more information and to get started for Intune customers, check out this helpful Microsoft document, and look out for further updates from Microsoft over the next week. I may also post a few updates here or on LinkedIn once I’ve had the opportunity to try it myself.

Android for Work no more

The other noteworthy update this week is the change from Android for Work to Android Enterprise.

Almost 2 years after Google introduced the new name, Intune was one of few, for reasons entirely unknown to me, who were yet to do a find and replace on their solution to bring the branding in line. Now, that has finally been resolved.

Why does this matter?

Every document, solution or service that still references Android for Work contributes to confusion between Android for Work and Android Enterprise I regularly come across when talking to organisations; the sooner this is updated, the better for the ecosystem as a whole (as would Google not renaming things all the time, I know..).

Solid updates all around!

What are your thoughts on COSU support? Have you been waiting on Microsoft to provide support for it? Did you migrate to another EMM in order to manage Android Enterprise devices? Will you be moving back to Intune if so? Let me know in the comments, @jasonbayton on Twitter or /in/jasonbayton on Linkedin.

Android Enterprise Recommended: HMD Global launch the Nokia 3.1 and Nokia 5.1

2018-05-29T17:23:51Z

On the 29th of May, HMD Global introduced three new devices for 2018: the Nokia 2.1, the Nokia 3.1 and the Nokia 5.1

First, just because it’s equally worthy of a mention and I’d like to briefly touch on it, the Nokia 2.1 is a welcome upgrade to 2017’s Nokia 2, touting double the processing power and a larger screen on a version of Android far less resource intensive – Oreo Go. Those who have had any hands-on with the Nokia 1 will understand how well Oreo Go handles such minimal resources, so on the Nokia 2.1 it should fly through most tasks whilst freeing up more storage at the same time.

Oreo Go isn’t necessarily enterprise recommended today (it can support some Android Enterprise features if desired by the OEM) however should anything change in the future, the Nokia 2 would make for an interesting COSU type endpoint at a not-unreasonable $115 USD (varying by region due to taxes), though it certainly won’t be Android Enterprise Recommended. On that subject…

Nokia 3.1 & 5.1 – Expanding the Android Enterprise Recommended family

When the Nokia 3 and 5 launched in 2017, the two devices weren’t able to apply for Android Enterprise Recommended validation due to having only 16GB of storage; the AER requirements stipulate 32GB minimum. To be clear – the lack of Android One had no impact on AER for the Nokia 3 and 5. The Nokia 8 is an AER device, after all. In fact other than the storage requirement, the devices worked perfectly fine in all of the Android Enterprise validation I have undertaken, earning a seat in my pool of test devices for any Android Enterprise testing I’ve needed to do (and I do a lot).

HMD’s pivot from their pure, stock Android image to that of Google’s Android One offering compliments AER, giving enterprises the best of both worlds, as Andrej, HMD’s GM of Enterprise Business, said recently at MobileIron LIVE!. With the switch comes a guarantee of two years of OS support, monthly security patches and all of the other enticing features of the Android One platform. There’s a lot of reasons to like Android One.

Twitter has been awash with requests to Juho, HMD’s Chief Product Officer, since the pivot to Android One, asking when the 2017 fleet will equally switch over, however it was never meant to be – there are branding and other requirements for devices to be a part of the Android One program, and the original 3 and 5 didn’t meet them. That doesn’t mean there’s anything wrong with HMD’s own Android images, far from it! With a promise of the 2017 devices seeing Android P and monthly security patches rolling out to all devices irrespective of image, HMD has shown nothing but continued commitment to their whole estate.

With the introduction of the Nokia 3.1 and 5.1, HMD finishes the transition to Android One for all models, and with new hardware configurations, so too do the devices now meet all of the Android Enterprise Recommended requirements for validation!

Nokia 3.1

The Nokia 3.1 sees a bump in spec from last year’s Mediatek MT6737 to a MT6750, and while the original RAM and storage options are still available – 2GB and 16GB respectively – HMD have also launched a version with 3GB and 32GB which meet the AER requirements. It additionally sees an upgrade in battery capacity to support a slightly larger, 18:9 display, on-screen navigation and also comes with a 13MP camera sensor on the rematerialar in place of the previous 8MP shooter.

It’ll retail starting from roughly €139 for 16GB and €169 for 32GB (varying by region due to taxes) from June.

The only downside I see is the lack of fingerprint sensor again, which is often utilised in the enterprise to balance the frequent use of long, alphanumeric passcodes. Additionally the Mediatek chipset can be off-putting to some, however I found the 2017 model held up well under normal use and had no issues at all with provisioning for Android Enterprise deployments, so I see no concerns with its continued use (particularly since HMD say the new chips are 40% faster).

Nokia 5.1

The Nokia 5.1 equally sees a shift in spec, again launching with both the original 2GB and 16GB memory and storage configurations respectively, as well as the new 3GB and 32GB variant meeting AER requirements . Like 3.1, the 5.1 also moves to a MediaTek – the Helio P18 – and in doing so moves away from the old Snapdragon SoC. It ships with a larger 18:9 display however the battery decreases down to 2970mAh from last year’s 3000mAh. Finally, better optics are added with a 16MP shooter vs the old 13MP sensor in last year’s model and navigation again has been moved on-screen.

It’ll retail starting from roughly €189 for 16GB and €219 for 32GB (varying by region due to taxes) from July.

A display increase teamed with a battery decrease is usually not a great combination, but we’ll see how it holds up with the MTK chip soon.

Ready for enterprise deployments

With the devices being Android Enterprise Recommended, that means they are guaranteed to:

Receive at least one letter upgrade, O to P in this case (in reality they’re likely to see Q)
Receive 3 years of guaranteed security patches within 90 days of release by Google, however HMD strive for monthly.
Support zero-touch configuration

Further requirements can be found here.

HMD now boasts 9 zero-touch supported devices on the market, 6 of which are Android Enterprise Recommended. They creep past Sony who stand at 5 devices in AER to level with Huawei. For enterprises wanting to leverage Android this is great news as HMD now offer an AER device for almost every budget, and without the bloat and skinned UIs offered by almost everyone else on the market.

Today’s launch shows just how dedicated to enterprise HMD Global are, and I’m looking forward to getting hands-on with them in the near future!

Are you considering Nokia devices in your organisation? Or maybe a personal device? What do you think of the price points and the specs? Let me know in the comments below, @jasonbayton on twitter, or find me on LinkedIn.

Android Enterprise Partner Summit 2018 highlights

2018-05-18T18:25:26Z

The Android Enterprise Summit has been, for what I’d imagine anyone who’s followed anything I do online for a minute or two would agree for obvious reasons, one of my most eagerly anticipated events of the year. Although a lot of the content wasn’t necessarily new information for me, I did come away learning of a few new features heading to the Android ecosystem in the near future, as well as further details on previous announcements, particularly with the upcoming release of P.

There are some really good things to come.

Those of you who were around during the summit might have caught wind of the live-blog I was updating over the course of the two days, and the following therefore won’t be new information for you, however here are the highlights of the event that I felt were rather significant, either due to the focus and attention provided by Google, or for benefits to the wider Android ecosystem these features bring. Please try to see past the terrible photos!

First however, stats

Android Enterprise activations

Over the last 12 months, Android Enterprise activations have grown 10x when comparing devices under “modern” (that’s Android Enterprise, in case you wondered) management to this time last year.

10x as many devices sounds significant, and while I’m sure it is, we don’t know how much that really is as Google won’t release figures publicly (or under NDA, I did try my luck..).

What it does mean in any case is growth, and the continued growth of Android Enterprise-managed devices is both reassuring and exciting. Last I checked with Google, about 35% of Android devices shipped were under management, meaning there’s both scope to convert the existing 35% and reaching out to the other 65% of business-use devices, promoting the use of work profile, application management without Google accounts and more. There’s a big market out there.

Zero-touch growth

Although I missed the graphs David was showing around zero-touch growth the message came through. Despite resellers still being an active bottleneck for the program, zero-touch is getting bigger and more viable every day. At the time of the event we have 31 devices available through 9 OEMs, and resellers are coming aboard rapidly too.. they’re just not public yet. Due to the legal and contractual requirements from both sides, getting a reseller on board can take a little while.

The growth of zero-touch can also be directly attributed to the Android Enterprise Recommended program, referenced in the ZT slide below. Since AER makes it a requirement for OEMs to support zero-touch in order to take part in the program, it makes sense to see the rapid uptick from the 20-something devices available only a short while ago.

Potentially harmful apps continue to decline

On the other end of the spectrum, the work done by the Google Play Protect and Android security teams appears to continue to pay off, as we see the number of PHAs in 2017 drop to their lowest number, ever. If you’ve read through the Android Security Report 2017 the following slide will look familiar:

0.01% infection rate for Google Play application installations is pretty incredible. Not to mention the dramatic decline of PHAs installed outside of the Play Store also. When Android asks if it can verify applications installed from unknown sources, this is why users should be tapping yes*.*

As a reminder, Play Protect scans 50 Billion applications every day through the Play Store, crawling the web, 3rd party app stores and on each individual device. Using the intelligence it gathers scanning all day, every day, it has become quite a difficult opponent to work around.

More security patches, more often

Over the last year the number of devices receiving patches has increased by 30% to top 1 Billion in 2017. Once again bolstered by programs such as Android Enterprise Recommended and soon to be bettered once more with the introduction what looks to be mandatory patching written directly into OEM agreements:

“We’ve also worked on building security patching into our OEM agreements. Now this will really … lead to a massive increase in the number of devices and users receiving regular security patches.”

– David Kleidermacher, Google’s head of Android platform security

Even devices years-old and no longer receiving OS upgrades will remain secure.

There’s more..

There are more stats available over on the live blog! On to the highlights (in no particular order)..

Device Administrator deprecation

At this point I’m starting to feel like everyone has talked, at length, about Device Administrator deprecation since its original announcement back in December, however judging by the chatter around the event it was, is and will continue to be news to both customers and partners alike for some time.

Device administrator mode to be deprecated. Slow phase out, but preparation for migration can start now.#AndroidEnterprise #planning

— Colm Warner (@colmwarner) May 8, 2018

I’ve previously prepared to documents that cover both the deprecation of DA and preparation for a migration to Android Enterprise, so I won’t go into this too much*, but it is without doubt the most fundamentally important change for Android in the enterprise to be announced in many years; Android management is permanently changing for the better by leaving behind a rigid and broken security model that does little to deter malware and misuse for a more secure, more flexible, quicker and easier to implement, and more robust in its management capabilities – Android Enterprise is, as I’ve said many times even prior to the announcement, the future of Android management and is where organisations need to be if managing Android devices.

But it is going to be disruptive.

The simplest transition would be from Device Administrator to work profile, however in doing this organisations will lose control over the wider device and only manage a dedicated work profile. It doesn’t require a factory reset however, nor does it even require a trip back to the office for employees as it can be adequately managed with a verbose communications plan.

It’s the DA to work-managed deployment scenarios, those including work-managed itself (COBO), managed work profile (COPE) or dedicated single use (COSU), equivalent to three very common deployment scenarios in organisations today, that will cause problems as these devices will need to be brought back to base in a lot of cases in order to be wiped and re-setup. If an organisation’s reseller supports zero-touch, it may be possible to retrospectively add previously purchased Android 8.0+ devices into the corporate ZT console so as to automate the factory reset and reprovisioning of devices on the organisations behalf, however it’s likely better to take a gentler approach in swapping the devices out or allowing users the opportunity to take backups of personal data first.

While true many devices today will not see a Q/2019 Android update and therefore won’t be impacted by the changes (for as long as EMMs support legacy Android management), the likes of HMD Global have already committed to updating the 2017 lineup to P, meaning the 2018 lineup, with AndroidOne, may well see Q; as soon as those devices update in 2019 the EMM will no longer be able to managed them if DA is still in use. Organisations buying their devices therefore right now, today, should be in a good position to start transitioning immediately, with the next scheduled hardware refresh guaranteed not to support the legacy Device Administrator APIs.

*300+ words later.

Zero-touch EMM integration

I was pleased to hear of the work Google are doing to better integrate zero-touch with existing solutions. Those familiar with iOS management will know EMMs have been managing DEP devices and pushing DEP profiles from within the EMM for quite some time.

In future and once integrated into the EMM, there will be little need for admins to log onto the zero-touch console, which aligns with Google’s goal of minimising the number of consoles required for administrators.

Zero-touch integration is a highlight for me as it makes the whole process simpler again. No one enjoys having to manage multiple independent consoles so this should hopefully help to further increase zero-touch use across the industry by making it easier to centrally manage.

OEMConfig

OEMConfig is very likely the most exciting announcement of the event for me as the implications are incredible. To understand why, here’s a little history:

For many years, as long as device APIs in Android have been in existence, in order to leverage them from the MDM/EMM platform of choice they would have to be supported by the EMM itself. Admins may remember looking at a toggle, dropdown or other such attribute within a profile and seeing an indication of which OEM supported it by the small tags alongside: SAFE V3, Sony, HTC, etc..

Originally Android Enterprise made this much easier, as all EMMs could align to one set of APIs and everything could be supported in one go. The problem is, Android Enterprise wasn’t designed to limit the capabilities of OEMs, allowing them to add their own APIs at will as has been seen recently with Zebra and Samsung. As Android Enterprise is becoming more popular and OEMs are migrating away from device administrator to the Android Enterprise API set, additional APIs will become ever more popular in order for OEMs to offer their own value-add and differentiate themselves from their competition. This means we start facing the same resource vs demand justification struggle EMMs have succumbed to for years and thus the potentially slow (or non-existent) adoption of APIs, or prioritisation of one OEM over another.

This is where things dramatically change for the better.. Google and Zebra have been developing a means for API support to be moved away from the responsibility of the EMM and over to the OEM by utilising OEMConfig.

OEMConfig is a small application installed on the device by the OEM and used for exposing APIs to the EMM administrator via managed app config, the configurations set through the Google Play API no different to how Gmail, Chrome, and other applications are configured today. The admin needs only to import the specific OEM (or device) OEMConfig application through normal means (as would be done with any public app) and will then be presented, after enabling installation for Android Enterprise, with a list of device-specific restrictions or features.

The beauty of this, and why I think it will fundamentally change the way we manage devices in the future, is because once it sits with OEMs, the app can be updated on the fly to incorporate changes as the OEM implements them rather than waiting for EMMs to take notice.

Devices can launch complete with an OEMConfig app and a wide range of new API functionality supported on day zero!

More info on OEMConfig will be coming soon.

DPC migration

DPC migration isn’t new, having been announced some time ago, however the team expanded on the this quite significantly at the event; we now know in-depth how migration will work and what it could mean for both migration within an existing EMM (on-prem to cloud, native to AMAPI) and also between competing EMMs.

The scope for this functionality is pretty huge and offers what I’d likely consider to be the first true EMM migration tool offering zero end-user disruption for Android Enterprise devices. In terms of work-managed migrations, which will always get wiped when the old EMM releases management control of the device, this is huge. Zero-touch will go a long way towards making re-enrolment much easier, but it’s still a major hassle to wipe and start fresh. With DPC migration this will no longer be an issue as the device will remain under management at all times.

The main blocker to this functionality is the requirement for migration support within the existing DPC as this is where the process is initiated. Without that support the process cannot even begin.

However, where an EMM wants to facilitate migration between their own solutions or to the AMAPI, support will need to be implemented and can then be leveraged at will equally by other EMMs (at least, unless EMMs figure out a way of whitelisting the DPC that attempts to initiate the process).

It’s in the interest of EMMs to build support into their DPCs from my point of view, even where an internal migration isn’t a likely requirement; admittedly it facilitates the simple migration away from the EMM but on the flip side it’ll make it easier for organisations to equally migrate in. Focusing on the best experience for Android Enterprise should see more migrations in than out regardless.

Expanding Android Enterprise Recommended

When Google previously announced the AER program (covered here), the intention was always to expand further afield than only phones. At the event Google offered further insight into what’s to come, including carriers, ISVs and expanding the program out to more devices, namely tablets and rugged:

This expansion out to additional partner types is still very much under development so was more of a reiteration (in terms of what I can share at least), however on the device front we’re seeing some tangible progress.

I won’t go into detail on the rugged as there’s an announcement from Google incoming, but it’s certainly interesting to see tablets also being validated.

Based on previous talks with OEMs, my experience at MWC, and a little process of elimination, it seems Huawei are likely going to be the first OEM to get AER certification for their MediaPad M5 series of tablets.

I’ve mentioned this over on LinkedIn also, since Huawei are

Already AER certified
One of a miniscule number of OEMs with a tablet offering today* (such as the MediaPad M5 I’m writing this article on)
Likely the only one to support zero-touch

…it would make sense they’d equally submit their tablets.

What the tablet requirements look like I’m not 100% sure, but unlike rugged devices which will have to really show some commitment to device support, I’d imagine the more generic business-use tablet case isn’t a million miles from phones.

*Untill I convince HMD to develop a tablet!

Improvements to COSU

This falls under the domain of Android P, but I’ve not updated my original Android P article to reflect the new announcements at the event just yet, so I’ll do so here:

Google have been focusing really hard on the single use scenario for P, and while I’ve covered off things like ephemeral users in other posts, the new and improved native kiosk which includes both single app and multi-app support is a rather exciting feature.

I’ve been deploying both the AirWatch Launcher and the MobileIron Kiosk frequently for customers, however unlike other aspects of Android Enterprise, this means the UX is different depending on the EMM you use. Combined with the additional restrictions coming in P, the native experience looks like a viable alternative.. if EMMs choose to support it.

EMMs and other partners will now not need to worry about developing a kiosk solution for Android Enterprise (they didn’t anyway technically, but the native AE kiosk was nothing to write home about), but given the amount of R&D gone into custom kiosk development, particularly for Workspace One UEM (AirWatch) that has only recently really come to market with a COSU offering (and improvements to it in 9.4), we’ll have to see what happens.

Project treble

Finally, I just wanted to take a moment to touch on Project Treble.

Again this is not new having launched with Android Oreo, but was thrust squarely into the spotlight at IO this year (which spilled over into the AE summit also) when the launch of the Android P beta came to multiple devices at once for the first time in the history of Android.

It’s a significant achievement showing just how groundbreaking the feature is, bringing updates to devices faster and easier than ever before, whilst improving the overall security of devices in the process by isolating low-level components (see image above).

I’m running P on my Nokia 7 Plus and never would have considered the thought of seeing it on anything but the Pixel before the announcement.

It’s pretty incredible.

To understand the effort involved with Treble vs without I’ve reached out to an OEM I work frequently with. I’ll add some comments here if I get the green light!

Conclusion

As titled I’ve only covered what I considered highlights of the event. For a greater overview of the whole two days please check out the live blog which will remain available indefinitely.

As I hope is pretty obvious, the Android Enterprise Partner Summit this year was significant; as much in terms of the early look at Android P as the progress the platform has made across the world in adoption rates, security, and general visibility within the industry.

And this is only the beginning.

Did you attend the event? What were your highlights? If you were on the fence about Android before, how do you feel now? Let me know in the comments, @jasonbayton on Twitter or on LinkedIn!

Live: MobileIron LIVE! 2018

2018-05-16T05:41:41Z

I’m attending MobileIron LIVE 2018 on the 16th and 17th of May.

Follow along below, or feel free to head over to the Discuss topic for live updates.

I’ll be arriving a little late so will miss the opening, but I’ll look to circle back around to that when I get there.

Something to say? Questions for the MobileIron team? Leave a comment below and I’ll aim to answer!

Android Enterprise first: AirWatch 9.4 lands with a new name and focus

2018-05-14T19:57:49Z

Earlier this month, VMware announced version 9.4 of their popular UEM solution and with it, both a stronger focus on Android Enterprise and a rebranding exercise to bring the platform closer in line with VMware’s range of other products:

VMware Workspace ONE UEM. Rolls off the tongue, doesn’t it?

This update therefore bids farewell to the AirWatch name, brand and colour scheme of old, other than the odd references here and there, and completes the brand unification that I imagined would be somewhat inevitable following the AirWatch acquisition some years ago:

The rebrand has certainly raised a few eyebrows across the industry, however in reality the name change doesn’t mean a significant amount on its own; rather it’s far more important to understand the recently published licensing changes. The way VMware explained the change to me at the recent Android Enterprise Partner Summit, many customers should end up better off as the numerous colours are dropped in favour of fewer WS1 options, I’d encourage organisations to take a look sooner rather than later in any case.

On to Android Enterprise, 9.4 introduces a first-look at VMware’s shift to Android Enterprise-first with a few new features and requirements:

New deployments will be prevented from enrolling legacy Android devices (device administrator enrolment) by default without explicitly opting in to legacy enrolment
Android Enterprise setup has been added to the first-run Wizard for new deployments
Terminology has been modified to the following:
- Device administrator > “Legacy Android”
- Android Enterprise > Android
Creating profiles will now require choosing between Android (Legacy) and Android, the previous two step workflow has been retired.
COSU (corporate owned, single use) functionality has been added to the launcher in order to reduce the possibility of escaping the kiosked environment.

If you’ve been paying attention to the VMware blog, the previously-announced deprecation of app search functionality for legacy Android enrolments (the Play Store Integration Service) isn’t listed in the changes above, this is because the rather disruptive change is not being implemented until the end of 2018, offering plenty of time for organisations to migrate to Android Enterprise ahead of time.

Console changes

For existing AirWatch customers you may be wondering how you’ll be affected..

You won’t.

Well, at least in so much as preventing legacy Android enrolments. If your organisation has previously deployed Android devices without taking advantage of the newer, more secure, simpler and more flexible way of managing Android devices, that explicit opt-in will have already been completed during the upgrade process without any manual intervention.

This change is only targeting new deployments in order to ensure Android Enterprise is very much front-and-centre when getting the tenant set up for Android management. Here’s what that new wizard looks like:

And clicking on configure Android EMM Registration:

If an organisation wants to permit the enrolment of legacy devices, the admin can find the relevant setting in Groups & Settings > All Settings > Devices & Users > Android > Android EMM Registration. On checking the box Deploy Android without registering with Google, WS1UEM will present a warning as follows:

If this option remains disabled, end-users attempting to enrol a non-Android Enterprise device will see the following error after authenticating with the WS1UEM server:

Beyond that, there will be more subtle changes, as mentioned above, in the terminology used and the way profiles are created going forward. VMware explain the terminology changes as follows:

Android for Work has been renamed to Android and is the default deployment method for new enrollments. The legacy Android platform will now be referred to as Android (Legacy).

In practice, with devices enrolled via both device administrator and Android enterprise methods, I saw no obvious “face value” indication which is which outside of the organisation group they were enrolled into:

It does become clearer on the profile side however. This is what admins will be greeted with when creating a profile going forward:

Notice the two Android options? Here’s how the profiles will look when configured, note the “(Legacy)” added at the bottom there:

One thing I did expect to see was a bit of logic. The screenshot of profile creation above for example is from within an organisation group in which Android enterprise is not configured, yet I can still try to create “Android” profiles. It fails of course:

But It’d be much better, I think, to hide those profiles that’d essentially do nothing when configured as I’m sure this will lead to support calls regardless. On the other side, within an Android enterprise-configured organisation group, it’s possible to create legacy Android profiles and no warnings are presented. Again, hiding this would both look cleaner and avoid any confusion whatsoever.

COSU Support

A feature I’m rather excited to see is full COSU support. The new update brings with it more granular control over the Launcher (Kiosk) experience:

I’m excited to do some proper work around this, as preventing access to the underlying OS is a frequent request in kiosk deployments. The Single App capability already gives it a leg up over the likes of MobileIron today and an answer to iOS native single app mode, so with more control this should be quite a powerful solution.

I’ve done a little experimentation on a Huawei MediaPad M5 and the experience is OK, though on that device at least I still see everything even if things like swiping down to get to notifications is possible, but prevented about mid-way through sliding the shade down the screen. More testing required. Launcher is making full use of app pinning to make this work, a solution that’ll become far more flexible with Android P later this year!

Conclusion

9.4 will begin rolling out to customers over the coming weeks to shared SaaS and dedicated SaaS customers. On-prem customers, feel free to get in touch with your VMware contact or partner in order to discuss how you can upgrade. Looking for a partner to help you through the upgrade or transition from legacy Android to Android enterprise? Get in touch.

Are you an AirWa.. err, VMware Workspace ONE UEM customer? What do you think of the changes? Will you be making use of the new features? Are you going Android enterprise first in your organisation? Let me know in the comments (login via your preferred social network!), via Twitter @jasonbayton or on Linkedin via /in/jasonbayton.

Live: Android Enterprise Partner Summit 2018

2018-05-07T16:25:07Z

May 8th marks the first day of the Android Enterprise Partner Summit, offering attendees a wide array of talks, demos, and information across two dedicated tracks (technical & go to market).

Given the success of 2017’s summit (see reference for that here) I’m super excited to be attending.

As a bit of an experiment and a first of its kind for the site, I’m going to be live-blogging the event (not religiously, but certainly highlights) throughout day one and two. The feed for that is below!

For live updates without refreshing the page and to get involved with questions or comments, head on over to the Discuss topic. I’ll do my best to direct questions to the right people or answer accordingly!

Want to get in touch via other means? I’ll be on Twitter throughout the event also.

Samsung, Oreo and an inconsistent Android Enterprise UX

2018-04-17T17:30:38Z

Oreo was released to the public last August; by Christmas I had a selection of Android 8.0 devices to hand and as of last week only 20% of my Android estate was not running 8.0 or above, one of which was my Note 8 which had been seemingly permanently stuck on 7.1.1 and failed to get any security updates beyond Jan 2018.

On Sunday evening however I did one of many weekly manual update checks since the announcement of Oreo for the Note some time back, and finally the upgrade had arrived (with last month’s security update – March 2018) with Samsung Experience 9 in tow.

I’d heard and read Samsung were fiddling with the Android Enterprise work profile experience, some EMMs have even published KBs warning of the changes, but of course I reserved judgement until I received and tested it for myself. Here’s my experience as a work profile user:

Upgrading with an existing work profile

Removing app shortcuts

For some reason, and this is a situation I have never experienced on a device upgrade before, work application shortcuts from folders on my homescreen had been inexplicably removed. I maintain a consistent homescreen, give or take, across all devices I use, so noticed this immediately upon reboot:

It’s very easy to put these back where they belong, but a pretty silly bug to have to encounter.

Hidden work notification content

Again, despite permitting work notification content to be shown normally, by default it had been changed to hidden and presented the following instead:

With the notification came an indication of the new changes afoot, I’ve never needed to “enter Workspace” before. Furthermore, it took a bit of fumbling around Workspace settings to locate the notification contents settings and return it back to how I had it.

A new work app indicator

Personally this seems unnecessary, but when a work application is opened, Workspace now adds a small triangle in the bottom corner to indicate the app icon with a bright orange work badge you tapped to launch the app, is still a work app after launching:

Multicolour work badge

Following the upgrade it appears Workspace didn’t know whether to colour the work badge orange or blue:

It adds a bit of colour to the app drawer in any case. After re-enrolling however they all went blue. Goodbye orange briefcase! I’m thankful at least to see Samsung didn’t change everything and left the work applications displaying in the app drawer after the upgrade.

On removing and re-enrolling the device

Convinced with the experience above was a bit buggy, I figured I’d take the opportunity to ditch the work profile and re-enrol for a fresh Workspace experience.

Work apps are now hidden by default

Within the app drawer there’s a new icon for Workspace, before tapping there you won’t see your work applications:

As an isolated feature I don’t mind this at all. Organisations have asked many times in the past why their users see duplicate applications and is one area of improvement for Android P. As an unexpected change to the UX though it could well initially be a tad confusing. It is however easy enough to revert back:

It’s also worth noting this “feature” only appears to work with the Samsung launcher. Nova, my launcher of choice for all of my BYO devices today, showed the work apps with a badge irrespective of whether that setting was toggled or not. Considering work profile is very much a BYOD tool, I’d have thought it would have been better QA’d with other popular launchers.

Notification content is hidden again

Likely a limitation of the EMM I enrolled with, but once more notification content defaults to hidden and has to be manually permitted via Workspace settings.

Moving away from a consistent UX

Samsung continues the march to make themselves different from everyone else on the market with the switch from work profile to Workspace for Android Enterprise deployments. Workspace is obviously not a new solution as it’s been around for years prior to the Android Enterprise/Knox unification and offers a nice value-add for paying customers over and above the standard Android Enterprise work profile. Depending on where an organisation comes from though – be that Samsung’s Workspace with Device Administrator management, or containerisation via any other means – it could either feel familiar, or bizarre. Given Samsung have supported work profile natively for a long time and that’s been the only option for work profile deployments, I’d lean towards the latter.

Based on my own lukewarm experience upgrading to Oreo and Knox experience 9, this is not going to be a smooth upgrade for many, and just as EMMs have published documentation warning of the changes, so too will organisations need to prepare their users and be prepared for unexpected changes, bugs and more.

The recent launch of work profiles on fully managed devices means Workspace will no doubt end up in use with work-managed devices. For every other OEM however, organisations will have one, clear, reliable user experience. Just as with the lack of zero-touch support today, I wouldn’t be surprised if the thought of managing Workspace and work profiles would be enough to reconsider Samsung when organisations look to purchase new devices, if the Android Enterprise Recommended requirement hasn’t done that already.

Time will tell.

Have you upgraded to Oreo? Seen and experienced Workspace first-hand? What do you think of it? Let me know your thoughts in the comments, @jasonbayton on twitter or @bayton.org on Facebook. If you’re on LinkedIn, you can also find me there – /in/jasonbayton.**

MobileIron launch Android Enterprise work profiles on fully managed devices

2018-03-27T10:09:13Z

Today, with the release of Core 9.7.0.1, MobileIron officially introduce support for work profiles on fully managed devices.

Work profiles on fully managed devices (further referred to as managed work profile) is the fourth and final deployment scenario (far-right, pictured below) for Android Enterprise and the one I’ve been waiting for since its announcement last year! For those unfamiliar, managed work profile is the equivalent of COPE – Corporate Owned, Personally Enabled – which has also gone by the name of COMP (Corporate Owned Managed Profile), WMWP (Work-Managed Work Profile) and likely other names/acronyms as well.

Image from What is Android Enterprise and why is it used?

Why is it important?

Prior to today, when provisioning an Android Enterprise device an organisation has had two deployment scenarios to choose from: work profile and work-managed. These scenarios, while suitable for a number of applications, offer what is essentially two extremes.

Work profile is an approach akin to BYOD management; the organisation has control over a dedicated corporate profile with the capability to enforce basic security on the wider device, but little else. The end-user has full control over the device.
Work-managed is the COBO approach to management; the organisation has full control over the entire device, offering no personal use by default.
Work-managed also extends to COSU, offering capabilities to further lock the device down to single-use.

Arguably that’s either potentially too open or too restrictive for many organisations, and given the default approach to Device Administrator (or legacy) enrolment has been more centred around the COPE model with varying degrees of restrictions, it’s easy to understand why.

Up to now the work-around has been to permit the addition of Google accounts within the work-managed environment, however this is a “solution” I’d recommend strongly against as it effectively mixes corporate and personal data, something organisations should absolutely not be considering; given legacy management has had containerisation for a number of years with the likes of MobileIron AppConnect, implementing this would be a giant leap back in terms of security and data isolation.

With today’s release that is no longer going to be a concern.

How it works

Once updated to 9.7.0.1, organisations will see a new option within the Android Enterprise mandatory configuration for managed work profile as follows:

There’s a bit of a change with the Lockdown Policy too, however this looks to be mostly wording, layout and the addition of yet more nested tables (I feel like this layout could be improved). Below shows 9.7 (left) against 9.6 (right), the basic options remain similar:

After Enable Managed Device with Work Profile on the devices is selected and the configuration is saved, when provisioning an Android Enterprise device to be work-managed using any of the typical provisioning methods (QR, NFC, DPCi, zero-touch) the device will be prompted to create a work profile after enrolling, leaving the parent profile (or device) untouched for later personal account setup.

In terms of UX, it’s honestly just a straight-forward mash-up between a work profile and work-managed deployment.

The key differentiation once the device is enrolled when compared to either existing deployment scenarios is having full control over both the device and the work profile! Organisations can therefore enforce any one of these or more restrictions, while permitting personal use on the device and maintaining a strict separation between work and personal data and applications, with each profile independently encrypted on disk:

Allow camera
Allow safe boot of the device
Allow factory reset
Allow the user to mount physical external media (e.g, SD card)
Allow the user to transfer files over USB
Allow use of USB storage
Allow SMS
Allow outgoing calls
Allow Wi-Fi
Allow Bluetooth
Allow mobile network to be configured
Allow tethering and mobile hotspots to be configured
Allow VPN to be configured

Prerequisites

Android Oreo (8.0) or above
GMS-certified devices
MobileIron Core 9.7.0.1
Mobile@Work 9.7

Demo

The below Sony Xperia XA2 is provisioned with a QR Code (off-screen) with system applications enabled.

https://www.youtube.com/embed/AcX-R1Yqx6c?feature=oembed

What organisations should be aware of

With the new deployment scenario comes a few recommendations and things to keep in mind.

1. Work-managed migrations are not supported

Just as it’s possible to migrate from a legacy Device administrator enrolment to work profile with a simple configuration change on the EMM server, so too is it supported to migrate from work-managed to managed work profile.

Unfortunately, MobileIron doesn’t support this with the release of 9.7.0.1, meaning in order to migrate from work-managed the device will need to be factory reset and reprovisioned. If the organisation utilises zero-touch this is a relatively simple process and combined with managed app configs the re-enrolment can be quick and painless. If zero-touch isn’t available just yet, utilising a QR code offers a balance between enabling remote reprovisioning while ensuring the relevant features are available (more below).

Furthermore, toggling the Enable Managed Device with Work Profile on the devices checkbox will have no effect on enrolled devices, only those enrolling after the configuration is saved.

What is zero-touch?

Did zero-touch catch your attention above? Not quite sure what it is? Check out What is Android zero-touch enrolment?

2. System applications should enabled

Normally for work-managed deployments, system apps are disabled to remove most of the unnecessary or unwanted bundled apps. As the device is being provisioned for a COPE environment, it makes sense to leave system applications enabled unless there’s good reason not to do so.

Disabling system apps will result in a device utilising a minimal number of applications, only enough to ensure the device works, requiring the end-user heads to Google Play in order to get the applications they desire. This could result in additional and unnecessary effort, as well as increased data costs for those primarily utilising data.

DPC identifier enrolment (afw#mobileiron.core) does not support enabling system applications and so NFC, QR code or zero-touch provisioning should be used instead.

Provisioning guides

Provisioning guides for the managed work profile deployment scenario can be found here: Android Enterprise provisioning guides

3. Retiring/wiping a device will initiate a factory reset

Unlike Device Administrator enrolment, when sending either a retire or wipe command, the following happens:

Work profile: The work profile is removed and the device is left untouched
Work-managed: The device is factory reset

As the devices utilising managed work profile will fall under the work-managed category above, whether a retire or a wipe is sent, the device will initiate a factory reset. All personal data will be lost unless backed up.

4. There’s no end-user wizard

When end-users complete enrolment, they will be returned to the home screen of the work-managed parent profile. Normally when setting up a new device the end-user will be taken through a wizard offering account addition amongst other things. This will not happen and therefore users will need to manually add a Google account through device settings (some exceptions exist, such as Pixel which offers to continue setup when opening settings).

An example of this is provided by my work profiles on fully managed devices provisioning guides.

5. Reassess label assignment

For organisations that have implemented one universal Android Enterprise configuration for all AE-capable devices, it will now make sense to start managing these via more complex labels integrating Active Directory groups, custom attributes or other means of separating the work-managed devices from those that will support managed work profiles. This hasn’t been otherwise required up to now as the two main deployment scenarios are invoked via different provisioning methods.

NB: G Suite accounts aren’t supported

If end-users within the organisation utilise G Suite accounts privately, adding them to the parent profile will result in Google Play becoming managed and limiting application installation to only those approved by the G Suite admin of the user’s private domain. It’s an unlikely scenario, however given private groups and individuals utilise G Suite as well as businesses, it’s possible this may cause a temporary issue (removing the account and adding a non-G Suite account instead will resolve this, but purchases will not be available).

Additional features

In addition to managed work profile, MobileIron have also introduced:

Self-hosted private apps (on managed Google Play)
Android Enterprise system update policy

Self-hosted private applications allow administrators to privately host APKs with MobileIron, whilst leveraging Google Play for distribution. This will be a welcome addition for organisations not wishing to push their in-house applications into Google Play itself.

An introduction to managed Google Play

Interested in learning more about managed Google Play? Check out my article for Brian Madden: An introduction to managed Google Play

Admins can simply import the APK file into Core, tick the box to install for Android Enterprise and finish. Once generated, admins will need to download the APK Definition file, extract the license and paste it into the provided area before saving.

As simple as that! More information can be found on Google’s help pages here or on my Introduction to managed Google Play over on Brian Madden.

For organisations managing Samsung devices, the system update policy will sound familiar; with this feature organisations can now control system upgrades on Android Enterprise devices directly from the MobileIron admin console:

It’s now possible to enforce upgrades automatically, set an update window to ensure system updates don’t interfere with BAU activities, or postpone up to 30 days for testing and verification. A welcome addition to make update management just a little easier for the wider Android ecosystem.

Did you know?

From Android P it’ll be possible to postpone updates for up to 90 days! Learn more about Android P: Android P demonstrates Google’s focus on the enterprise

Conclusion

I believe managed work profiles are possibly the most important deployment scenario Android Enterprise offers for the non-rugged market. Understandably Google chose to first concentrate on the BYOD (work profile) and fully managed (COSU, COBO) deployment scenarios in order to tackle two large market segments, however with 78% of business-use device shipments being Android last year (Source: IDC) and still only ~35% of these devices being under management, there’s a very large market of both new and existing organisations who’ll want to take advantage of work profiles on fully managed devices over the existing option; when I talk to organisations it has often been the type of deployment scenario they’re keen to adopt and, until today, one they haven’t been able to adequately replicate with Android Enterprise.

Knowing organisations can migrate from Device Administrator to Android Enterprise managed work profile without sacrificing either organisational control or personal usage is going to have a dramatic impact on Android Enterprise deployments going forward.

Ready to get started? Check out the new work profile on fully managed devices provisioning guides over on Android Enterprise provisioning guides and contact your MobileIron solutions provider to learn how you can upgrade to Core 9.7! To learn more about Android Enterprise in general, head over to Android to read all the documentation created to date.

Android P demonstrates Google's focus on the enterprise

2018-03-21T09:11:14Z

Just over a week ago Google released the first Android P developer preview.

It’s a good one.

On the consumer side, Google introduced a nice slew of features that have been extensively covered by mainstream media, including:

The mild design tweaks (it’s all very rounded now)
The improvements to notifications
New, long-overdue restrictions for the camera(s), microphone(s) and sensors when an app is idle
Multi-camera support
Display cutout (notch!) support

.. unsurprisingly I found myself far more interested in the changes, additions and improvements for Android Enterprise that come with P.

There are a lot.

In fact, it’s probably safe to say this is the most enterprise-focused release of Android to date; the primary reason it’s taken over a week to publish a post about the changes in P has been due to the amount of testing I’ve been doing! Here are some highlights:

1. Improved separation of work and personal applications

Today when deploying either work profile or work profile on fully managed devices into an organisation, the work and personal applications are fully mixed together within the launcher. While not overly problematic, it has been a source of feedback for Google (and myself via customer deployments) with end-users asking why their applications are duplicated.

Obviously with this change the application duplication itself hasn’t been addressed (and I’m OK with that), but the stock Google launcher now features a distinct separation between work and personal apps (pictured), making it much easier to differentiate whilst significantly reducing the cluttered feeling of seeing duplicate applications in the app drawer.

Just in case you’re wondering, the personal & work tabs don’t show up unless a work profile is present.

If the stock launcher would also introduce swipe gestures and manual backups for layouts, I’d finally consider letting go of Nova launcher because this implementation is nice.

2. More ways to toggle the work profile on and off

Tying into the separation above, Google also added new options for toggling the work profile in P.

Being able to turn the work profile off for BYOD users is something I believe to be quite important; when a device is shared between work and personal usage there’s a natural tendency to fall into the always-on culture that offers little time to switch off.

Google’s earlier introduction of the work profile toggle enables users to literally turn off work and be entirely left alone until it’s switched back on, but being hidden up in the quick settings means it’s often forgotten about.

While it’s being used in the stock launcher (pictured), APIs becoming available mean any application with the permission MANAGE_USERS or MODIFY_QUIET_MODE will now be able to modify the work profile state, whether through a toggle or otherwise.

I’m quite pleased to see more attention being given to this.

3. Simpler switching between work and personal accounts within apps

The focus on the work and personal split continues with this next simple, but massively impacting change; it’ll be possible (once applications support it) to switch between work and personal profiles from within apps directly.

Today if you have a personal account and a work account (via the work profile) in an app like Gmail, you’ll need to actively switch between the work and personal instances of Gmail on the device (pictured). Once support is available, switching between work and personal email accounts will be as simple as switching between multiple accounts within a profile is today.

This change is more about adding dynamic shortcuts between the two versions of the application, so this change will have no impact on EMM-enforced DLP controls, separately encrypted work/personal app storage or anything else that has been put in place to secure corporate data.

4. Easier QR code provisioning

Up to Oreo 8.1, when provisioning a device for enrolment using a QR code, a few time-consuming things happen:

You need to input Wi-Fi details
You must wait for the QR libraries to download and install before a QR reader will open.

With P, both of these issue are resolved.

Wi-Fi configuration details can now be embedded into the QR code, a raw example as follows (highlighted in bold):

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.mobileiron/com.mobileiron.receiver.MIDeviceAdmin",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM":
"S-21kvHAUKM0Uy7Ps7oBI4s8XPoH9QldPSWTj_cwXS4",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
"https://home.bayton.org/download/mobileiron-MIClient-latest.apk",
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
"android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED":false,
<strong>"android.app.extra.PROVISIONING_WIFI_SSID":"BAYTONwifi",</strong>
<strong>"android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE":"WPA",</strong>
<strong>"android.app.extra.PROVISIONING_WIFI_PASSWORD":"wifiallthings",</strong>
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
"server":"core.bayton.org",
"user":"jason",
"quickStart":true
}
}

If those look familiar, it’s because they’re already supported in the NFC payload. The difference is now because Android P comes bundled with the QR code libraries out of the box, there’s no need to first connect to Wi-Fi and wait for them to download, the reader pops up immediately allowing Wi-Fi to configure in the background. That easily saves up to 2 minutes per device, maybe more on slower connections!

Here’s a demo of it in action:

https://www.youtube.com/embed/-eVbZb9xDyo

5. APN configuration support

A long-awaited feature, Android P introduces support for remotely configuring APN settings on Android Enterprise work-managed devices.

Many no doubt won’t consider this to be particularly important at all, however if you work in Government or in an organisation generally large enough to warrant (and afford!) a private, dedicated network APN for mobile devices, it has been a difficult few years of manually editing APN settings.. or not using Android Enterprise at all.

A notable solution taking advantage of APN settings is Wandera; with APN settings available Wandera will be able to fully support native Android Enterprise devices as well as Samsung. It’s a pretty big deal for that alone.

6. More control over updates

Today organisations can already postpone Android Enterprise-managed device updates by up to 30 days, or force them to install immediately.

With P, 30 days stretches out to a whopping 90 days, offering organisations three times the amount of time for testing and validation on the release of updates, or simply the ability to prevent devices attempting to update over an extended holiday period (or some other reason a change-freeze may be in place).

However, those thinking of indefinitely postponing updates to support the legacy Android 2.3-era Frankenstein application barely just holding on with Oreo will be disappointed as there’s a cooling-off period of 60 days after being postponed, which means updates will eventually make their way to devices no matter what.

7. Several new device restrictions

As with every Android update, P includes some new restrictions in order to offer more control to organisations, these include:

DISALLOW_AIRPLANE_MODE
DISALLOW_AMBIENT_DISPLAY
DISALLOW_CONFIG_BRIGHTNESS
DISALLOW_CONFIG_DATE_TIME
DISALLOW_CONFIG_LOCATION
DISALLOW_CONFIG_SCREEN_TIMEOUT
DISALLOW_PRINTING

I’m particularly fond of the ability to prevent Airplane mode, though I’ve had requests for configuring Date/Time, Location and more granular control of screen timeout in the past; these will be well-received by organisations I’ve worked with!

8. Support for multiple users on dedicated devices

Another long-awaited feature particularly useful to the COSU/dedicated market (Zebra comes to mind): Ephemeral users.

Multi-user support in Android has been around for a long time, however it has been very much consumer-focused, intended to allow a device at home to be shared between families and other similar situations.

However, since COSU devices are often shared between many end-users – be that in a warehouse, logistics, or even shared tablets in hotels, hospitals and other situations – providing platform support for managed ephemeral users to provide short-term access to devices either as guests or a fixed users will come in very handy. Revolutionary, even.

With this feature alone I imagine we’ll be seeing a very positive shift in how COSU devices are managed today.

9. The introduction of DA deprecation

At this point the deprecation of Device Administrator APIs should not be new information; Google announced it in December, I have written about it extensively both here and on social media, and at this point many mainstream media outlets have talked about it also.

The following policies will start to throw warnings when used in Android P, and will throw an exception (or error and fail) in Android Q next year:

USES_POLICY_DISABLE_CAMERA
USES_POLICY_DISABLE_KEYGUARD_FEATURES
USES_POLICY_EXPIRE_PASSWORD
USES_POLICY_LIMIT_PASSWORD

It’s definitely time to be thinking about migrating from legacy Android enrolment to Android Enterprise.

Conclusion

There are far more additions to P I haven’t referenced here, which is definitely worth a read for those interested. There are controls and features added around COSU for example that will be very welcome for organisations deploying shared, single use devices.

Given this is only the developer preview I’m sure there’s potentially more to come; I’ll be waiting with my Pixel to test the next drop and will report back anything new and interesting I find either here, on LinkedIn or Twitter. Keep an eye out for updates!

An introduction to managed Google Play

2018-03-19T16:20:00Z

If you’re an Android user or manage Android devices in your organisation today I probably don’t need to tell you what the Google Play store is; you are no doubt familiar with Android’s equivalent to the Apple App Store hosting an estimated 3.5 million applications as of 2017 (Statista).

users are nine times less likely to contract a PHA downloading from the Play Store

Google Play is a cornerstone of the Android ecosystem, and while it’s not the only way to source applications for Android devices it is the most secure, as recently revealed in the Android Security 2017 Year In Review, users are nine times less likely to contract a PHA (Potentially Harmful Application) downloading from the Play Store vs alternative methods, at a probability of only 0.02% in 2017 (50% lower than 2016 at 0.04%).

For businesses however, Google Play has been something of a challenge.

Traditional application management

Traditionally, securely managing applications on Android devices has required a few things:

An Enterprise Mobility Management Server
A Google account for every device
Full, unrestricted access to Google Play

just as iTunes accounts on iOS devices are a pain, so too are Google accounts on Android devices

The Google account mandate is the biggest challenge for organisations due to the need to manage them; once a Google account is present users can download any applications they wish, back up data to Google’s servers or return them locked due to Android’s Factory Reset Protection (FRP). Obviously there are ways and means of preventing this (wholly or in part) via an EMM, however the fact remains, just as iTunes accounts on iOS devices are a pain, so too are Google accounts on Android devices.

If an organisation doesn’t want to deal with Google accounts, the alternative has been to enable unknown sources on the devices (in and of itself a security risk) and push APK files directly from the EMM server, either silently where supported (Samsung Knox, Zebra) or on-demand via the EMM app catalogue typically pushed down to devices as part of enrolment. Ignoring the breaches in distribution agreements this may invoke, it’s also extremely unreliable due to the various APK versions potentially targeting different form factors, architectures and Android versions. There’s no guarantee the one APK uploaded to the EMM will install on all devices and this can potentially lead to hefty data bills given some EMMs will re-push a failing APK repeatedly, forever.

There are of course 3rd party app stores, however these are absolutely not a viable alternative; 3rd party app stores are a haven for malware and PHAs, and are the leading cause of infection globally.

So it’s fair to say it hasn’t been the best possible experience to date.

Introducing managed Google Play

There is, however, another way. With the introduction of Android enterprise also came managed Google Play, an enterprise-targeted version of Google Play that:

Provides access only to applications an organisation explicitly approves
Enables the bulk-purchasing of paid applications
Removes the requirement for user-managed Google accounts
Can push applications and updates silently without requiring user intervention
Offers managed configurations for pre-configuring applications as they’re installed.

Approved applications

As mentioned above this is part of the Android enterprise solution set; managed Google Play isn’t available for legacy-enrolled devices that will have to continue with legacy application management, but given Android enterprise is becoming the default and only option for managing newly-purchased Android devices from next year, organisations should be evaluating a migration already. In tandem with default options preventing such things as application installation via unknown sources, organisations can rest easy knowing managed Google Play will be the only option for application installation available to end-users either within the work profile for BYOD/COPE deployments, or across the whole device if work-managed (COBO/COSU).

If 0.02% accounts for the 3.5 million applications available in Play today, imagine the odds of contracting a PHA with only a handful of applications available for download

By default, managed Google Play will offer no applications; administrators – whether G Suite or managed Google Play Accounts with a partner EMM solution – will need to start approving applications either via their EMM solution or play.google.com/work directly; this entirely depends on the EMM platform as Intune for example requires applications are approved via managed Google Play and then synced into the Intune tenant, while MobileIron and AirWatch on the other hand offer direct application import and management through the EMM console without the need to interact directly with managed Google Play.

Whether an organisation approves 1 or 100 applications, only these will be available to end-users. If 0.02% accounts for the 3.5 million applications available in Play today, imagine the odds of contracting a PHA with only a handful of applications available for download!

Bulk Purchase Program

For anyone reading this situated outside of the US, the Bulk Purchase Program (BPP) may jump out at you as something mostly unheard of. Unfortunately that’s because it’s not available globally just yet, but I expect it to expand out of the US this year.

BPP answers a familiar problem – if users need to use apps requiring payment, how does the organisation deal with this?

Ask the user to purchase and expense the license?
Purchase the license on the user’s behalf with a corporately managed Google account?
Work out ad-hoc licensing deals with developers directly?

In practice, much like Apple’s VPP, an organisation may purchase and manage application licenses for distribution and retrieval to reduce the burden on end-users purchasing and expensing app licenses, while allowing organisations to reuse them repeatedly rather than having licenses leave with ex-employees if associated with the ex-employee Google account.

As with most Android enterprise APIs, the Bulk Purchase Program needs to be supported by the organisation’s EMM platform and so is worth enquiring about before attempting to sign up.

No more Google account management

Because managed Google Play works in tandem with Android enterprise, there are no Google accounts to manage; if the organisation uses G Suite the Google accounts are already corporately managed, while managed Google Play Accounts, the newer solution for Android enterprise enrolment, automatically create generic accounts on the fly during EMM enrolment and offer no personal customisation, they’re there purely to facilitate application management.

Managed Google Play however goes even further than this, offering organisations the ability to silently install public applications from the Play Store with absolutely no interaction from the end-user; corporate applications can install silently and automatically as soon as the device is enrolled!

Managed application configurations

If the EMM platform is leveraging managed Google Play APIs, whenever an application that supports managed configurations (it is unfortunately opt-in for app developers at this time) is approved/imported into the EMM, it is possible to pre-configure the application so that, for example, email is already pre-installed and ready to go, or the Kerberos environment is fully configured for password-less login across all managed apps, without any user intervention.

Organisations are no doubt familiar with support calls requesting enrolment/setup assistance, or dedicating resource to creating in-depth enrolment guides in an attempt to alleviate the burden on support teams.. with managed app configurations, there’s little need since the app with provision itself!

Conclusion

Managed Google Play is entirely understated in its complementary capabilities within the Android enterprise solution set, but with a 2000% increase in managed Google Play activity in 2017, it will continue to revolutionise how organisations manage their Android applications in the future.

MWC 2018: Android One, Oreo Go, Android Enterprise Recommended & Android Enterprise

2018-03-02T22:22:43Z

2018 marks the first time I was able to attend Mobile World Congress. While a few topics appeared to feature heavily across the event – IoT, 5G, AR/VR and connected everything, and others – it was the sheer dominance of Android that truly captured my attention.

Between the device launches, the Android Works, the Google & Android “offices” (because it certainly felt like a building within a building), the folks in white Google Assistant overalls roaming around, and Android marketing pretty much everywhere I looked, it was clear Google held nothing back this year.

Android as a topic is a little broad though; what I noticed in particular centred significantly around the enterprise and specific Android editions, with the consumer introduction to Android Enterprise Recommended, potentially a new perception of Android One and the adoption of Oreo Go.

Hello Android Enterprise Recommended

One of the first stops I made at MWC was HMD Global, the company behind the Android-powered Nokia devices on the market today. While I’ll come back to them on Android One below, they were the first OEM I saw displaying their Android Enterprise Recommended badges against all three of their enterprise-ready devices, the Nokia 6 (2018), Nokia 7 Plus and Nokia 8 Sirocco.

I spent a good amount of time discussing Nokia devices with Andrej Sonkin, GM of Enterprise Business at HMD. They’re a passionate company working very hard to build their enterprise story and were one of few OEMs I was able to have a lengthy enterprise conversation with. Amongst other plans is a scheduled update to Oreo for the Nokia 3 and Nokia 5. Once those devices – which cannot be part of the AER program as they ship with 16GB of storage (that needs to be fixed with the next hardware revision!) – get up to Oreo they will also support zero-touch along with the rest of the 6 and above range. Nokia will end up with a selection of devices fitting all budgets and common form factors, all supporting ZT, vanilla Android and proactive security updates for at least 3 years.

Another OEM with the largest presence on the AER list currently is Sony, whose release of the XZ2 and XZ2 compact (as well as the XA2 not long ago) took the total number of AER devices up to 7 with potentially more to come. The XZ2 and XZ2 Compact demonstrate a move away from Sony’s long-held design language to offer instead curved edges and smaller bezels while still retaining their familiar Sony skin.

They didn’t have the Android Enterprise Recommended badges on display with their devices, but on asking, Sony employees were able to confirm these devices were on the list (when Google updates it).

Unfortunately Sony continue the trend of bundling a lot of crapware on the devices – for which there’s no mandate in AER to stop today – but for work-managed or work-managed with work profile (COPE) Android Enterprise deployments this is easily controlled/removed.

Although Sony don’t publish their security update advisories publicly today (something I’m pushing for via both Sony and Google), being part of the Android Enterprise Recommended program means these devices will get every security update Google release within 90 days guaranteed. With 7 devices varying in price and spec, Sony again offer a strong enterprise range for organisations.

One other OEM to get my attention was Huawei. Not for their phones though, I already knew they offer 5 devices today certified with Android Enterprise Recommended, including the Mate 10 & Mate 10 Pro, the P10 lite and others. Rather instead it was their new tablet, the MediaPad M5 Pro, I found interesting.

This device could be the first Android Enterprise Recommend tablet to hit the market with zero-touch support.

Although that’s only speculation, I’m reasonably confident given the inclusion of “Android for Work” (still using the old name?) support, the device spec meeting AER requirements and already having devices that are AER certified. Huawei will be in a pretty strong position with many organisations still using tablets today.

I’ve equally been awaiting a zero-touch compatible tablet since the Pixel C reached end of life a few months ago, so should Huawei get this device certified I’ll be sure to pick one up.

There were of course other OEMs on the AER list represented including LG, Motorola and BlackBerry, but I didn’t get the opportunity to speak to them.

Redefining Android One

For a while the perception around Android One was that it was for low-powered devices targeting specific markets. Perhaps this was because that’s where the devices initially launched, or perhaps because that was indeed the intention until the likes of Xiaomi came along with the Mi A1 offering a vanilla Android experience on a mid-range device.

In any case, the introduction of Oreo Go left many wondering if there’d be overlap between the two Android editions.

As it turns out, there isn’t. Google’s messaging is now very clear – Android One offers the purest edition of Android on the market. Much like the Nexus program where Google chose the OEM to work with, Android One allows OEMs to opt in and build a device around it. Where Nexus offered a bleeding-edge reference device, Android One is far more about the user experience; the consistent UI, lack of bloatware, frequent updates and more. OEMs can offer Android One dedicated handsets as in the case of Nokia, or create Android One editions based on existing handsets, as I hope Sony do with the XZ2!

Prior to HMD’s launch event I was pretty confident at least one Nokia device was going to be based on Android One; discovering the 6, 7 Plus and 8 Sirocco were running it was a very pleasant surprise. Furthermore, that HMD’s new flagship was an Android One device will do wonders for clearing any perceptions Android One is only intended for emerging markets.

Android One turned out to be pretty popular at MWC, with BQ and General Mobile also showing their own Android One devices, all adding to the models already available from Motorola, Xiaomi, HTC and Sharp.

For those of you who like your updates fast, your Android as close to vanilla as possible and the assurance that whether you pick up a Moto X4, a Nokia 7 Plus or a Mi A1, your experience will be identical, then Android One is the Android edition you need to embrace!

Touching on Oreo Go

One other very popular edition of Android, Oreo Go, was featured heavily at MWC much to my surprise. In addition to the HMD Nokia 1 I had a little hands-on time with (which was very snappy despite the rather low spec!) There were releases from Alcatel, General Mobile, Micromax and ZTE.

HMD see Oreo Go as an Android edition to help move feature phone users over to the Android platform, a sentiment shared by a few OEMs. With the market able to offer low-powered Android devices with decent battery life in or near the price ranges of today’s feature phone handsets, we may see increased Android adoption to come.

Outside of that use case, the obvious target market for Oreo go is again emerging markets.

Android Enterprise dominates

If there’s one takeaway from MWC, it’s just how serious both Google and OEMs are about the future of Android in the enterprise. With Nokia focusing heavily on pure, untouched Android with full enterprise support, Sony having even more devices certified for Android Enterprise Recommended, Huawei potentially bringing the first zero-touch enabled tablet to market and many other OEMs both present and absent from MWC showing their support and enthusiasm for Android Enterprise in general, things are only going to get more interesting from here.

Even Samsung, who currently aren’t part of the Android Enterprise Recommended program, have otherwise embraced Android Enterprise with their unification of APIs in Knox 3.0. Their stand was as impressive as always and although I didn’t attend, the enterprise summit they ran covered a number of their enterprise offerings, including the S9 Enterprise Edition offering 4 years of security updates, extended availability and more.

Exploring MWC

I’ve popped a few more photos below!

Enterprise ready: Google launch Android Enterprise Recommended

2018-02-21T17:22:04Z

Today Google announced Android Enterprise Recommended, a certification program for devices that aims to finally answer the age-old question – What devices are recommended for business use?

While Google has made an effort in the past to list devices suitable for business use based on support for Android Enterprise and zero-touch, there has been no clear set of requirements that guarantee the devices in question offer extended software support, adopt a unified Android Enterprise provisioning experience or meet minimum hardware expectations.

Partners, resellers and systems integrators all work with customers in the enterprise on a regular basis and will each by now have their own preferences based on experience, relationships with OEMs and other factors. Many, however, have to juggle customer requirements in trying to find the best balance between functionality and budget available, sometimes resulting in a device that may be under-specced or potentially unsuitable for the needs of the customer. With no stringent requirements in place to define what an enterprise device should be, the process can and has been a challenging one.

With Android Enterprise Recommended, that changes.

Devices submitted for certification will be thoroughly tested against Google’s “established best practices and common requirements”. Some of those include:

Minimum hardware specifications for Android 7.0+ devices
Support for bulk deployment of Android devices including zero-touch enrollment
Delivery of Android security updates within 90 days of release from Google, for a minimum of three years
Availability of unlocked devices, direct from manufacturer or reseller
Consistent application experience in managed proﬁles and on managed devices

.. and more. The full list of requirements can be found here.

It’s worth mentioning that this certification process is per-device, not per-OEM. This is a good thing as it ensures each individual device will need to be tested and certified, meaning the OEM itself can’t submit a single device, receive Android Enterprise Recommended certification, and continue to manufacture devices that don’t necessarily meet Google’s requirements.

What does it mean for OEMs?

Devices that pass certification are granted the Android Enterprise Recommended badge (above) for use in marketing and publications. Arguably more importantly however, Google will support OEMs participating in the program with enhanced technical support and training. This means those that may be struggling with issues in implementing Android Enterprise, be that UX, capabilities or otherwise, will receive more help and support from Google themselves.

As someone who’s done a fair deal of device testing independently and found discrepancies in the UX flow and scope of Android Enterprise support not only between OEMs but within the line-up of devices an OEM offers, this is excellent to hear! In theory, some issues I’ve highlighted in the past such as:

Interjection of the setup wizard during AE provisioning (Huawei, Motorola, Sony)
Access to device settings within a COSU kiosk environment that should be otherwise locked down (Motorola)
Access to the SD Card from both work profile and the parent profile, undermining DLP policies that may be in place (Motorola)

..will all be checked and validated by Google themselves prior to certifying the device. Where they fail, Google can directly inform and mentor the OEM on how to fix this before the devices reach customers (or will be quickly patched if already available).

Ultimately it’s in the best interest of OEMs to participate, as those who do will find it easier to stay on top of the evolving requirements for enterprise devices as the program and Android itself continues to mature. The AER certification will also almost guarantee heightened interest from customers with enterprise use in mind, while for those who choose not to take part I’d expect interest to fall.

And for organisations?

When buying devices for enterprise use from today, organisations need only look for the Android Enterprise Recommended badge to know the devices have been thoroughly vetted against the above (and more) best practices and requirements from the company that develops Android and the Android Enterprise solution. It’ll help to ensure organisations align expectations (and potentially budgets) accordingly to ensure the devices being considered will:

Be supported by the OEM for software/security patching for 3 years
Meet the demands of typical enterprise use without worry of slowdown, incompatibility or other potential concerns
Be available for purchase through multiple channels
Act and behave reliably when being provisioned as a work-managed or work profile device
Support Android zero-touch enrolment

Obviously with it being freshly announced there are a fair number of OEMs that have yet to submit their devices for testing, so for organisations in the final stages of device selection it doesn’t make sense to stop. What I would recommend however is vetting devices against Google’s recommendations and requirements (here) before signing on the dotted line for the reasons above.

Devices are already certified today

For organisations thinking about a refresh of their Android estate today, whether due to device age, suitability or anything else, there are already a selection of devices available for consideration:

BlackBerry KEYone and Motion
Google Pixel, Pixel XL, Pixel 2, and Pixel 2 XL
Huawei Mate 10, Mate 10 Pro, P10, P10 Plus, P10 Lite, and P smart
LG V30 and G6
Motorola X4 and Z2
Nokia 8
Sony Xperia XZ1, XZ1 Compact, XZ Premium, XA2, and XA2 Ultra

With more confirmed to be joining the program both in the short term and later in the year.

The program will expand beyond devices

An interesting note towards the end of the announcement states:

Throughout 2018, we will also be applying the Android Enterprise Recommended framework to additional partner types, including OEMs of “dedicated” and rugged devices, mobile carriers, enterprise mobility management (EMM) providers and systems integrators.

With Google looking to expand the Android Enterprise Recommendations program to providers, resellers and systems integrators later this year, not only will organisations be able to quickly and easily choose from certified enterprise-ready devices, but they’ll be able to apply the same decision process in selecting the solutions and partners they work with to guarantee a successful Android rollout.

Final words

I’m very pleased to see what has been something of an uncomfortable process for a number of years now is finally getting the guidance from Google the industry sorely needs. Echoing Google’s sentiments, this should mean less time and effort spent on the device selection process, more confidence for organisations in selecting the devices they see have met Google’s AER requirements and – hopefully – a greater onus on OEMs to improve Android Enterprise support while receiving recognition from a trusted source that the devices they’re offering to organisations are indeed enterprise ready.

I’m looking forward to seeing the Android Enterprise Recommended badge show up in the wild very shortly!

Are you a considering renewing your Android estate or currently in the process of doing so? What does the Android Enterprise Recommended program mean to you? Let me know your thoughts in the comments, @jasonbayton on twitter or @bayton.org on Facebook. If you’re on LinkedIn, you can also find me there – /in/jasonbayton.

Year in review: 2017

2017-12-31T23:40:52Z

As 2018 approaches, I thought I’d take a moment to reflect on some of this year’s activity and achievements.

#1: 100K visits!

Earlier in December bayton.org finally reached (and has since overshot) 100,000 visits. I sent out a brief tweet to mark the occasion.

100K, while not significant compared to the big sites out on the web, is a nice milestone for me and my humble website; that’s 100,000 of you who’ve stopped by to read what I’ve written and for that I’m extremely grateful!

Here’s to besting that in 2018!

#2: Top articles

In 2017 a couple of choice articles, both from the newly-launched documentation, took the top spots this year, combined contributing to just under 50% of all traffic to the website:

Installing Nextcloud on Ubuntu 16.04 LTS with Redis, APCu, SSL & Apache – a little under 30K visits
LXD, ZFS and bridged networking on Ubuntu 16.04 LTS+ – a little under 20K visits

Both of these in-depth, easy-to-follow guides have helped thousands of readers set up lightweight virtualisation environments and start hosting their own data, taking back control from the likes of Dropbox, Google Drive, Flickr and more. Some, like myself, may have even combined both in one environment!

The consistently growing traffic to these articles over the last year, combined with the oodles of positive feedback I’ve received, tells me I’ve done a good job of writing these guides and I’ll aim to create more like it in 2018.

A few other articles were unexpectedly popular this year, despite being published back in 2016:

#3: Enterprise documentation

2017 marks a first attempt at documenting the knowledge I’ve gained in the enterprise, and in such a way that’s easier to read and navigate than the traditional blog layout. While I’ve certainly written bits and pieces in the past, the explosion in interest – particularly around Android enterprise – has been incredible this year. In the last few months Enterprise Mobility has grown to around 1/5th of all traffic monthly and is steadily growing. Some of the highlights of both documentation and commentary on announcements:

What is Android enterprise and why is it used?
What is Android zero-touch enrolment?
Android zero-touch enrolment has landed
Google is deprecating device admin in favour of Android enterprise
Samsung launched a Note 8 for enterprise
Restricting access to Exchange ActiveSync

In 2018 I’ll be looking to double-down on this. Should documentation start entirely overshadowing the blog content on the site, a redesign and shift of focus may be on the cards to ensure docs are front-and-centre to visitors old and new.

#4: Top countries

The US takes top-spot for most visitors in 2017 with almost 20% of all views, followed by the UK, Germany and France. As the graphic shows though, almost every country in the world popped by to say hello at some point!

#5: Top referrers

Besides Google/search engines contributing to ~60% of traffic, my top referrers this year have been:

Nextcloud (Nextcloud community & NC website)
Twitter
Youtube
Reddit
LinkedIn

The social dominance in the list reflects a much stronger focus on social media this year, both automatically sharing new posts and manually resharing them while utilising targeted hashtags, keywords and other means to reach the biggest audience. I’ve also dabbled a little more with Twitter and Facebook marketing, the latter clearly hasn’t paid off given it didn’t make the top 5!

2017 equally marks the year I started to invest time into LinkedIn. For many years although I’ve kept my work history very much up to date, I used LinkedIn only really for the occasional post, job search or profile update and got very little out of the platform (despite landing my last 3 roles through it!). Using it as a primary platform for enterprise topics (with Twitter in 2nd place) has been very rewarding despite the lower referral rate.

The amount of mentions I’ve received from others sharing my posts has increased considerably also this year, particularly in the last 4 or so months with active users frequently sharing content. This also ties in with the increasing popularity of enterprise documentation.

#6: Downloads

As a value-add to my enterprise documentation I’ve additionally started publishing downloadable resources around Android. With over 400 downloads to date I’m very pleased, it’s definitely worth the effort and I’ll therefore be publishing more downloadable content next year!

#7: Other mentions

That pretty much covers off the website, so what else happened in 2017?

I joined Brian Madden’s team of external contributors and published my first article.
I discovered, and was therefore one of the first ever to provision an Android enterprise device using a QR code with MobileIron Core, leading to accelerated support for the option only 2 months after publishing my findings.
I’ve been able to work closely with Sony, HMD Global (Nokia) and others while testing Android devices for Android enterprise compatibility. I fully intend to continue this next year.
I’ve gained connections with all of the leading EMM vendors through my independent EMM documentation – MobileIron, AirWatch, MaaS360 and SOTI – as well as continuing to work with Miradore and Google around Android enterprise.
I joined CWSI as their first UK engineer after being made redundant from Vodafone (before being rehired in another role and later leaving) and have been working with customers all over Europe and more. CWSI’s support and encouragement towards this website has been truly incredible and definitely a key factor in focusing far more on the content this year (as well as publishing on the corporate blog, of course).
I’ve worked with big names like Wandera, and a number of independent developers in order to test and advise on the Android enterprise managed configuration implementation for managed applications; it’s been fantastic to be involved and I’m looking forward to some exciting announcements around this next year.

It’s been a good year.

Happy new year to all of my visitors, and I hope to see you all again soon as bayton.org turns 10 years old!

Google is deprecating device admin in favour of Android Enterprise

2017-12-21T19:24:41Z

On Tuesday, Google finally announced their intention to deprecate a number of Android Device Admin APIs – which have enabled enterprise device management since Android 2.2 Froyo in 2010 – in order to promote Android Enterprise (or work profile and managed device APIs as Google refer to them) as the default and only management APIs for Android devices from 2019.

The APIs to be removed with the Q release are:

USES_POLICY_DISABLE_CAMERA
USES_POLICY_DISABLE_KEYGUARD_FEATURES
USES_POLICY_EXPIRE_PASSWORD
USES_POLICY_LIMIT_PASSWORD

In their announcement, Google state device admin will remain supported in Oreo now and through the next major release, Android P. One rather important caveat in Android P however is passcode enforcement will be deprecated ahead of being removed entirely in Android Q. Once Android Q is announced, Android Enterprise will be the only available solution for device management going forward.

This has been a long time coming.

As both an active proponent of Android Enterprise and someone who’s seen device administrator capabilities abused by applications over the years, this is a really exciting announcement; it reinforces and validates the long-held opinion I’ve had that Android Enterprise is the future of Android device management and will no doubt help to further improve the security of the Android platform.

What does that mean for organisations?

It depends to a degree, but it will sooner or later require a change in the way devices are managed. There’s a good chance many of the devices under management today won’t see an update to Android Q, since OEM’s typically provide only 18 months of support for updates. With Oreo being installed on only 0.5% of all Android devices, and Android P less than a year away already marking functionality as deprecated, it’s a good time to start thinking about a migration.

As you might imagine, Oreo and earlier devices won’t be receiving this change and therefore device admin won’t be going away overnight, but eventually devices will give up or get flagged for renewal and the organisation will need to be able to support Android Enterprise within their chosen EMM platform when that happens.

That won’t be easy; a migration from legacy enrolment to Android Enterprise work-managed enrolment, a deployment scenario most comparable to the device administrator management of today’s devices, will require a factory reset of each device and will therefore be highly disruptive. A better idea, recommended both by Google and myself previously, is to tie the migration in with the hardware lifecycle of the organisations Android estate.

Naturally that may be difficult or simply not possible for some organisations within the space of two years, so a hybrid management environment on the EMM platform will need to be supported during the migration.

Why is Android Enterprise better?

The device admin API is based on an all-or-nothing approach requiring full device administrative permissions in order to manage a device. This applies to both corporately-owned devices and BYOD, which is hardly ideal. Furthermore, a Google account is required for public application installation, while enabling unknown sources is needed for private application installation. In both cases this has been something of a pain point, with the latter having the distinction of being a reluctantly accepted security risk.

Even when administrative permissions are granted, management APIs for individual OEMs are mostly non-existent and as such modern EMMs aren’t capable of managing just any Android device off the shelf. This is why Samsung is so dominant today, but more can be read about that here.

Android Enterprise consists of a robust set of management APIs built right into GMS-certified devices that allow for universal and consistent management. Furthermore, with managed Google Play and managed Google Play accounts, not only will unknown sources be unavailable on work-managed devices by default, but only applications explicitly approved by administrators will be shown in managed Google Play, with silent application installation available as a standard feature. On the other hand for BYOD users, Android Enterprise finally enables managed access to corporate resources without the organisation taking full control of the personal device. More can be read about Android Enterprise here.

Importantly, EMM vendors are already working on making migrations easier for organisations, with AirWatch announcing a switch to an Android Enterprise-first deployment experience in the very near future only a few days ago.

Getting started

Ultimately the sooner organisations start evaluating Android Enterprise, the better. I’d recommend starting with considerations for migrating from device administrator to Android Enterprise for those familiar with Android Enterprise, or what is Android Enterprise and why is it used? for those who are just beginning the journey.

I’m always happy to hear from organisations managing Android devices, so please feel free to reach out for a chat and/or advice.

Are you a considering or deploying Android Enterprise? Will you be looking to do so in 2018? Let me know your thoughts in the comments, @jasonbayton on twitter or @bayton.org on Facebook. If you’re on LinkedIn, you can also find me there – /in/jasonbayton.

Hands on with the Sony Xperia XZ1 Compact

2017-12-18T16:23:06Z

Photos

Photos in this post were taken with a Moto Z Play, and as you’ll see why when scrolling down, I don’t recommend the Z Play if you like decent pictures..

After the Android enterprise device support testing, Sony let me keep hold of the Xperia XZ1 Compact for a while longer, and I figure since it’s been more than 5 months since I sat down with the Nokia 3, I’d take the XZ1 Compact for a spin as a consumer device, too!

The XZ1 Compact is Sony’s miniature alternative to their new Xperia XZ1, a device I tested earlier that felt premium, well specced and was a delight to use (aside from my Nexus, was also the first device I saw ship with Android 8.0!). I therefore held high expectations for the XZ1 Compact, given the Compact line is intended to be a no-compromise alternative to devices some consumers deem too large.

Hardware

The photo above doesn’t do the XZ1 Compact screen any justice as the gaudy, poorly fitting screen protector is obscuring it, however the XZ1 Compact boasts a 4.6″, HD display housed within a 129 x 64 x 9.3mm frame. It feels small, yet solid given the chunky design and hard corners aligning with Sony’s familiar design language.

The colours pop quite nicely, and of course benefit from Sony’s Triluminos display with a multitude of options for colour, brightness and enhancement controls. I quite like that the display can get both extremely bright and quite dim, something that I’ve struggled with on other devices in the past and comes in very handy both in very bright and dark conditions. The inbuilt automatic brightness management does a good job of adapting to surroundings without being too aggressive.

At ~319PPI it is hardly comparable to high-end displays on the market, but given the small size I’ve absolutely nothing negative to say about the image quality in day to day use.

Around the display are speaker grilles and an 8MP front-facing camera.

Unlike the XZ1, the XZ1 Compact appears to be a mix of plastic, metal and glass. with the plastic cover on the back being a pretty gnarly fingerprint magnet (see the pic below)! I ended up covering it with a case pretty quickly given the difficulty I was having trouble removing fingerprints from the matte finish. It also flexes under a small amount of pressure, which honestly I’d forgotten was even a thing given the amount of glass and metal-backed devices I’ve used for a good while now.

Given the bigger XZ1 doesn’t use plastic, I wasn’t expecting to see it here, either. It feels obviously quite a bit cheaper due to this, even with the metal finish on the top and bottom; regardless of this however, the XZ1 Compact still benefits from IP68 water resistance.

On the back there are a 19 MP f/2.0 camera with laser autofocus and flash. The camera makes use of EIS rather than OIS, but the output has been pretty good regardless (see below). It also supports 3D scanning! The NFC radio location is indicated on the shell, making it much easier to get NFC working without the typical full-device swipe-and-hope I’ve had with some devices.

Along the right-hand side is the plastic volume rocker, and a power button/fingerprint reader which I quite like. Admittedly it takes some getting used to as it’s quite out of the way compared to the front or rear-placed fingerprint readers on other devices, but it’s much easier to use than Samsung’s oddly-placed fingerprint reader. It scans a fingerprint nice and quickly, and with the device being quite small, I can unlock it either with my right thumb, or just reach around with my left index/middle fingers to unlock the device. Handy!

Along the top is a microphone and 3.5mm headphone jack (thank you Sony).

Down the left-hand side are the SIM and microSD card slots; both are hidden behind a cover which is easily to pull out and doesn’t require a SIM tool to do so (another aspect of Sony I quite like). The SIM tray itself however is still the typical flimsy plastic piece I wish would go away, and still to this day Sony devices appear to require a reboot whenever a SIM card is inserted or removed. I’ve no idea why.

Along the bottom is another microphone and a USB C port.

Inside, the XZ1 Compact is specced as follows:

Android 8.0 (Oreo)
Snapdragon 835
32GB Storage (microSD support)
4GB RAM
2700mAh battery
Fingerprint reader

The battery is interesting; while it may look quite small on paper, having to only power a 4.6″ display it does actually offer pretty decent battery life. With my work-related use (as it is my current work device) I’m putting it on charge once every couple of days and that’s better than I was initially expecting.

Overall then the device does feel well-built and substantial in the hand considering the size, even if I’m not a massive fan of plastic.

Software

Sony devices ship with a light skin atop Android which, depending on your own personal preferences, may be a good or bad thing. The XZ1 Compact is no different here, however although I do prefer pure, vanilla Android, Sony’s skin is by no means unattractive and is so lightweight I’ve mostly not even thought about it. It additionally ships with Android 8.0 and was one of the first OEMs to do so!

As with many devices I get hands-on with, the first thing I did out of the box was to remove/disable a whole heap of bloatware applications (Lookout, Amazon, EE, and more). This also extends to Swiftkey, the default keyboard on Sony devices. I don’t particularly like using it nor the popups it gives me to sign up, so that got swapped out with GBoard very quickly.

With that out of the way, the device is a delight to use. I appreciate the built-in swipe down to search the device from the home screen, the occasional app recommendations (if enabled, it’s optional) and that Google Assistant is right there in the corner if you swipe over to it, as with most phones with the Google launcher. Normally on devices I’ll have swapped over to Nova launcher, however I’m pretty content with Sony’s launcher for the time being.

Running a Snapdragon 835 on a small screen, obviously performance is going to be pretty good. Compared to the Snapdragon 625 in the Moto Z Play I currently use as a daily driver – and the stutter/lag I occasionally have to put up with – the Sony doesn’t miss a beat; animations are smooth, I notice no dropped frames or other stuttering during normal use or even when running splitscreen concurrently.

Naturally running 8.0 it also benefits from Oreo improvements, like picture-in-picture, notification dots, faster boot-up times and much more.

Camera

The camera is pretty good, though I’ve not put it through its paces in difficult environments (night, macro, etc). Certainly one of the better cameras I’ve used recently. There are plenty of other camera comparisons online, and I’d recommended searching those out, but the samples above give an indication of camera quality.

I have tried to AR apps that ship with the phone, which made for some interesting photos, though I can’t see myself making much use of it. Saying that, there are a number of camera apps available to liven up the experience for those who want to add a bit of pop to their photos.

Enterprise use

The XZ1 family (that being the XZ1 and the XZ1 Compact) were the first devices, outside of Google, to support zero-touch enrolment. I’ve written fairly extensively about zero-touch enrolment over on docs for further reading.

Even outside of Android enterprise, Sony are one of few OEMs who have supported native Android management for a number of years. Their design language is consistent, they stay on top of updates (as can be seen with the rollout of 8.0 across their estate at the moment) and while they don’t yet have an enterprise version of their devices, given the infrastructure and teams already in place working on enterprise-class devices, it won’t take much effort for them to do so (or offer extended support for existing devices, like this XZ1 Compact).

Conclusion

Although it’s not exactly fully aligned to notion of reducing size without any sacrifice, the XZ1 Compact is a powerful offering for those who don’t want the mammoth devices littering the market today. With the XZ1 Compact you get all of the power of the XZ1 but in a much easier to handle 4.6″ form-factor.

At £399 online currently it’s got some competition with the likes of the Nokia 8 with its dual cameras and a number of mid-range devices, but more often than not competitors won’t be pushing a Snapdragon 835. Sony definitely has the upper hand for consumers looking for a smaller device in any case.

It’s a very nice device. If it had shared the finishing materials of the XZ1, though, that would have been icing on the cake.

Moto C Plus giveaway

2017-12-11T12:15:38Z

The competition is closed! Congratulations to David in Scotland on the win!

To celebrate the growing success of documentation – accounting for just under 50% of all website traffic already in only 6 months of being live – I’m doing a giveaway on the latest device to be tested against Android enterprise compatibility (results will be going live next week):

The Motorola Moto C Plus in Starry Black.

The device is brand new (arrived yesterday), barely used and therefore in perfect condition. I have all the devices I need here, so putting the Moto on a shelf would be a waste.

Specs

For £99 direct from Motorola, you get:

Android™ 7.0, Nougat
MediaTek MT6737 64-bit quad-core 1.3GHz processor
1GB RAM
16 GB internal, up to 32 GB microSD Card support
5.0” HD (1280×720)
4000 mAh battery
8MP/2MP cameras (back/front)
Factory unlocked

How to enter:

Share this giveaway to your favourite network
Follow @jasonbayton on Twitter
Add your details to this Google form
Do all of this before 31/12/2017!

Terms

This giveaway is open to residents of the UK and Ireland.
Competition closes on 31/12/2017.
The winner will be randomly chosen from the above Google Form and notified by email.
No response within three days of notification will result in another winner being chosen.
The device should be posted by 08/01/2017 (unless delayed).
Data collected during the competition will be deleted once the device is confirmed received by the winner.
I offer no implied support, warranty, monetary alternatives or anything beyond sending the winner a device that has been briefly used for my own testing and put back in its box.

Contact

For questions or concerns, tweet me, email me or comment below.

Good luck!

The state of Android Enterprise in 2017

2017-11-27T16:12:00Z

The state of Android enterprise in 2017

Enterprise mobility consultant and Android SME Jason Bayton reflects on the evolution of Android enterprise, where it is today, and what’s to come.

If you’re an organization contributing to the ~30% market share of managed Android devices in the enterprise, (Q1 2017, Google) you may have heard of Android enterprise, formerly Android for Work. (You might have also seen some of my Android enterprise-related content in the last few months!)

As someone who’s managed Android devices for a number of years, I’ve felt the burden—as many have—of dealing with limited management capabilities, the Samsung lock-in, Google accounts, and more. Android enterprise is a program I feel is revolutionizing Android management.

However, it isn’t perfect, so read on as I take a step back to provide a reflection on where Android enterprise has been, where it is today, and what’s to come.

Building momentum

Android enterprise isn’t new by any means; launched with Android Lollipop (5.0) back in 2014 and iterated upon with every Android release since, the idea of bringing a standardized enterprise management experience across all Android devices—and thus reducing both platform fragmentation and Samsung’s long-held dominance in the industry—seems like it’s increasingly garnering attention in 2017.

Over the last several months I’ve witnessed both customers and peers alike take an active interest in the newer, better alternative to device administrator (or classic/legacy) enrollment, either for their Android deployments, or for developers, adding EMM-managed configurations to their applications.

This is for good reason. With four deployment scenarios available—work profile, work-managed, COSU (corporate-owned, single use) and the most recent work profile on fully managed devices (or a “work-managed work profile” as I’ve been calling it, but otherwise akin to corporately-owned, personally enabled)—Android enterprise can adapt to suit various requirements:

BYOD? Go with work profile. It’ll allow the organization to manage a separate, yet integrated, fully-encrypted profile space (like a container) on the device and enforce basic device security, but leave everything else untouched. With both personal and work apps combined on the device (the latter indicated with a distinctive badge), it offers an efficient environment promoting both productivity and user-freedom.

Corporately owned? Go with work-managed. Using a number of provisioning methods, including the latest zero-touch enrollment method launched with 8.0, and rolling out to devices and resellers as I type, organizations can lock down a device, only permitting approved functions and applications. The end-user is therefore not given the freedom to use the device in a personal capacity.

CYOD (choose your own device) or COPE (corporate-owned, personally-enabled)? Go with work profile on a fully managed device. Launched with 8.0 and making its way to EMMs, this scenario pushes work applications and data into an encrypted, integrated profile. The device is fully managed but allows for personal use in the parent (non-work) profile.

Finally, for single-use environments, like kiosks in a shop, ruggedized devices used for delivery or transport, or anywhere else a device may be locked down to one or a limited number of applications, COSU utilizes the work-managed deployment scenario and locks the device to a remotely-managed kiosk environment.

All of these include silent application distribution via managed Google Play, which offers admin-approved public and corporate apps with the ability to automatically configure them when they’re installed, yet no need for a Google account. Work profile includes features like dual-passcode protection (both device and work profile separately), a simple quick-settings toggle for disabling the work profile on evenings/weekends, and DLP controls to prevent data moving between profiles without approval. Work-managed enables the removal of “bloatware” OEMs and carriers relentlessly push upon customers. Today, all of this is available on a range of devices that can suit almost any budget, form-factor, and requirement.

Sounds pretty good, doesn’t it?

But there’s still some way to go.

In terms of EMM management, Android adoption in the enterprise generally could be improved, with Android enterprise unsurprisingly moreso. Part of this is due to relatively limited marketing; although Google are putting more focus on security and enterprise functionality in their announcements, keynotes, and events recently, many organizations today still don’t know what Android enterprise is or does. (Nor did they know of Android for Work; and the rebrand didn’t help.)

Another aspect, besides security perceptions, is the F-word: fragmentation. Android enterprise was created to reduce fragmentation, however when it launched it was optional, meaning OEMs could choose to implement it… or not… Ironic, huh? Thankfully, this was put right in 6.0, so enterprises could search for devices based on other requirements, as long as they don’t opt for any of the 5.x devices that are, for whatever reason, still being sold today. Android enterprise started to feel more mature with Android 7.0, however 7.0 and higher only represent about 21% of the market, with 5.x–6.x combined representing over 58%. The sooner this changes, the better.

EMM vendors could also step up a little more. Even today, other OSes and Android features are being prioritized over Android enterprise. Case in point, it took AirWatch until October to finally support a COSU deployment, meaning up until now customers who wanted to mix COSU and other deployment scenarios would require two different implementations (I’ve done several like this, it’s not great).

On newer functionality, no EMM yet supports work profile on fully managed devices that launched with Oreo. This is easily the most comparable deployment scenario to device administrator (or classic/legacy) enrollment, which means we still don’t have that perfect middle-ground that will further bolster adoption for organizations currently sitting on the fence. You may argue Oreo was only released in August, but I’d counter that if EMMs have provided zero-day support for other platforms and OS updates, why not in this instance? Also, while zero-touch is an incredible tool for easing the Android enrollment process, it too is an optional feature (albeit one OEMs are currently jumping on to offer support). After the struggle getting earlier versions of Android enterprise off the ground, this came as a surprise to me.

Finally, OEMs also need to ensure they properly QA their implementations. Having tested a number of devices independently already, I’ve found that there’s a real disparity both between OEMs, as well as between devices from a single OEM. Some won’t have NFC or QR code support enabled out of the box; some will follow the process as intended; and others will jump back to the start and expect to be set up like a normal device. All of this can be quickly and easily resolved with an OTA update (which I’ve seen happen with Nokia, Sony and others).

So what’s next for Android and Android enterprise?

Well, Google will continue their march towards feature parity (and beyond) with Samsung and KNOX, as Samsung are still ahead in a few different areas and management capabilities (as you might expect, with Samsung’s offering having more time to mature). In the end, though, Google aim to have a unified experience across all compatible devices, allowing organizations to pick any device and know they can all be managed reliably and in the same way.

With the introduction of project Treble in Android 8.0, we should begin to see devices updated more frequently and for longer periods, as it separates the Android framework from the vendor/OEM implementation. This will make it much easier for OEMs to support enterprise-class devices such as the recently-announced Samsung Galaxy Note 8 Enterprise Edition. As the Note 8 runs 7.1.1, it’s possible Samsung won’t opt to support Treble with the upgrade to Oreo, but for devices launching with 8.0, all future platform upgrades will be much simpler and easier to undertake. I won’t be surprised to hear of other OEMs creating similar enterprise-oriented devices in the near future, as well. All of this is good news for organizations that have struggled with hardware lifecycles that are drastically different between consumer and enterprise devices.

Now that zero-touch enrollment has officially launched, as I mentioned, we’re already seeing OEMs jump on board, with resellers equally gearing up for this new wave of simpler, faster enrollment experiences. The list of devices and resellers is currently small but growing rapidly, and I imagine we’ll be spoiled for choice within the next 6 months, even if not all Android devices will benefit from it (due to the optional implementation). This alone will be enough to completely revolutionize Android management.

Finally, with OEMs and EMM vendors hopefully more aggressively supporting Android enterprise in the future, (in particular, work profiles on fully managed devices) we should see more organizations adopting this truly faster and better alternative to current legacy enrolment processes.

Final words

Today, Android enterprise isn’t perfect, but it is a viable alternative to legacy management, and it has certainly come a very long way since its launch a little over 3 years ago. With help from OEMs and EMM vendors, I see no reason why it won’t be the default for Android management for all possible deployment scenarios in the not-too-distant future.

Want to learn more about Android enterprise? Check out the documentation I’ve been writing on the subject, including the newest zero-touch enrollment process, or find me on Twitter where I talk all things Android.

Samsung launched a Note 8 for enterprise

2017-11-02T15:24:38Z

Yesterday, Samsung announced the Galaxy Note 8 Enterprise Edition, a PC-Class version of the consumer device better suited to a corporate environment.

What does it mean?

Many organisations today have a hardware lifecycle they like to follow. It may be 3 years, 5 years or another number that normally ties in with support contracts, budgets, reliability, or other factors.

However long they may be, they’re almost guaranteed to be at odds with consumer-grade hardware – specifically in the Android ecosystem – that’s been encroaching upon enterprises over the last several years; with the annual refreshes, a maximum of 18 months of software support and security updates, and a growing difficulty as time goes by to be able to replace a broken device with the same model as OEMs and carriers choose to stop making or stocking them, managing these devices can be a bit of a headache.

Samsung, then, are looking to fix that in two ways:

Allow the devices to be purchased for a longer period
Support the software on the devices for up to three years, and keep them patched monthly with security updates to prevent lingering vulnerabilities

These add up to a longer lifecycle for the device, making them easier to replace for a longer time and guarantee they won’t fall out of date and become susceptible to vulnerabilities anywhere near as quickly as competing devices still running on a consumer lifecycle, thus more PC-Class, even though the device is physically no different to the consumer model.

Why does it matter?

Well, when considering organisations suffer from a few reoccurring issues:

Devices can no longer be sourced, and so a mish-mash of devices need to be supported as existing ones break or otherwise fall out of support. After a few iterations of this you might imagine organisations ending up with a plethora of devices they have to keep running.
Devices are long past EOL and still in use as there’s no budget to change them. Vulnerabilities like the recent KRACK will never be patched.

The thought of an enterprise-ready device with guaranteed software support and attainability far longer than what we most have today will offer better security, less overhead (support, documentation, etc), make purchases easier to forecast and generally offer more peace-of-mind for those who care for and maintain the lifecycle processes, ensuring the Note 8 can be more comfortably integrated into them.

What else?

As this is an enterprise-targeted device, Samsung also make a point of talking about their configuration and management tools for quick, simple device deployments and business-as-usual activities – The Samsung Enterprise Firmware Over the Air (E-FOTA) will “help reduce downtime and simplify the complexity of enterprise-wide smartphone deployments” and enable “IT admins to comprehensively manage a fleet of devices through centralized OS and software version control and scheduled updates.”.

It’ll also support Knox Configure for secure, branded “mobile experiences” and of course the Note 8 Enterprise Edition is compatible with all of the other Samsung enterprise mobility solutions to boot.

The disadvantages – you’ll be expected to pay a bit more per device for the Enterprise Edition, and they can’t just be picked up from a local phone shop; rather only via authorised resellers. It also appears to be a US announcement, though I suspect wider availability will come in time (and hopefully under the same terms as noted here).

Final words

The struggle of integrating consumer devices into a corporate environment is one that has been ongoing for many, many years; I’m surprised it’s taken Samsung (or any other popular OEM) this long to come up with a – perhaps not compromise, but certainly an attempt to lessen the impact on organisations trying to incorporate consumer devices into their estate.

The approach to security updates in particular is excellent; hopefully by setting the trend here for the market we’ll start seeing other OEMs follow suit, a scenario in which everyone benefits and will most definitely aid to change the (incorrect) perception that Android security isn’t up to the standards of other OS’ on the market.

It’ll be interesting to see if and how the Note 8 Enterprise Edition succeeds in the enterprise arena.

MobileIron officially supports Android Enterprise QR code provisioning

2017-10-20T10:52:09Z

Overnight, MobileIron’s Provisioner app updated to version 1.2.0 and with it came the long-awaited support for QR code generation. The Mobile@Work DPC received official support for QR enrolment on the 16th of this month with version 9.5.1.0 following MobileIron Go last month, so it was only a matter of time!

I’ve covered unofficial QR code support with MobileIron previously:

These articles garnered attention both within and outside of the MobileIron community, leading to the accelerated official support we see with today’s update. With that in mind, I’m obviously very interested in how it’s been implemented! As a reminder, here’s the (now supported) raw QR snippet I got working with MobileIron:

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.mobileiron/com.mobileiron.receiver.MIDeviceAdmin",
 
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM":
"tlYEdUEZ3sUGJM-ySibMl0YjJXKDoUJOM1GxSSoVsrE",
 
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
"https://home.bayton.org/mi-android-nfc-latest.apk",
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
}
}

And below, the MobileIron Provisioner-generated QR code I decoded:

{
"android.app.extra.PROVISIONING_LOCALE":"en_GB",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.mobileiron/.receiver.MIDeviceAdmin",
"android.app.extra.PROVISIONING_TIME_ZONE":"Europe/London",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":"https://support.mobileiron.com/android-client-nfc/mi/mi-android-nfc-latest.apk",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM":"F-Ui0YRmoacQYly_lzW8eOCHxjc9TVy6R5eQ9FtSdRk",
"android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED":true,
"android.app.extra.PROVISIONING_LOCAL_TIME":"1508485289505",
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":
{
"server":"core.bayton.org",
"user":"jason",
"quickStart":false,
"qrCode":true
}
}

There are indeed a couple of differences here, the most significant being the addition of PROVISIONING_ADMIN_EXTRAS_BUNDLE which wasn’t previously supported by the Mobile@Work DPC prior to the 9.5.1.0 release; this addition makes it even easier to get enrolled as it pre-applies the server URL and username within the DPC, leaving just a password (or PIN) required in order to get started. Nice.

Less significant, but very nice to support nonetheless is PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED, providing the ability to leave system applications enabled. Now when enrolling, the EMM won’t have to try to download/enable system applications as they’ll already be available – another nice touch, however it does enable everything, bloatware too. You may find it easier to leave this off and manage via EMM to avoid having to manually hide all unwanted packages.

Otherwise, PROVISIONING_LOCALE, PROVISIONING_TIME_ZONE and PROVISIONING_LOCAL_TIME are the same as those found in the NFC payload.

One other interesting thing to note is the use of PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM rather than PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM; as I’ve mentioned in my previous article(s), the package checksum changes when the DPC is updated, which is why running:

$ curl -s https://support.mobileiron.com/android-client-nfc/mi/mi-android-nfc-latest.apk | openssl dgst -binary -sha256 | openssl base64 | tr '+/' '-_' | tr -d '='
$ F-Ui0YRmoacQYly_lzW8eOCHxjc9TVy6R5eQ9FtSdRk

Generates a different checksum to:

$ curl -s /download/mi-android-nfc-latest.apk | openssl dgst -binary -sha256 | openssl base64 | tr '+/' '-_' | tr -d '='
$ tlYEdUEZ3sUGJM-ySibMl0YjJXKDoUJOM1GxSSoVsrE

Mine hosted is 9.4.x, MobileIron’s is 9.5.1.0.

This means the checksum is going to need to be updated more frequently, and I’m not sure how MobileIron are managing that but as they’ve been using this to date with the NFC payload, it’s probably no big deal.

Admin signature is now used

From Provisioner 1.3, MobileIron have switched over to Admin Signature Checksum. This means the QR code generated in-app will be valid for far longer!

Implementation

The use of the Provisioner app for QR generation is an interesting one; I’d hoped EMM admins would be able to generate them directly from the Core/Cloud admin console either generically or as part of adding in a new device (wherein the admin extras for username could also be generated ad-hoc). Instead, admins will need to install the app on a device and generate them as required. Thankfully these can be shared over email or any other supported intent which doesn’t require the second device to be anywhere near those being provisioned which is a definite improvement over NFC.

For those wanting to generate QR codes without the use of the Provisioner however, my Manual Android Enterprise work-managed QR code generation for MobileIron document is still 100% valid and can used also (as long as you don’t ask MobileIron for support). If you’re looking for QR code provisioning enrolment guides also, check out Android Enterprise provisioning guides.

So there we are! Only two months after discovering it myself, MobileIron now officially support QR code provisioning for Android Enterprise.

Are you a MobileIron admin or end-user? Will you be looking to make use of QR code provisioning for devices in your organisation? Let me know your thoughts in the comments, @jasonbayton on twitter or @bayton.org on Facebook. If you’re on LinkedIn, you can also find me there – /in/jasonbayton.

Android zero-touch enrolment has landed

2017-09-23T19:22:06Z

On Thursday, Google officially announced zero-touch enrolment for Android 8.0+, enabling out-of-the-box EMM enrolment without the manual processes traditionally associated with Android provisioning. If you’re familiar with Samsung’s KNOX Mobile Enrolment or Apple’s Device Enrolment Programme (wherein iOS devices come configured out of the box to enrol onto a corporate EMM solution), Android’s zero-touch will not be a new concept.

Zero-touch as a solution has been somewhat available since the original Pixel came onto the scene, with documentation referencing it against Android 7.1 which launched back at the end of 2016. With only the original Pixel supporting it however, it failed to make any significant impact on the industry (and I can personally attest to how difficult getting any official information on it has been before this launch).

To understand how monumental zero-touch is for Android management, let’s take a trip back in time.

How Android enrolment has evolved

Legacy enrolment

In the beginning, enrolling an Android device onto an EMM solution straight out of the box was a long-winded process. Here’s an example (give or take the exact order):

Turn it on
Set a language
Connect to WiFi
Choose to setup as a new device, or transfer data from another
Agree to T&C’s, or opt into/out of specific OEM services
Add a Google account
Add a Fingerprint and/or Passcode
Agree to Google services/additional permissions
Exit the wizard, land on the home screen
Open the Play Store
Download the relevant EMM agent
Begin the enrolment process
Install additional EMM-related service APKs (and needing to enable unknown sources)
Set the device administrator
Get diverted to the Play Store to install any additional required applications

This is of course assuming the device contains management APIs the EMM can leverage to begin with; outside of Samsung the pickings were (and still are) rather slim and so some policies and configurations could simply not apply.

This early fragmentation in management capabilities contributed heavily to Samsung’s dominance in the enterprise today. More about that can be found here.

The introduction of Android Enterprise

With the launch of Android 5.0 came the introduction of what was then Android for Work. Google implemented a number of management features akin to those available with KNOX directly into Android – a set of universal enterprise management APIs OEMs could optionally choose to add to their device OS builds.

Android Enterprise has matured considerably since then, moving from optional to mandatory in 6.0, extending provisioning methods from the original NFC bump to later include Wireless Token (afw#emm.vendor) and from 7.0, QR Code enrolment too. Just as with Samsung’s KNOX and Apple’s Supervision, every major release adds more management capabilities or deployment scenarios. Today, provisioning a Work-Managed device is significantly faster, which the below video demonstrates:

https://www.youtube.com/embed/PBTI0TQAUyM

Above: Work-Managed provisioning using a QR code, a quick and easy alternative to devices that don’t support NFC if running Android 7.0+

Furthermore, applications can be managed silently, Google accounts are no longer a requirement and for enterprises using GSuite, end-users already get a near zero-touch experience when the device automatically initiates enrolment based on the detection of a GSuite email address associated with an EMM.

How zero-touch adds the finishing touches for Android Enterprise

With zero-touch, enterprises purchase their Android 8.0+ devices from an authorised reseller. Those devices can then be associated one of any of the EMMs that support a Work-Managed deployment scenario (Device Owner mode) using the Zero-touch portal. The DPC (EMM Agent) will be pulled down automatically along with any defined configurations when the device first boots.

As of writing, the number of devices that are about to support zero-touch (aside from the Pixel which already does) can be counted on one hand, however Google have partnered with almost all popular OEMs to have the functionality implemented – Samsung, Huawei, Sony, HTC, HMD Global (Nokia), LG and more will support zero-touch in the very near future. For those wondering, Samsung will continue to offer KNOX Mobile Enrolment, zero-touch is just another option for those who prefer not to use KME.

On the EMM side, there’s not a considerable amount of work to be done — for EMMs that do already support Work-Managed deployments it’s basically ready to go. For EMMs that don’t yet support it, more information on allowing support can be found here.

Resellers are being actively engaged, with already at least one in the UK and several others across the World coming soon. The resellers – aside from selling the devices – will also be responsible for setting customers up with a zero-touch portal account where, as mentioned above, the DPC and configurations are set. Once access is provided however, organisations can manage which resellers are associated with the portal themselves should it ever need to be changed.

When everything is set up and ready to go, the end-users who receive a device will experience something similar to the process demonstrated in the GIF – the device boots, they connect to WiFi and zero-touch takes over.

Incredible.

As someone who was there in the very early days of Android management and has experienced the pain of bulk-enrolling devices on behalf of users and/or customers, zero-touch – just like DEP for iOS devices – is the solution the Android market has needed to a very, very long-standing problem.

Android Enterprise is still a relatively new concept for many organisations and legacy enrolment is therefore still prevalent throughout the industry. With the also recently-announced Work-Managed Work Profile deployment scenario (more on that here), Android Enterprise covers all common deployment scenarios and is only a short way off feature parity with Samsung KNOX (SAFE). If your organisation is looking for a new approach to Android management, start testing with Android Enterprise now, zero-touch is only around the corner.

MobileIron unofficially supports QR provisioning for Android Enterprise work-managed devices, this is how I found it

2017-08-02T07:45:13Z

Update!

MobileIron now officially support QR code provisioning. Check out the updated post: MobileIron officially supports Android Enterprise QR code provisioning

This isn’t officially supported

The following discusses a feature that is not officially supported and may stop working at any time. Use it as reference or learning experience to better understand the generation and validation of QR code enrolment with Android Enterprise rather than relying on it within your/another organisation for MobileIron enrolment unless support is officially announced.

The QR codes below point to the respective APK files hosted on my own server and not that of MobileIron. This is entirely due to the fact the QR codes will cease to function when the APKs are updated (and the checksum changes). As this is only demonstrating a proof of concept, hosting potentially out of date APK versions is not what I’d consider a problem, however I strongly advise you generate your own QR codes using the more official document I’ve created here and, as above, use the below only for testing the process.

Android Enterprise supports a few options for provisioning devices destined to be work-managed, an NFC bump, a wireless enrolment token and, more recently, QR codes. For GSuite users there’s also the option to simply enrol using your corporate email address at the Google account prompt, but for Android Enterprise managed accounts we need to rely on the three mentioned above.

QR enrolment is particularly interesting to me as it offers some benefits:

No need for another device to transfer an NFC provisioning payload
Less “technical” than asking users to input the token (in the case of MobileIron, that would be afw#mobileiron.core or afw#mobileiron.cloud) in the Google account prompt
QR codes can be generated on demand, within or external to MobileIron, and shared freely via email or any other means (as long as they don’t contain sensitive data)

I’ve badgered MobileIron a little bit recently on ETAs for rolling out QR support as AirWatch already provides this but haven’t received any firm information (nor would I share roadmap info here either, of course). But when I saw how straightforward the raw code for generating an AirWatch QR code looked, I started to ponder.

Why wouldn’t it work?

Fundamentally the requirements for QR provisioning should already be baked into the Mobile@Work (and MobileIron Go) apps as the same components are used with NFC and token enrolment. The only thing missing as I saw it was the legwork to pull this existing information together in order to generate it as a QR.

I took the code provided by AirWatch above:

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.airwatch.androidagent/com.airwatch.agent.DeviceAdministratorReceiver",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":
"6kyqxDOjgS30jvQuzh4uvHPk-0bmAD-1QU7vtW7i_o8=\n",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
"https://awagent.com/mobileenrollment/airwatchagent.apk",
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
"serverurl": "Server URL",
"gid": "Group ID",
"un":"Username",
"pw":"Password"
}
}

And compared it to the closest thing MobileIron offers, the NFC provisioning payload transferred via NFC bump between two devices (one the provisioner, the other a freshly factory reset device supporting NFC out of the box). Using an NFC reader app on another device I got this:

#NFC provisioning
#Wed Jul 19 22:27:55 GMT+01:00 2017
android.app.extra.PROVISIONING_LOCAL_TIME=1500499675305
android.app.extra.PROVISIONING_TIME_ZONE=Europe/London
android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE=wpa
android.app.extra.PROVISIONING_WIFI_PASSWORD=12345678
android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https\://support.mobileiron.com/android-client-nfc/mi/mi-android-nfc-latest.apk
android.app.extra.PROVISIONING_WIFI_SSID="myWIFI"
android.app.extra.PROVISIONING_LOCALE=en_GB
android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM=VTra4byZJGOmUFXZpKzmQ7ST6nU
android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_NAME=com.mobileiron

They’re not identical, obviously, but I could see some similarities:

MI: android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_NAME=com.mobileiron
AW: "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.airwatch.androidagent/com.airwatch.agent.DeviceAdministratorReceiver",

MI: android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM=VTra4byZJGOmUFXZpKzmQ7ST6nU
AW: "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":"6kyqxDOjgS30jvQuzh4uvHPk-0bmAD-1QU7vtW7i_o8=\n",

MI: android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https\://support.mobileiron.com/android-client-nfc/mi/mi-android-nfc-latest.apk
AW: "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":"https://awagent.com/mobileenrollment/airwatchagent.apk",

Turning then to the Android Enterprise documentation, I noted android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE is optional, so removed it. I then used the information from the NFC payload to create a similar QR payload, as follows:

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.mobileiron",
 
"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":
"VTra4byZJGOmUFXZpKzmQ7ST6nU", 

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://support.mobileiron.com/android-client-nfc/mi/mi-android-nfc-latest.apk", 
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false, 
}

It didn’t work. I received errors on the device stating the code was invalid; probably not surprising given I was shooting entirely in the dark:

On a whim, I added android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE back in but emptied it of configurations:

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.mobileiron",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":
"VTra4byZJGOmUFXZpKzmQ7ST6nU",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://support.mobileiron.com/android-client-nfc/mi/mi-android-nfc-latest.apk",
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
}
}

(For reference, ADMIN_EXTRAS_BUNDLE allows for additional bespoke, DPC-based configurations like server URL, user/password, etc)

Tried again, this time I got a message to say “Can’t set up device”. This was progress.

Noting the differences between MobileIron and AirWatch on android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME I figured this was the next item to focus on. Since AirWatch already provided the string to find in the app, finding the same in MobileIron’s should be simple, or so I thought.

APKs are really just archives, I therefore extracted the contents of both the AirWatch and MobileIron agents and started looking. A couple of days passed here as I jumped in and out of this while doing other things, but eventually gave up; the component name I was looking for wasn’t presented in plain text in either app.

Plain text is the key, because I then wondered if the app sources were obfuscated. After a little Googling and chatting with Android devs I stumbled across Apktool, a free, open source utility for decoding Android apps back to their original (or near enough) source code.

Running it against AirWatch first I was – for the first time so far – able to open and freely read the contents of the Android Manifest file. Searching for DeviceReceiver took me directly to it, and a permission it uses, android.permission.BIND_DEVICE_ADMIN.

Searching then for android.permission.BIND_DEVICE_ADMIN in the Mobile@Work Android Manifest file gave me exactly what I needed:

com.mobileiron.receiver.MIDeviceAdmin

Following the format used by the example code, I combined it with the package name to end up with:

"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.mobileiron/com.mobileiron.receiver.MIDeviceAdmin",

Generating a new QR code against this got me further again! This time I received a checksum error – indicating there was a mismatch between the APK and the checksum I provided, both listed in the NFC payload and supposedly therefore fine.

Nevertheless, returning to the Android Enterprise documents I noticed the option for a SHA-256 checksum in place of the SHA-1 used with the NFC payload. Assuming QR provisioning is much newer than that of NFC I figured perhaps – despite notes on the docs to say SHA-1 will work for now – the documentation was outdated and therefore I had to use SHA-256 instead. So I generated a SHA-256, base64, URL-safe checksum using the following command in bash:

cat mi/mi-android-nfc-latest.apk | openssl dgst -binary -sha256 | openssl base64 | tr '+/' '-_' | tr -d '='

Where:

mi/mi-android-nfc-latest.apk is the application
openssl dgst -binary -sha256 generates a SHA-256 checksum
openssl base64 converts it to base64
tr '+/' '-_' | tr -d '=' makes it URL safe (mandatory requirement)

I then had everything I needed, I thought, to make this work:

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.mobileiron/com.mobileiron.receiver.MIDeviceAdmin",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":
"tlYEdUEZ3sUGJM-ySibMl0YjJXKDoUJOM1GxSSoVsrE",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
"https://home.bayton.org/mi-android-nfc-latest.apk",
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
}
}

And yet, I was still getting the checksum error. I went through various troubleshooting steps to regenerate checksums, triple check the component name and much more, only to realise in a last-ditch attempt to get it working that I’d completely overlooked the type of checksum I was using:

DEVICE_ADMIN_SIGNATURE is used by AirWatch (which appears to use certificate(s) within the APK for validation), but for MobileIron I’d been generating package checksums. So I changed SIGNATURE to PACKAGE as follows:

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.mobileiron/com.mobileiron.receiver.MIDeviceAdmin",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM":
"tlYEdUEZ3sUGJM-ySibMl0YjJXKDoUJOM1GxSSoVsrE",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
"/download/mi-android-nfc-latest.apk",
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
}
}

Success!

https://www.youtube.com/embed/PBTI0TQAUyM

Here’s the QR for MobileIron Core that I’ve successfully tested, the APK is hosted on my own server to ensure this QR continues to work with the provided checksum:

It took well over a week and 150+ factory resets on multiple test devices to get it up and running. Perhaps if I was a developer I’d have cracked it sooner, but nevertheless perseverance prevailed and I can now make use of QR codes before they’re officially supported!

To top it off, I also confirmed provisioning works equally fine with MobileIron Cloud (in about 20 minutes this time), with the code as follows:

{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
"com.mobileiron.anyware.android/com.mobileiron.polaris.manager.device.AndroidDeviceAdminReceiver",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM":
"1voVtaGkapb9a-JIOlEItoB47KBmD832JwjBUiRqhNg",

"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
"/download/mobileIron-go-46.0.0.9.p.apk",
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
}
}

And here’s the QR for MobileIron Cloud, the APK is hosted on my own server to ensure this QR continues to work with the provided checksum:

Update: A proper document has now been created. Check it out: Manual Android Enterprise work-managed QR code generation for MobileIron

What do you think of QR codes? Do you prefer them to other enrolment methods? Are you an end-user or administrator? Let me know your thoughts in the comments,@jasonbayton on twitter or @bayton.org on Facebook.

Hands on with the Nokia 3

2017-07-30T13:56:20Z

It finally happened.

After years of watching Nokia ship device after device running Windows Phone, gradually fading into the great technological abyss following Microsoft’s bargain £4.6 billion purchase, Nokia devices are back in the form of HMD Global, a Finnish startup comprising of ex-Nokians licensed to develop a new range of mobile devices.

Not just any devices though. Android devices.

As far back as 2012 I was musing the thought of a Nokia based on Android, and as the years went on – the hardware always far outshining the Windows OS it ran – the desire never left. While today’s Nokia isn’t the Nokia it once was, I still lived in hope when I heard they were returning to the market the core characteristics of the Nokia of old would be carried over – good looks, excellent hardware and a premium feel. These aren’t the first Nokia-branded Android devices ever of course, that title belongs to the N1 – a Nokia tablet that never made it to the UK. They are however the first phones, due to since-expired Microsoft licensing agreements, to get the green-light.

Of the three announced, the Nokia 3 is the first to hit the shelves here with the 5, 6 (and probably 8, 9 eventually) to launch next month. With all of that build-up it’s no surprise I grabbed the phone on launch day, but how has it fared against my very high expectations?

Hardware

Inkeeping with the materials synonymous with Nokia’s Lumia line, the Nokia 3 is a combination of aluminium and polycarbonate; it feels and looks far more expensive than it is. It feels well built and there are no gaps where materials meet – a problem some devices have had in the past.

On the back is the 8MP camera and flash module:

Down the left-hand side sits the satisfyingly clicky volume rocker and power button, and on the right is the SIM and MicroSD trays (two of them). Oddly they don’t quite match the colour of the surrounding aluminium frame, but this only really shows in the right light:

On the front is the 5″ 720p screen, an odd choice in 2017 given the increasing demand, nay expectation of 1080p displays as a minimum, however the image is crisp enough, the display is bright and honestly unless you’re looking it’s not obvious HDMG skimped on the display. It’s protected by Gorilla Glass 3 at least, so it could have definitely been worse. Above the screen is an 8MP selfie-shooter and below the screen is another feature I wish would disappear, capacitive buttons:

At least on the Nokia 3 these follow the standard layout, unlike competitors. Along the bottom, the mono speaker and microUSB (no USB C?) charging port:

On top the standard (or, non-standard now? Who knows) 3.5mm headphone port.

On the inside the Nokia 3 is specced as follows:

1.3GHz quadcore MediaTek MT6737
2GB RAM
16GB Storage
NFC
MicroSD support up to 128GB
2,630mAh battery (non-removable)
NO fingerprint reader

Opting for a MediaTek was a little unexpected given the prevalence for the lower-power Snapdragons we see in competitors like the Moto G5 and Wileyfox Swift 2 series, however using the device I don’t see it suffering because of this in normal, everyday use (games on the other hand, probably not so much).

The battery certainly isn’t massive, however having to only power a 720p display it holds up quite well.

Over all then it’s not too bad. For the price it could have perhaps benefited from a couple of spec bumps here and there, though I wouldn’t be surprised if the funds were instead funneled into the design and build rather than raw spec, though I definitely applaud the inclusion of NFC!

Software

The Nokia 3 ships with Android N 7.0 out of the box. Considering the Wileyfox Swift 2x ships with 7.1.2 and Android O 8.0 is just around the corner it’s a little disappointing to see 7.0 being shipped (in the context of HMDG stating they were going to be focusing on updates and security from the get-go, I’d otherwise not complain). I did receive an update to bring the security level up to July 2017 in the first 10 days of ownership which is definitely encouraging, but more can be done.

The UI itself is almost completely vanilla Android, a decision I fully appreciate and support – Nokia don’t need unwieldy skins to make an impact; in fact the stock look makes it far more appealing to me (not to mention the potential impact on performance skinning could have on a cheaper CPU). It’s generally a pleasant device to use with no apparent stutter or lag.

The home app is the Google (Now?) Launcher with it’s new dock/slide up app drawer in one. Other apps include the Nokia mobile care app, similar to the support app for Amazon Fire devices, this puts you directly in touch with a Nokia support rep or access to documentation. I had a brief chat with Zayn about an “issue” and he was very helpful. The camera app too is very clean and simple; while the 8MP shooters aren’t going to win awards, I did like taking photos with the app.

I’ll also mention the notification jingle – classic Nokia. I get a tinge of nostalgia every time an email comes through.

Enterprise use

Update September 2017

Nokia have since fixed all issues reported below around Android enterprise and now works perfectly as a work-managed device. It still does not, and will not, work when enrolled as a legacy device (as this is what Android enterprise replaces).

It is now more than suitable for enterprise use!

Original content below:

The Nokia Lumia line was synonymous with Enterprise use, particularly in Windows-houses. Cast that association aside, as although Nokia is now running a better-supported operating system for common EMM platforms, the support for enterprise management is completely lacking. The following is taken from a post on Google+ I wrote after completing in-depth Android Enterprise compatibility testing:

While I’m impressed with the device overall and definitely 100% in favour of a stock Android experience, it is basically impossible to provision as a work-managed device through AE.

To summarise my testing (http://j.son.bz/2ufKN4q):

NFC is disabled out of the box, requiring a workaround to provision via a bump
QR provisioning isn’t available at all
Wireless token enrolment almost works, but ultimately fails

This is the first device I’ve seen where the setup wizard continuously interjects during the DO process, requiring it’s restarted multiple times. Then, as a final act of belligerence, locks up the device entirely on the final step, requiring a factory reset from Recovery(!) in order to bring it back to life.

3 possible ways of enabling Device Owner mode and not one is successful.

A saving grace, potentially, is that Work Profiles are supported, so that’s certainly better than nothing, but this puts the device entirely in the BYOD segment of AE devices.

As an aside I tested it with legacy enrolment in a MobileIron Core and while it does support a number of restrictions around passcode (disable smartlock, minimum length, max retries, etc) the ability to lock it down (disable bluetooth, NFC, USB file transfer, etc) is almost nonexistent (not surprising as this is normal for non-Samsung Android). Containerisation works akin to Android Enterprise with MobileIron’s AppConnect and device certificates (for auth) can be used, but again that’s very much a BYOD scenario.

In summary, don’t buy this device for your organisation. If an employee comes along wanting to use it for BYOD, that’s really the only usecase an enterprise can support.

Conclusion

For £109 at point of purchase (or currently £139 on Amazon) the new Nokia 3 is a great phone and a really nice re-introduction of the Nokia brand to the Android market. The spec isn’t going to win any awards, but the build quality and general feel of the device should make for a great every-day phone for those not interested in pushing their devices too hard.

While mine is white, it also comes in Blue and Black to suit all tastes.

I’m pleased it ships with a pretty new version of Android, though disappointed it’s not the very latest point release. I’m also happy with the decision to use near-stock Android and not go full Samsung with an awful skin.

It’s a great all-rounder and for most should be perfectly adequate, though those wanting a Nokia with a bit more oomph should hold out for the Nokia 5, 6, 8 or even the flagship Nokia 9 supposed to be coming later this year.

Have you bought a Nokia 3? Let me know your thoughts on the device in the comments,@jasonbayton on twitter or @bayton.org on Facebook.

Experimenting with clustering and data replication in Nextcloud with MariaDB Galera and SyncThing

2017-06-10T11:32:34Z

Update

After discussions with the Nextcloud team and guys at TU Berlin, the below could be officially supported with some small changes. See the updates noted against the challenges. A rewrite or additional post will be coming soon to address and test the changes.

Nextcloud works really well as a standalone, single-server deployment. They additionally have some great recommendations for larger deployments supporting thousands of users and terabytes of data:

Up to 100,000 users and 1PB of data

What wasn’t so apparent until last week, however, is how someone might deploy Nextcloud across multiple datacentres (or locations) in a distributed manner wherein each Node can act as the “master” at any point in time; federation is obviously a big feature in Nextcloud and works very well for connecting systems and building a trusted network of nodes, but that doesn’t do an awful lot for those wanting the type of enterprise deployment pictured above, without having all of the infrastructure on one network.

Now that Global Scale has been announced this will likely be the way forward when it’s ready, however given I’d already started a proof of concept (PoC) before NC12 was officially made available, I kept working away at it regardless – more for my own amusement than anything else for reasons explained further down.

The concept

The theory was as follows:

If I’m at home, the server in the office is the best place to connect to since it’s on the LAN and performance will be excellent. In this case, a DNS override will point the FQDN for the Global Load Balancer (GLB) to a local HAProxy server that in turn points to the LAN Nextcloud instance unless it’s down, where the local HAProxy will divert to the GLB as normal.

If I leave the house and want to access my files, I’ll browse to the FQDN of the Nextcloud cluster (which points to the GLB) and the GLB will then forward my request seamlessly to the Nextcloud instance that responds the fastest.

In the graphic above, I opted for a future-proof infrastructure design that would:

Only expose HAProxy to the internet directly, leaving the individual servers on the VLAN hidden out of the way
Allow for expansion at any remote location by adding another server and populating it in the local HAProxy configuration
Separate the webroot from the Apache server by mounting it via NFS from the SyncThing server, allowing for super quick provisioning of new Apache servers as required, writing back to the same dataset in one location.
Sync session data to all nodes, so if I jumped from one node to the other due to latency, downtime or anything else, the other node(s) would allow me to continue without any noticeable delay.

No matter which Nextcloud instance I eventually land on, I wanted to be able to add/remove/edit files as normal and have all other instances sync the changes immediately. Further still, I wanted all nodes to be identical, that is if any file changes in the Nextcloud web directory on the server, it should be synced.

Why SyncThing?

The answer to that is pretty much “why not?”. This isn’t a serious implementation and I had no intention of scaling the solution beyond this PoC. GlusterFS or any one of the alternative distributed filesystems are designed for what I’m doing here, but I wanted to get some hands-on time with SyncThing and didn’t see a reason I couldn’t implement it in this fashion. I talk about it more here with Resilio Sync, but swapped Resilio with SyncThing as Resilio is proprietary.

Challenges

All recommended deployments suggest using Galera (MySQL or MariaDB) in a Master-Slave (-Slave-Slave, etc) configuration with a single centralised Master for writes and distributed slaves for quick reads. In my case, that could mean having a Master in Wales for which the nodes in France, Holland, Finland, Canada or anywhere else would have to connect to in order to write, introducing latency.

To get around this, I opted for Galera Master-Master. This setup isn’t supported by Nextcloud I later found out (by reading the docs, no less, oops) but at the time it appeared to work fine – I uploaded 10,000 files in reasonably quick succession with no database or Nextcloud errors reported, however that may well have simply been luck.

Update: Galera Master-Master is supported, however a load-balancer supporting split read/write must be used in front of it. The master should be persistent and only failover to another Galera server in case of failure. ProxySQL (https://www.proxysql.com/) offers this functionality and is FOSS.

At a minimum I’d have to replicate apps, themes and data for the individual nodes to sync data and retain a consistent user experience; enabling an app on one node wouldn’t be automatically enabled on the other node otherwise, as it’d first need to be downloaded from the Nextcloud store. I didn’t want to think of the issues this would cause for the database.

At this point I also considered the impact of upgrades, as when one Nextcloud instance successfully upgrades and makes changes to the database, the other nodes will want to do the same as part of the upgrade process. So rather than just syncing the data, apps and themes folders individually, I opted to replicate the entire /nextcloud webroot folder between nodes on a 5-second sync schedule (that is, there will be a maximum of 5 sec before data uploaded to one node is replicated to the others).

In testing this setup in several containers on the home server, the additional load this put on the machine was enormous during an upgrade of Nextcloud; a hex-core with 32GB RAM and SSD-backed storage ended up with a load average nearing 30, far more than the normal 0.4 it typically runs at; not so much a problem with a distributed service but where traffic is monitored with some providers, the constant sync could have an impact on transfer caps.

Load and data transfer aside, the tests were successful; I updated Nextcloud from 11.0.3 to 12.0.0 and watched it almost immediately start replicating the changing data as the upgrade took place – it was beautiful.

This was naturally the 2nd attempt, as first I’d forgotten to leave the Nextcloud service in maintenance mode until all sync had ceased, and on accessing one of the nodes before it had completed, things started going wrong and the nodes fell out of sync. Keeping maintenance mode enabled until it was 100% synced across all nodes then worked every attempt (where an attempt involved restoring the database and falling back to snapshots from 11.0.3).

Update: SyncThing is a nice PoC, but if you’re seriously planning to run a distributed setup I’d strongly recommend Gluster or another distributed storage solution.

HAProxy wasn’t failing over fast enough. If a node went down (Apache stopped, MySQL stopped or server shut down) and the page refreshed anywhere up to 2-3 seconds later HAProxy may not have downed the node quite yet and throws an error.

Getting past that didn’t take long fortunately, and I ended up making the following changes to the HAProxy config:

server web1 10.10.20.1:80 check fall 1 rise 2

This tells HAProxy to check the servers in its configuration, but more importantly drop them out of circulation after only one failure to connect when doing a check, and require two successful checks to bring a server back in. After this it was much faster and knowing I had enough nodes to handle this type of configuration I wasn’t concerned about HAProxy potentially dropping a few of them out in quick succession if required.

Redis doesn’t really do clustering, and authentication options are limited.

This was pretty much a stopper for distributed session storage. Redis docs and a lot of Googling led me to the conclusion I can’t cluster Redis. Therefore each node would have to report session information on all Redis nodes. That’s not a dealbreaker, but worse, either Redis remains completely open on the internet for the nodes to connect to, or if authentication is used, it’s sent in plaintext. Not good. Redis suggests connecting in via VPN or tunneling, but that feels like it defeats the purpose of this exercise and requires a lot more configuration. Perhaps Memcached could solve the problem, or figuring out a way of replicating the session files with plain-old PHP session handling. I didn’t look much further into it.

Update: Speaking to TUBerlin, they got around this with IP-whitelisting between Redis nodes. Ultimately Redis can be left “open” and without authentication, however on the server/network level, only whitelisted IPs may successfully communicate with the Redis nodes. Within the Nextcloud configuration, stipulating all Redis nodes is the only way of achieving replication (as Nextcloud will write to them all).

SyncThing comes with user-based Systemd service files, and after a while of trying to make them succumb to my will for a custom user and home directory (because the web user doesn’t always have a “home“, despite pointing to /var/www/ SyncThing kept dying on me when I’d made the changes)

Being all data is presented, manipulated and used by www-data for Nextcloud, I needed to ensure SyncThing ran as www-data in order to retain permissions and not run into issues trying to manage data in a non-user directory (/var/www/html/nextcloud/data). Because of this, I edited the default SyncThing service files to create some that aren’t user-based with a custom home directory, as follows:

Syncthing Service
Syncthing-inotify Service

Testing

So in order to confirm it was all working as it should be I did the following:

Increased the web nodes from 3 to 6 to test data replication. Piece of cake in the home environment as it was just a case of cloning an existing LXD apache node and assigning a new IP address. However I additionally spun up some blank Ubuntu containers and configured from scratch, this included:
- PHP settings for max upload, max post size, etc
- Apache settings for htaccess overrides and a conf file for default webroot location with Nextcloud (/var/www/html/nextcloud)
- Mounting SyncThing repo via NFS
- Static IP, updates, general server maintenance
Initiated a load test via Load Impact against the FQDN and monitored the HAProxy logs, brief video below
Manually downed both Galera nodes and web nodes, then brought them back up to test HAProxy failover

Here I dropped a Galera node, checked the state of Galera, brought it back in and checked again. Exciting.

And here’s a snippet of the load test at work on HAProxy (web nodes only):

https://www.youtube.com/embed/ruCX31n6fDg

I don’t know why I recorded that rather than screen capture, but c’est la vie.

During the load test Nextcloud remained responsive, load on the server went off the charts but that was fine as it too remained responsive. I could continue to upload, edit, download and use Nextcloud, so I was happy with it.

The next step would have been to start replicating the home server setup on remote servers, I’d considered a couple of containers with ElasticHosts, one or two LightSail servers from Amazon and perhaps a VPS with OVH. However this didn’t happen due to at this point finding out Galera isn’t supported, and Redis was going to cause me problems.

What I learned

In conclusion, this type of deployment for Nextcloud seems to work, but isn’t feasible. Redis is a bit of a stopper and an alternative would need to be found, and Galera master-master is a major issue and a bit of an inconvenience in master-slave. Here’re the details I published over on the Nextcloud forums:

SyncThing is super reliable, handles thousands upon thousands of files and has the flexibility to be used in a usecase such as this; full webapp replication between several servers without any fuss however:
- Feasibility in a distributed deployment model where latency and potentially flaky connections wasn’t tested thoroughly, and while the version management was spot on at picking up on out of sync files, it would need far more testing before being even remotely considered for a larger deployment
- Load on the server can be excessive if left setup in a default state, however intentionally reducing the cap for the processes will obviously impact sync speed and reliability
Data/app replication between sites is not enough if you have multiple nodes sharing a single database
- The first few attempts at a NC upgrade for example led to issues with every other node once the first had a) updated itself and b) made changes to the database.
  - This may be rectified by undertaking upgrades on each node individually but stopping at the DB step, opting to only run that on the one, I didn’t test this though.
- I think a common assumption is you only need to replicate /data, however what happens if an admin adds an app on one node? It doesn’t show up on the others. Same for themes.
Galera is incredible
- The way it instantly replicates, fails over and recovers, particularly combined with HAProxy which can instantly see when a DB is down and divert, is so silky smooth I couldn’t believe it.
- Although a powercut entirely wiped Galera out and I had to build it again, this wouldn’t happen in a distributed scenario.. despite the cluster failure I was still able to extract the database and start again with little fuss anyway.
- The master-master configuration is not compatible with NC, so at best you’ll have a master-slave(n) configuration, where all nodes have to write to the one master no matter where in the world it might be located. Another solution for multimaster is needed in order for nodes to be able to work seamlessly as if they’re the primary at all times.
Remote session storage is a thing, and NC needs it if using multiple nodes behind a floating FQDN
- Otherwise refreshing the page could take you to another node and your session would be nonexistent. Redis was a piece of cake to setup on a dedicated node (though it could also live on an existing node) and handled the sessions fine in the home environment.
- It doesn’t seem to scale well though, with documentation suggesting VPN or tunneling to gain access to each Redis node in a Redis “cluster” (not a real cluster) as authentication is plaintext or nothing, and that’s bad if you’re considering publishing it to the internet for nodes to connect to.
When working with multiple nodes, timing is everything.
- I undertook upgrades that synced across all nodes without any further input past kicking it off on the first node; however don’t ever expect to be able to take the node out of maintenance mode in a full-sync environment until all nodes have successfully synced, otherwise some nodes will sit in a broken state until complete
- Upgrading/installing apps/other sync related stuff takes quite a bit longer, but status pages of SyncThing or another distributed storage/sync solution will keep you updated on sync progress
The failover game must be strong

Conclusion

With the Redis exception I basically built an unsupported, but successful, distributed Nextcloud solution that synced well, maintained high availability at all times and only really suffered the odd discrepancy due to session storage not working properly.

SyncThing proved its worth to me, so I’ll definitely be looking more into that at some point soon. In the meantime, this experiment is over and all servers have been shut down:

If you have suggestions for another master-master database solution that could work*, and a session storage option that will either a) cluster or b) support authentication that isn’t completely plaintext, let me know!

*Keep in mind:

A multi-master setup with Galera cluster is not supported, because we require READ-COMMITTED as transaction isolation level. Galera doesn’t support this with a master-master replication which will lead to deadlocks during uploads of multiple files into one directory for example.

Have you attempted this kind of implementation with Nextcloud? Do you have any tips? Were you more or less successful than my attempt? Let me know in the comments, @jasonbayton on twitter or @bayton.org on Facebook.

Introducing documentation on bayton.org

2017-05-06T21:12:11Z

The way content is published on bayton.org is changing. Despite efforts to incorporate features into posts based on length, complexity, etc, I’ve not been pleased with the results. As such, over the last few weekends I’ve been working on a new area of the site dedicated to long-form, technical articles which will benefit from features like:

While categories and tags have their place, when reading through documentation on a subject there’s nothing quite as good as having content-aware navigation, allowing quick access to both similar topics, those in a series, or just having the ability to jump up a level without requiring any additional effort.

Every article will now have a table of contents to refer to, saving endless scrolling on longer articles as is currently the case.

Linked headings

To make it as easy possible to:

Share the article from a particular point
Pick up exactly where you left off via a simple link

Each heading now has it’s own direct link within a document:

Organisation by colour and highlighting recently published

To make it easier to differentiate between topics, each one has a unique colour; super useful for finding related documentation at a glance:

Furthermore, all new documentation is highlighted beneath the topic it sits under, as demonstrated above.

Regular updates

Traditional WordPress posts tend to drift off into the abyss after they’re pushed out of the first page in the admin area and it’s very much a case of out of sight, out of mind unless a comment to say something isn’t working pops up. What’s more, occasionally these posts rely on other posts for context or additional content which also has to be located and edited when it falls out of date.

It’s all a bit involved and less than simple to maintain keeping these posts updated.

While still today most of the writing done is contextually sensitive (Vault7 and the CIA: This is why we need EMM for example), an increasing number of articles are far more suited to a fixed, date-exempt (within reason) hierarchy which makes keeping them updated far easier.

Hello documentation

There are even more features available to readers of bayton.org docs I haven’t mentioned here, to get started and check it out yourself, head over to:

/docs

I hope this improves the quality of reading for visitors and I’ll carry on tweaking as necessary to improve it more!

If you have questions, comments or concerns, do feel free to reach out in the comments.

Goodbye Alexa, Hey Google: Hands on with the Google Home

2017-05-05T21:00:00Z

After months of waiting, Google Home finally launched in the UK at the beginning of April. Amazon’s Echo has sat firmly unchallenged in the personal assistant market over here for what feels like forever whilst Google dragged their feet, but at long last there’s a viable alternative for those who feel the Echo isn’t quite up to the job.

When the Echo launched, I ordered one immediately; I had high hopes it’d easily match Google Now’s capabilities on my phone and add just that little extra to my day. Unfortunately at the time (a few months back as of writing) I found while the Echo was quite good at some things, like music, most general knowledge questions, voice recognition and so on, others, like asking about the traffic between my location and work, or the distance and time from point A to B as a car would drive, rather than a crow would fly, etc, left me with the less than satisfying answers. It also wasn’t able to buy items from Amazon at the time, one of the things I was looking forward to trying!

With the launch of Google Home in the US and news it’d be making its way over the pond soon, I made the choice to pack up the Echo and ship it back to Amazon.

I was definitely not expecting to wait so long, however when I did get an email notification to state it was in stock on the Google Store, I bought it immediately and haven’t stopped using it since. Here are my thoughts on the device.

Hardware

I find myself struggling to find an adequate comparison for the Home’s shape; a Pear perhaps? A deformed tear-drop? In any case, the Google Home is quite a bit shorter and less imposing than the tall cylinder that is the Echo. Beyond that, though, they’re not a million miles away from each other as design goes – both have LEDs on top and speakers on the bottom – admittedly I much prefer the sharp directional LEDs of the Echo to the opaque dots of the Home, but I didn’t buy a digital assistant to stare at it, so that’s not a big deal.

On the back of the Home sits a microphone mute button to disable the two internal mics and on top is touch area for physically interacting with the device; a swipe left or right will adjust the volume, a tap will start or stop what it’s currently playing (very handy) and a long press will prompt it to listen for a command.

Behind a removable cover sit the multi-directional speakers; they offer a good, strong sound with adequate bass to comfortably fill an average sized room. The cover can be swapped for any number of alternatives to suit the decor around which the Home will sit, though the white top half is unfortunately not customisable. Replacement covers come in at £18 for material (such as the grey above) and £36 for metal – a lot to pay for a bit of additional colour!

Like a few recent household Google products, the Home is designed to sit on display rather than hidden away, and although perhaps not to the taste of everyone, I think they’ve done a decent job designing a device that while isn’t by any means a centrepiece, equally isn’t offensive to the eye either.

It currently sits on my desk in the office, pretty much directly in front of me beneath the mounted monitors. This makes interacting with Home incredibly simple and the touch commands even more useful; I frequently pause and resume music when taking a call with a quick touch, for example – much more convenient than Hey Google, stop.

Setup and use

Like the Chromecasts before it, the Home (arguably just a larger Chromecast with speakers) is an absolute doddle to set up; simply turn it on, open the Home app from a mobile device in the vicinity and it’s detected. Setup includes a sound test, assignment to a Google account and after that you’re away.

Being a G Suite user, I received a message almost immediately stating Home wasn’t able to integrate with my calendar or email. That was a little unexpected and somewhat disappointing, but actually not all that surprising; G Suite accounts have always come second to products and services launched by Google. Hopefully that’ll change in the near future.

With that aside, I switched entirely from asking my phone questions (which I do quite often, as it happens) to asking the same on the Home.

Hey Google, tell me about my day

One of my most frequent requests from Home is Tell me about my day. Excluding calendar appointments currently, Home returns the time, weather and news based on a curated list of sites I provide it (via the home app); I can carry on working on what I need to rather than perusing the news, which can often be a bit of a time-suck. As news and weather change through the day, it hasn’t once yet repeated information it had told me earlier.

Other frequent phrases include music; I have it connected to my Spotify account and linked up with several Chromecast Audio’s around the house in various group configurations. Though a single unit, I can request it plays music in almost full surround sound due to the way everything works so wonderfully together. When music is playing occasionally Home won’t hear me say Hey Google, though this has only happened a couple of times and I can understand why.

Then there’s video; while I don’t do much with Google’s paid TV/movie offerings, I can ask Home to bring up pretty much anything from YouTube on my NVIDIA SHIELD hooked up to the TV with very little fuss, useful in situations where the remote has wandered off (which happens an astonishing number of times per week, that remote is too sleek, but I digress..).

Naturally it also covers off many of the same questions I’ve historically asked Google Now/Assistant – what’s this, define that, how’s the traffic to somewhere, etc. All pretty flawless where the question is supported.

I haven’t had the opportunity to test the Smart Home capabilities of Home just yet, but knowing it can control my lights, power outlets and many other component around the house, I’m eager to give it a whirl.

It isn’t perfect, though

Despite the pretty obvious self-imposed limitation on calendar details and whatnot (entirely my fault for not ditching GSuite already, really), there are other ways Home could be improved.

Sound quality

The volume can go pretty high and fill an average-sized room quite well as I mentioned earlier, though I think the Echo beats it on sound quality. There’s not much in it, granted, but nonetheless. I sold my two Sonos Play:1’s earlier this year and although I definitely didn’t expect Home (or Echo) to live up to that sound quality, I think for the size and price there’s definitely room for a little more quality.

It doesn’t know everything

I found Alexa’s inability to assist with some – what I’d consider – simple questions a little exasperating, however Home actually isn’t that much better in some scenarios. I’ve noticed in particular rather than reverting to a web search by default as I’d expect Google Now to do in situations it can’t help, it simply tells me it doesn’t know what to do and that’s that.

A simple divert to the phone with a Google search would be an improvement here.

Integration could be improved

I’m not referring to services per se, though more services would be obviously better as Amazon is way ahead here. What I mean refers back to Home not knowing how to do things – asking Home to send a message for example – if it’s smart enough to divert some queries to another device, it should surely be able to do the same with a text, WhatsApp message, etc. My phone often tells me my query is being handled by Home, there’s no reason, to me, the phone can’t take over.

GSuite compatibility

Just come on already Google, please.

Please.

Conclusion

So as it stands today both the Echo and Home offer a reasonably consistent experience. They’re both improving day by day and though Amazon have had a pretty incredible head start, Google’s experience with digital assistants shines through frequently.

Between the Echo and Home I’d side with Google; it’s cheaper, more tightly integrated with Google accounts, seems to have more answers with more contextual awareness and with features like multi-user support rolling out, it’s going to shortly live up to the whole family theme Google have been pushing from the start.

I look forward to being able to use Home to it’s fullest, hopefully before I get fed up and migrate everything back to an @gmail.com account.

Do you have a Google Home? How are you getting on with it? Let me know in the comments, @jasonbayton on twitter or @bayton.org on Facebook.

Restricting access to Exchange ActiveSync

2017-04-15T20:58:47Z

Introduction

By default, Exchange allows connections to ActiveSync from anywhere in the world. While this is great for new Exchange admins, small businesses who don’t want to do much configuration and those who want things to just work, it poses a security risk on par with any other service openly accessible over the internet.

As Enterprise Mobility continues to grow and management platforms become more prevalent within the industry, leaving ActiveSync completely open is making less and less sense both from a security and management perspective.

Once devices are fully managed and ActiveSync profiles have been configured and deployed, limiting access to ActiveSync externally will prevent devices circumventing MDM in order to access email on their mobile devices. With circumvention impossible, end-users are required to enroll their devices onto the corporate MDM platform in order to get their email, enabling greater control over the devices in general; a benefit in its own right.

The aim of this guide is to provide directions for restricting access to ActiveSync to only specified, whitelisted IP addresses; these may be for a MobileIron Sentry, an AirWatch SEG or any other ActiveSync proxy that may be in use in the business. When finished, it will only be possible to connect to ActiveSync through the specified, whitelisted service, whether on-site or remote.

Before you begin

This guide uses Microsoft IIS configurations to restrict access. For firewall configuration this guide is not suitable.
The directions outlined below will only restrict access to ActiveSync, leaving OWA (Outlook Web Access) traffic untouched.
Although aimed at the EMM industry, this guide is suitable for any ActiveSync proxy, or just to keep ActiveSync locked down.
Despite being shown on a Windows 2012 R2 server, the same steps apply on earlier versions of Windows Server.

If you are happy to proceed, please read on.

Open IIS Manager

Click start and open IIS Manager from the start menu. On Server 2012 just type IIS within the Start Window and it will appear, for older Windows Server versions it’ll be under All Programs > Administrative tools.

Locate Microsoft-Server-ActiveSync

In the new window, expand the Servername, followed by Sites, Default Web Site and scroll until you find Microsoft-Server-Activesync.

Select this.

Open IP Address & Domain Restrictions

Once selected, in the main console will be a number of settings to choose from. Find and select IP Address and Domain Restrictions. Double click to open.

Is IP Address and Domain Restrictions missing? It may need to to be added using Add features in Server Manager.

Add Allow Entry

Once open, the Actions pane on the right-hand toolbar will show Add Allow Entry. For this guide we will add the allow entry before denying access.

Click Add Allow Entry and a new window in which to put the IP address of the whitelisted service will pop up. Enter the address(es) here and click OK to close.

For those with an on premise application, input the internal IP.
For those with a hosted/cloud service, ping the public URL to obtain the public IP address.

Edit Feature Settings

With the whitelisted application in place, we’ll now prevent all other traffic from connecting to ActiveSync.

As mentioned above, Exchange permits traffic from anywhere. This means anyone with an ActiveSync device can try to connect to the server irrespective of whether or not they are permitted to do so. In this step that option will be revoked, meaning only devices connecting through the whitelisted application can make an ActiveSync connection (and only MDM-enrolled devices are able to utilise this service, increasing security dramatically).

Going back to the Actions pane on the right-hand side, select Edit Feature Settings.

Deny unspecified clients

This will bring up a new window. In here, select the dropdown for Access for unspecified clients and change it to Deny. Click OK to close.

Restart IIS

Finally in order for the changes to take effect, IIS will need to be restarted. The exchange server can remain online for this if we opt for an iisreset, otherwise schedule downtime accordingly and test access to ActiveSync both through the whitelisted service and externally to confirm changes have been successfully applied.

IIS will be unavailable for a number of seconds while an iisreset is being performed. The business may need to be aware of any disruptions so plan accordingly.

What is Mobile Device Management?

2017-04-09T08:44:47Z

What is it?

Mobile Device Management, or MDM, is one of the cornerstones of the Enterprise Mobility Management ecosystem, providing remote, over the air management of mobile devices.

MDM enables:

Setup and configuration of devices
Enforced security to fall inline with company policy
Simple access to corporate resources (such as email)
Removal/limitation of features
The ability to find lost or stolen devices at a moment’s notice
..and much more

More than this, it helps the organisation to help the end user; tasks such as resetting the PIN or password, blocking the use of dangerous applications and remotely wiping a device (should it be necessary) are available at the push of a button; not only for MDM administrators, but via user portals users are able to do some of these functions themselves, meaning resolutions to issues historically complex and time-consuming can be almost immediate and with or without the involvement of IT.

Some configurations available to devices (where the OS supports them) include:

Network configurations
Managed configurations
Restrictions (the disabling of the Camera, iTunes, NFC, USB, YouTube, Roaming, etc)
Email (including POP, IMAP and Exchange)
VPN
Certificates
Security (PIN/Passcode management, etc)
..and more

If MDM isn’t enough alone, organisations can additionally take advantage of the ability to manage content, applications and monitor data usage using Mobile Application Management (MAM), Mobile Content Management (MCM) and Telecoms Expense Management (TEM) services respectively in the broader EMM scope. Not all platforms support all features, so due diligence is required when looking for a suitable platform to implement.

Having the ability to roll out an application to a vast number of devices simultaneously has huge benefits, not least in the time it saves having end-users locate and install applications themselves. Despite it having its own acronym – MAM – this is available almost as standard across MDM platforms and provides a secure location for both public and in-house applications, meaning access can be granted and removed from confidential information quickly and efficiently, leaving little doubt of confidential data being stored on device storage. In combination with MDM, applications can be pushed out as part of the enrolment process, vastly improving deployment time for new devices and greatly improving the time it takes to reconfigure devices already in the wild.

Robust reporting modules built into today’s MDM platforms mean organisations can generate various ad-hoc reports for installed software, storage usage, hardware, operating system information and more, with the ability to export these metrics or forward them on to industry-leading reporting solutions. This means organisations know exactly how a device is being used when issues arise and can use this information when working towards a resolution.

What problems does it solve?

Before investing in an MDM platform, an organisation will naturally need to understand the problems it solves and benefits it introduces. MDM can and does solve very real problems on a daily basis:

Apple Activation lock (find my iPhone): When a phone is handed to an employee without management and that employee leaves without fully signing out of the device, the device is entirely inaccessible after a factory reset without the original employee Apple ID password. Organisations globally spend hundreds, potentially thousands of hours a year working with Apple to prove they own the devices in question in order to gain an Activation Lock bypass code. With MDM and Supervision, activation lock can be disabled, completely rendering this issue entirely moot.

Lost and stolen: When an unmanaged device goes missing, Organisations don’t know where it is, whether it’s suitably protected against unauthorised access and cannot remotely wipe potentially sensitive information from device storage. Depending on the access granted to the employee or their status within the company (think CEO) a device may well hold critically sensitive data. With MDM, not only can the corporate data be secure on the device, it can be completely removed or the device fully wiped as soon as it comes back online. In best-case scenarios, the device can be located and collected if location reporting is enabled.

Data protection: When an unmanaged device is used for business purposes, the employee may collect gigabytes of corporate data stored openly on the device. The device may not be encrypted, may run compromised applications or be vulnerable to any number of known vulnerabilities. This data can be emails, downloads, data copies via USB from corporate machines or more. When that employee leaves, and organisation can prevent further access to corporate resources, but cannot remove the data already on the device. With MDM, managed email, content management and secure device profile or device-wide encryption can not only ensure data on a device is encrypted and optionally containerised, but remove that data on device unenrolment.

There are many other scenarios MDM can help. Take a moment to consider them.

What can it do?

The MDM solution is a platform used to provide support to mobile devices anywhere in the world with an internet connection and offers the following benefits:

Remote Management

As soon as a device is enrolled it becomes a managed endpoint and policies/configurations will be automatically pushed down. The single first indication of device management will normally be prompting the user to set up a PIN or password depending on the policy applied to their device. Devices do not have to be returned to base for new applications or settings to be applied and similarly, if an end user does not for any reason comply with the changes pushed out or the device is lost/stolen, there are a number of ways to utilise the inbuilt security features of an MDM solution to rectify the situation. Here are some examples of the tools MDM administrators have at their disposal:

PIN reset: Occasionally a user may forget their PIN or password. Through MDM, it is very easy to reset the PIN and have the user back up and running on their device in a fraction of the time of alternative methods. In a lot of situations, a user might end up completely resetting their device to factory settings either through too many wrong PIN combinations or intentionally to regain access to the device, causing significant impact on daily responsibilities whilst the device is set back up. With MDM, this is no longer a worry.

Alerts: If an end user becomes non-compliant with policies and compliance rules in place, alerts can be triggered to inform those requested of the action that triggered the non-compliant state.

Enterprise wipe: A partial wipe consists of removing all corporate data on a device put there by the MDM solution. This will include documents and applications accessed through the native mobile MDM application as well as corporate email. This will not wipe internal storage or external SD cards, nor will it remove personal information such as Google accounts or installed applications. The device will become unmanaged following an Enterprise wipe and will need to be re-enrolled in order to once again access corporate resources.

Full wipe: A full wipe will return a device to factory settings. All information will be removed. This includes MDM control, leaving the device completely unmanaged.

Device block: Partially or fully wiping a device is inefficient. It requires re-provisioning a device resulting in wasted time. Ideally it should be a last resort. For devices that need to be locked down for any reason, an alternative is to block the device. This prevents access to corporate resources (email, documents and applications) requiring a call to have it unblocked. At this point, the non-compliance issue can be discussed and potentially resolved over the telephone.

Device lock: Prevent access to a device by resetting the PIN/password to something only known by MDM administrators.

Compliance: In addition to setting rules on applications permitted, type of password in use, etc, it is possible to monitor the devices to ascertain whether or not end users are adhering to the rules in place. If for whatever reason they are not, it is possible to set a timer on their non-compliant state which can trigger any of the above actions after as little as 60 seconds or as long as several days. The end user will be fully aware they are non-compliant from the moment the native MDM application alerts them and will be told how long they have to rectify the situation. It is then in their best interest to become compliant in order to prevent the actions above taking place.

Location information: If a device is lost or stolen, MDM can assist in retrieving location information for the device providing it is switched on and connected to the internet.

Configuration deployment

As noted at the beginning of this topic, the range of configurations or policies which can be pushed to devices is broad and granular. Some devices may have GPS enforced for location data requirements, others may have all external radios bar Wi-Fi disabled when used as a display device in a store or tethered to an office location. Email configurations, VPN, managed app configs, passcode requirements (including how long before a device sleeps, how many failed attempts before a wipe, etc) can all be pushed remotely and with relative ease.

Combined with geofencing, time-scheduling and more, a device can be completely locked down during the day, and opened up completely in the evening should an employee be located in a secure facility, for example. For those in less demanding environments, the MDM admin may just opt to block YouTube during work hours.

Both Apple and Google offer ways of further locking down corporate devices; Apple’s Supervision can be enabled via IT or by enrolling in the Device Enrolment Program (DEP) and allows organisations to disable such things as Activation lock, Facetime/iMessage, the ability to factory reset and more. While Google has introduced Android Enterprise to allow organisations to manage many different Android OEMs consistently, something that has oft been a pain point for organisations. More information about these management options can be found in the links in this paragraph.

Application management

Application management allows for the distribution of applications to as little as one and as many as all devices within a group quickly and easily. All applications are deployed and managed securely and are easily accessible from within the native MDM application(s) or the Home Screen/App Drawer of the device.

Most MDM solutions support the distribution of both Play Store/App Store/Microsoft Store apps and Enterprise apps not located within the Play Store/App Store catalogues natively. More recently, the introduction of Apple’s Volume Purchase Program (VPP) and Android Enterprise support means applications can be distributed to devices without private App Store accounts to further reduce the support burden associated with managing iTunes and Google accounts.

There are typically a number of applications that should not be used in the workplace. Using application blacklists it is possible to block the use of applications with minimal effort.

This has two benefits:

Blocking applications that are not permitted means focus fully remains on the permitted applications and tasks at hand.
Application installation does not have to be prevented, allowing the installation of applications which are not blocked freely and in turn preventing wasted time logging requests for applications to be pushed out to a device.

On the other hand, using application whitelists take the polar opposite approach. Only applications permitted by management are permitted to be installed on a device. No other applications can be used unless they are first whitelisted. This allows a device to be used only for purpose with no wiggle room.

End user portal

The end user portal allows users quick and simple access to view the devices they have enrolled onto the MDM solution and perform basic tasks as follows;

Lock device
Reset PIN
Wipe device
Locate device

The availability of these options to all end users can help reduce requests for assistance that may arise from forgotten PINs or lost devices, however it is very much in the control of the organisation what users can and cannot do without MDM administrator intervention. Users may also optionally self-enrol onto the corporate MDM platform to gain access to email and other corporate resources if permitted. In many organisations the MDM administrator never needs to enrol a device for a user, reducing overhead there to almost zero.

Additional EMM components

When MDM and its security-first featureset is not quite enough, consider a broader EMM suite to take advantage of some or all of the following:

Expense management

Expense management allows for the monitoring of data usage for devices enrolled onto the MDM solution. Using a pre-configured data cap for a device, it is possible to monitor data usage against the limit and receive notifications when data usage surpasses set limits.

For example: If members of a team have a set limit of 1GB of data per month, it will be possible to monitor the data usage on a daily basis and when reaching set limits such as 50%, 75% and/or 90%, an email can be scheduled to warn relevant people of the impending data limit in order to either prepare for or avoid costly over-usage.

With this data organisations gain far more transparency over data usage within their teams that can help to avoid surprise bills.

Taking this a step further, 3rd party TEM solutions are available which integrate directly into the EMM platform and are able to report incredible amounts of data on telecoms usage, such as per-app, time of day, sites visited and more. One of these solutions has been reviewed, click here for more information.

Content management

Often email alone is not enough; when organisations have large data repositories internally they may wish for enrolled devices to gain secure access to them through the EMM platform. These repositories may be file shares, Sharepoint sites, any combination of common file sharing protocols such as SMB/CIFs, NFS, (s)FTP and more. Once setup and configured, EMM-managed devices can gain secure access to these resources while not being able to copy or share sensitive data outside the secure EMM area of their devices.

Naturally for smaller environments, documents can be uploaded to the EMM platform, optionally password protected and distributed or removed on request. No backend infrastructure required.

Conclusion

MDM is quickly becoming vital for the enterprise and paramount for adequate device management. Utilising all of the services and features outlined above, our ability, as an industry, to manage devices both locally and across the world is made significantly easier. With EMM organisations can extend management to applications, content and telecoms management with very little effort.

It is most certainly a must for any organisation making use of mobile devices today.

8 tips for a successful EMM deployment

2017-04-07T23:12:51Z

Recently, while browsing through EMM resources on Gartner, I stumbled across an interesting study undertaken in 2016, in it Gartner reports:

more than half of employees who used smartphones at work rely solely on their personally owned smartphones

That is by no means an insignificant number, one that’s likely already increased 4 months into 2017 and will only increase further as we approach the next decade.

And that’s a problem.

While employees are ready to leverage Enterprise Mobility to improve productivity, enhance their work experience and make their lives easier, businesses in many cases simply aren’t keeping up; a recent study by Synchronoss (via CWSI) delved into the state of Enterprise Mobility in 2017 across organisations in the UK and US and highlights how alarmingly unprepared many organisations are – 38% of those asked are yet to implement basic measures to safeguard corporate data such as enforced device security, restricted access to corporate resources or even basic visibility* of who is connecting in and to what.

* ActiveSync logs notwithstanding

These problems also extend to COPE (Corporately Owned, Personally Enabled) and CYOD (Choose Your Own Device) where organisations recognise there’s a need to implement control over the devices allowed to be used in the business, but don’t necessarily expand this initiative to address the corporate (HR) policies, security concerns and many other necessary considerations for ensuring a successful EMM deployment.

Indeed, a successful deployment is not simply granting permission for employees to access email via their own smartphones or handing out devices with no corporate management enabled, it’s a time-consuming, complex project that has far-reaching implications if not properly thought out; planning for a successful deployment now is much easier than cleaning up a poor deployment later.

Here are some things to think about:

1. Decide what employees can access remotely

A good starting point here is to evaluate current remote access tools such as VPN (Virtual Private Network). While some organisations grant employees access to everything on successful VPN authentication, many will only provide a subset of services remotely. The latter offers a reasonable template on which to base mobile access as well. In any case, the three main contenders for remote access generally are:

Intranet
Document repositories/File Shares
Email

Occasionally other services such as Skype for Business or backend services for corporate applications may make the list as well. It’s not overly important to list every last item at this point, but to get enough to work with to make a start – more services can always be added later on.

2. Decide what services will no longer be publicly available

Now is also a good time to consider the public services made available to employees:

ActiveSync

By deploying an EMM email gateway, whether on-premise or in the cloud, two of the most common issues with ActiveSync can be fixed:

It’s open to the entire world as it’s infeasible to attempt to lock it down to every possible IP range an employee may be logging on from
Anyone can authenticate and gain access to their email on any ActiveSync-enabled device

With an email gateway, email access is only going to be originating from one or two IPs (depending on the number of gateways required for the number of devices using ActiveSync), and as devices have to be enrolled onto the corporate EMM platform, organisations can feel confident no one is going to be accessing email from devices they don’t know about, or don’t approve.

There’s no reason why, once EMM is successfully deployed, ActiveSync has to be open to the entire world when it can be easily locked down, reducing the attack vector on the corporate network (be that local or cloud, with services like Office365).

(S)FTP, Sharepoint, other Document/Intranet repositories and sites

Providing access to corporate content from mobile devices has always been something of a challenge, one often “overcome” by employees through the use of 3rd party services such as Dropbox or OneDrive with or without the knowledge of the business.

While the threat of data leakage through external file sync services is bad, at least those services are secured with a password; once employees download content to their devices through these services or others, such as email, they may be doing so potentially to unencrypted, unsecured and unmanaged devices.

EMM may not be able to entirely solve a data leakage issue in the organisation, but it can certainly be improved.

With MCM (Mobile Content Management) and content gateway solutions, combined with stronger DLM (data lifecycle management) policies can help to achieve a few things:

Services such as Dropbox, Box, etc can be inaccessible from the networks on which corporate data is stored
Corporate data can be freely accessed from managed, secured devices through MCM applications but cannot be stored outside of the secure application
With MCM specifically, documents can be distributed ad-hoc to devices based on specified criteria, only opened in approved applications and be set to expire after a certain period of time.
Email attachments can be intercepted and prevented from opening outside of the secure corporate device environment

Typically content gateways are set up on the corporate network as either a virtual appliance or dedicated virtual server and configured from the EMM solution to provide the necessary access based on groups and criteria the business sets. Users that aren’t enrolled onto the corporate EMM platform will find it much more difficult to gain access to corporate data through unofficial means once effective steps have been taken.

3. Decide how employees will access the network

Revisiting the acronyms above once more – BYOD, CYOD, COPE (and others) – how employees access corporate resources can vary depending on the type of EMM deployment they’re a part of. If a device is fully corporately owned and managed, it’s reasonable to feel it should get direct access to the corporate network. Devices brought into the organisation and owned by employees however, not so much.

Furthermore, if employees do indeed bring their own devices, should any and every device ever made be automatically supported? Of course not. Policies (discussed below) should be put in place and the organisation can decide the operating systems (and versions) and/or device types to be supported following some internal testing to confirm those chosen work well with both the EMM solution and the services they’ll access.

Beyond that, the organisation needs to consider how employees authenticate to services – username and password? Certificates? Two-factor authentication? There are security and usability factors to keep in mind whichever methods are chosen, as well as the infrastructure to support them.

Data Containerisation

Containerisation is the act of separating work data from personal data on a mobile device. It was a big topic of discussion in 2016 and it’ll no doubt continue to be this year; although containerisation is often associated with BYOD, there is no reason why it can’t be implemented for CYOD, COPE or other corporate mobile initiatives in which the business owns and manages the devices for additional security.

For example, it may be fine to use the native email client to access mails, but a highly-secure content repository might reside inside a password-protected EMM container on the device where DLM (data lifecycle management) tools may block the ability to copy, email, print, etc. documents within it.

4. Decide what devices can and can’t do

No one enjoys using a device that’s been utterly crippled by corporate restrictions, but sometimes they’re necessary, like disabling the camera in secure environments or enforcing actions on the detection of a root or jailbreak.

EMM platforms may provide time-based and geographic profiles, meaning between 9am-5pm Youtube can be blocked, but when the work day is over the device is freed of its limitations. Similarly for employees entering and leaving a secure facility, everything from camera to bluetooth, microphone and more can be disabled to prevent any unnecessary collection of secure data.

Naturally with devices being used for work, it shouldn’t come as a surprise to employees to see a prompt asking they enable a passcode or encrypt their device. The type of passcode can range from a pattern to a 6 digit PIN or 24 character alphanumeric password, though for the latter do consider the impact it’ll have on employees if it’s not necessary.

5. Evaluate the architectural requirements

In order to provide access to file shares and other internal services, often one or more additional components (beyond the main EMM server, if installed onsite) will need to be installed. As with most appliances, the more users and devices requiring enrolment, the larger the implementation.

Evaluate the hardware and software requirements, the number of devices supported per appliance (as performance can suffer when overloaded) and the network requirements in order to discern how many components and of what type need to be installed, and where they’re best located – in the DMZ, LAN or both where the component can split into relay and endpoint.

For an EMM platform integrating with LDAP, email, file shares and intranet services, no less than 3 additional components over the EMM platform itself will normally need to be installed. For the platform itself, this may be one self-contained virtual appliance or it may require a database server, reporting server and more. Where HA, clustering (if required) and DR is involved, that’ll obviously increase.

When designing the solution, aim to forecast device numbers 5 years ahead where possible, reducing the likelihood of future premature expansion projects.

6. Define corporate policies

With a plan in place and a reasonable agreement on how devices will interact with the corporate network, the business will have a better understanding and scope with which to align corporate HR policies.

It doesn’t matter what is announced to the business in a town-hall, or how many emails are circulated with rules and warnings for interacting with corporate information, without policies and procedures in place for all employees to understand, agree to and sign, the organisation will not be legally protected.

It’s much easier to amend policies already in place than create them when required, so aim to publish, at a minimum, the following policies/procedures before enrolling devices:

Acceptable use for corporate/personal devices
Data ownership and storage
Enrolling and retiring corporate/personal assets
Supported devices

Feel free to combine the above headings into larger BYOD/Corporate policies, add or amend as required. Once policies are in place, the organisation will know where it stands in relation to the use of mobile devices. These policies can also be pushed to employees while their devices are being enrolled, making it a mandatory step during enrolment and ensuring the policies are agreed to before gaining access to corporate data.

7. Test, tweak and iterate

Few organisations get it right on the first try, and that’s perfectly fine.

Once the goals and objectives from a business/security perspective have been agreed on paper, encourage and utilise the feedback from employees directly impacted by the changes to reach a balance between locking everything down and enabling employees to undertake their corporate responsibilities.

Make use of pilot groups and don’t be afraid to tweak configurations and profiles as necessary; it is a new and challenging aspect of corporate IT, one which, as referenced at the beginning, is still in the very early stages of adoption across a large portion of businesses. In the last 5 years the mobile landscape has shifted considerably in capability and security, and likely will continue to do so – unlike traditional IT the mobile space moves at a consumer pace and will absolutely require amendments to all aspects of the Enterprise Mobility deployment in order to ensure the business keeps up the pace.

8. Seek assistance

Years ago an EMM undertaking was very much a self-support affair. Today however, there are businesses all over the world dedicated entirely to Enterprise Mobility.

Any organisation looking to take the plunge, whether that’s undertaking a brand new EMM deployment or making changes to an existing deployment, who feel they may benefit from advice, professional installation/rollout or even an entirely managed service should absolutely seek assistance from market leaders.

Conclusion

Mobile usage in the business isn’t going away any time soon and organisations, in order to both enable employees to better do their job and keep corporate data secure, need to seriously consider implementing a robust EMM environment.

Hopefully the tips above offer a few points to think about for both new and existing implementations; as an evangelist of all things mobile in the enterprise I only want to see the industry succeed in taming unmanaged device usage and the serious security and data implications that come with it. As the industry matures I look forward to seeing it flourish and, more importantly, that 38% drop to nothing in the near future.

Long-term update: the fitlet-RM, a fanless industrial mini PC by Compulab

2017-03-19T21:26:28Z

It’s been just over 250 days (or about 8 months) since I published my review of the fitlet-RM. At the time I was very impressed by the system, its versatility and being able to run a reasonably powerful PC completely passively cooled. It didn’t take long before I found the perfect use for it and given how critical it is to my home network today, I thought I’d revisit the fitlet-RM to shed some light on how I’ve gotten on with it.

Around the time of publishing I was also looking to build myself a new router based on OPNsense (a pfsense fork). I’d tried a few options but ultimately wasn’t happy with anything due to noise, size or reliability. I figured the fitlet would be a viable option, so once I’d finished benchmarking it and hit publish on the review, I set to work on installing OPNsense.

In terms of IO, the fitlet I received is the perfect machine for networking, with the single NIC on the back and 3 additional NICs through the facet card on the side, it offers more than enough ports for what I need – in fact today only two are in use; a NIC for internet and another for LAN going out to an access point (from which it connects via switch to the rest of my network). I’m saving the other two for when I begin experimenting with segmented LANs, a DMZ or other such experiments.

In combination with the fit-Uptime, the fitlet has achieved over 99.999% uptime excluding the occasional planned shutdowns (holidays, etc) despite a couple of power cuts over the last 8 months (thanks, Wales). At no point have I needed to manually bounce it for any reason and I haven’t noticed any network issues associated with long uptimes. It’s currently sat at over 40 days, though was up for over 100 previously with no issues.

Here are a couple of stats courtesy of OPNsense:

Average temp: 50.2*C
Disk usage: 2.9GB
Average memory (free): 66%
Average load: 0.18

I’d have liked to show traffic as well, however traffic totals aren’t reliable (and rarely sampled) it seems.

Despite the system sat in a small cabinet with the door closed most of the year, the temperature has remained fairly stable (it certainly got far warmer running Windows previously). Unsurprisingly it’s rather over-powered for what I’m using it for; realistically the fitlet-X-LAN with the A4 and 4GB RAM would suite this usecase far better, and at some point I may pick one up when I find a new use-case for the one I have, but for now it’s doing an excellent job.

In the picture above you may notice the VESA mounting plate and the (still) silver heatsink. It took a little longer than expected for the black heatsink to go on sale, by which time the fitlet was already out of sight under the TV and I found I wasn’t particularly bothered enough by the colour mismatch to do anything about it. Similarly the VESA mount was for me to mount the fitlet under my desk in the office and again hasn’t been necessary, instead I’m using it as an additional plate to help further dissipate heat (whether or not it works like that I don’t know, but there’s no harm in having it attached either way).

That’s really all there is to this followup. Being absolutely rock-solid in terms of performance, reliability and causing me no issues whatsoever as the gateway to my network, I felt the fitlet (and the Uptime) deserved another mention; it’s required the least amount of attention of all the devices I own and that, in its own right, earns it top marks in my book. To echo what I said in my first review:

In combination with the fit-Uptime I envision the fitlet will ultimately – just as advertised – be one of the most resilient and reliable systems I’ll ever run. For the price I wouldn’t have expected a system as decent as this.

And for anyone interested, to save going back to my first review, here are the product links:

fitlet heatsync: Amazon UK
fitlet remote power button: Amazon UK
fitlet VESA/wall mount: Amazon UK
fit-Headless: Amazon UK
fit-Uptime: fit-PC (official)
fitlet-RM-XA10-LAN barebones: fit-PC (official) – links to all fitlet models

Have you purchased your own mini PC since my initial review? Or a fitlet-RM? Let me know in the comments, @jasonbayton on twitter or @bayton.org on Facebook.

First look: the FreedomPop V7

2017-03-18T13:36:15Z

You may have heard of FreedomPop at some point, they’re an MVNO offering free (as in beer) minutes, texts and data every month with no strings attached (unless you count the requirement for their app as part of the deal). They launched in the UK in 2015 and have been slowly making a name for themselves both for the free service and their low-cost plans for when the free tier is not quite enough.

I’ve been making use of their services infrequently over the last couple of years for test devices and tablets which mostly live near WIFI, but may occasionally pop out of the house with me. It’s incredibly convenient to have a service that’s always there when I need it, but not costly when I don’t.

They recently launched the FreedomPop V7, a 5 inch Android Marshmallow handset preloaded with FreedomPop’s service and apps. It’s not the first FreedomPop-branded device (well, perhaps in the UK it is) as they’ve dabbled in the past, but they’ve been more often associated with the sale of refurbished devices through their website. With the launch of this new device, I thought I’d jump at the opportunity to take it for a spin and publish my thoughts.

Hardware

The device itself is a fully unlocked V7 Zyro which has been subject to no additional FreedomPop branding and can be purchased on Amazon for under £100. FreedomPop however offered it bundled with their £11.99/month Premium 2GB plan (the first month is free and can be cancelled before renewal) for £59 all in. This 2GB plan also comes with unlimited texts and minutes.

For the price it’s a reasonable handset that feels more expensive than it is; the aluminium frame is the biggest reason for this and looks great against the matte, grippy, plastic back cover. Under this cover sits a 2100mAh removable battery, 2 SIM slots (the 2nd is 2G only for some reason) and a MicroSD slot capable of carrying up to 32GB MicroSD cards. The back of the unit is easy to gain access to, though the cover on my mine is quite difficult to re-secure to the device due to somewhat poor clips.

The V7 is powered by a Snapdragon 210 (I didn’t realise they went that low, honestly) 1.1GHz quadcore chip with 1GB RAM and 16GB storage. Commonly devices touting a gig of RAM are bundled with 8GB of internal storage, so doubling it is a nice touch. The screen is a 5″ 720p display that uses Dragontrail glass instead of the more popular Gorilla Glass, but it comes with a factory-fitted screen protector. Underneath the screen sit capacitive buttons which still seem to be a thing in 2017.

The headphone jack (yes, it has one!) and microUSB charging ports sit on the top of the phone, while the power and volume sit down the right-hand side. The buttons are clicky and don’t feel cheap, another nice touch for a budget device.

On the back sits a 13MP camera, which is adequate, though not particularly impressive. The front camera is even worse at 5MP, though admittedly I’ve seen front facing cameras with a much lower resolution. Here’s a sample from the rear camera.

On the bottom sits a mono speaker which is quite loud, though by no means the loudest I’ve heard, and finally while it benefits from Bluetooth 4.0, WIFI is limited to 2GHz and there’s no NFC – so sorry, no Android Pay on the V7.

Software

The V7 ships with 6.0 Marshmallow and a light skin. Besides the hexagonal icons and an additional setting or two, the device is pretty much stock. Given the low-end processor and limited RAM, limiting the skinning was definitely a wise choice.

Performance is more than adequate; I found doing the day to day activities of browsing the web, checking mails and browsing twitter perfectly fine, though more media-heavy apps such as Facebook do suffer the occasional stutter.

The most interesting aspect of the unboxing was the way in which FreedomPop set it up – on powering the device up for the first time I was greeted immediately with a home screen; no first-run Wizard and no indication at all this is how it was supposed to be. FreedomPop appears to take each device, run through the Wizard without adding any accounts and then install their apps via APK (by enabling unknown sources) before then shipping the device out.

My first thought was someone has messed with this device before factory resetting it and starting fresh. This, unfortunately, wipes out the apps FreedomPop pre-loaded, but luckily I took a backup of the APKs just in case (I’ll link to them at the bottom for others who have done the same).

At the point of resetting I also got a taste of just how slow the device can be. Something that takes a couple of minutes on higher-end devices took around 10 minutes to complete on the V7, it spent an uncomfortable amount of time on the V7 boot animation following the reset which had me wondering if it may be looping.

Additionally while discussing the odd way in which the device was set up, I also notice encryption is disabled by default, a setting that likely coincides with the low-end processor, though after enabling encryption I saw no particular decrease in performance. Given the benefits of encryption, I’d certainly always enable it when the choice is presented and you should, too.

Battery life

I’ve only been using the device for a couple of days so haven’t had much of a grasp on battery life. It does at the moment with limited use last well over a day despite the small battery (the HD screen and low-end processor definitely play a part here).

Enterprise use

Given the low price, it may be tempting to order in bulk for enterprise deployment. Like many low-end smartphones, once loaded up with enterprise applications, encryption enabled and a management agent running frequently in the background, battery life and performance may suffer. It certainly seems more capable than some of the older low-end Samsungs (The Ace and Young line of devices were horrible) but should be thoroughly tested under all corporate use-cases before deployment.

Being Android 6.0.1 it does indeed support Android Enterprise (AfW) out of the box and managed Device Owner mode without much fuss. Under normal circumstances however (enrolling them without AE), don’t expect to be able to control much, and don’t expect much reliability in pushing payloads.

In other words, embrace Android Enterprise or don’t consider this device.

Conclusion

At £59 with free mobile service for life*, the V7 is a pretty compelling offer. It doesn’t wow on any front particularly, but it is a cheap, cheerful and capable device for day to day usage for those who wouldn’t consider themselves power users.

As for FreedomPop’s provisioning, I’d have hoped for better; sending out devices somewhat pre-configured with no notes to say why the device isn’t presenting the first-run wizard may lead to confusion and concern. Moreover, sideloading APKs and leaving unknown sources enabled is bad practice and not secure. They need to be working with v7 to have their apps preloaded into a factory image, or provide instructions for how users can set the devices up themselves.

If you buy a v7 through FreedomPop, I’d suggest factory resetting it on receipt, you can then reinstall the missing apps by downloading the following zip:

FreedomPop Apps

*This is what they say, how long it actually lasts we’ll have to wait and see, though it’s been a few years so far. The free for life offer includes 200 minutes, 200 texts and 200MB data.

Have you bought a FreedomPop V7? Have you purchased it through V7 directly? Let me know your thoughts on the device in the comments, @jasonbayton on twitter or @bayton.org on Facebook.

Vault7 and the CIA: This is why we need EMM

2017-03-16T14:20:34Z

In a post-Snowden world, the recent Wikileaks dump exposing myriads of vulnerabilities and the tools the CIA use to exploit them across iOS, Android, Windows and the wider connected ecosystem shouldn’t be all that surprising. This is, after all, what these secretive government agencies do in order to do their jobs effectively. A look at my last This is why we need MDM article shows this mentality is widespread throughout various agencies.

Some may be focusing on the ethics of their behaviour here, but there’s a more concerning issue at hand; in making this information available to the public, Wikileaks has armed the general population with some of the tools necessary (Wikileaks redacted a number of them) to do everything the CIA, GCHQ and the others have been doing with alarmingly little effort, and this is bad.

Impacted companies are rushing to patch the previously undisclosed vulnerabilities with Samsung, Microsoft and Apple having all responded in the hours following the leak:

We are aware of the report in question and are urgently looking into the matter

– Samsung

We are aware of the report and are looking into it

– Microsoft

While our initial analysis indicates that many of the issues leaked today were already patched in the latest iOS, we will continue work to rapidly address any identified vulnerabilities.

We always urge customers to download the latest iOS to make sure they have the most recent security update

– Apple

Google, whose Android OS is one of the most fragmented in existence, followed up later with the following:

As we’ve reviewed the documents, we’re confident that security updates and protections in both Chrome and Android already shield users from many of these alleged vulnerabilities. Our analysis is ongoing and we will implement any further necessary protections. We’ve always made security a top priority and we continue to invest in our defenses

– Google

While investigations and patches are underway, both individuals and enterprises are exposed to a risk much greater than just Government snooping. Once again and for the second time in just over a year, this is why we need EMM – Enterprise Mobility Management.

Managing and securing a mobile estate with EMM

There are a number of measures that can be taken to minimise the fallout from this event. Even if it’s almost impossible to make the devices impervious to the vulnerabilities exposed, it isn’t difficult to make valuable corporate data much harder to steal. With EMM the capabilities are there, it’s just a case of implementing them.

Evaluate the estate

Every device enrolled onto an EMM platform reports its operating system, OS version, patch level (where applicable), and many other valuable attributes by default. EMM administrators, utilising the information in the leak, can identify the most at-risk devices in the estate and act upon this. For iOS the majority of vulnerabilities were identified at iOS 9 and below, for Android, version 6.0 and below.

Update or replace

Over 80% of Apple devices on the market are running the latest version of iOS and therefore pose the least amount of risk in the mobile estate, broadly speaking. Naturally the enterprise market isn’t known for pushing updates as soon as they land, but for enrolled devices, EMM administrators can identify and strongly encourage device owners to update to the latest iOS release. Those that can’t be updated to iOS 10 are likely old enough that replacement may be a viable option.

For Android this is a little trickier:

With the majority of Android devices sitting between Lollipop (23.1% v.5.1) and Marshmallow (31.3% v.6.0), even bought new today, device replacement may not be viable. It’s not all bad news however; from Android Lollipop Google began pushing security updates on a regular basis in order to tackle the worst vulnerabilities as they’re discovered. These updates are distributed independently of OS updates, allowing Google to push them out in a controlled, reliable fashion using Play Services.

EMM platforms should be logging patch levels of enrolled Android devices, so utilise this information to ensure devices are up to date. Those that are not updated often may not be secure enough to remain in the organisation.

Android devices under version 5.0 should be flagged for replacement as once again they’re likely end of life, exceptions being for rugged devices being actively developed and known to be secure – this may or may not be easy to verify but needs to be established with the respective manufacturers.

While evaluating the devices to replace, use the opportunity to form a new business case for the devices the business should support. Perhaps opting only for devices that support encryption, Android for Work or KNOX, etc. Once a clear process is in place, it will be much easier to support the estate in future.

Prevent (re-)enrollment

Particularly relevant for BYOD environments, where simply replacing a device may not be within the power of the enterprise, deciding where to draw the line on supported OS versions can mean the difference between keeping data secure on a device and leaving it wide open for attackers to take at will.

Most EMM solutions are capable of blocking enrolment for devices below a certain OS version across various platforms, or particular platforms entirely. It is down to the administrator and the business to assess the risk in order to decide what end-users are no longer allowed to enrol (even if their Gingerbread tablet is perfect for email).

If as part of the update or replace undertaking devices not belonging to the company were unenrolled/retired, the above will ensure they cannot be re-enrolled, saving the EMM admin from having to check for disallowed OS versions on a regular basis, only returning to make changes as versions become unsupported in the future.

Secure the estate

With the out of date devices removed from the equation, it’s time to start implementing stricter control over the devices that remain. These devices, as it happens, will support the implementation of a lot more of the below recommendations.

Enforce encryption

Modern devices support encryption by default, though it may not be enabled out of the box. By enforcing encryption across all devices in the estate, it adds a base level of security, protecting the data at rest on the device from unauthorised access.

Optionally additionally enforce SDcard encryption to prevent the access of external media from any device but the one that encrypts it (if SDcard storage is permitted).

Keep in mind: Encryption may reduce performance and for lower-powered devices this may be more noticeable to end-users. Additionally, the encryption process can be slow and time-consuming. Ensure the policy isn’t applied at 9am on a work day if end-users rely on devices for BAU responsibilities.

Containerise corporate data

As long as corporate data resides within the user-space of a device it will always be at risk; the data can be accessed using file managers, emails can be copied and forwarded to other accounts and confidential information may be stolen if the device is compromised.

Containerisation adds an additional layer of encryption and, as the name suggests, encapsulates corporate data and applications within a secure container environment on the device which cannot be accessed using typical applications. In combination with DLP (data loss protection) preventing screenshots, copy/paste, opening documents in apps outside of the container and more, it’s possible to ensure corporate data is fully secured.

EMM platforms generally offer the same type of deployment – the platform distributes an application which will usually be passcode-enabled. Within this app end-users will find their corporate applications (like email, in-house apps, a secure browser and more), and data (typically secured both at rest and in transit). Attempting to access corporate apps and data outside of the container is simply not possible.

Other solutions such as Android Enterprise secure corporate data on another device profile while integrating the corporate applications directly into the current user space to offer a seamless experience. Samsung takes Android Enterprise a step further with KNOX, offering hardware-backed secure workspaces and device attestation certified for government use.

Excluding Android Enterprise which doesn’t currently support a passcode requirement, gaining access to a container-enabled device isn’t good enough to obtain corporate data. The device in question would effectively need to be compromised twice for a breach to occur.

Restrict device functionality

Utilise EMM lockdown/restrictions profiles to prevent end-users from enabling device functionality that may be considered risky, for example:

USB debugging
App installation from unknown sources
iCloud backup
USB mass storage (accessing the device filesystem via USB cable connected to a PC)
Developer options
Airdrop
iCloud Keychain (storing passwords in a personal iCloud account)

Even with corporate data containerised, preventing things like USB debugging and developer options will further harden the device against threats inadvertently introduced by the user while preventing APK sideloading (unknown sources) prevents installation of potentially harmful applications from outside of the Play Store. Similarly preventing the storage of data and passwords in iCloud reduces the attack vector should that account be compromised.

Block access to corporate data

Particularly in iOS where the end-user can manually override some EMM-enforced settings, but also if a device fails to encrypt or an end-user roots/jailbreaks a device, it is inevitable occasionally a device may not fall in line with corporate requirements. In this case it will be considered out of compliance.

Compliance rules may be put in place to block or quarantine an already-enrolled device on the EMM platform, preventing further access to corporate data until such time the device is either fixed, updated or replaced (the EMM agent on the device should explain why the action was enforced). This automated access control is a nice way to strongly encourage an end-user to resolve the out of compliance state (as noted in update or replace above) without admin intervention. As soon as the device is compliant, all blocks are lifted.

For more serious matters, such as the device being rooted or jailbroken, the device can be automatically partially or fully wiped. This is necessary as once the device is compromised it’s very difficult to trust the integrity of the device and its data.

Keep in mind by enforcing these automated actions, the end-user may be unable to undertake their BAU responsibilities and a support request will likely follow.

Conclusion

Although nothing is impenetrable given enough time and effort, EMM platforms offer simple, effective management and security enforcement across the whole mobile estate. In combination with modern, supported devices and the right balance between security and user freedom, it’s entirely possible to mobilise the workforce while ensuring corporate data is secure.

As situations such as Vault 7 become more common and mobile device usage across the world continues to increase exponentially, any organisation serious about securing corporate data needs to have an Enterprise Mobility Management solution.

The mentioned features above are only some of many capabilities of an EMM solution and by no means cover a fully managed deployment. In addition, this doesn’t cover additional tools such as Threat Management.

Does your organisation use an EMM solution? Are you concerned about the latest Wikileaks dump? Are you prepared? Let me know in the comments!

As always I’m @jasonbayton on Twitter, +JasonBayton on Google+, /in/jasonbayton on Linkedin or @bayton.org on Facebook. You’re also welcome to leave a comment below or send me an email. Free free to get in touch to discuss this or any other topics you have in mind!

What is Android Enterprise (Android for Work) and why is it used?

2017-02-26T20:08:43Z

Although I talked about iOS Supervision in a previous post, Android is where I’ve firmly hung my Enterprise Mobility hat over the years. This is mostly due to my experience with Android stretching all the way back to the days of the first Android phone, but generally because I tend to enjoy using Android far more than other mobile operating systems.

In the enterprise I come across Android frequently; while iOS is often allocated to the C-levels and higher management, usually employees lower down the corporate ladder are provided Android handsets.

It makes sense really, although there are many flagships competing directly with Apple, there are even more directly targeting the mid-to-low end of the market at very attractive prices – perfect for mobility on a budget, right?

Up until relatively recently, not really.

A little backstory

EMM (Enterprise Mobility Management) platforms rely on APIs to communicate with and control managed devices. Things like disabling the camera, bluetooth or preventing access to system settings are all individually exposed via one or multiple APIs. This is important to know and it’s not limited to Android.

The difference is while iOS, Windows Phone, QNX (BlackBerry) and others include these APIs with their respective operating systems and system applications, for many years Android did not, or offered very few – certainly not enough to consider manageable by any stretch.

But that wasn’t the end of the world. Because Android is open source, manufacturers can build upon it and tweak it as much as they see fit. While other manufacturers tested the waters, offering some API functionality here and there, Samsung saw the gap in the market and devoted resources to making a splash.

And it paid off.

Today Samsung are by far the strongest Android device manufacturer for the enterprise due to their early efforts and not only that, they’re the most-supported Android manufacturer for EMM solutions. Other manufacturers have since added APIs to try and compete but compared to Samsung with SAFE (KNOX) and KNOX Premium, there’s really no comparison.

The downside is how Samsung deploy their APIs; the more expensive devices tend to get the newest versions of SAFE, while the mid-market and budget have to endure older versions, occasionally causing confusion (if they’re all 2017 models, why don’t they all have the same management capabilities?) and often meaning the newest EMM functionality won’t work with the cheaper devices as well (if at all).

The same goes for system applications, too. EMM requires APIs in order to push PIM data to the email, contacts and calendar apps on devices. For a long time it was either not possible or very unreliable to try to push Exchange data to a mid-range HTC, for example, and near impossible on other devices. Finding devices besides Samsung that could be reliably managed was no trivial task – eventually 3rd party apps such as K9, touchdown and many others began showing up offering EMM integration; for businesses only really needing basic management and PIM who were prepared to purchase licenses for these 3rd party apps, they could relatively safely look beyond Samsung.

And that’s really how it’s been up to recently, when it seems Google had taken notice of both the uneven playing field for enterprise device selection and a recurring perception that Android security is somewhat lacking.

Enter Android Enterprise

Or, as it was up until fairly recently, Android for Work.

Android Enterprise debuted with 5.0 Lollipop in 2014 as an optional* solution manufacturers could add to their OS builds in order to integrate a common set of device management and EMM APIs. From 6.0 Marshmallow it was no longer optional and has since been a mandatory component for all manufacturers.

Android Enterprise (AE) offers a few things:

A reliable EMM experience, knowing when a configuration is pushed, all AE devices will support and execute the relevant requests
A containerised work/life separation primarily aimed at BYOD
A Device Owner (DO) mode for complete corporate ownership
A unique Google Play for Work portal offering a corporate Play Store with only IT-approved applications within.
App configs, a way of deploying corporate settings on work apps
Mandated device encryption

With the introduction of 5.0 Lollipop Google also made user profiles available to phones in addition to the tablets that had already had it. Using the same underlying functionality Android Enterprise is able to create a managed user profile that although sits entirely separately encrypted on disk, integrates directly with the current user on the device in order to provide both personal and work applications in the same app drawer – the latter indicated by a briefcase:

Source: arstechnica.com

There are two ways of enabling Android Enterprise, the first and original is through a GSuite managed domain that requires either an existing GSuite subscription or a free single-user account used for little more than initial setup. If domain verification hasn’t already been done through GSuite, the business will need to undertake a couple of tasks to prove they own the domain they’re setting AE up against.

The second and newer method is Android Enterprise Accounts and works with any Gmail account – No domain verification required, takes practically minutes to set up and Google manages the individual Android Enterprise accounts on the managed devices, meaning there’s no need for additional Gmail or GSuite user management.

Whichever method is used, it’s then possible (but not necessarily required since GSuite has basic EMM functionality) to link one of many existing EMM platforms which support AE (even Intune!) and configure the corporate Play Store.

Some EMM platforms don’t make use of the Enterprise Play Store application and instead manage apps through the integrated EMM app catalogue as has always been traditionally available, an example would be MobileIron:

Notice the briefcases on managed apps? Source: bayton.org, photo: MobileIron Core 9.2

The benefit of utilising an EMM platform for app management is app config, making it extremely easy to tailor applications to the business for immediate use on deployment, no additional end-user config required:

Source: bayton.org, photo: MobileIron Core 9.2

For EMM admins the above config may look familiar, though apps like Chrome offer far more granular functionality around permitted domains, browser functionality and more.

When Android Enterprise is deployed, it looks something like this:

Source: bayton.org, photo: Android 6.0 BYOD Android Enterprise

The mix of work and personal apps together on the above BYOD handset demonstrates the level of integration; as an end-user it feels like just another few apps installed, despite the underlying profile configurations working to separate and secure that corporate data. Should an enterprise wipe be issued, it simply removes the AE profile and leaves all userdata untouched.

The BYOD model isn’t quite perfect yet, with the feedback most commonly circling around the lack of additional authentication.

Consider BlackBerry’s Good, MobileIron’s Apps@Work or AirWatch’s Container. With these containers they sit as apps on the device and when opened, can be configured to require a PIN or passcode to unlock the enterprise content within.

AE doesn’t support this yet but it’s on the horizon. Until then, once the user authenticates with the device (via lockscreen) the enterprise data is available without any further authentication. DRM policies can prevent the transfer of enterprise information outside of the container environment, but it’s still possible to see it if the user’s lockscreen passcode is compromised.

Furthermore, the ability to pause (temporarily turn off) the work profile for evenings, weekends or holidays is occasionally promoted, but I’ve found the implementation to be inconsistent across devices and scenarios; sometimes I can indeed turn it off as described, other times the best I can do is disable sync under Settings > Accounts.

Diving deeper with Device Owner mode

With device owner mode there is no user space. As the intended use is for wholly company owned devices, DO removes any typically BYOD or COPE (Corporately Owned, Personally Enabled) scenarios and locks the device down strictly to the environment set by the EMM administrator.

Enabling DO mode is currently done on first boot of a new device – or one that’s been freshly factory-reset – using a provisioning app on a dedicated provisioning device (configured with EMM server details) and an NFC bump.

Depending on the EMM provider provisioning app used, the process will vary slightly in what agent is downloaded in order to enrol the device on the relevant platform.

DO mode strips out almost all applications from the device and utilises the authorised apps via EMM or Play for Work. Nothing more. This means should an app require Play Services to function, Play Services would need to also be authorised for use by the business – a scenario I’ve seen cause issues a couple of times.

Given the need for an NFC bump to get this enabled currently there are some limitations:

Much like Apple Configurator, all devices being provisioned are somewhat tethered to a base location – yes the provisioning device can be replicated elsewhere (it’s only the app with some environmental information) but it cannot be done remotely.
If the device is wiped, DO mode needs to be enabled again, otherwise it returns to a fully unlocked, factory-reset device
Devices not supporting NFC naturally won’t support the use of the provisioning app

Furthermore:

If issues are detected during DO enablement or EMM enrolment the device will factory reset with little to no feedback. This can be frustrating.
As mentioned above, initial app management may take some time to get right. Missing core apps may cause problems and as such the setup will need to be tweaked and tested before deployment.

Thankfully with the introduction of Pixel we heard the first mention of zero-touch, Android’s presumed answer to DEP, permitting Device Owner mode to be enabled remotely! Early signs of this are present in current Android versions, though it’s not fully enabled/supported just yet.

Conclusion

Hopefully the benefits of Android Enterprise have been adequately conveyed above. To summarise:

Prior to Android Enterprise the market was awash with inconsistent management capabilities across various Android manufacturers and app developers
Android Enterprise offers a set of consistent APIs for basic device management and app management
Android Enterprise securely separates corporate and personal data, or enables a purely corporately-owned profile without a user space
More features are coming in future to expand capabilities and enable remote provisioning

According to Google this is just the beginning. Their aim in the short term is feature parity between other offerings provided by the likes of Samsung and Apple, and long-term to far surpass the management capabilities of everyone else to make Android Enterprise the de facto choice for enterprise device management. Of course in doing so, they hope the perception of Android security improves in the process.

If your organisation has struggled in the past managing Android devices, are sick of dealing with Google accounts, are looking for more tools for entirely corporately-owned devices or anything else above, it could well be time to consider Android Enterprise.

*I mentioned the voluntary incorporation of Android Enterprise there because as 5.0 devices began showing up on the market, they were being bought with Android Enterprise usage in mind and seemingly found to be missing the needed APIs for reliable management. Not all manufacturers – particularly less popular ones – felt the need to add this new, optional functionality.

Does your organisation use Android Enterprise? Are you an admin? Feel free to discuss your deployment in the comments. End user? Let me know how Android Enterprise affects your daily life performing your job role.

Introducing night mode on bayton.org

2017-02-25T14:20:43Z

Deprecated

Night mode has been deprecated, at least in its current form, as it was negatively impacting both page loading speed, and because not all browsers support the “disabled” flag on CSS resources, it was defaulting dark for new visitors. This will be re-addressed in future, likely in line with a rebuild of the theme.

I spend a lot of time on here, particularly at night when I’m finished with my duties for the day and fancy putting some words down on virtual paper. I’ve noticed, however, the glare of the bright, minimal theme can be quite bothersome on the eyes after a while.

Always eager to improve the site, I set about looking for a solution.

I didn’t want to make any permanent changes to the current theme that would detract from what it is; the current white-on-grey design is really nice and it’d be a shame to tone it down for the sake of a few hours a night.

With that in mind, I decided to implement a more elegant solution; changing the theme colours based on time of day while allowing a manual override stored in browser local storage (meaning the option chosen remains saved until site data is cleared from the browser).

The end result looks like this:

It’s been live for about a month, but I’ve been tweaking it too frequently to officially announce it. There’s still a few areas of improvement (buttons, etc) but it’s good enough for now.

The implementation is a mix of CSS, CSS transitions and jquery. Ideally, I’d have preferred to implement this in PHP to be served prior to the page loading, but since PHP only knows the server’s local time and not that of the guest browsing the site it isn’t as easy to implement (though I’ll take advice in the comments!). This means the page will always load the default white theme, then darken when jquery is ready.

There wasn’t anything particularly complex about the implementation, I created my dark CSS file and added it to the header in a disabled state. I then used jquery to control when the CSS is enabled based on time of day as reported by the guest’s browser.

The dark/light indicators to the left of the menu use a similar jquery function when clicked to manually override the time-based theme, but obviously uses onClick rather than being time-based.

In the main CSS I added CSS transitions to introduce a fade effect rather than instantly changing back and forth. I prefer it this way, though it’s obviously subjective.

Now whenever you log onto bayton.org between the hours of 9pm and 8am, you’ll be greeted with a darker theme. Don’t like the colours displayed? Just click the icon to the left of the menu to select your preferred theme and it’ll be remembered for as long as you don’t clear browser storage.

At some point I’ll look at implementing sunrise/sunset detection to replace the hard-coded times, but that’s a little far off yet. In the meantime I’ll fix up the last few niggles and see if I can’t get the implementation a little more seamless.

Like the new theme option? Hate it? Think you can improve it? Let me know in the comments! I welcome feedback on this or any other aspect of the site – my goal is to make it as easy to read and enjoy my content as possible, if anything is preventing that please let me know.

What is iOS Supervision and why is it used?

2017-02-23T19:48:23Z

Looking for Android enterprise?

This topic discusses iOS Supervision. If you’re also looking for Android enterprise (Android for Work) please click here.

Introduction

As someone who deals with mobile devices in the enterprise on a daily basis, I often encounter customers looking to purchase iPhones/iPads for their employees. Most of the time customers will have, or are looking to have an EMM (Enterprise Mobility Management) – or MDM (Mobile Device Management) – platform such as MobileIron, AirWatch, Soti, etc. to manage these devices, and that’s great.

The thing is, iOS devices are by default targeted more towards consumers, than enterprise. This means out of the box there are things we admins can’t remove or disable, such as:

iMessage
Activation lock (“find my iPhone”)
Factory reset
Airdrop/Airplay
iBooks

For anyone who’s been on the receiving end of an activation-locked iOS device, I don’t have to say how difficult it is to convince Apple to unlock it. For those unfamiliar, the last time I had to do so it involved rifling through 2 years of paperwork for a receipt showing the company I called on behalf of truly owned the device in question; it took days of effort, scans of documents showing the company as legitimate and many hours on the phone to Apple through multiple escalations – all because a device was wiped without the end user removing their iTunes account before leaving. A lot of businesses won’t go through this process and render the device a brick, writing off hundreds of pounds(/euros/dollars) in the process.

Furthermore, a number of settings can be configured via the EMM platform, but easily overridden by the end-user, such as GPS, bluetooth and others. The platform can set and reset these settings by pushing out configuration profiles but ultimately the end-user has control over the device, as Apple intended.

iOS devices aren’t unmanageable by any means, but compared to the likes of Windows Phone and some Android manufacturers (gradually improving now due to Android Enterprise) where pushing a setting usually guarantees it won’t be changed, dealing with iOS devices can be a little frustrating at times.

Enter Supervision

Supervision was introduced back in the days of iOS 5 as a way for the enterprise to enforce more control over corporately-owned devices. Even back then Apple understood the use of iOS in the enterprise was a growing market and they’ve been working at it ever since, gradually adding and improving restrictions with every release.

Having access to a Mac with Apple Configurator installed, it’s very simple to create a set of configuration profiles to do a few things, including:

Skip some of the initial setup assistant prompts when an end-user turns the device on for the first time
Preload applications through IPA files or via the public app store (including VPP)
Update or deploy a custom iOS release, either via a fresh install (ipsw) or by restoring a backup from another device
Prevent the iOS device from syncing with other computers
Enroll the device into a compatible EMM platform
Disable activation lock
Configure the homescreen layout
Prevent a factory reset

And plenty more. Even better, in combination with EMM, the act of putting the iOS device into Supervised mode alone means not having to spend time creating several configuration profiles; almost all EMM platforms on the market can take advantage of Supervision to enable/disable many of the options found in configurator over the air.

Source: bayton.org, photo: MobileIron Core 9.2

What remains after completing the Supervision process is a freshly installed (indeed, it performs a full reset – something to keep in mind) iOS device capable of being managed on a far more granular level than any out-of-the box iPhone or iPad, and subject to far fewer user-overrides.

Apple Configurator isn’t perfect

There are, however, some downsides with Apple Configurator.

The first major inconvenience is requiring physical access to the device being Supervised. It isn’t possible with Apple Configurator to do this remotely; for a large number of iOS devices having to be Supervised in bulk, that means making use of some pretty interesting (and potentially costly) setups to avoid being limited by the number of USB ports on the machine:

Photo: apple.bretford.com

Also, should a device require a wipe, whether initiated from an EMM platform or by the end user (should factory reset not be disabled, or they figure out how to recover it via iTunes), it will factory reset to a stock, vanilla, un-Supervised state allowing the end-user to continue as if they had received a completely unmanaged device. It requires a trip back to the Mac for another round with Apple Configurator before it can be sent back out again.

Configurator is therefore far better suited to small businesses or offices wherein the iOS devices never venture too far. Larger organisations or those with considerable field teams will potentially feel the burden of needing to return to base when something goes wrong.

Thankfully Apple has put some thought into this, and have come up with an elegant solution to overcome these hurdles.

DEP, the Device Enrolment Program

Launched in 2014 and gradually rolling out across the world, the Device Enrolment Program takes everything great about Apple Configurator and makes it zero-touch.

Starting with company enrolment into DEP, any devices purchased through Apple or an authorised reseller can be automatically assigned to the organisation’s DEP account and have configuration profiles pushed out wirelessly the moment the iPhone or iPad is turned on. What’s more, from the DEP console an EMM platform can be linked, offering an enrolment prompt on the device before the first-run setup even completes.

The biggest benefit? If the device is reset for any reason, being assigned via serial number to the DEP account means it automatically receives all configurations, EMM enrolment prompts and apps immediately on being turned on for the first time after the event. The only way to stop this is to remove the device from the DEP console (an irreversible action). Until then, the device is protected. This should theoretically greatly diminish the need to return to base.

The downside with DEP has been the potential inability to add every iOS device the organisation currently owns, be it due to device age (nothing before 2011) or the authorised-sellers requirement (directly via Apple or through an approved partner). This means if organisations have been using Apple Configurator up to this point, some devices may be unable to move over to DEP. For more recent purchases made through authorised channels though this won’t be an issue, nor will it be as of iOS 11, which introduced provisional DEP, the ability for organisations to manually add iOS devices into DEP via Configurator.

Additionally for organisations moving from Configurator to DEP, custom OS version and backup management functionality is not available, though for that use-case DEP perhaps isn’t suitable regardless.

Touching on VPP

When combining Supervision with VPP, the Apple Volume Purchase Program, wherein both free and paid app licenses (and books) can be obtained in bulk and assigned to the organisation, it’s no longer a requirement to even set up an iTunes account on the device during or after enrolment – apps are pushed down automatically from the EMM platform after linking the VPP account and licencing is taken care of in the background.

Apps can be silently pushed, removed and their licenses can be applied or revoked – returning to the VPP licence pool for the apps in question – at any point. This renders the need to expense enterprise apps completely moot and makes managing applications substantially easier.

Conclusion

Hopefully the benefits of Supervision, whether via Apple Configurator or DEP, have been adequately conveyed above. To summarise:

Unsupervised iOS devices pose a greater risk to the Enterprise due to the issues that arise with activation lock
Supervised devices offer more granular management, particularly for EMM platforms
Apple Configurator offers a quick and easy solution for small SME, testing, devices illegible for DEP or those that remain close to base
DEP offers much of the functionality of Apple Configurator, but entirely zero-touch, ready from the moment the device comes out of the box
VPP in combination with Supervision makes app deployment much, much easier

If your organisation has struggled in the past with activation lock, iTunes account management, end-users overriding corporate policies or anything else above, it could well be time to consider Supervision.

Hands on with the Galaxy TabPro S

2017-02-10T22:13:14Z

The 2-in-1 market has been heating up tremendously over the last few years with contenders such as Microsoft, HP, Asus, Lenovo and many, many more all turning out impressive devices that challenge the traditional laptop-tablet divide. Although ceasing production of laptops, Samsung’s tablet offerings have gone from strength to strength, arguably being ahead of the game for a number of years.

Although not the first Windows tablet Samsung has released, the converged market offered a perfect opportunity for them to bridge the divide by bundling a keyboard with their latest offering. With it they’ve secured a nice corner of the market for themselves with what I’d consider to be one of the thinnest and lightest 2-in1’s I’ve ever used.

Over the New Year the price of the TabPro S was significantly reduced (no doubt to clear stock for the yet unannounced TabPro S2) from a whopping £849 down to a far more reasonable £500. After giving up on the Linx 12V64 I jumped at the chance to try one out. Now over a month later, here are my thoughts.

Hardware

Like many Samsung tablets, the TabPro S is a mixture of metal and plastic; while the outer rim of the device feels exceptionally premium with its aluminium frame, the back is the typical, slightly flexible plastic. Admittedly it’s almost never seen with the keyboard in place but at the price Samsung launched the TabPro for I’d have liked to see an all-metal finish akin to the Surface. Unlike the Surface however, the TabPro does come with a keyboard as standard (but no pen, that’s sold separately for a hefty £45 at the time of writing. I have one on the way..).

Across the top of the device are the power and volume buttons. Down the left is the physical start button (which is still a thing) and on the bottom sit the pogo pins for the keyboard. The physical buttons on the TabPro are satisfyingly clicky and responsive.

As far as physical dimensions go, it boasts 290 x 198 x 6.3mm and 693g – it is unfathomably thin and light, largely thanks to the 2.2GHz dual-core Core-M under the hood requiring passive cooling rather than needing to run a fan, even under load (though it does get rather warm to the touch occasionally). The keyboard case adds very little bulk when connected also, resulting in a tablet that always feels like I’m carrying almost nothing around when travelling.

In terms of ports, there’s really nothing to list. It has 1 USB type C port and a headphone jack.

That’s it.

Being somewhat vocal about Apple’s decision to limit the ports on the new MacBooks obviously this is even worse; with only one port I have to decide between charging the tablet or doing basically anything else. Naturally there are dongles, but I haven’t gotten around to picking a decent all-in-one dock just yet. On the plus side, the port supports quick-charging, offering a full charge of the 5,200mAh battery in a couple of hours.

I found the camera situation to be rather pleasing. In my last review I wrote:

I often feel with tablets this is the wrong way around; I, like many, won’t take photos on a tablet for a few reasons and therefore don’t make use of the better rear sensor, while video conferencing with family and colleagues tends to suffer by comparison.

The TabPro S boasts a 5MP camera on both sides. They’re as good as each other! This means whether you are indeed taking a photo at the zoo or conferencing a team remotely you can guarantee the exact same picture quality and resolution. Thank you, Samsung!

Battery life & performance

On a full charge I generally see a full day of mixed use (and often more since I have another laptop for work during the 9-5). Under more intense usage I can watch the battery slowly draining away significantly faster, though this isn’t a recurring scenario and still offers me better battery life than most of my other devices.

On the inside, as mentioned above, the TabPro S uses a 64bit dual-core Core-M processor with 4GB RAM and 128GB storage. Under normal usage (writing, browsing, image editing, etc) it’s more than capable, however I do occasionally notice Chrome tabs reloading in an effort to manage with the limited memory available. In an ideal world and certainly for the price I’d have hoped to see 8GB RAM; it’s not a costly upgrade for a manufacturer and makes all the difference in the world to the experience for consumers. Alas, I’m not prepared to pay out the extra required for the Gold edition (which also boasts a larger SSD), so 4GB will have to be enough.

Over all I haven’t noticed any considerable slow-down, stutter or otherwise poor performance in daily usage. It’s worth mentioning the usage I’m referring to is almost identical to that of which the Linx 12V64 was subject to, and that did suffer pretty considerable performance issues. I’ve been very pleased with the TabPro by comparison.

Screen

The 12″ FHD+ (2,160 x 1,400) sAMOLED screen is easily the best looking display I’ve used on a Laptop/2-in-1 device to date. Colours are vivid (if a little oversaturated), bright and offer excellent viewing angles. At this resolution images are crisp and clean. It’s a stunning display to work with.

The sAMOLED panel is unique in this market otherwise filled with IPS and TN displays, but it comes at a cost; Samsung’s power management defaults to dimming the display after 30 seconds of inactivity by default, a rather irritating “feature” when watching a video or reading a long-form article. This is done to lengthen the life of the panel, one that is otherwise susceptible to screen burn-in if not properly taken care of. Thankfully Samsung allow this to be extended to up to 10 minutes which is more than enough for me generally, though those doing presentations or watching longer videos will still suffer. It’s not possible to disable it entirely.

For me, it’s a trade-off I can live with; for the benefits of sAMOLED I’m prepared to more actively care for the panel.

Keyboard

Unlike other 2-in-1’s the TabPro S comes with a keyboard out of the box. No additional cost. When considering the Surface Pro keyboard is around the £100 mark on top of the already expensive tablet itself, it’s satisfying to have one included in the price with the TabPro.

It’s a little more than a keyboard too as it acts as a folio case, protecting both the front and the back while propping the tablet up in 2 distinctive angles for easy viewing. It attaches to the tab with reasonably strong magnets and stays put quite well.

Admittedly it took me a couple of hours to get used to the compact layout, the Surface keyboard benefits from spacing between keys however this is not the case with the Samsung. All the same once I was used to it there was absolutely no issue. I do find the angles to be slightly too extreme in many circumstances; sitting it upright for example is a little too upright on anything but a flat desk, and laying it on the lower angle I’ve found is only really super useful for typing in bed, on a lap or anywhere else I’m not necessarily sat up straight.

There’s also the issue of balance. As the tab is only held up by magnets any decent knock has the potential to push it out of place, causing the tablet to topple over; it could definitely benefit from a little more work here as a couple of times I’ve moved the tablet about on a desk or chair with a little too much haste and had to catch it mid-fall.

The keyboard itself has minimal flex, ample key travel and is very responsive. I thoroughly enjoy typing on it.

Conclusion

At the original list price of ~£849 I considered it far beyond my humble budget, instead looking at more conventional laptops with far better spec for the same price. Even now at between £649 – £700 on Amazon it feels quite costly.

On the other hand it’s cheaper (currently) than a similarly spec’d Surface Pro, particularly as it comes with a keyboard folio case out of the box, and is possibly one of the thinnest and lightest 2-in-1’s I’ve ever laid my hands on.

The hardware under the hood will by no means blow anyone away, though for what it is and what it’s designed to do it excels. If I had the choice between the TabPro S and the Gold Edition with additional RAM before purchasing I would have naturally opted for the better spec, but the tab doesn’t feel as though it’s struggling and therefore isn’t a cause for concern to me.

Since purchasing the TabPro S I’ve put my other laptops up for sale, they’re now surplus to requirements as the TabPro S does literally everything I want in a portable device and is so easy to carry around I rarely feel the need to opt for anything else.

Do you have a TabPro S? How are you getting on with it? Let me know in the comments, @jasonbayton on twitter or @bayton.org on Facebook.

Introducing Nextcloud demo servers

2017-02-10T01:21:27Z

I’ve previously written the very well-received Nextcloud guide offering one of the most complete start-to-finish installation guides available currently. I also reviewed the Nextcloud Box back in October and have since launched my Nextcloud hosting endeavour, but with my knowledge in virtualisation and Linux felt I could do more to give back to the project that serves me so well both personally and professionally.

With that, today I’m launching a collection of demo servers offering completely vanilla installations of the most up-to-date versions of Nextcloud 9, 10 and 11. They’ll naturally be kept updated with point releases and when required I plan to launch new servers for Nextcloud 12, 13, etc.

Obviously an official demo server already exists running the latest version for Nextcloud and also includes collabora integration, however there’s no harm in offering more than one option (on likely vastly different hardware) and the NC project doesn’t host demos of previous supported versions.

The goal is to provide a testing ground for new and existing Nextcloud users, those locked to an older supported release due to corporate policy or politics (who may wish to present the benefits of a newer version without spinning up an instance), and to simply demonstrate the evolution of Nextcloud across major releases – the speed difference between version 11 and the older releases for example is very apparent.

Each server has been set up using my guide and so benefits from caching via Redis & ACPu, SSL connectivity and pretty URLs.

The servers are set to refresh on the hour, every hour so offer up to 60 minutes of testing (this may be changed in the future) before all data and configuration settings are wiped and reset back to a vanilla installation.

Credentials

Both the user and password are admin across all installations.

Links

Nextcloud 9
Nextcloud 10
Nextcloud 11
Nextcloud 12
Nextcloud 13
Nextcloud 14

Technical info

The installations run in LXD containers, each container is a full Ubuntu 16.04 LTS deployment with Apache, PHP 7 and a shared MariaDB container running separately (I’m also looking at potentially using a single Redis server rather than running a unique instance within each container).

Utilising ZFS and snapshots, the containers accessible via the links above are replicas of snapshots created from “master” containers. On the hour, the Nextcloud containers are destroyed, re-cloned and restarted, while the databases are overwritten with vanilla backups. This process takes about 30 seconds and is done in series, meaning only one server is down for about 10-15 seconds at a time. Here’s how the very simple bash script looks:

#!/bin/bash
lxc delete --force nclive-9
lxc copy nextcloud-9/snap0 nclive-9
lxc exec mdblive -- mysql nextcloud9 < /media/resources/nextcloud9.sql
lxc start nclive-9
sleep 1
lxc delete --force nclive-10
lxc copy nextcloud-10/snap0 nclive-10
lxc exec mdblive -- mysql nextcloud10 < /media/resources/nextcloud10.sql
lxc start nclive-10
sleep 1
lxc delete --force nclive-11
lxc copy nextcloud-11/snap0 nclive-11
lxc exec mdblive -- mysql nextcloud11_1 < /media/resources/nextcloud11.sql
lxc start nclive-11
sleep 1
lxc delete --force nclive-12
lxc copy nextcloud-12/snap0 nclive-12
lxc exec mdblive -- mysql nextcloud12 < /media/resources/nextcloud12.sql
lxc start nclive-12

Doing this process rids the servers of any uploaded files, as well as resets the databases back to a clean, like-new installation. I toyed with the idea of omitting the re-cloning of the NC servers in favour of a bash script to clean out the data directories, but restoring from snapshots feels cleaner if a little more arduous on resources.

As the dedicated server uses a single public IP, the LXD host runs an Apache proxy to direct traffic to the private IPs of each container based on hostname. The benefit of this is enabling SSL for any number of unique containers can be done by excluding the .well-known directory from being proxied in the Apache vhost config, ensuring when LetsEncrypt tries to perform verification, it can create all verification entries on the LXD host rather than needing to be run manually or on each container. Verification traffic – being excluded from the proxy – terminates on the host where the verification files sit and is therefore far more convenient. Excluding traffic from the Apache proxy is as simple as the example here:

<strong>ProxyPass /.well-known !</strong>
ProxyPass / http://10.11.12.2/
ProxyPassReverse / http://10.11.12.2/

Ensure the exclusion is listed above the remaining proxypass rules, otherwise it won’t be executed.

The future (to do)

As the server deployments are brand new and a little raw, there will no doubt be some minimal downtime for maintenance and optimisations here and there. If the server fails to load, give it a few minutes and try again.

~~I’m also working on a maintenance page for the moments the servers are down while being refreshed, as currently Apache will simply throw a (pretty ugly) error.~~ Completed 27.03.17

In addition to the hosted demo installations, I’m aiming to also make LXD images available for all major versions at some point soon to allow simple, direct download of fully configured Nextcloud LXD OS containers, save having to install Nextcloud manually; a little like the official VMs but on a much, much lighter hypervisor.

When ready, LXD users will be able to add the hosted public repository and pull a Nextcloud container down as follows:

lxc remote add nextcloud demo.nextcloud.bayton.org --public
lxc launch nextcloud:nextcloud-11 local-nextcloud-server

29.03.17: A demo for Nextcloud 11 is available as an LXD image, details here.

Feedback welcome! I’d be interested to know if any issues crop up with the servers, how they’re being used and what can be improved following a period of testing on any of the installed versions.

Part 4 - Project Obsidian: Obsidian is dead, long live Obsidian

2017-01-15T15:25:53Z

Just tuning in?

This is a multi-part build log for Project Obsidian: a ~~low power~~ Ubuntu 16.04 LTS NAS & container server.
You’re currently viewing part 4. Head over to the introduction for context and contents.

A new direction

It’s worth mentioning before I go any further that Obsidian has been up and running since around August last year in one way or another – decommissioning other builds (more below) left me no choice as maintaining two systems ultimately doing the same thing was only going to lead to problems. It hasn’t been perfect however, leading me to re-evaluate my wants and needs for the build as 2017 approached.

At the end of part 3 I mentioned being unhappy about splitting disks over a PCIe card and the motherboard. I was also concerned that, having decided on ZFS for my RAID filesystem, the motherboard I’d selected in part 1 wasn’t capable of supporting Error-correcting code (ECC) memory – a very much recommended type of computer memory for ZFS due to its ability to detect and correct corruption in RAM before it’s written to disk. What’s more, the motherboard supported only 16GB maxed out; ZFS being the memory-monster that it is ate this up very, very quickly (improved with optimisations, but not ideal) and left me feeling like I needed more from the system than I was getting.

I resolved the disk situation; not long after the previous post in the series I managed to secure a Dell H200 SAS card boasting two 4-channel controllers and running in IT mode (no hardware RAID, simply JBOD or “Just a Bunch Of Disks”). With support for all 8 4TB disks (the number has increased..) without the need for splitting them across multiple controllers this card is ideal.

The lack of ECC support and the limitation on the amount of RAM supported by the motherboard however was a bit of a dead-end for the project, so something needed to change.

In searching for a motherboard that did support ECC I kept finding myself being directed towards ASUS. Their boards all generally support ECC by default despite not being heavily advertised. With ECC being more of an enterprise feature it didn’t leave a lot of choice on the consumer market without paying extortionate amounts for high-end motherboards, so it was ultimately ASUS I focused on.

Looking at the available options I saw a familiar board; my 2014 build had the ASUS M5A78L-M/USB3 which comes with ECC support built in, something I’d been completely unaware of up to this point. I figured I could dismantle the 2014 build (currently serving as a desktop PC in the office), move the key components to the 2015 build (already dismantled as shown in previous posts in the series) to take over desktop PC duties, and then utilise the 2014 motherboard for Obsidian.

The downside to this? The 2014 build motherboard is mATX, quite a bit larger than the mITX board in Obsidian and therefore can’t fit in the HAF 915 I opted for with this build. My first thought was to move the contents of Obsidian into the 2014 case, however with support for only 6 3.5″ disks natively and 8 with a 5.25″ adapter in the drive bays, the Fractal Define Mini simply wasn’t big enough for my 10 4TB drives and 2+ SSDs.

So a new case became necessary, and keeping with the Fractal theme I noticed the Node 804. It’s a case I’d seen advertised for some time and even requested for review a while back but unfortunately wasn’t something that came to fruition. With native support for 12 drives (10×3.5″ + 2×2.5″) in a compartmentalised setup while maintaining a wonderfully small footprint it meant no more behemoth cases would be required, and I could fit all of my components into a case much smaller than the other mATX+ supported cases I have on the 2014 and 2015 builds. Lovely.

I purchased the Node 804, 32GB of ECC RAM, a few additional cables and set about putting it all together. The finished product, minus some cable management, is below the revised parts list.

A new parts list

Motherboard

Gone is the ASRock in favour of the already-owned ASUS M5A78L-M/USB3. It’s currently trending for a little over £60 on Amazon though fluctuates often, I recall purchasing it for around £48 a few years ago during a sale.

The ASUS has 6 SATA ports, 2 PCIe slots (16x & 1x) as well as a couple of legacy PCI slots. It also has support for 32GB ECC RAM.

CPU

Due to opting for the ASUS board, the Hex-Core FX-6300 has moved over with it. This is a chip with a 125w TDP and as such any chance of saving a bit of cash on a low-power CPU is out of the window. The power in this chip does however offer one extra benefit – resource to manage KVM guests. I appreciate KVM isn’t LXD, but needs must and I had some pre-made VMs needing support (primarily for my EMM projects)

Passive cooling is also a lost cause on a 125w TDP, so the Arctic Cooling Freezer 13 CPU cooler moved over with the board. I have plenty of space in the case due to the dual compartment layout so may swap this for an all-in-one water cooling unit in the future.

The FX-6300 is trending at a little over £80 on Amazon and the Arctic Cooling Freezer 13 at £24 on Amazon

RAM

Ideally I should’ve opted for ECC memory however the board doesn’t support it. At a later date I’ll move the Ballistix into my desktop, swap the board with something a little more up-market and get as much ECC memory in as I can

Remember this from part 1? In hindsight waiting a couple of months before starting the build after eventually selling off some components to fund the improved specs would have been the best course of action. Alas, I’m impatient.

Obsidian now has 32GB (4x8GB) of ECC unbuffered through two Crucial CT2KIT102472BA186D 16GB kits, currently trending for a little over £100 (per kit) on Amazon.

SATA expansion

I now have a Dell H200 dual-controller 8-channel SAS card flashed to IT mode and a couple of mini-SAS to SATA breakout cables. In IT mode the card acts as a basic JBOD controller, presenting all disks to the host system with no interference whatsoever, unlike traditional RAID cards which often require configuration on the card independent of the OS. As I’m using ZFS – a softraid solution – I have no need for hardware RAID configuration.

This card cost me around £50 on ebay second hand.

Case

As the HAF Stacker 915 can no longer be used with the much larger mATX motherboard, I purchased the compact-yet-spacious Fractal Node 804. With support for all of my disks, multiple cooling options and a compartmentalised layout it fit the bill perfectly.

Separating the system from the disks means a case that’s twice the width of conventional mid-tower cases, though much shorter as a result, giving me what I feel is a less obtrusive system sitting on top of the cabinets in the office.

The Fractal Node 804 is available from Amazon for around £99.

The finished product

Now with the build finally out of the way, the next posts in the series will concentrate on software and configuration!

Sponsors

There are no sponsors just yet.

Interested in helping out? Sponsors get a mention in every post and frequent shout-outs on social media. For this build I’m currently looking for high capacity drives (6-8TB) and cooling options aimed towards near silence. Feel like you can contribute in another way? Let me know! I’ve also got a donate button below the post if you’ve enjoyed this series so far.

Get in touch

As always I’m @jasonbayton on Twitter, +JasonBayton on Google+, /in/jasonbayton on Linkedin and I’m available via email.

Free free to get in touch to discuss this or any other topics you have in mind!

My top Android apps 2016

2016-12-31T23:48:40Z

With minutes before 2016 officially comes to an end, I’d like to continue my yearly tradition of listing my top Android apps over this and previous years. This year my aim is to offer a fresh list of applications not previously featured, mostly as I’m still very much using those highlighted in 2015!

Without further ado and in no particular order..

HoloIRC

I recent addition towards the end of this year. As I’ve become more heavily interested in open source software and with the myriad of projects that I have to started to rely upon, a common theme is the use of IRC for communication.

HoloIRC is one of the better options on the Play Store, and though it’s named after the Holo design guidelines of old, it has been updated to reflect the newer Material Design guidelines we’ve come to associate with Android and Google in general.

The client supports a multitude of typical IRC options including adding/editing/removing servers and channels, editing nicknames, setting disconnect/quit messages and more. It’s a genuinely nice client to use from both phone and tablet.

The app is open source on GitHub and is available for free on the Play Store.

Nextcloud

In 2017 I’ll be continuing my slow-but-steady march towards moving my data out of the cloud and back to my own systems. Nextcloud, as I’ve talked about here, here and here, is my home cloud platform of choice.

Naturally I quite like to be able to access this data when out and about; while the web interface is mobile optimised and works quite well, it doesn’t offer automatic upload or manual sync, amongst other features.

The Nextcloud Android client is therefore the perfect companion for the Nextcloud server, and with features such as 2-way sync and automatic backup of any folder coming for all devices in the future, there are only going to be more reasons to start using it!

The app is open source on GitHub and available for free in the Play Store.

DAVdroid

In tandem with (but not reliant on) the Nextcloud client, DAVdroid enables the sync of my Nextcloud contacts and calendars using the *dav protocol. For contacts there’s cardav and for calendar, caldav. DAVdroid can syncronise and update these remote accounts bidirectionally in the background and acts as just another account when adding a new contact or calendar entry on the mobile device.

A nifty app to have if you use (or plan to use) remove dav servers, DAVdroid is available on the Play Store for £3.19

Freedome

One of many, many VPN apps on the Play Store, however Freedome is ultimately the one I ended up going for. For £39.99 a year I can register Freedome on 3 devices (not just Android) and may select from a multitude of remote VPN servers.

The app in addition to VPN will block harmful websites, tracking attempts, and offer to scan on-device apps for known rogues.

F-secure comes highly recommended in my circles, and this was the primary driver for opting for it over competing and likely cheaper alternatives. Due to the amount I’ve used it this year (primarily while travelling) I felt it was worth an honorary mention.

The Freedome app can be downloaded for free from the Play Store. Subscriptions can be purchased in-app or through the F-secure website.

Join

Join is Android developer joaoapps’ answer to the mess Pushbullet made in turning into a freemium app. Offering SMS sync, data push between devices, notifications between devices and shared clipboard, Join is a powerful tool for anyone with multiple devices (both Android or not) wanting to effortlessly push data around.

All data is encrypted, and potentially confidential data such as SMS’ are stored securely in your own Google Drive, therefore never making its way into servers owned by joaoapps.

I use Join most frequently for pushing tabs between devices and sharing the clipboard, but honestly I’m only scratching the surface of what the app can do.

Join is free for 30 days via trial, after which it can be purchased for a one-off fee of $3.99. Download the app via the Play Store.

Mirror

Mirror is a great application. I’ve used it countless times this year alone for demos and recordings both in and out of work and I’m not sure I could work without it today.

Mirror allows for the casting of the current screen to any cast-enabled device. It can also simply record the screen itself for later sharing, as is my common usecase.

The app is simple to use, intuitive and works like a charm with every device I own!

Mirror can be downloaded free from the Play Store with an optional in-app payment to allow the creation of gifs.

RWG Mobile

Not too long ago a new mobile network was launched for the people of Wales. The difference between RWG and almost every other mobile network on the market is that it was entirely app-based, offering a free virtual telephone number through the app that can be used as a VoIP line with my existing 3/4G SIMs on multiple devices.

As it happens, I’ve been waiting a very long time for this Google Voice-esque service to arrive in the UK and not only did I sign up as soon as I could, I now use it today as my own personal voicemail number. Why? Because when a caller is diverted to and leaves a voicemail I can see it through the RWG app, listen to it and save it for later – the VM control is entirely removed from the network provider and instead is managed by me on any device I choose to install the RWG app.

In fact, I wrote about it here.

RWG is free on the Play Store and comes with one free virtual number. More can be bought as required.

That’s all folks

Having received a couple of comments relating to how few apps were featured last year, I hope this is a little better! If you’re looking for more applications to install, feel free to check out My Top Android Apps 2015 or My Top Android Apps 12/13.

Thank you for reading and I hope to welcome you back to the website for more articles in 2017.

Happy new year!

Do you have a favourite app this year? Sound off in the comments! As always I’m @jasonbayton on twitter and @bayton.org on Facebook.

Hands on with the Linx 12V64

2016-12-31T16:14:01Z

A few weeks back I got my hands on the new 12″ 2-in-1 from Linx. For a very attractive £200 I received a Surface-esque tablet and (included!) folio keyboard with the following specs:

1920 x 1200 FHD display
4GB RAM
64GB eMMC storage
Quadcore Atom x5

On top of this, it benefits from a full-size USB 3.0 port, micro-USB port, micro-HDMI and a microSD slot.

For a while I’ve hunted for a decent, portable device; my primary laptop has for years been a 17″ HP which feels and looks like a pavement slab, one which I loath to take with me when I travel. Prior to finding the Linx I’ve been using a 10″ Asus Chromebook Flip and while that has some uses (certainly more recently), I ultimately find it a tad too small most of the time.

Too many budget devices have been following the Chromebook line of devices, shipping with 2GB/32GB (RAM/Storage, respectively) by default. I appreciate Microsoft have worked hard at making the experience not suck on devices with poor specs, but it’s refreshing to see a 4GB/64GB model for the people who expect to do more than browse the web without breaking the bank.

So on paper the Linx sounds fantastic. But how does it fare in day to day usage?

Hardware

The tablet is well built, boasting a solid metal frame and glass front covered by a factory-fitted screen protector (thank you Linx!). The bundled keyboard has a material feel to it, similar to that of the Surface Pro. The keys are well spaced and the touchpad isn’t too small to be usable.

On the back is a dual-position kickstand below an unapologetic Linx logo. Unlike the several-hundred pound more expensive Surface Pro, the kickstand is limited to two pre-set positions which I found to be fine in a lot of circumstances, but also entirely impractical in others.

Unlike the Surface, the hinges on the Linx are full of thick, immensely sticky gunk, presumably for lubrication.

Above the kickstand is one of two cameras, this back one pictured is 5MP while the front sensor is 2MP. I often feel with tablets this is the wrong way around; I, like many, won’t take photos on a tablet for a few reasons and therefore don’t make use of the better rear sensor, while video conferencing with family and colleagues tends to suffer by comparison.

On top of the tablet to the left are the power and volume keys which have a premium feel to them. Down the left hand side is a USB 3.0 port, a MicroUSB port (for charging, primarily), a microSD slot, a miniHDMI port and a 3.5mm jack. The tablet has stereo speakers situated on either side towards the bottom, and pogo pins on the base for the supplied keyboard.

I found the speakers to be a little on the quiet side, however by no means the worst I’ve ever encountered. In a quiet room they are more than adequate though in an office setting or a room full of family/friends with the TV on it’s worth making use of the headphone jack instead.

A trend borrowed from many tablets on the market in recent times is the use of a MicroUSB port for charging; unlike the Surface Pro or MacBook (until recently) with their dedicated proprietary charging ports and cables, the Linx can be charged via any reasonably powerful USB charger, of which naturally one is supplied! Linx also supply a microUSB to USB A adapter, which is excellent since the 3.0 port – as pictured at the beginning – is being used for a 5GHz WIFI dongle, a WIFI band sorely missing from the 12V’s 2GHz-only WIFI module.

On to the screen, the 1920*1200 resolution is impressive for a budget tablet with excellent viewing angles from all directions. The display isn’t as bright as the Galaxy TabPro S for example (then again, what is?), but it’s more than adequate for most situations.

Where it falls short, however, is the horrendous light bleed as pictured. It’s comparable to the Yoga 300 I bought and returned earlier in the year.

In addition on my unit there are a couple of areas around the display where the backlight shines through without obstruction – a defect, according to Linx, where the tablet may have been bumped in transit. It’s not a major issue but it feels a little cheap.

Finally, lets talk about the keyboard.

It attaches to the Linx with strong magnets and can be used either flat or at a slightly raised angle, similar to that of the Surface.

As mentioned already the keys are well spaced and the touchpad is a decent size. Using it however is not quite as pleasant.. I find the keys will occasionally stick causing repeated characters in text – possibly one of the most annoying things a keyboard can do for someone who types quite quickly. In addition and possibly related, the keyboard is mounted to the tablet in the same ergonomic, angled fashion as on the Surface Pro, though unlike the Surface it succumbs far more to flex during use.

Worse still however is the touchpad. Although it’s a decent size, Linx in their infinite wisdom decided to impose permanent, impossible to disable (without 3rd party software and/or hackery) gestures on every side but the bottom. Because the touchpad isn’t registered in Windows as a Precision Touchpad, it’s impossible to tweak touchpad settings, relying instead on mouse settings to make minimal adjustments to the experience.

Here’s what a precision touchpad settings screen looks like:

Here’s what the Linx offers:

Source: howtogeek.com

Two-finger scrolling (in the opposite direction to what I prefer, since I can’t change it) is fraught with frequent “share” dialogues after a screenshot is taken from swiping down from the top of the touchpad. It’s infuriating.

Having spoken to Linx, there’s no plan to change this in the future. There’s also no alternative to the supplied keyboard, unlike with the smaller Linx 10 devices in which a nicer looking, dock-like keyboard exists. I asked if a similar would be developed for the 12V however that also is not on their roadmap.

Ultimately I chose to put the supplied keyboard aside and opted for one of my many bluetooth keyboards with touchpad instead. Problem solved.

Performance

It’s no secret I’m a bit of a power user which is why I tend to burn through hardware quite quickly. While cumbersome, my 17″ HP has the power of a desktop (i5, 16GB RAM, Dual SSD) and as such will likely always be my primary machine away from my desktop (Hex-core, 32GB RAM). My experience of the Linx is therefore from the point of view of someone used to quite powerful, capable systems. Of course, I also loved the Surface Pro 3 which was the primary driver to picking the Linx up.

Unlike many of the tablets offered by Linx, the 12V64 is a 64bit computer with 64bit Windows 10. Admittedly Windows 10 Home edition, but 64bit all the same. This means the tablet can make full use of the 4GB RAM this model has.

Day to day usage, such as browsing the web, working with Office or reading emails works very well with no hiccups as would be expected with a quad-core (even if low-powered) CPU and the aforementioned RAM. Too many programs running however and the cracks start to show.

This is mostly due to the eMMC storage Linx have opted to use. In testing I noticed it was really quite easy for the disk I/O to become something of a bottleneck for the system with a little effort. This in turn results in a laggy, jarred experience when using the tablet despite the otherwise decent spec. Unfortunately it’s not possible to upgrade or replace the eMMC in any way as it’s soldered to the board, so it’s instead something of a permanent Achilles heel. The use of eMMC is clearly a cost-saving measure, though at the expense of performance; had it been replaceable it would have been the first thing I did!

Of course being a lower-powered CPU it’s pretty easy to run it at 100% utilisation too, though that doesn’t affect the system quite as much when the disk is otherwise relatively quiet. Ultimately Linx should have chosen one area for cost savings, rather than both CPU and storage, that way one could compensate for the other.

Battery life

Linx advertise 6 hours of battery life. In testing I found it to vary quite considerably, with the average being about 4 hours between charges.

Unfortunately the tablet doesn’t charge quickly at all. Relying on a USB charger for a large, meaty tablet with no quickcharge support results in spending hours waiting for the tablet to reach 100%. On this basis I found myself using it sparingly and often waiting until bedtime to put it on charge, ready to use the next morning. Usage also impacts charging times significantly, so leaving it alone to get it over with was definitely my preferred course of action.

Again, I’m a big fan of MicroUSB charging, just because it’s so simple. I’d have preferred USB C but at this point I can understand why MicroUSB was chosen instead. A higher-rated stock charger would have been a nice addition, with the option to use other chargers if necessary.

Conclusion

Admittedly this review has leaned more towards the negative points of the Linx, and I’d like to stress for light use – particularly travelling or a simple couch device – it’s a capable machine. I love that a keyboard was included in with the price and commend Linx for all of the ports available on the device in an industry that’s increasingly decreasing the number of ports available.

However, the cost-cutting is more than apparent to me when I pit it against devices like the Asus Chromebook Flip (4GB/32GB), Dell Venue 8 Pro (2GB/32GB) and naturally the generally more expensive tablets on the market.

For £200 during Black Friday sales I can’t really complain, though with a typical retail price of around £330 I can think of many other tablets and laptops that I’d pick before the Linx 12V64.

Did you get a Linx 12V64 during Black Friday? How are you getting on with it? Let me know in the comments, @jasonbayton on twitter or @bayton.org on Facebook.

Wandera review 2016: 2 years on

2016-12-14T23:06:53Z

Back in 2014 I came across a new, powerful and totally unique solution to the growing problem of telecoms expense management (TEM) in the enterprise: Wandera. It offered unparalleled insight into data usage across the corporate mobile estate and helped tremendously in the never-ending quest to monitor and control data usage both at home and abroad.

At the time I said:

I’m really, really impressed by how the solution works and how theoretically easy Wandera makes it to manage devices. Considering at the moment I’ve got very little insight into how users use their allocated data on a monthly basis, Wandera really appeals to me.

It wasn’t perfect however, missing functionality I felt made bulk-deployment something of a challenge; even adding additional administrators required a ticket to be raised with Wandera support. For the benefits Wandera offered though, I was willing to mostly overlook the drawbacks for what was otherwise a fantastic new service with a lot of potential.

As it turns out, being a simple data monitoring solution wasn’t enough for the good people of Wandera; not too long after my first review they announced they were entering the security sector. Today, two years later and after pivoting their focus to mobile threat defense, let’s see what’s changed, what’s remained the same and where there’s still room for improvement.

How does Wandera work?

Unlike typical EMM platforms with TEM built in or even popular data monitoring applications that estimate and/or periodically report data usage, Wandera acts as a proxy (or “gateway”), taking control of the APN settings of enrolled devices in order to divert all cellular traffic through Wandera servers where it is analysed, compressed and forwarded on to its final destination in real time.

With policies, data caps and traffic shaping at its core, Wandera has the ability to block traffic on the fly whether due to a restricted site/genre, a soft data cap, a detected security issue or simply switching over to a roaming profile. It can do this while still providing access to core corporate services such as Exchange so as not to prevent employees from performing their job function. How Wandera behaves is entirely down to how the administrator sets up the various policies.

Some traffic cannot be optimised due to SSL encryption and therefore a lack of visibility of the data it captures. In these circumstances, Wandera simply measures the amount of traffic passing through and counts it up against the respective device in the console. The data that can be compressed however can help to considerably lower data usage and, in combination with real-time reports, alerts and data blocking, Wandera can help to almost completely eliminate bill-shock.

Logging in

On logging into the console at https://radar.wandera.com, I’m greeted with a familiar, though busier dashboard offering a redesigned overview featuring a new focus on mobile threat defense at the very top; this shows threats and risk for mobile devices enrolled on the platform. Below this are the familiar data usage metrics, savings provided by Wandera’s compression engine and an overview of on what (and where) data has been used.

On the left I notice there are a number of new areas in the navigation, including Secure, Administration, and Policy which I’ll touch on below.

The dashboard is now much cleaner and offers more information at a glance. It’s a nice update on what was already a very useful landing page.

Estimated cost savings

The cost savings demonstrated in the dashboard above are only accurate after configuring the default (and any other) Plan Details located in Settings.

Enrolling a device

Device enrolment is definitely an area that has seen some significant improvement over the last two years. While the traditional single and bulk enrolment options still exist from within the Wandera console, they have since expanded the number of EMM solutions App Push works with and have introduced a feature that I find particularly exciting – EMM Connect.

What’s the difference?

App Push was the first attempt at EMM integration and today still supports the highest number of EMM platforms.

Using the EMM-provided Application Management tools, the Wandera app can be imported into the EMM platform, staged using provisioning keys unique to each Wandera customer and distributed automatically to enrolled devices. When the end-user then opens the Wandera application, it will provision automatically with only a few taps required to confirm profile installation.

This is the process on iOS at least and is definitely smoother than on Android, wherein an additional activation app is required for the provisioning steps which can later be removed. I picture this improving in the near future with the uptick in Android for Work deployments and although Wandera don’t support AfW currently, the Wandera App appears to be compatible (though not enabled) in some preliminary testing I undertook.

EMM Connect, by contrast, utilises the APIs of popular EMM platforms AirWatch and MobileIron to automatically sync and provision EMM-enrolled devices/users with Wandera, without all of the extra hands-on required with provisioning keys as used with App Push, the app itself will still need to be distributed though .

EMMC once connected will generate a unique EMM label to be created within the EMM platform. All devices assigned to this label will then be synced to Wandera automatically and provisioned on launch of the Wandera app. Furthermore, Wandera can see any other groups/labels through the EMM API and allows administrators to assign different labels to various Wandera Groups, an excellent and simple way of dynamically assigning devices to group-based data policies.

Wandera Groups

Wandera Groups, much like groups or labels in EMM products, allow for multiple unique policies to be applied to devices based on group membership and dramatically increase the flexibility of the platform. Data policies can then be set according to department, operating system and more.

As of publishing, EMMC only works with iOS devices and while silent provisioning is an option, it requires the devices be Supervised and/or enrolled onto Apple’s Device Enrolment Program (DEP); non-supervised iOS users will be prompted to manually allow the installation of the relevant profiles, a familiar process for those who have previously enrolled onto an EMM platform.

A further benefit of Supervision is the ability to manage not only mobile data but WIFI also. It has long been the case that no matter what rules are put in place to block access to various services, switching on WIFI circumvents it all. Once Supervised this is no longer the case.

In testing I found the EMMC method was very reliable, though it took a few days to get set up due to using Let’s Encrypt SSL certificates for my MobileIron Core. I worked with Wandera to get these certificates supported as I know for a fact they will only grow in popularity as time goes on. From here on out that will no longer be an issue.

Here’s how an EMM-connected device is displayed within the console:

I look forward to seeing Android devices supported in EMMC, once again perhaps in tandem with Android for Work we will soon see far more opportunities for integration on par with what iOS users get today.

What’s supported?

One of my biggest criticisms of Wandera was only offering support for iOS and Samsung – not Android, just Samsung devices. Two years on and unfortunately nothing has changed in this regard; Wandera will not run on Android devices except those by Samsung due to the required APIs in the AOSP simply being non-existent.

It’s no secret Samsung is the Android Enterprise manufacturer; with SAFE, KNOX and the respective APIs available with these solutions that simply don’t exist in other Android OEMs, it’s no surprise Wandera are only focused on working with the platforms they know they can support reliably.

That doesn’t mean I like it however. With no less than 7 Android devices of varying ages in my house, I still had to go out and buy a Samsung Galaxy (J3, for those interested) in order to be able to review the Wandera platform from an Android perspective. It’s my hope that as Android for Work evolves, these APIs currently exclusive to Samsung will be replicated on all OEM devices out of the box in the near future. I’ve mentioned AfW several times in this review already with good reason, it should completely change the game for Android management as it matures.

Setting up plans and data policies

Wandera have introduced the Policies heading which brings both Data Policy and Business/Personal across from the previous location in Settings, along with a new Security Policies configuration discussed further below.

Data policies provide limitations around how data can be used for managed devices. Different policies can be created for different groups, for example in the image above I have limited data to 20GB per month, allowing tethering but setting compression to its most aggressive level in order to preserve some bandwidth where possible. This is only for devices in the Devices group and won’t affect anyone else.

Above the group level is a Global policy in which settings such as Reset Interval Period and Reset Day are set globally. As the screenshot above shows this cannot then be changed on the group-level, a possible problem in an environment where different providers with different billing dates operate together.

Different caps and limitations can be enforced for different situations: domestic, roaming and (where supported) WIFI. This means it’s possible to disable tethering and prevent data being used excessively abroad, even if the policy is rather liberal at home.

Furthermore, anything from one particular website to a full range of sites under any one of several categories can be blocked, as shown here:

In the above example, among other things I have blocked both News & Sport as a genre, but also techcrunch.com as an individual website. As soon as this policy is saved devices are updated immediately and all blocks are enforced without any further action required from the administrator.

One of the best features here I think is the whitelist; a common conundrum I hear is how to effectively stop users from running up huge bills once they’ve breached their data allowance, but at the same time avoid cutting them off completely to the point where they can no longer do their job. Whitelisting applications such as email or iMessage (or anything else) allows the user to remain online in a capacity that is controlled by the business until such time a new billing period starts or an additional bundle can be added, offering data at a much cheaper rate than those incurred through overages.

For those who’ve adopted BYOD, Business/Personal is simply a collection of checkboxes that allow traffic to be appropriately categorised. Facebook, for example, would usually be marked as a personal site and can therefore be reported as such within Wandera to aid with reimbursements based on usage.

Secure devices

Secure is a new function that encompasses mobile threat defense and content filtering to prevent targeted mobile attacks, identify data leaks, and filter access to risky or unapproved usage. It does this by not only reviewing the sites visited, but also the state of the device itself (as demonstrated above). In testing I found it could be a little over-sensitive (MobileIron, my EMM platform, is naturally going to be a device admin) but the insight Secure offers generally is both vast and incredibly useful. Some of the security threats it’ll pick up on include:

Data leakage (unencrypted transport) of email, credit card info, authentication credentials
Developer mode
Android root / iOS jailbreak
OS version, security patch levels
Bad apps
Risky WIFI APs

In fact, just looking at the Event Logs gives an indication of what has been detected on my device over the last week:

Some of these are less severe (according to Wandera) than others, though ultimately the administrator has the ability to either receive alerts on detection or ignore these events all together. By default these are reported silently, requiring the administrator to actively investigate. I’m OK with this as typically being bombarded by email alerts doesn’t particularly excite me. Notifications can be set up in Settings > Notifications.

Each event listed can be drilled down further in order to provide more context around the device it was flagged against:

If an event, such as Device Admin app found is not a concern, it can be turned off by clicking Manage Policy in the above screenshot:

The issue I see here is I can seemingly only turn all Device Admin alerts off for one device or all devices. While I’m confident MobileIron in this case is safe, there’s no guarantee anything a user installs requiring Device Admin later would be. I’d rather turn it off on a case-by-case basis, opting to whitelist MobileIron or any other perceived low-risk Device Admin at the moment it is brought to the administrator’s attention.

Security Policies

Naturally reporting any security concerns is nice, but it’s only half a solution; Wandera have as such also introduced Security Policies that sit within the new Policies area of the console to enable automated actions based on the incident detected.

By default Wandera has a number of Recommended Settings enabled to offer out-of-the-box protection, including blocking traffic for phishing apps or credit card information being transferred over unencrypted channels, though again no alerts are set up to avoid swamping administrators (or users!). As an administrator it’s additionally possible to manage exceptions, rule ignores and supply trusted root certificates to aid in the prevention of false positives and unimportant alerts.

In testing I wasn’t able to replicate a scenario whereby traffic would be blocked due to a security concern – partly because I had no intention of downloading a phishing app, but also with everything generally quite secure browsing around my typical sites there wasn’t much in the way of opportunities to do so.

Managing the console

I’m pleased to see since my last look at Wandera it’s no longer necessary to submit a support ticket in order to add another administrator. This was an immensely basic necessity which I couldn’t believe was overlooked initially, but adding additional admins today is a piece of cake.

Other than this, notifications can easily be set up through Settings > Notifications, allowing for very simple yes/no decisions on what alerts should be sent to the admin, the user or nowhere at all.

Other changes

As with the dashboard, a number of changes since my last review appear to be mostly cosmetic – offering a better layout with more information at a glance. Wandera have again dropped the dated design:

In favour of a much cleaner, nicer interface with richer filtering and search options:

Devices

In addition for Devices, Wandera have added a Summary view which is not drastically different from that of the dashboard:

Though it does offer a somewhat different visualisation of the data available, instead focusing on device availability and connectivity to the Wandera platform. Admittedly I didn’t find myself looking at this too often with such a small deployment of devices, but it’s not dissimilar to the dashboard views I’m used to seeing (and heavily utilising) on various EMM platforms.

View

One of the more interesting features under View was Real-Time which gave an indication of the data passing through the server as it happened. It was a little gimmicky perhaps, but for troubleshooting purposes was probably as close to a tool as Wandera offers for administrators. Unfortunately that’s now gone, but the excellent tables and graphs showing data usage clearly, along with the apps and sites frequented by users, is still all very much present:

An interesting addition I don’t recall seeing in the past is under Settings > Service Controls. Particularly in the run-up to the new General Data Protection Regulation (GDPR), having the ability to anonymise reported data feels like a crucial necessity to prevent huge fines for breaches of data protection:

For those interested, Wandera themselves have published a whitepaper outlining the implications of GDPR.

The user experience

As an end-user it can obviously be frustrating if out of nowhere websites are blocked and data caps are enforced. Wandera however do a really good job of keeping the user informed and the application is completely transparent in showing what limits are applied to the device as well as why a site may have failed to load.

Furthermore, there’s a really nice data monitor built in so a user will never not be able to know how much data they’ve used and how much is left.

Browsing with blocks in place:

https://www.youtube.com/embed/-suSyLFVOFo

Browsing the Wandera app:

https://www.youtube.com/embed/ybOq1uH3YsQ

Conclusion

I’m impressed by the changes and new features I’ve seen once again with Wandera and maintain it’s one of the best solutions for TEM on the market today. Combined with the new mobile threat defense features ensuring devices are safe and compliant, it feels almost untouchable against the competition as an all-in-one solution.

Wandera works reliably, integrates well into existing EMM platforms for simple (bulk) provisioning, offers a completely transparent user experience and provides all the tools necessary to ensure bills remain well and truly within budget.

I’ve by no means covered everything here again, but I’d hope this review gives a good overview of what Wandera is, does and how it can help. If you have questions or comments, or would like to see more reviews, guides or general chat about Wandera here, let me know and I’ll be sure to write more about it in the future.

As always I’m @jasonbayton on Twitter, @bayton.org on Facebook and will also respond to comments below.

If you spot any errors in the above or have suggestions on how to improve this review, feel free to reach out.

Deploying MobileIron 9.1+ on KVM

2016-10-16T19:57:29Z

Introduction

Recently MobileIron announced the release of Core and Connector version 9.1.0.0 and with it comes the newly-supported option for KVM deployments.

This is good news for enterprises who rely on Linux (well, Ubuntu Linux officially but all the same) as it’s now possible to install both the Core and Enterprise connector without the need for VMWare, Hyper-V or physical hardware.

MobileIron Sentry support

To date there has been no update for the MobileIron Sentry. Due to this, the following guide will not be relevant and any installations will not be supported by MobileIron

Prerequisites

Before continuing, please ensure you meet the following prerequisites:

MobileIron

Core version: 9.1.0.0
Connector version: 9.1.0.0

Linux host

Flavour: Ubuntu Server
Server version: 14.04 or above
QEMU version: 2.0.0 or above

This guide assumes a fresh copy of Ubuntu server 14.04.4 or newer has been installed, but not yet modified. Copies of Ubuntu server can be obtained on the Ubuntu website. The server should be accessible either directly or via SSH. It also goes without saying the MobileIron ISO has been downloaded and is readily available for installation. To get a copy of the MobileIron software please speak to your MobileIron account manager.

Recommended installation

MobileIron recommend using Virtual Machine Manager (virt-manager) version 0.9.5 or above and installation via GUI. However, this guide will also include steps for installation via commandline and remote Virtual Machine Viewer (virt-viewer) on Windows (referred to as “Remote Viewer”).

Installation

Ubuntu server QEMU packages

From the command line, install QEMU KVM, virt-install and bridge utilities:

sudo apt-get install qemu-kvm qemu virtinst bridge-utils

Setup the network bridge

A network bridge will allow the VM to look and behave as if it’s sitting directly on the LAN. This avoids issues with port forwarding from host to guest. This step is optional, but recommended.

sudo vim /etc/network/interfaces

Edit the file by first typing i. This will display INSERT in the lower left corner and allows editing of the document.

A typical interfaces file will look as follows:

# The primary network interface

auto ens33
iface ens33 inet dhcp

In order to create the bridge, the primary interface (referred to above as ens33) will need to be set to manual and the new bridge interface br0 setup below:

# The primary network interface

auto ens33
iface ens33 inet manual

auto br0
iface br0 inet static
    address 192.168.0.150
    netmask 255.255.255.0
    network 192.168.0.0
    broadcast 192.168.0.255
    gateway 192.168.0.1
    dns-nameservers 192.168.0.1
    dns-search localdomain
    bridge_ports ens33

In the above example, the bridged interface br0 has been assigned a static network IP based on the LAN in which it sits. Netmask, network and broadcast must reflect the properties of the LAN network, while gateway and the DNS server(s) should echo those that are already present in the network.

DNS search is optional, but provides the server a simple way to search for other servers in the same domain on the LAN.

Most importantly, bridge_ports is set to ens33 – the physical NIC of the server.

When complete, tap the Escape key, :wq and exit with Enter.

At this point, either reboot the server or restart the networking service to enforce the changes made to the network configuration:

sudo reboot

Install MI connector via VMM

From a remote *nix machine running virt-manager, ensure key-based authentication is set up first to avoid connection errors (that is to say, you can ssh user@ip without needing to input the password from a terminal) then connect to the KVM server by clicking File > Add Connection and inputting the relevant user and hostname (as well as checking the checkbox for Connect to remote host).

As an example, if the SSH user with key-based authentication is jason and the host is 10.10.10.98, these make up the username and hostname respectively.

Click Connect when done.

To create a new virtual machine, right click on the remote host and click New

Follow the prompts through 1 to 5 using the following screenshots as a guide:

Recall the bridge created earlier – this can be now selected under Network selection

Click Finish to create the virtual machine.

The MobileIron installation can now continue as normal by typing vm-install at the prompt in the newly-opened console window.

Install MI connector via CLI

Following the reboot of the KVM host, log back in.

Time limit!

Before running the following command, ensure you have the Remote Viewer application installed on your remote machine. You will have 30 seconds to open the remote viewer and input the vm-install command on the MobileIron installer before the system will fail to boot, and the VM configuration file will need to be manually edited to re-add the MobileIron ISO file.

First ensure the MobileIron ISO has been downloaded to the KVM host. If it has been downloaded to a remote *nix workstation, you can use SCP to copy it over using SSH, for example on your workstation:

scp /home/user/mobileiron-9.1.0.0-64.iso user@10.10.10.98:/home/user/

If SCP isn’t an option, FileZilla or another SFTP application may also be used.

To create a new VM from the command line, enter the following command; the bold entries need to be customised in order to match the environment:

sudo virt-install --name=mobileiron-connector --os-type=linux --network bridge=br0 --vcpus=4 --disk path=/home/user/mobileiron-connector.qcow2,size=20 --cdrom=/home/user/connector-mobileiron-9.1.0.0-64.iso --boot=cdrom,hd --graphics spice,listen=0.0.0.0 --ram=7629 --serial file,path=/home/user/serial

Where:

name is the name of the virtual machine
os-type is the type of operating system, like Linux or Windows
network is the network interface to use
vcpus is the number of virtual connectors to provide the virtual machine
disk is the virtual disk path and size which will be created if it doesn’t exist
cdrom is the path to the bootable ISO
boot is the boot order
graphics provides the console for the Remote Viewer application
ram is the amount of RAM to assign to the virtual machine
serial is an optional serial file to pipe the MobileIron serial console

On pressing Enter virt-install will begin the installation of the virtual machine, and stop on Domain installation still in progress. Waiting for installation to complete.

Immediately following this message, a 30 second timer starts on the MobileIron boot screen.

Open Remote Viewer and input the connection address:

By default, this will be spice://ip-or-host:5900 for the first virtual machine to boot, with the port incrementing by 1 for every virtual machine running. The port can optionally be set manually by editing VM configuration file.

On clicking connect, the Remote Viewer will load the remote console where installation can be continued as normal. If the session disconnects, simply re-open it again.

Hands on with the Nextcloud Box

2016-10-10T12:25:43Z

If you’ve been here before you’ll have no doubt seen any one of several mentions I’ve made of Nextcloud; it’s a fantastic self-hosted platform and my go-to when recommending a do-it-yourself alternative to the mainstream DropBox type platforms. Here’s a refresher if you need it:

What is Nextcloud?

Nextcloud is a fork of ownCloud that’s quickly becoming the newer, better and faster-developed alternative to the self-hosted cloud storage software of old. It has every feature OwnCloud has to offer and more; if you’re an ownCloud user and have ever been frustrated by the dual licenses, the paid vs free model and – as part of it – lack of some of the better features, Nextcloud have gone completely FOSS (Free and Open-Source Software) following the Red Hat model of charging for enterprise support rather than enterprise features.

Some of the previously enterprise-only features released as part of the standard FOSS Nextcloud installation include FileDrop, an alternative to Dropbox’s “File Requests”, two-factor authentication and LibreOffice online, an alternative to Google Docs or Office Online.

In addition to recently announcing version 10, Nextcloud have worked with Canonical and WDLabs to bring to market the Nextcloud Box, a small (not quite fitlet-RM small but still), Raspberry Pi-powered, Snappy Ubuntu Core server with a 1TB WD PiDrive retailing currently for £60. I asked Nextcloud if I could get a review unit and a fortnight later it arrived at my door complete with a Raspberry Pi (not included on retail units).

Unpacked it looks a little something like this:

As pictured, the package comes with:

Nextcloud Box enclosure
MicroSD card
1TB PiDrive (pre-installed)
A HDD/microUSB/USB3 splitter cable to connect and power both the HDD and the Pi
A microUSB cable and 3A plug
Screws & screwdriver

Again, the Pi is not included in retail units so will have to be supplied. Currently the Nextcloud Box supports the Raspberry Pi 2 Model B, but this will be expanded with software updates in the future to work with additional boards.

Build

As the Nextcloud Box comes disassembled it will naturally need to be put together.

This is as simple as screwing the Pi into the enclosure with the 4 supplied screws and cabling it up as shown above. Nextcloud provide a handy image to demonstrate how the cables should be routed (click for PDF):

To me the cable routing felt a little tight, I wasn’t too excited by how sharply-angled the USB cable coming out of the Pi had to be for this setup, but it works regardless. The ethernet cable (not pictured in the instructions) can easily follow the route of the power cable as the cutout is certainly large enough for both:

Once assembled, the lid secures with a few powerful magnets making it wonderfully easy to gain access if required without the need for tools.

Setup

After powering it up there’s a bit of a wait while a built-in script takes care of pre-setup of the Nextcloud environment (8-10 minutes is stated, though mine didn’t take that long) and eventually navigating to https://ubuntu-standard.local – or https://ubuntu-standard.yourdomain if you don’t use local internally like me – should present the Nextcloud interface requesting the creation of a new administrator:

Once credentials are created, we’re in:

Yes, that’s really all it takes. It’s worth noting this is still Nextcloud 9. An update to 10 is currently in the works as of publishing.

HTTPS support

You may notice the links above are plain old HTTP. HTTPS is not enabled by default due to firewall requirements.

Let’s Encrypt is included with the Nextcloud Box as standard and once port forwarding is in place it’s really easy to enable HTTPS. Once set up, Let’s Encrypt will automatically renew its certificates, requiring no further input to remain secure.

The steps for enabling HTTPS can be found here.

Snappy Snaps

Being a Snappy Ubuntu Core, there are a slew of other apps that can be installed, including some recommended by Nextcloud such as Snapweb.

Snapweb is a graphical interface for searching and installing various snaps through the Snap store. It’s much easier for those unfamiliar or uncomfortable with the command line:

Unfortunately at the moment Snapweb itself requires manual installation via the command line as follows:

sudo snap install snapweb --beta

However following this the interface will be available either via the internal IP or hostname on port 4200, e.g.: https://ubuntu-standard.local:4200. The Nexcloud Box wiki explains how this can be setup as an external site from within Nextcloud itself here. Snapweb will be installed by default in this way in the future.

Note

As of publishing there’s currently a bug with the newly released version of snap-confine which prevents newly installed snaps from running. To get around this for now, run:

wget https://launchpadlibrarian.net/287156245/snap-confine_1.0.42-0ubuntu3_armhf.deb
sudo dpkg -i snap-confine_1.0.42-0ubuntu3_armhf.deb

This installs the latest snap-confine version from Yakkety and only needs to be done if Snapweb (or other snaps) don’t appear to be running after installation. When installed, run:

sudo snap run snapweb

Other recommended Snaps include Rocket.Chat and SpreedRTC, but there are so many available it’s definitely worth exploring the Snap store to check out the various services which can be run in addition to Nextcloud on the Box.

Performance and issues

Up to now my main Nextcloud instance has run within an LXD container atop a Ubuntu 16.04 host with 4 cores and 16GB RAM, by no means a slouch. By comparison, the Pi-powered instance is somewhat less responsive, but by no means does it perform poorly.

I uploaded around 17GB of data overnight averaging out at roughly 9MB/s – not unexpected on the Pi’s 10/100 NIC. Inside the network the 10/100 NIC is something of a bottleneck, but from outside – where you can access your files on the go – this will not be noticeable.

It didn’t crawl to a halt as I was somewhat expecting it to uploading so much data in one go, and I feel the performance is fine for a couple of users. Cracks will show with multiple users simultaneously using the Nextcloud Box for large up/download tasks though, so keep that in mind.

My only real gripes with the box as it stands today are thumbnail generation (which can be quite slow on big folders) and a lack of PrettyLink support. For the former I’ve raised it as a concern in the official Nextcloud Box topic and have been told NextCloud 11 will help alleviate this. For the latter I’ve raised a feature request.

Conclusion

The Nextcloud Box is a big step forward for the IoT (Internet of Things) arena and I’m really impressed with the first iteration of what I anticipate to be a very popular product. It won’t be for everyone given the minimal specs of the Pi, but for enthusiasts and hobbyists, it’s a great introduction to Nextcloud and other self-hosted solutions.

Nextcloud are all about empowering people to take back their data. With the Nextcloud Box being simple to build, simple to setup and most importantly, simple to use, they’re taking this vision to the next level.

Interested in getting one? You can purchase a Nextcloud Box by selecting your country from the dropdown on https://nextcloud.com/box/

Are you a Nextcloud fan? Are you considering picking up the Nextcloud Box? Let me know in the comments, @jasonbayton on twitter or @bayton.org on Facebook.

How a promoted tweet landed me on Finnish national news

2016-10-08T20:46:07Z

This isn’t something I’d usually write about as I like to reserve my career updates and whatnot for friends, family and occasionally LinkedIn. Then again, it’s not every day I end up featured in the news of a foreign country through my use of social media!

After hearing I was being made redundant at the end of last week, I needed to fathom a way of simply and quickly putting myself in front of as many potential employers as I could with the least amount of hassle.

Writing a CV and keeping profile information up to date on job sites is probably one of the most time consuming and mundane tasks of finding a new job. Naturally the more sites you keep updated, the more chance you have of being found by the right recruiter or hiring manager and so it’s a pretty tedious task to stay on top of.

Yet staying on top of it is even more important when considering recruiters may be active on some sites but not others; even if they are active, they’re likely only looking for particular keywords when searching for candidates and the chances of being found aren’t always favourable.

Logging on to the tens and tens of job sites (once I’d reset forgotten passwords to many of them, no doubt) and painstakingly updating my profile on each one to indicate I was looking for work, followed by spending hours searching high and low for suitable positions to apply for and.. waiting.. is not something I really wanted to do on a Friday evening.

As I perused my Twitter feed, scrolling past promoted tweet after promoted tweet, it hit me – Twitter is the perfect platform to promote myself; millions of people use it from all walks of life and although many would be in normal, non-managerial roles like mine, plenty of people are higher up and have the power to make hiring decisions. Even those in non-managerial positions can bring it to the attention of management, as was the case in one instance this week.

Combined with the fact I’ve spent hours upon hours working on my LinkedIn profile, it seemed the perfect fit in combination with a Twitter ad and is much more versatile than a job site profile. With more time I could have created a purpose-built mini-site but for this exercise I didn’t feel that was a necessary or efficient use of time.

With that, I got to work on two ad campaigns, one for Finland and one for the UK.

Why Finland?

I like the country and have family there. It would be just a lucrative for me to find employment in Finland as it would here in the UK and I’d never turn down the opportunity to live in abroad again. Additionally, two separate countries with differing economies and skill requirements can only increase my chances of landing a role.

The ads were relatively simple, they were set up to:

Run continuously from the point of creation
Spend no more than £5 per day, with a maximum budget of £30
Display on both Twitter and Twitter’s Audience Platform (the latter under a Job search category)
Target all ages and genders
Target users interested in the entire technology category
Target users in the whole of Finland/UK
Target all devices, carriers and so on
Show up on both users’ timelines and profiles & tweet detail pages

What I ended up with however were two completely different audience sizes:

: UK

: Finland

That’s a dramatic difference at first glance, but when considering the population of each country, and then acknowledging only roughly 5% of the Finnish population use Twitter vs closer to 35% for Brits (stats based on figures for 2015, estimated), it makes more sense.

Here’s where things get interesting, however. Having let both campaigns run for 6 days, the results are as follows.

UK:

Finland:

As it happens, the UK campaign included three different promoted tweets vs. Finland’s one. I did this in order to test different wording and #hashtags, though the tweet shown above was by far the most popular, with the other two combined contributing ~2,000 more impressions and about 40 additional link clicks. One of those poor-performers used almost identical wording to the Finnish tweet.

In all, the promoted-only actions for the British campaign beat out the Finnish campaign – as you might expect given the vast difference in audience size (though not by much, really) – as seen here:

Something amazing happened with the Finnish campaign however, people took notice of it, liked what they saw and retweeted it to their followers. Some of them happened to be influential, such as the co-founder of Jolla:

I don't know you @JasonBayton, but you made my day – definitely an innovative way to use @twitter ads 😉 https://t.co/DXrAHtP66Z

— Stefano Mosconi (@zzste) October 4, 2016

Stefano’s (amazing!) comments went out to his 8,000 followers, and he wasn’t alone:

Dear Finland of mine is open for new talents and innovative recruitment. #työnhaku #rekrytointi https://t.co/xv5lIaGMRr

— Hani Olsson 💖 (@haniolsson) October 4, 2016

Innovative job hunting! Good luck, Jason! https://t.co/FUamyIpAMo

— Ani Narhi (@aninarhi) October 3, 2016

At one point I got an invitation to provide more information:

Cool. Can you DM me about some details? What kind of work? Starting from when etc?

— Topias Uotila (@THUotila) October 2, 2016

Ultimately that didn’t work out as I’d just missed a recruitment drive, but we had a good conversation either way and I’m truly grateful for the time he devoted to looking into it for me.

That’s just the tip of the iceberg, from these likes and retweets the organic interactions – those being of much higher quality – continued to climb until it drastically overshadowed the British campaign as can be seen in the screenshot of the tweet activity for Finland above.

Finally, as the campaigns drew to a close I received an email:

More than happy to oblige, I answered a few questions and later found an article on the front page of YLE (offline copy) – Finland’s equivalent to the BBC in the UK:

Blimey.

That in itself drove even more traffic my way with new discussions spawning on Facebook as well as Twitter.

Throughout all of this my LinkedIn profile was constantly littered with views and connection requests ranging from managers to CIOs, CTOs and CEOs from all over. It’s still happening as of publishing this post, though has dropped off significantly now the ad campaigns are over. I’ve gained a small addition to my following on Twitter too which is nice.

Did any of this lead to employment, or at the very least, interview offers? No. It’s too bad as that would have made for a fantastic end to this post, but I suspect I’d have had to run the campaigns a bit longer and potentially across Facebook or Adwords to make a huge impact.

As it happens I interviewed for another role internally earlier this week, before payroll cut me from the company entirely, and was able to get transferred over to a new team where I’ll be starting next week. Due to that I won’t be reactivating the campaigns.

This was probably one of the more exciting social experiments I’ve ever performed, even if it did cost me hefty £60 for the experience.

As always I’m @jasonbayton on Twitter, @bayton.org on Facebook and will also respond to comments below if you have any questions!

Using RWG Mobile for simple, cross-device centralised voicemail

2016-07-21T15:53:44Z

RWG Mobile (Red White & Green Ltd) is a brand new MVNO running on the Three network. They launched a few days ago at the Royal Welsh Show and while in principle they’re much like other MVNOs, there are a couple of distinct differences…

Firstly they’re a Welsh Telco based in Wales, run by Welsh people for Welsh people with support offered in both Welsh and English for speakers of either. In fact, with a support landline prefix of 01633 they’re just down the road from me! As a Welsh tech blogger with a career in Enterprise Mobility, seeing a company that closely matches my interests open in my country (nevermind my City) is great; Wales has a thriving technology sector in general, but I’ll always pay special attention to this field in particular.

Secondly, they’re putting a large focus on virtual numbers in what they call “profiles”. Virtual numbers aren’t new by any means, but they’re most commonly associated with business accounts needing to route several numbers to one SIM and certainly not treated like a commodity that any average user can buy and cancel at will, as is the case with RWG. The advertised benefit here is being able to hide your “main” number and instead use virtual numbers for different things; friends, colleagues, dating/job sites, so on. The first virtual number is free (for as long as it’s used) and up to 3 more can be purchased for £0.99 a month, £2.49 for 3 months or £6.99 for a year.

As well as free RWG to RWG communication, they offer voicemail and low-cost local/international calling and texting too. Being app-first, they utilise your current data plan (through any provider) to offer their services, with a SIM solution coming in the future.

At this point in time I don’t have any requirement for multiple profiles, but I do run a PBX at home that all of my phones (work, personal, test) forward to should I be unable to answer a call. The PBX plays a pre-recorded message, records the caller’s voicemail and emails it to me. I prefer this over having multiple network voicemail boxes as VMs are then backed up and easily available when I require them from anywhere. It’s unfortunately not always reliable, so RWG looks like a potential replacement (backups excluded).

RWG provides a free phone number and, as mentioned, voicemail included. The below guide will help in the very simple process of signing up with RWG, forwarding calls and finishing with one centralised voicemail inbox across all your phones and tablets (yes, tablets too).

Note!

Obviously forwarding from one number to another does cost, so bear that in mind before continuing. Being on contract(s) with “unlimited” minutes makes this a non-issue for me, but it has the potential to rack up a small bill where not covered.

Centralising voicemail

To begin with, download the app from Google Play or the App Store. The rest of this guide will continue on Android.

Step 1

Open the RWG Mobile application and enter your current SIM telephone number.

Step 2

The app will then send a verification PIN to the device via SMS.

Step 3

Once the PIN verification completes, agree to the terms and conditions and skip through the promotional screens.

Step 4

Following the promotional screens, select GET NUMBER. On the next screen input a profile name, again tap Get number and accept the prompt warning your number will expire if you don’t get at least one call forwarded every 30 days.

Step 5

You’ll now be taken to the home screen. Credit is shown as £0.00 but this doesn’t matter as it won’t be needed. If it isn’t already selected, tap the new profile you created along the bottom of the screen; in my case it’s named VM. Now tap Settings.

Step 6

Tap Availability, then in the new screen tap Do not disturb. Tap OK to calls being forwarded to VM.
NB! If you choose Off the number won’t work at all.

When you return to the app home screen you’ll be met with a green cross through the voicemail profile. This is normal.

Step 7

With the RWG configuration out of the way, now is the time to configure your mobile device to forward unanswered calls to RWG Mobile.

The settings area where this takes place can differ between devices. LG for example requires you open the phone app, tap the menu icon and head into Call settings. From there the option Forwarding is listed.

On Samsung devices, you must open the phone app, tap the menu icon, enter Settings, select Call, tap More settings and you’ll find Forwarding in that submenu.

Either way, once you end up in Forwarding, the view should be fairly consistent. Select under which circumstances you wish for your call to be forwarded and enter your RWG Mobile number.

Once finished, return to your home screen and wait for your next missed call!

Tapping on the notification will take you directly to that voicemail:

Though you can view all voicemails at any time by tapping Voicemail from within the RWG Mobile app. You can add other devices by simply following the same steps to register, always choosing the primary phone number when it asks. A PIN will be sent and moments later it’ll all sync up. VMs on any (Android/iOS) device:

Of course, if you’re not happy using the same voicemail number for all messages, additional profiles (and as such, voicemail greetings) can come in handy to maintain that separation. All VMs across all profiles are still accessible through the one single app however you wish to set it up.

—

Have you heard of RWG Mobile? Are you planning on moving to them now or in the future?
Do you manage your voicemails in a similar, or better method than described here?

Let me know in the comments, @jasonbayton on twitter or via my brand new facebook page @bayton.org!

Part 3 – Project Obsidian: A change, data migration day 1 and build day 2

2016-07-13T14:56:12Z

Just tuning in?

This is a multi-part build log for Project Obsidian: a low power Ubuntu 16.04 LTS NAS & container server.
You’re currently viewing part 3. Head over to the introduction for context and contents.

A change

Despite some effort on my partit hasn’t been possible to obtain the 6/8TB disks I’m aiming for just yet. I would have continued (and still will) to work on that, however noticed my 16TB MDADM RAID array was flaking out on me a little over the last few days, going even as far as no longer showing up in the system until it was rebooted. (There’s nothing wrong with the disks, it’s the server).

So in an effort to avoid any potential data loss I’m going to make do with what I have now; moving 7 4TB disks from my current AMD FX-6300 storage server into the Obsidian build and a whole lot of extra data migration as a result.

I’m still aiming for the larger capacity disks, and having now decided on ZFS for my system, swapping out the 4TB’s for larger will be a piece of cake.

Data migration

Luckily, I caught the tail-end of this HotUKDeals find and was able to fetch two MyCloud 4TB external drives for £82! With the extra disk I was able to set up a temporary MDADM RAID5 with one extra 4TB I had lying around and proceeded to rsync all data from the 16TB RAID6 to the 8TB RAID5. A nice, simple command on linux systems to guarantee both files and metadata (permissions, ownership, etc) is:

sudo rsync -avP /source/path/ /destination/path/

-a stands for Archive, which handles the file permissions and ownership
-v is for Verbose, as I like to see in detail what it does
-P stands for Progress, giving me a vague indication of what’s happening by streaming a list of files through the console as it copies them across.

This took the better part of a day to complete. At that point I left the new RAID5 in place for a couple of days having mounted it in place of the old RAID6 through fstab (seamless change on a reboot) and haven’t noticed any issues.

Build day 2

So with the temporary RAID5 in place and data migrated, I shut it all down and began stripping down the storage server. There’s no build video for day 2, it was all a little manic.

In the above image I’ve mounted 3 4TB WD RED NAS hard drives in the 2 5.25″ bays, later joined by the system 120GB SSD. After first destroying the 16TB RAID6 from within Ubuntu I powered the server down and began disconnecting the drives in the bottom Cooler Master 915R. The beauty of a case like this is being able to mount the drives separately from the main system and easily remove the whole chassis in situations such as this.

Once the disks were disconnected, the 915R uncoupled from the 925 and moved out of the way, all surplus cables were removed leaving the 925 but a husk of the mammoth system it was before:

And no, still not cable managed. Yet.

With the storage server back up and running and everything looking good, I proceeded to transport the 915R and its disks downstairs to a waiting 915F housing the compute module.

After a lot of dusting (it’s impossible to get in there when they’re stacked), stacking the storage module on top of the compute module and connecting a whole heap of wires, it was ready to boot:

At this point it’s worth pointing out none of this is very black and that would be right. I haven’t yet wired up the all-black power cables and given the rather quick turnaround on moving the disks, simply reused the far-too-long SATA cables I already had. As and when the parts come in I’ll publish some updated pictures.

The system is up and stable. I’m still not pleased about having 4 disks on a PCIe card and 3 on the motherboard, but until I can find a 4-channel, 8 port SAS/SATA card that won’t cost more than the rest of the system combined (disks excluded) there’s little other choice.

So that’s all for this update. In the next I’ll cover off some Ubuntu configuration and RAID setup.

Sponsors

There are no sponsors just yet.

Interested in helping out? Sponsors get a mention in every post and frequent shout-outs on social media. For this build I’m currently looking for high capacity drives (6-8TB), PCIe SATA/SAS solutions and cooling options aimed towards near silence.

Get in touch

As always I’m @jasonbayton on Twitter, +JasonBayton on Google+, /in/jasonbayton on Linkedin and I’m available via email.

Free free to get in touch to discuss this or any other topics you have in mind!

Hands on: fitlet-RM, a fanless industrial mini PC by Compulab

2016-07-11T18:24:14Z

A few weeks ago I got in touch with Compulab in order to get my hands on one of their renowned passively cooled mini PCs. After a brief discussion around their available products, we agreed I’d review one of their to-be-released models when it became available. Earlier this week I received their just-announced fitlet-RM-XA10-LAN, the followup to the fitlet-XA10-LAN AnandTech reviewed some time back, along with a fit-Uptime mini UPS. All product links will be provided at the end.

Who are Compulab?

Compulab have been around since 1992, starting out as a consultancy company before branching out to CoM/SoM (1997) and later micro PCs (2007) such as the model being reviewed in this article. They’re a market leader in their field specialising in ARM and have repeatedly pushed the boundaries of what can be offered in respect to hardware and size. Their systems can be found today in robotics, industrial applications, surveillance systems and much more.

What is the fitlet-RM?

The fitlet-RM series is a follow-up to the previously launched fitlet-XA10-LAN/fitlet-iA10 and is aimed towards applications requiring a reliable, power-efficient, hardy system with a minuscule footprint. At 10.8 cm x 8.3 cm x 2.4 cm (0.22l) it’s barely larger than a standard SSD and can fit comfortably in a pocket, in an obscure corner of a rack, hidden in the depths of a larger appliance or fixed unassumingly behind a display.

Despite its size the fitlet-RM is packed with features. The RM-XA10-LAN sent to me comes with the following spec:

CPU: AMD A10 Micro-6700T SoC – Quadcore 1.2GHz (2.2Ghz with boost) @ 4.5W TDP RAM: 8GB DDR3L-1333 non-EEC
Graphics: AMD Radeon R6 Graphics with dual HDMI outputs
Storage: 64GB mSATA internal, support for micro-SD external
Network: 4x Intel 10/100/1000 LAN ports
Other: 3.5mm audio in/out, 2x USB3, 3x USB2, COM port & SIM slot
*RAM and disk are not included as standard

Opting for the fitlet-RM-iA10 would see 4x LAN ports reduced to 2x LAN and the addition of a WIFI/Bluetooth module, though the fitlet-RM-XA10-LAN does come bundled with a USB WIFI n module. The 3x LAN ports are provided through what Compulab calls a “FACET” card. Although these are the only two available configurations currently, Compulab allows for 3rd parties to create their own FACET cards meaning in the future there may be as many FACET cards as there are “FACE” modules – slightly larger cards designed for the bigger fitlet-H, fitlet-T and fit-PC models.

The system is encased in an aluminium & zinc housing which acts like one large heatsink, dissipating heat effectively without the need for a fan thus retaining the ultra compact form factor. It is also strong! Compulab showcased this by running over a fitlet:

As there are no moving parts and the casing is well sealed, it is perfect for applications where the ingress of dirt, humidity or extreme temperatures could be encountered; the fitlet can operate under a wide temperature band ranging from -40°C to 70°C with the parts inside equally capable of handling constant extremes of temperature, shock and vibration. Furthermore with the unique twist-lock power cable, there’s little worry about accidentally removing the fitlet’s power supply:

The fitlet-RM series starts at $311 and is currently available from fit-PC (official).

What’s in the box

The fitlet arrived with the following components provided:

The fitlet-RM-AX10-LAN
Power supply – European and US blades (plugs) provided, UK available
HDMI to DVI adapter
Audio 3.5mm to RCA cable
802.11n Wifi module
Mini-serial to DB9-male adapter cable
mSATA heatsink

This fitlet was pre-built with 8GB RAM and a 64GB mSATA SSD and the heatsink was therefore already installed. Compulab also provided a fit-Uptime UPS.

Separately in addition to this, I purchased:

fit-Headless 4K
fitlet heatsink
fitlet VESA/wall mount
remote power button

Performance

Despite being a low power, 4.5w TDP chip the AMD A10 Micro-6700T is a capable CPU. In benchmarks it outpaces similar and slightly higher-clocked Intel Atoms of the same release period such as the Z3795, a chip commonly used in tablets and laptops, as seen by PassMark’s benchmarks:

I did a few benchmarks of my own on Ubuntu using sysbench running 1 and 4 threads and wasn’t disappointed:
sysbench can be installed on Ubuntu/Debian by running sudo apt install sysbench

jason@fitletr:~$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

[..]

                                                                                             [
Test execution summary:
    total time:                          24.8739s
    total number of events:              10000
    total time taken by event execution: 24.8717
    per-request statistics:
         min:                                  2.42ms
         avg:                                  2.49ms
         max:                                  5.45ms
         approx.  95 percentile:               2.67ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   24.8717/0.00

jason@fitletr:~$ sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

[..]


Test execution summary:
    total time:                          8.3709s
    total number of events:              10000
    total time taken by event execution: 33.4761
    per-request statistics:
         min:                                  3.11ms
         avg:                                  3.35ms
         max:                                 23.82ms
         approx.  95 percentile:               3.34ms

Threads fairness:
    events (avg/stddev):           2500.0000/5.96
    execution time (avg/stddev):   8.3690/0.00

For comparison, the AMD FX-6300, a 3.5GHz chip with 6 cores and a 95w TDP, powering my home storage server gets the following from the same 1 and 4 thread test:

jason@ElGrande:~$ sysbench --test=cpu --cpu-max-prime=20000 run

[..]

Test execution summary:
    total time:                          15.2784s
    total number of events:              10000
    total time taken by event execution: 15.2770
    per-request statistics:
         min:                                  1.42ms
         avg:                                  1.53ms
         max:                                  3.54ms
         approx.  95 percentile:               1.56ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   15.2770/0.00

jason@ElGrande:~$ sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run

[..]
Test execution summary:
    total time:                          4.1375s
    total number of events:              10000
    total time taken by event execution: 16.5428
    per-request statistics:
         min:                                  1.46ms
         avg:                                  1.65ms
         max:                                 25.91ms
         approx.  95 percentile:               1.74ms

Threads fairness:
    events (avg/stddev):           2500.0000/66.11
    execution time (avg/stddev):   4.1357/0.00

Generally the fitlet feels quick and extremely responsive. This is no doubt thanks in part to the mSATA SSD and 8GB RAM, however in testing both using OPNsense and Ubuntu server the fitlet responded reliably and quickly both acting as a router for the 40 or so network endpoints I have at home and later as a media server for streaming from emby to my Nvidia Shield TV without a fault. Load remained minimal almost all of the time.

The only time I saw any notable struggle was when running Windows 10 from a USB3 hard drive, however this was clearly due to the bottleneck associated with running an OS from a 2.5″ HDD over USB3. Windows being the resource hog it is did push the CPU usage up more often than on either Ubuntu or FreeBSD, but nothing that would be considered untoward.

For networking applications, it goes without saying the 4 LAN ports on the fitlet-RM-XA10-LAN are fantastic. For server applications, being able to bond multiple connections has its own advantages; 4 individual GB ports all responding to one network address makes for a very fast streaming/storage server with no bottleneck on network. Naturally on a 64GB mSATA there’s not a lot of storage to be had, however it’d be just as easy to install 1TB of mSATA storage as well as multiple USB drives and even eSATA on the fitlet-RM-iA10.

Temperature control

Heat can be a concern for any passively cooled device and the fitlet is no exception. Installing Windows updates saw the fitlet steadily increase in temperature to a whopping 59.6°C before cooling back down to the low 50’s when complete. At those temperatures the fitlet is simply too hot to touch, though they are well within the operating range and therefore should be nothing to worry about.

In an industrial or enterprise environment this shouldn’t be an issue. It did have me wondering where I’d mount the device though due to the heat generated; the original plan to mount it within the case of my storage server (the VESA bracket suits 120mm fan mounting points nicely) may not be suitable, as the server will need to work harder to cool both systems.

Here’s where the fitlet heatsink comes in:

At the moment only the bare aluminium version is available, but regardless of colour the heatsink does the job perfectly. I noted a temperature drop of about 11°C to the low 40’s resulting in a PC that is no longer too hot to touch and therefore more manageable.

Compulab say they’re working on a black version of the heatsink, once it becomes available soon I’ll swap it out.

What is the fit-Uptime?

The fit-Uptime is a micro-UPS designed specifically to be entirely plug and play. It uses an 18Wh lithium-polymer battery and is capable of powering the fitlet for over 3 hours at a draw of 5w.

Unlike some UPS systems, the fit-Uptime can switch back and forth between mains and battery power in an instant. The fitlet will never detect the change and will never suffer instability as a result.

As it’s such a simple device, there’s no capability for the fitlet to know when it has been switched to battery power, nor when that battery power is about to run out. Due to this the fitlet won’t be able to shut itself down safely on loss of mains power, relying either on manual intervention to shut it down, or for mains power to return before the 3 hours is up (which in fairness is a nice, long window to work with).

Compulab are considering a “pro” version in the future that will be able to directly interact with the fitlet in order to add the functionality that is currently missing here.

I have so far used fit-Uptime to move the fitlet to various parts of the house while setting different things up. It switches between battery and mains flawlessly, remains accessible over the network (via WIFI) at all times, meaning I can leave SSH connections open and it hasn’t glitched even once. I haven’t run the UPS to 0% battery yet, but the fitlet has been sat on battery power for over an hour on occasions with no problems at all. Living in a location which suffers the occasional power outage, the fit-Uptime is a highly appreciated little piece of hardware to me!

The fit-Uptime is available from fit-PC (official) for $68.

Conclusion

The fitlet is by far the smallest, most useful mini-PC I’ve gotten my hands on so far. I’ve used NUCs in the past and while conveniently small they’re often hampered by limitations in hardware or cost.

The dual HDMI make running a dual display setup such as my 2 Asus VS247HR 23.6″ monitors a breeze for desktop environments, while on the server side the 4 Intel LAN ports and low-power (but aptly powerful) system make for a perfect little pfsense/OPNsense (or other) system for advanced routing.

Indeed it can get warm, but such is the plight of fanless systems; particularly those with literally no internal space utilising the casing directly for heat dissipation. When tucked out of the way in an open environment this will never be an issue.

If I were to bring up one minor complaint it would be only that the power button is a little awkward to depress. It requires quite a deep push to turn on/off and would benefit greatly if it were more of a static button with a few mm of travel, similar to that of the fit-Uptime.

In combination with the fit-Uptime I envision the fitlet will ultimately – just as advertised – be one of the most resilient and reliable systems I’ll ever run. For the price I wouldn’t have expected a system as decent as this.

Product links

fitlet heatsync: Amazon UK
fitlet remote power button: Amazon UK
fitlet VESA/wall mount: Amazon UK
fit-Headless: Amazon UK
fit-Uptime: fit-PC (official)
fitlet-RM-XA10-LAN barebones: fit-PC (official) – links to all fitlet models

—

Are you looking for a mini-PC? Are you considering the fitlet-RM? Let me know in the comments, @jasonbayton on twitter or via my brand new facebook page @bayton.org!

Part 2 - Project Obsidian: Build day 1

2016-07-01T23:01:30Z

Just tuning in?

This is a multi-part build log for Project Obsidian: a low power Ubuntu 16.04 LTS NAS & container server.
You’re currently viewing part 2. Head over to the introduction for context and contents.

Building the compute module

As I’m still considering the storage aspect of Obsidian, I’m splitting the build into two halves; this half covers the top 915F housing the mini-ITX system and PSU, while the bottom 915R housing the storage will come later.

For the sake of getting Obsidian up and running I have temporarily housed the 120GB SSD and a single 4TB disk in the 915F. These will relocate down to the 915R later.

Build video

I managed to get a half-decent build video sped up to 100fps. To do this I propped my Logitech C920 up on the highest object I could find and hoped for the best. The angle isn’t ideal but it’s relatively easy to follow the build. Here’s the video:

https://www.youtube.com/embed/C9osk0UKnMA

Notes

To begin with and prior to the recorded build I pre-installed the CPU and 16GB of RAM.
Due to poor visibility I found it somewhat difficult to install the passive heatsink, opting in the end to screw by hand the two mounting screws just enough to confirm alignment before then pushing the heatsink down onto the chip.
With the 915’s ability to remove basically every panel it was incredibly easy to work with the case, and being a mini-ITX board made it easier still.
Cable management was not a goal during the build. I’ll tidy everything up and utilise the copious amounts of zipties provided both with the 915 and PSU at a later date.
Despite opting for a passive heatsink, while the SSD and HDD accompany the motherboard I’ve opted to install the supplied chassis fan to draw in air.
Unexpectedly the supplied black sata power connectors wouldn’t fit the SSD due to fouling on the backplate on which it’s mounted, so a sata power extension cable was required due to having a completely flat connector on the end.

Sponsors

There are no sponsors just yet.

Get in touch

As always I’m @jasonbayton on Twitter, +JasonBayton on Google+, /in/jasonbayton on Linkedin and I’m available via email.

Free free to get in touch to discuss this or any other topics you have in mind!

Part 1 - Project Obsidian: Objectives & parts list

2016-06-27T10:20:31Z

Just tuning in?

This is a multi-part build log for Project Obsidian: a low power Ubuntu 16.04 LTS NAS & container server.
You’re currently viewing part 1. Head over to the introduction for context and contents.

Objectives

Data

Today my data sits across multiple services; the vast majority of it sits disorganised on my 2015 build, desperately requiring some TLC as I know I have backups of backups taking up large quantities of disk space unnecessarily. Plenty of it though sits fragmented across Drive, Dropbox, Box and OneDrive, this data isn’t backed up and needs to be relatively quickly. I have more than enough space already to bring everything in and dump it on my RAID, but I’m reluctant to increase disk usage on the 2015 build as it then becomes difficult to shuffle it around when the much-needed RAID rebuild has to take place.

Power

The 2015 build idles between 90-110w and can ramp up pretty quickly when under load. As it’s primarily used as a VMware Workstation server for both personal and work projects, it doesn’t sit idle very often. The hexcore works great for what I have it doing, but it’s more powerful than it needs to be once I optimise the system; VMware for example powers several 16.04 LXD hosts as the underlying OS is still running Ubuntu 14.04.4 LTS. The new build will incorporate LXD directly and therefore reduce the amount of virtualised hardware the OS needs to run. With virtualisation reduced, so too is the CPU power requirement meaning I can opt for a much lower-power chip.

Clutter & bloat

The 2015 build is running an install of Ubuntu 14.04.4 LTS from the beginning of 2014 where it began life as a 13.10 install. Ignoring the several upgrades its gone through, the system has been a test-bed for anything and everything remotely interesting on Linux for years. Projects get cancelled, PPAs 404 and dependencies no longer update, so what I’m left with is a cluttered, bloated OS I don’t particularly enjoy maintaining.

VMware fixed that to some degree as I moved a lot of individual services into their own Ubuntu VMs. At one point I was running close to 20 Ubuntu 14/15.x installations and the load on the server was becoming apparent. Later I moved everything over to LXD where it has remained and have switched off almost all VMs.

That hasn’t fixed the underlying install other than allowing me to remove some applications that now live in containers, so the goal with Obsidian is to start with a new, fresh 16.04 LTS build and containerise everything from the beginning; I’m aiming to keep all installations as vanilla as possible so when upgrade day comes, I won’t have anything to worry about.

Space

The 2015 build is huge. I found myself drawn in to the modular capabilities of the Cooler Master HAF Stacker series without truly considering the requirements of the build. Today the server towers above an already large printer and due to the open nature of the case – despite positive airflow and plenty of filters – dust is an issue, one I didn’t face with the 2014 build using a Fractal Define case far more suited to my needs.

For Obsidian I’m partially dismantling the 2015 build, taking the lower Stacker 915R and combining it with a second to create a server capable of holding as many disks as I need at half the size. Dust ingress is still a concern, however I have a plan to better manage this with the two smaller cases combined. The new build will be mini-ITX to sit comfortably within the 915R.

Parts list

With the above objectives outlined I put in the order:

Motherboard

I chose an ASRock AM1B-ITX as my motherboard as it was relatively cheap (£28.73 on Amazon UK), sits on par with other boards in this arena and covers the bare minimum SATA connections required for a maximum of 7 RAID members + OS drive in combination with a PCIe card. In an ideal world I’d have liked 6-8 SATA ports however I can make do, and will look for a PCIe option in the future to support more than 4 SATA ports, freeing up the motherboard all together.

CPU

Having done a little research I found myself repeatedly seeing the AMD Athlon 5350 being mentioned online as something that strikes a good balance between power and efficiency. Again I found the chip was relatively cheap (£29.76 on Amazon UK) and suited the ASRock board nicely. With a TDP of 25w it ticks the box for low power and a cursory glance at CPU boss shows I’m not losing too much over the FX6300 powering my previous builds (I take benchmarking with a pinch of salt).

The AMD comes with a CPU fan as standard, however I’ve ordered a passive heatsink to keep fan noise to a minimum. I’m not normally one to attempt to passively cool my builds, but given the low TDP and the well ventilated case I figure it will be a learning experience.

RAM (not pictured)

I opted, as I normally do, for Ballistix Sport DDR3 1600 to cover the RAM requirement. As Obsidian will be an LXD & Docker host, I decided on 16GB (8GB x2) in order to guarantee resource for every LXD and Docker guest, plus any resource required for streaming from the host itself. The RAM is a more expensive component at £38.99 on Amazon UK but doesn’t break the bank. Ideally I should’ve opted for ECC memory however the board doesn’t support it. At a later date I’ll move the Ballistix into my desktop, swap the board with something a little more up-market and get as much ECC memory in as I can, though that requires I sell some of my existing hardware otherwise I can’t justify the expense.

PSU

Doing some rough calculations I came up with a requirement for ~200w to run the system and 8 drives. Not knowing what the future holds however I opted to give myself a buffer should I choose to use the PSU in another build in the future, or just run something more power-hungry in Obsidian. I therefore went with a brand I always use for power supplies: Corsair. The semi-modular Corsair CX450M is a 450w supply and allows for better cable management than its non-modular alternatives. The supply has been the most expensive component thus far at £42.08 on Amazon UK (not including disks or case).

SATA expansion

I had a spare PCIe 4 port SATA card that I bought at one point when it was on sale. It’s a generic card branded as IOCREST and the same card has been working perfectly well in the 2015 build for many months, so it’ll do for Obsidian in order to expand the 4 SATA ports to 8 until I decide on a more permanent solution or a sponsor sends me something to test!

Update: I got my hands on a Dell H200 dual-controller 8-channel SAS card flashed to IT mode and a couple of mini-SAS to SATA breakout cables. See part 4 for more information.

Case (not pictured)

Already owning a HAF Stacker 935 consisting of the 925 and 915R, for Obsidian I’ve chosen to take the existing 915R from the 2015 build and combine it with a 915F stacked on top to house the server components. It’ll then look similar to this: (image courtesy of OC3D)

The 915F was sourced as an open-box item through eBay for £38

Storage

Finally and arguably the most important component of the Obsidian build. For the OS I’ll be using a 120GB Crucial M500 SSD. This is another spare I have; though they can be had for under £30 on Amazon UK currently, I believe I paid closer to £45 around the time of my 2015 build.

For the RAID I’m currently attempting to engage sponsors. I’m aiming for 7x 8TB or 6TB HDDs for a total of 56TB or 42TB of RAW storage respectively, these figures will drop to 40TB and 30TB respectively once in a dual-parity RAID (RAID6). If that isn’t possible, I have a number of 4TB drives I will use instead.

In any case, the total amount of RAID storage will be over 20TB!

Accessories

I’ve purchased reels of black wiring, black braiding/sleeving and black heat-shrink. The goal here is to create perfect-length power connectors colour-coded to the build to both look slick and maintain a degree of cable management. Beyond that I have black filters, fans, screws and a selection of other dribs and drabs to ensure a very black build.

Build

With the parts (mostly) sorted and the objectives defined, stay tuned for the part 2 where the build will begin! I’m also looking into setting up a camera for the purpose of recording a time lapse, so I’ll see how successful that is and include it in the next part if it works out.

Sponsors

There are no sponsors just yet.

Get in touch

As always I’m @jasonbayton on Twitter, +JasonBayton on Google+, /in/jasonbayton on Linkedin and I’m available via email.

Free free to get in touch to discuss this or any other topics you have in mind!

Part 0 - Project Obsidian: Low power NAS & container server

2016-06-26T23:26:26Z

I’ve built a number of machines over the years, dating back to my first Intel Celeron D build over 10 years ago; it had 2GB of RAM, 80GB storage and I’d spent months saving up for the parts one by one to eventually bring it to life. Since then times and technology have changed; my latest build completed in 2015 is a hex core AMD with 32GB RAM and 24TB of storage (and horrible cable management):

It replaced a 2014 media centre build that shared the same processor, but with 16GB RAM and 6TB of storage (and slightly better cable management):

The only thing these machines have in common, aside from the person who built them, is that they’ve never been documented. I’ve wanted to do a build log for years but despite repeated good intentions have never managed to do so.

For 2016 I set myself a goal to not only build a new system, but document it from start to finish, so without further ado I present my multi-part build log for Project Obsidian: a low power Ubuntu 16.04 LTS NAS & container server.

Part 0 – Project Obsidian: Low power NAS & container server (introduction)
Part 1 – Project Obsidian: Objectives & parts list
Part 2 – Project Obsidian: Build day 1
Part 3 – Project Obsidian: A change, data migration day 1 and build day 2
Part 4 – Project Obsidian: Obsidian is dead, long live Obsidian
Part 5 – Project Obsidian: Setting up Ubuntu – LXD, ZFS & more
Part 5 – Project Obsidian: Migrating data
Part 6 – Project Obsidian: Conclusion

NB: Everything is subject to change until completed.

What is it?

This is better outlined in objectives, however essentially the aim of the project is to build a low power Ubuntu 16.04 LTS server with as much storage as possible. The 2015 build has 20TB in MDADM RAID6 (28TB RAW) and 4TB reserved, my aim is to increase that. Secondly, as well as being a NAS I will be running LXD, Docker and a few native applications to consolidate everything I have around a few local (and remote) servers into one central behemoth.

Sponsors

There are no sponsors just yet.

Get in touch

As always I’m @jasonbayton on Twitter, +JasonBayton on Google+, /in/jasonbayton on Linkedin and I’m available via email.

Free free to get in touch to discuss this or any other topics you have in mind!

5 Android apps improving my Chromebook experience

2016-06-20T16:00:52Z

It’s no secret I’ve never truly seen the attraction to a PC that is essentially just a web browser; my last Chromebook was used once in a blue moon to browse the web and little more before being sold. On the announcement Android apps were officially coming to ChromeOS I knew my perception would change and I was absolutely right.

Now the Android update has been running on my Chromebook for a little while, I’ve spent some time going through my list of frequently used apps to determine how I can improve my Chromebook experience. Here’s a list of the first notable 5 apps I use frequently.

Google Photos

Google Photos is great as it provides simple, direct access to all photos uploaded from all of my devices. It’s easy therefore to upload, download and share whatever I want directly from the Chromebook rather than utilising the Photos website.

As a bonus I can set my screenshots to automatically upload by allowing Photos to monitor the downloads folder, making them available on all devices shortly after I take them; very useful for when I take screenshots on the Chromebook while I’m writing about it using my desktop. Like now.

This functionality was to a degree there already since all my photos are available in Drive, but the experience is different and not any where near as pleasant as using the Photos app.

Word

My reliance on Office has never truly disappeared. I blame it on every company I’ve worked for requiring I use Office, corporate templates, and definitely not Google Docs because it’s not an authorised storage area for corporate documentation (fair enough).

Office 365 and Office Online is fine for what it is, but it’s not at all comparable to native applications. The Android app certainly isn’t as feature-rich as desktop counterparts, but it makes working with office documents that much better than the alternatives.

Word hooks directly into my 365 account and allows me to edit documentation without having to switch to another PC. There are occasionally formatting issues, but they’re not as bad as what I see using Office Online. Definitely the lesser of two evils and I begrudgingly admit I somewhat enjoy being able to use a MS app on the Chromebook.

Juice SSH

Back in the day, Chrome OS provided a relatively OK SSH client through Crosh, the Chrome OS terminal (Ctrl + Alt + T if you’ve never seen it and are using a Chromebook to read this now).

Then for reasons unknown by me they dumped it and requested everyone install Secure Shell to re-enable the functionality.

If I have to install an SSH client, I may as well install one I enjoy using on my other devices: JuiceSSH. Other than it being very customisable, it has features such as CloudSync (pro licence) keeping SSH endpoints synchronised between all signed-in clients, snippet support for providing easy access to saved commands and plugin support to further extend functionality as required.

I’ve been using JuiceSSH for a couple of years and recommend it for anyone looking for an Android SSH app.

Nextcloud

Beyond the corporate stuff in Office 365 and some data I keep in Drive, Nextcloud hosts everything else I have on my own home servers.

What is Nextcloud?

Nextcloud is a recent fork of ownCloud that’s already quickly becoming the newer, better and faster-developed alternative to the ownCloud of old. If you’re an ownCloud user and have ever been frustrated by the dual licenses, the paid vs free model and – as part of it – lack of some of the better features, Nextcloud have gone completely FOSS following the Red Hat model of charging for enterprise support rather than enterprise features.

I’m very happy to have made the decision to migrate so soon at what is but the beginning of their journey. More info: nextcloud.com

Chrome OS has an app in the webstore called Network File Share that’s recently been released to provide access to network shares and it works fine – the added shares all show up as new paths on the right-hand side menu in the files app – but like Photos and Drive, it’s not the same as having a dedicated app utilising an interface designed to compliment the solution whether inside the network or accessing remotely.

The Nextcloud app allows for quick, simple access to my private datastore from anywhere, and makes it super easy to upload, download, edit and share data with a few clicks.

Gmail

A definite nice to have; I’m somewhat used to accessing mail direct from my device rather than through a web browser. Gmail works pretty well, although it’s a lot slower to sync on the Chromebook than pretty much anything else I have it installed on. I put this down perhaps to sync settings, though unlike a normal Android device it’s not seemingly possible to get into the guts of sync settings to make changes. Perhaps that’ll change with an update.

Bonus: Chrome

Not really.

Conclusion

This is just a small list of the apps I’ve found that add to my Chromebook experience and I’m working to find more as I go along. Unfortunately not everything seems to run quite right at the moment, with the two big ones I’m missing being TeamViewer as the app crashes the Chromebook entirely and Sonos as the way the Android container is networked is not allowing it to scan my LAN for my speaker system.

Regardless of how trivial it may seem to be able to do something via an app rather than going through a web interface, it all adds up to what feels more like a conventional “desktop” experience and less cloud-based; one of the biggest things I’ve disliked about Chromebooks to date.

Have you gotten the Android update for your Chromebook? What are your go-to apps? Let me know in the comments or tweet me @jasonbayton.

First look: Android apps on ChromeOS

2016-06-18T00:03:23Z

After almost a month following the announcement, Google has finally dropped ChromeOS update m53 for Asus Chromebook Flip dev channel users and with it, the Play Store.

Following last month’s announcement I ordered a Flip almost without hesitation. I’ve been waiting for Google to expand on their previous ARC beta back in 2014 and having spent a few hours with it this evening, here are my thoughts.

What is it?

Unlike ARC (App Runtime for Chrome) – a solution that required modifications to be made to Android apps in order for them to run – Google’s new approach takes a leaf out of the increasingly popular Linux container world (Docker, LXD, etc) to provide a minimal Android environment within a secure container running on alongside Chrome on the ChromeOS system, this has the benefit of sharing system resources effortlessly when compared to traditional hypervisors and as such performance is top-notch.

As the Chrome OS UI sits atop of both Chrome and the Android container, both systems can be integrated into the same UI. Notification access, windowed applications and the general feeling of a “native” solution has been achieved.

It “just works”

Upon booting back into ChromeOS following the update, the Play Store icon sat unassuming on the shelf. On opening the Play Store I was greeted with a little introduction (above) and terms of service.

A couple of clicks later, here it is in all its glory!

Navigating around the Play Store is super smooth and feels pretty natural. The Flip is a touchscreen-enabled Chromebook, however using the Play Store with either the touchpad or the touchscreen work equally well.

Applications install quickly and notifications are well integrated into the ChromeOS notification centre.

It’s fast

Being a developer preview I wasn’t expecting the system to fly; I was very much waiting to watch as the Flip, or at the very least the new apps running on ChromeOS regularly grind to a halt.

Not a single stutter.

This likely has a lot to do with the container technology used to run Android on ChromeOS rather than a traditional hypervisor approach as mentioned above wherein the container shares resources with the host directly as opposed to Chrome OS having to virtualise the hardware on which the Android framework runs. This dramatically reduces the resources required to run it. It may also be because the Android system running appears to be relatively light, foregoing features in favour of speed. Of course it could be something entirely different!

As it stands at the time of writing, I have Gmail, Google+, JuiceSSH, Spotify, Skype & Hangouts running. Switching between these apps is effortless and despite the added load, there’s no indication the Flip can’t handle it.

Additionally, apps appear to be able to work in the background even when the app window is closed. JuiceSSH for example retains a permanent notification in the notification area when an SSH session is active. Clicking this will launch a window to return to the session exactly where it was left off. A nice addition.

It’s not perfect however, as I noted youtube videos would stop once they were no longer the “foreground” app, however this was hit and miss; it would appear providing the Android app is foreground on the Android container it was possible to retain a level of interaction even when using Chrome. If I brought up another Android app, this was no longer the case.

It’s easy to manage

Once apps have been installed, they’re all available within the Launcher. It’s not always possible to differentiate the Chrome apps from Android apps, so occasionally confusion can occur where two (or more!) versions of the same app have been installed.

Right clicking on any app provides a quick and simple way of uninstalling it, though this can also be done through Android settings linked from within ChromeOS settings.

From Android settings it’s also easy to configure other aspects of the Android container, like additional accounts, notification settings, print settings and more. Again, not being a mobile device the options available are quite a bit more limited, but it’s certainly granular enough to get the job done.

But it’s not perfect

Obviously it’s available only to those on the dev channel for a reason; this implementation of Android is certainly not without its niggles:

While the Android world comes to terms with this new functionality, applications won’t be perfect. Some applications when maximised show large black bars, some force close. Others such as those requiring GPS, telephony or any sensors unavailalbe on a Chromebook as a prerequisite for installation won’t be compatible.
Trying to store data on the local storage area leads to hanging in some applications, particularly the screen recorders I attempted to use to capture video for this review (sorry!)
Windows can’t yet be dynamically resized and are therefore fixed to the three window sizes Google have defined, except for the option to maximise.
Attempting to update the Android OS results in an immediate force close of the settings app.

I would definitely also like to see adoptable storage for ChromeOS, the 16GB most Chromebooks have today is pretty limited when considering there’s ChromeOS, Android and all related apps from both platforms taking up space. What remains isn’t significant.

Conclusion

For a development build I really can’t knock what Google have shipped here. The speed and simplicity far surpass my expectations and the ability to access the Android system settings directly is a nice touch that retains a level of user control.

With this new feature I truly now believe Chromebooks are finally usable for the many who have held out due to limited functionality; before the announcement of the Play Store I would have never even considered getting another Chromebook (I’ve used a few over the years, never for very long), yet for the price and now the capabilities offered, it’s a steal.

I’ll look at Chromebooks in a whole new light from now on.

Competition: Win 3 months of free VPS/Container hosting - Closed!

2016-05-17T15:42:39Z

The competition is now closed

Thank you to everyone who entered. If you won you will be contacted in due course.

Note: As of 27.05.2016 the rules have been relaxed to make it easier to enter the competition!

To celebrate my 100th post on bayton.org I’ve teamed up with ElasticHosts, the subject of my latest review, to provide one lucky reader with 3 months of free hosting on the ElasticHosts platform.

What you get

The winner can select a region of their choice and benefit from the following resources for the entire duration of the promotional period:

2000 MHz CPU (VM)
1024 MB Memory (VM)
2000 MHz CPU (Container)
1024 MB Memory (Container)
5 GB SSD
30 GB Disk
1 VLAN
1 Firewall
1 Static IP (public IPs are provided for all servers via DHCP)
10GB data transfer per month

This will allow provisioning of a number of containers, a couple of VMs and the ability to test-drive a vLAN and Firewall. All completely free for 3 months!

How to enter

For a chance to win, these steps must be completed by 15/06/2016:

Follow @jasonbayton & @elastichosts on twitter.
Share the ElasticHosts review on your social network of choice using the hashtag #EHTrial.

The rules

ElasticHosts’ updated T&C’s can be found here.

The winner will be selected within 14 days of the competition ending and contacted via tweet to the provided @handle once the prize can be redeemed.

How to enter

~~For a chance to win, these steps must be completed by 31/05/2016:~~

~~Follow @jasonbayton & @elastichosts on twitter, and like ElasticHosts’ page on Facebook.~~
~~Share the ElasticHosts review on your social network of choice using the hashtag #EHTrial.~~
~~Sign up for a free trial with ElasticHosts (no payment information required).~~
~~Share your experience of the platform via a public post on social media, a YouTube video or a blog article.~~
~~Once you’ve published your social media post, YouTube video or blog article, you can submit the link to it in any of the following ways:~~

~~In the comments below (Please include your twitter @handle in comment submissions).~~
~~Via tweet using this pre-populated link to us:~~

Tweet to @jasonbayton
@elastichosts

Please note: Once signed up, you have 5 days to utilise the ElasticHosts platform before the free trial expires. However, the competition will not close until 31/05/2016 providing plenty of time to consolidate your thoughts and submit an entry.

The rules

~~As this is a corporately sponsored competition, there are terms and conditions. ElasticHosts’ T&C’s can be found here.~~

Some key points:

~~The competition will run up to and including 31/05/2016. Any entries after this date will not be considered.~~
~~All entrants will be subject to verification of steps 1-4 and may be contacted to confirm this.~~
~~The winner will be selected within 14 days of the competition ending and contacted via tweet to the provided @handle once the prize can be redeemed.~~
~~If for any reason the entrant no longer wishes to take part, they should contact the Promoter to delete any data associated with their trial account.~~

Good luck!

If you have questions or concerns, please comment below, tweet/DM me @jasonbayton or email me.

I look forward to announcing the winner in June!

ElasticHosts review

2016-05-09T15:17:43Z

ElasticHosts are one of the earliest cloud computing providers to launch in Europe, doing so all the way back in 2008, and since then have become a cornerstone of today’s providers of VPS and container solutions.

They were the first to provide SSD storage, first to provide containers through their arachsys container platform and one of the first to utilise KVM as their underlying VPS technology. It wasn’t until last year, however, that they really caught my attention.

You may have seen a review I wrote on Springs.io back in February after testing out the platform for a good many months. Springs is an ElasticHosts subsidiary which runs the same technology stack that powers ElasticHosts datacentres all over the world.

Following that review, ElasticHosts invited me to put them to the test again, this time going as far as to move my more-important services away from AWS and on to their infrastructure – something I wasn’t willing to do entirely with Springs due to a lack of redundancy on what is a relatively new service.

So I did! Here are my thoughts on the experience so far..

In a rush?

Skip to the conclusion for a chance to take part in a little surprise I’ve lined up!

Choosing a location

Unlike the likes of AWS, OVH and others, when you sign up for an account with ElasticHosts you do so to one particular region. Should you create an account in the London Maidenhead region and later decide you want to put a few servers in Miami, you’ll need to create a new account on the Miami region.

Speaking to ElasticHosts I discovered this is by design. While having one account with access to all regions would be convenient, it also introduces a point of failure in requiring a centralised SSO (single sign on) service. Keeping the account management decentralised is intended to improve redundancy in the event of a failure.

Typically all regions offer the same services, though some regions cost a little more or less than others depending on demand and location. London, for example, is a little more on the expensive side which I assume correlates directly with the cost of running a datacentre in the region. The exception to the services offered is the newly launched Cloud Storage, which is only available in Maidenhead and Dallas for the time being, though I understand this will change in the future also.

Once a region is selected, signing up for a free, 5-day trial account takes only a couple of minutes before you’re ready to get started. I was surprised to see ElasticHosts generates a password and sends it in two halves; one as an email and the other as a text. I’ve not seen this practice used by other providers and appreciate the security-concious approach.

The interface

The interface is simple and clutter-free. Until a server is created there’s really nothing on there bar a message reminding you of the remaining time left on your trial. This disappears once the trial finishes or as soon as either a plan is selected or credit is added.

Beyond that though there’s not a lot to explore until you’ve had a few servers up and running for a while, at which point the Activity and Statistics tabs begin to show some meaningful data. I like the fact there’s a region identifier on the top right of the screen, and hovering over this allows for quick switching back and forth between them.

After adding a few servers, vLANs and static IPs the interface starts to look a little more interesting:

As with Springs, it’s an interface that focuses on the servers you’re running rather than everything around them, and that’s a design philosophy I very much like. I also like how servers are grouped within their assigned vLANs if that functionality is enabled (as can be seen in the screenshot above).

Server management

In-keeping with the simplicity of the interface, managing servers is a piece of cake.

Creating a server

Clicking the Add button pops up a number of options to choose from. Within this menu you can not only create servers, but additional drives/folders to mount to existing servers, vLANs and static IPs.

Selecting either a Virtual Machine or a Linux Container server will bring up a new window, though the options at this point are pretty much the same; just provide a name, CPU and RAM thresholds, and either an image to provision from, an already-provisioned disk/folder to attach or – in the case of a VM – a live CD to boot from. VMs also benefit from disk thresholds.

The server will then provision. Once complete, powering on the server and clicking on the icon will provide login credentials.

Managing servers

As easy as it is to spin up a server, managing them is no more difficult. Looking at the control panel the ability to power servers up and down, adjust resource limits and to obtain connection information is available at the click of the mouse. Clicking on the icon however goes one step further, revealing every possible configuration option for servers as follows (click to enlarge):

Both containers and VMs share a majority of options, though where containers provide an SSH password for remote administration, VMs additionally provide a VNC connection – particularly useful for operating systems that don’t run an SSH server such as Windows. Furthermore, containers allow the mounting of additional folders and VMs additional disks (it is possible, however, to mount folders within the OS of either).

From within this management interface you can also assign additional NICs, IP addresses and firewall rules; though the former two need to be set up first:

Additional IPs can be created through the Add button. There’s no customisation available, when a static IP is requested, ElasticHosts provides one from their pool.

Assigning the IP to a server means opening the menu while the server is powered off, changing the Network option from Assigned at boot to the static IP that’s now available and clicking Save. When the server boots back up it’ll have it’s new static IP and the previous DHCP-provided IP will return to the ElasticHosts pool.

Private vLANs are also created through the Add button. Once again the menu should be opened and an additional NIC assigned. Once this is done the new vLAN will be available in the dropdown associated with the new NIC.

Interestingly I had initially imagined the vLAN would be pre-configured with a private IP range that could be edited, however it is completely unmanaged and relies on the server admin to assign the vLAN to all servers required and manage the IP side of things there. I created a DHCP server within a container to test the functionality of the vLAN and was pleasantly surprised with the relatively little effort it took to set up internal communications between servers.

Deleting servers

To complete the lifecycle, deleting servers is simply a case of clicking the delete icon on both the server and it’s allocated storage. In order for the storage to be deleted, the interface requests entering a confirmation to make absolutely sure a deletion was intended. Once that’s done the data is gone.

Similar prompts also appear when trying to delete a vLAN, which makes sense – removing a vLAN that’s in use could have a pretty dramatic effect on inter-server communications on larger deployments.

Additional tools

In addition to what has been discussed already, ElasticHosts provides a few other tools and solutions that aren’t necessarily all that common amongst the competition.

Backups

Backups are absolutely critical to the successful running of servers long-term. It’s impossible to say when downtime, corruption or complete catastrophic failure will take a website irreversibly offline.

While most hosting providers offer backups, I’ve yet to come across any other provider that offers a combination of simplicity and utility; backups can literally be made at the click of a button. Though this is not unique, clicking the icon immediately creates a carbon-copy of the folder or drive, with drives even providing the option to copy either to HDD or SSD:

With that disk/folder copied successfully, there are a couple of things that can be done with it.

Mount it locally – For containers, each folder can be accessed remotely via webdav, SSH or the API. This means after a backup has been taken, it’s really simple to mount the backup copy on my local machine and take a copy of the server data without impacting the live server at all.

Mount it on another server – using the same details as above it’s just as simple to mount a folder to another server. Additionally however it’s possible to mount the folder natively within server settings, overcoming any network bottlenecks you may otherwise face.

Duplicate a server – As mentioned in the beginning, when adding a new server one of the options presented is to boot from an existing drive/folder. Selecting the copy will essentially create a duplicate of the server that was backed up.

Backups in the opposite direction (Cloud Storage)

As well as creating copies of servers to backup websites and such like, it’s also possible to create a standalone, empty folder. When not assigned to a container, folders can be used as remote storage locations, enabling tools like rsync to replicate local data into storage areas on ElasticHosts’ infrastructure.

In fact, as mentioned at the beginning ElasticHosts just recently launched a new service called Cloud Storage.

It’s essentially folders, but based on cheaper spindle-based storage whereas folders utilise SSDs. This makes remote backups even cheaper than previously.

Firewalls

Within every server is the ability to configure firewall rules, it works just as expected, only permitting traffic on the ports specified and blocking everything else.

In the example above I opted for a “whitelist” approach which, depending on requirements, may not be suitable for everyone. I know for certain I only want that server accessible over 3 ports and it works like a charm.

For the cost ($7.50/month) it’s not something I’d rely on long-term, instead perhaps looking to achieve the same result with iptables, but as a proof of concept it’s great.

Statistics and reports

Two of my favourite things. ElasticHosts provides an audit log of every action within the account for everything from logging in to destroying a server all through the Activity tab.

With a detailed audit trail like that, it’s easy to keep tabs on who’s doing what with the account in larger teams. Naturally filtering is available in the form of Search.

Similarly, the statistics tab does an excellent job of visualising things like plan limits, CPU usage, network usage and much, much more.

This provides granular insight into the activity of your servers and can be used to compare activity to bills should a query arise.

Pricing

Compared to Springs, ElasticHosts pricing model is quite a bit more complex. Just running containers within San Jose, Dallas or Miami* will work out the same with pricing as follows (correct at time of publishing):

CPU (core-GHz per hour): $0.008
RAM (GB per hour): $0.011
SSD (GB per month): $0.250
Data transfer over 1TB (per GB): $0.050 (* only the three regions above get 1TB free traffic)
Static public IP address (per month): $3.000

The exception are IP addresses which are for some reason $1 more expensive per month. Additionally, testing out vLANs and Firewalls will set you back $7.50 for each every month, which is a little too high for my liking!

Opting for other regions causes the pricing to vary. Understandably VM hosting is a little more expensive but still very much in the realm of competitors. Thankfully discounts are available when purchasing plans rather than relying on pre-paid credit which can bring the cost down significantly.

The full price list can be found here, and I’d very much advise reading and understanding it thoroughly before getting started.

Issues

Considering my biggest gripe with Springs was the lack of redundancy, there’s really nothing major to report with ElasticHosts.

That said, here are a few niggles for the sake of a balanced review!

Out of date images

Although they provide free data transfer in most regions, I’ve found some of the images provided such as Ubuntu and pfSense are quite a bit out of date. It’s not a huge problem, but given the first thing you do on a new installation is update it to patch security holes and improve reliability, waiting around for everything to download and install isn’t the quickest way to get started.

Cloud Storage availability

Currently the new Cloud Storage solution is only available in a couple of regions. Reading through some of the how-to documents you get the impression it has been deployed everywhere and immediate come to find the option under the Add button missing. It’s a little confusing.

Lack of documentation/visibility

I really like ElasticHosts, but finding out information about the various solutions has been a bit of a chore. Furthermore, for a company that’s been around since 2008 the amount of documentation and, as such, visibility on the web leaves a lot to be desired. Although recently there’s been an apparent push to publish more documentation (if their social media accounts are anything to go by), ElasticHosts need to market themselves so, so much more than they do.

Support

For issues where help is required, ElasticHosts support is fantastic.

They’re quick to respond, intimately knowledgeable with their platform and always eager to help. Their support team isn’t huge, so in the myriad of requests I’ve made I’m regularly talking to the same few engineers across both ElasticHosts and Springs.

Not only are they helpful when issues arise, they’re equally always open to suggestions and improvements; most recently I requested an updated beta image of Xenial (just before the official launch) and they were more than happy to get that set up, which is just one of several examples where they’ve gone above and beyond what I’d typically expect based on experiences with competitors.

ElasticHosts support is easily in the top three of any company I’ve ever used.

Conclusion

Having already spent time on their technology stack in the form of Springs, I had a good feeling moving over to ElasticHosts. The more time and energy I invested in the platform, the more confident I’ve been feeling about hosting even my more important services with them.

Their interface is easy to use and intuitive even for the less technical of users. For the more advanced features their support is amazing.

Do I think ElasticHosts is for everyone? No. Truthfully like any VPS provider, for the average Joe looking for somewhere to host his first website this is a bit overkill and likely more expensive to maintain than your everyday web hosting companies.

For the power users, larger groups and businesses looking to invest in a plan and/or take advantage of all the features EH has to offer however, it’s a fantastic solution and definitely worth the investment.

If you’re interested in trying them out, every free trial comes with 2000 core-MHz CPU, 1GB RAM, 30GB HDD and 5GB SSD which can be utilised for 5 days. Just sign up to get started!

—

Do you use ElasticHosts? Are you considering it? Let me know in the comments or tweet me @jasonbayton with the tag #EHTrial

Are you interested in winning 3 months of free hosting?

In celebration of this, my 100th article on bayton.org, I’ve arranged a competition with ElasticHosts to provide one lucky winner with 3 months of free VPS and container hosting.

More information will be published shortly, in the meantime feel free to register your interest below to be notified when the competition goes live!

ElasticHosts: Cloud Storage vs Folders, what's the difference?

2016-04-15T12:48:38Z

ElasticHosts recently debuted Cloud Storage, their new remote backup solution geared towards Linux users. Working with tools such as Rsync, SCP, SSH & Cron, Linux admins can set up automated backups to their own offsite storage area(s) on ElasticHosts infrastructure.

Having recently moved some of my Springs.io containers into ElasticHosts, the announcement piqued my interest and I decided to check it out. According to their announcement, here are some uses for Cloud Storage:

Offsite backups: Full Rsync integration allows system administrators to import files and maintain incremental backups using standard Linux tools

Shared network drives: Share files, connecting securely from multiple locations over SSHFS or WebDAV

Hosting static web pages and downloads: Serve simple pages or large downloads without a webserver, or offload these from your webserver

Integration with ElasticHosts cloud servers: Run auto-scaling Linux Containers directly from SSD storage, and mount your storage on VMs, enabling tight integration with your software and direct remote access into the filesystem of your running server

With pricing starting as low as $0.06 per GB, it’s a tempting proposition. What’s interesting though is ElasticHosts have been already providing this functionality with folders (the storage half of their containers) for quite a long time.

So how is Cloud Storage different?

It isn’t (yet) available in all regions

ElasticHosts has several regions available from London to Amsterdam, the US to Australia. The first thing I noticed when I logged into my region (Amsterdam) was the option to create a shiny new Cloud Storage instance wasn’t there.

I’ve no doubt it will expand in the future, but in the meantime some form of visual cue to suggest you’re not in the correct region wouldn’t go amiss here. I spent a good amount of time searching around before concluding it wasn’t available to me, personally, just yet. This isn’t the case of course.

For those eager to try it, it’s available in the London region at the moment (amongst others).

Expectation taken from here.

It’s slower

Cloud Storage uses traditional spindles for data storage whilst Folders use SSDs. My immediate mental comparison was Amazon’s S3 vs Glacier (that is, fast and readily available storage vs slow, infrequently accessed storage), though definitely no where near as extreme (or annoying to use).

Is this a bad thing? Of course not. Remote storage is hardly benchmarked for speed, and in real-world usage it wouldn’t be apparent at all. If anything it’s a win-win; ElasticHosts provide storage on what are likely underused disk arrays, and customers don’t pay as much as they would otherwise have to using Folders.

And yes, it’s cheaper

Based on current pricing, SSD storage is $0.25 per GB per month. Cloud Storage on the other hand – as mentioned above – can be as little as $0.06 per GB depending on the chosen region, allowing for 4x the amount of data to be stored for the same price as Folder storage with all the same functionality.

So with that in mind, if you’re currently utilising folders for remote storage and feel like cutting your costs, switching to Cloud Storage may save you a pretty penny to invest in other areas of ElasticHosts’ infrastructure.

—

Are you using Cloud Storage? Let me know in the comments or tweet me @jasonbayton.

Interested in ElasticHosts? I’ll be writing about them again soon. Stay tuned!

Adding bash completion to LXD

2016-03-23T15:11:13Z

I’ve recently started moving my servers from VMware to LXD running on a Ubuntu 15.10 host due to the rapidly maturing platform combined with incredibly low resource usage.

One of the most frustrating “issues” with LXD so far has been the lack of bash completion when fumbling around on the CLI. I’ve become so accustomed to bash completion being part of everything and anything Linux that having to manually type out all commands in full for LXD is a chore, particularly when the container aliases are quite long!

Example: lxc exec mylongcontainername-32 bash
Better example: lxc config device add ip48-mycontainer Resources disk source=/media/mount/resources path=/media/mount/resources

After raising this as a feature request, LXD dev tych0 soon replied offering a simple solution; pop the already-present bash completion profile into the relevant directory:

sudo cp /usr/share/bash-completion/completions/lxd-client /etc/bash_completion.d/ 

Followed by a quick logout/login to make sure it’s applied.

So LXD ships with a bash completion profile, but for whatever reason it isn’t enabled by default. Hopefully this will be resolved for the launch of LXD v.2.0

Happy containerising!

Update:

bash_completion.d is deprecated and the reason the included bash completion profile doesn’t work is due to a naming issue. This should be fixed in an update soon, but for the time being and while bash_completion.d is still available for use, popping the existing file in there will at least enable the functionality in the short term.

Android N: First look & hands-on

2016-03-09T23:34:16Z

The Android N beta program has been open to to the public for a couple of hours as of writing this, and after an excruciatingly slow ~800MB OTA download following my immediate opt-in I’ve got the first development build running on my Nexus 6.

What’s new

It feels immediately as though something’s changed on first boot, with a lockscreen that’s visibly different. The notifications catch the eye straight away.

Gone are the adequately spaced cards in favour of a new, tighter, simpler design. In addition similar notifications are grouped together, expanding on a quick tap near the arrow beside the notification time. Once expanded they look like this:

The screenshot above also sheds a little light on the new notification shade. As can be seen there are now quick shortcuts along the top (which can be edited) which on a second swipe down then opens the full selection of settings as it did in Marshmallow.

The lockscreen is fixed in portrait orientation, as is the Google Now launcher the device unlocks into. While on the subject of launchers, Android N so far retains the oh-so-Androidy application drawer!

Opening settings reveals a similar but slightly different layout. There’s a new “Suggestions” area at the very top which offers shortcuts to things like screen lock and wallpaper. It’s an interesting idea, though one I fear may be somewhat redundant to all but brand new users to Android (after all, users of the over 1 billion devices in the wild would have already figured most of it out by now).

Additionally there’s now more information immediately available while scrolling through settings. It’s nice to see information like how much data has been used at a glance rather than having to tap into it first. If you do tap into one them though, Android N now has a menu to jump between various settings:

I also noticed Android Pay is the default Tap & Pay option, though this may be already the case in countries where Android Pay is supported.

Android N debuts a change in the way multitasking is handled in Android. Tapping and holding the recents key will allow for two apps to be selected to run in split screen. It works surprisingly well.

In the above screenshot Settings is in the left window and in the right is recent applications. Additionally – and I discovered this accidentally – tapping the recents key repeatedly will now cycle through the list rather than opening and closing recents repeatedly; a really nice usability feature.

Finally, it looks like night mode is back! By tapping and holding the settings cog in the notification area, another menu item will appear in settings called “System UI tuner”. In here night mode (amongst other things) can be enabled. Hopefully this will make it into N and not get pulled at the last minute as it did for M.

Other notable additions to N

Beyond the immediate, noticeable features, Google have additionally added the following:

Picture in picture for apps, which will allow videos to continue running whilst browsing the web or checking emails.
Reply to notifications directly from the notification shade.
Doze is more aggressive, kicking in even when the screen is turned off.

Issues

This is a developer build and as such problems are to be expected. So far the Google App has crashed a good number of times, and ~30 of the 45 updates on my device have failed for “unknown reasons”.

Beyond that luckily everything is working as expected, which is incredible for such an early beta.

Have I missed something?

If you’ve noticed any new features that I haven’t, shout out in the comments and I’ll update and credit accordingly.

Now you’ve finished reading this, it’s time to get involved! Head over to google.com/android/beta to enrol your own supported device and experience the new features for yourself!

Springs.io - Container hosting at container prices

2016-02-29T12:54:12Z

Elastichosts are a long-established player in the hosting arena offering a vast range of dedicated and VPS servers to individuals and businesses alike.

Last year, in line with the huge growth of container technology in recent years (Docker, LXC, LXD, OpenVZ, etc), Elastichosts launched Springs – a flexible, easy to manage and cost-effective hosting platform based entirely on Linux containers. Unlike other providers, Springs doesn’t use a pre-built container solution, instead opting for their own software built from the ground up by co-founder Chris Webb: Arachsys Containers.

Back in Springs’ infancy, I was contacted over Google+ to see if I’d fancy taking a look at their brand new platform. I was offered a bit of starter-credit after creating an account and got started on the transition from my previous VPS provider OVH.

I opted to do this gradually starting with just the one server running bayton.org. I later added a few more services as my confidence in the platform increased. The containers are all run on SSD storage and have access to a 20 core Xeon processor with ~260GB RAM, at least from what I’ve seen so far. How many servers they have at this point I can’t say, but when I started using the platform they only had the one.

Days turned to weeks without any issues. As my starter credit diminished my first request was the ability to add credit via PayPal, which was implemented pretty quickly (to my surprise!).

Following that, I’ve simply been enjoying the simplicity and flexibility of the service. Even today the server my containers run on is still very much underutilised and as such I haven’t experienced any performance problems.

So, how does it work?

On creating a new account and logging in, add a bit of credit (assuming you aren’t gifted any as part of a trial). Adding credit, at least via Paypal, is quite a quick, painless process and once complete is immediately available for use.

When you’re ready, clicking “Add Spring” will open a popup requesting a server name (one will be auto-generated for you), operating system and optionally an SSH key. At the moment the only options are Debian, Ubuntu, cPanel and centOS. That may be expanded in the future, but for those of you wishing to run openSuse, fedora or any other distribution you’ll be out of luck at present.

Once you’re happy with your selection (and do make sure you are as the distribution can’t be changed later) click Add Spring. It may take a moment or two to initialise and install, but once ready will show in your server list as follows:

At this point, you’ll notice the container is switched off and the IP is blank. Clicking “Login” will let you know you need to turn the container on before anything else can happen.

Cancel out of that and click on the power toggle. Once the IP populates, login details will also shortly become available. If you used an SSH key this information will be of little concern, if you do need the password however clicking “Click here to reveal it” in the Login popup will do just that.

And that’s basically all there is to it. You can now SSH into your Linux container and begin running the services you’d run on any other normal virtual or physical server.

If you wish to limit the resources the container can use, simply change the values listed next to CPU and RAM. I found 2000/1024 to be quite a bit more than I’d need on a modest little webserver and so have lowered them as can be seen in the screenshot above.

In the beginning I wasn’t sure what I should set it to for my web server, so I left it. After a while the Average usage area begins showing how much resource the container is demanding and from that more adequate limits can be set.

In the below image I can see over the last month the CPU hasn’t spiked past 25MHz, so the limit of 500MHz both provides a huge buffer in case of dramatic increase of activity (one can hope, right?) and a limit to how much money I’d be prepared to spend should demand increase.

Finally, when you’re finished with a container, clicking Delete will irreversibly destroy the container and all data within it.

Costs

The pricing for Springs is based on usage, so setting the CPU to 2000, 3000, or 10,000 doesn’t mean you’ll be paying 10,000*$0.008/hour. If the server is only using 0.32GHz and 128MB of RAM on average, that’s what you’ll pay for. This also makes it a little more difficult to estimate exactly how much you’re going to spend, but it can be figured out once the server is up and running and averages are being reported.

Springs has a usage calculator, but for those like me who want to see figures in black and white, the pricing breaks down as follows:

CPU (core-GHz per hour): $0.008
RAM (GB per hour): $0.011
SSD (GB per month): $0.250
Data transfer over 1TB (per GB): $0.050
Static public IP address (per month): $2.000

I’ve watched the costs slowly creep up as I’ve added more servers. At the moment running 4 servers – a mix of web and DNS servers – I’m giving Springs about $20 a month, roughly £14. For comparison my OVH server cost me around £10 a month and was only used for web hosting. Similarly my t1 nano AWS instance costs me about £4 a month.

Springs is drastically cheaper than running 4 OVH servers, and a little cheaper than running nano instances on AWS. Unlike either of those platforms though, I don’t think adjusting resource caps could be any easier. Managing multiple containers from that one simple panel is a breeze and the support Springs includes is equally top-notch – quick, personal and they’re always happy to help.

On that basis I couldn’t be happier with the costs incurred so far.

What could be improved?

As is stands currently I’m really happy with Springs and have recommended it to friends and colleagues on many occasions. I would like to see a few things though..

More options

I mentioned above that Springs containers are limited to those 4 options. It would be nice to see that expanded out to more distributions. What would be potentially even better though is templates. Some hosts can deploy ready-to-run WordPress/Drupal sites, LAMP instances, ownCloud instances, etc. at the drop of a hat. If Springs could replicate this with their container hosting they’d immediately appeal to a much, much wider audience; an audience that doesn’t care about operating systems or command line interfaces and just wants a button to click and a link to navigate to. The cPanel offering addresses this to some extent, but it could be easier.

Reliability

I mentioned at the beginning that as far I was aware Springs was only hosting containers on the one server. This was totally fine, until it wasn’t.

Dear Springs Customer,

Please be advised of a container host reboot in Springs on 09/Sep/2015 UTC 17:16 .

The host is now back up and all containers should now be running.

[…]

Best regards,
Springs.io

A few months back I received the above email to say the Springs server had gone down. Everything came back up promptly with minimal downtime but it did get me wondering how I could spread my servers across multiple hosts to reduce the likelihood of a total blackout in the event of a prolonged period of downtime.

At the moment it’s not possible. Downtime matters to me, which is why I’m keeping some of my services on AWS for the time being. Springs expanding to more hosts with the appropriate options within the console to manage them would negate my need to have services on other platforms.

It’s worth mentioning that so far since the middle of last year the server has only bounced once. I’ve suffered no further downtime since.

Reboots

At present, rebooting a container with via command line will shut it down. This caught me off guard a few times in the beginning where I waited, and waited, and waited a bit more for the container to become available over SSH again before eventually logging into the control panel to see what’s happened.

Thankfully they’ve more recently added a warning when the reboot command is given:

Reboot doesn’t yet work as expected inside containers.
This container will now be shut down, please start it from the Control Panel.

Broadcast message from jason@ubuntu
(/dev/pts/1) at 23:10 …

The system is going down for reboot NOW!

This is a limitation of the Springs containers at present and is being worked on. Hopefully it won’t be too much longer before a solution is found.

Is it worth it?

Absolutely.

This is still a relatively new service which is gaining momentum. While it’s unlikely that problems occur, it’s a possibility and regular backups should be taken (which is the case with any host).

Springs offer a really nice, easy to use interface. Their support team are friendly, prompt and knowledgeable and as well as benefiting from reasonable pricing, you get to use the same infrastructure that powers Springs’ parent company, Elastichosts.

I only wish they’d open source that control panel so I could use it for my containers at home!

Do you use Springs? Are you considering it? Let me know in the comments or tweet me @jasonbayton with the tag #SpringsIO

Apple vs the FBI: This is why we need MDM

2016-02-23T14:06:40Z

If you’ve been online in the last few weeks you may have caught wind of a high profile battle of will between Apple and the FBI.

To summarise: The FBI want to gain access to an iPhone recovered from the San Bernardino massacre last year, but due to the security policies in place by Apple it is not currently possible. Should they try to brute force it, it’ll wipe itself after 10 failed attempts. To work around this the FBI want Apple to create a version of iOS that will remove this policy, essentially allowing the FBI to try all 10,000 possible combinations.

Creating this version of iOS in itself is no particularly difficult task; it is the aftermath that has the tech world concerned. Tim Cook himself said it best:

the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation. In the wrong hands, this software — which does not exist today — would have the potential to unlock any iPhone in someone’s physical possession.

While the FBI have been on the defensive, it’s recently come to light the DoJ could have about a dozen more iPhones they’ll want unlocking in the near future. The FBI winning this argument sets a disturbing precedent for the future of smartphone security and privacy, and to say it won’t ever fall into the wrong hands would be naïve.

This could have been avoided

The iPhone in question belonged to and was issued by San Bernardino county; a county that apparently uses an Enterprise Mobility Management platform to manage their mobile estate, but for reasons only they would be able to provide have not enrolled all of their devices – including this iPhone.

I spend a lot of time talking and writing about the advanced functionalities EMM suites are capable of providing – app management, location tracking, message/telephone histories, containerisation of apps/services and so much more. Yet at its core, every platform has one thing in common – device management.

That means enforcing security policies: encryption, passcodes, black/white lists and restrictions on capabilities of devices. But just as these policies can be enforced, it also means San Bernardino could have just as easily reset the PIN used to secure the iPhone in question and allowed the FBI access to the device with little effort.

San Bernardino could have resolved this fight before it even started.

The circumstances leading up to this are awful and tragic, but it shows the importance of MDM and managing corporate data. While Apple and the FBI/DoJ continue to publicly lambaste each other over who should do what, businesses with a fool-proof MDM strategy can take comfort in knowing they’ll never have to become subject to the same gruelling fight to extract data from their devices should the need ever become apparent. Obviously not necessarily in circumstances such as this, but any situation where extracting information may be warranted – fraud, anti-competitive practices, interpersonal issues, etc.

As mobile devices continue to dominate every aspect of our lives it is vital that we take steps to secure and manage them. If Apple wins this argument, and for the sake of privacy and security I hope they do, it will only reinforce the notion that businesses have to be responsible for their own devices, their own corporate data, and they can’t rely on someone else to try to put the entire industry at risk if they are not.

Miradore Online MDM: Expanding management with subscriptions

2016-02-22T13:09:23Z

It has been a little under 2 years since I first came into contact with Miradore and not too long after that I wrote my first review on their free MDM product, Miradore Online.

A lot has changed since then, rendering even my more recent second review somewhat out of date. I’ve watched as Miradore have slowly but surely graduated from a simple, basic MDM platform into a feature-rich EMM offering incorporating things like application management, Apple’s DEP (Device Enrolment Program), Apple’s VPP (Volume Purchase Program) and in the future, Android for Work under the Miradore Online umbrella.

Naturally as their platform has grown, so too has the need to monetise the product. While they have and always will offer MDM functionality for free, their ever-growing EMM feature set can only be enabled with the purchase of either a Business or Enterprise subscription.

I’ve enjoyed following Miradore’s journey so far and am always excited to see the product evolve. They still have a way to go with features in competing, arguably more expensive, EMM platforms which are yet to be implemented, but how do they stand today? In my 3rd review near to the 2nd anniversary of discovering the platform and almost 1 year out of beta I will be focusing on two areas:

Benefits of the Enterprise/Business plans over the basic free tier.
Changes and improvements since my last review.

In my two previous reviews (linked above) I talked at length about the free tier. For this review however, just as I directed my attention towards the Business plan last time, I’ll be completely focusing on the benefits of splashing out on a higher tier and why anyone who does will not be disappointed. Both the Business and Enterprise plans provide big EMM functionality for little MDM cost, continue below to see why.

Why should I upgrade?

There are circumstances when the free tier just isn’t quite enough.

In larger groups or SMBs where day to day management of devices needs to be handled by a support team, or if application management has become a necessity as device numbers have increased, Miradore offer both Business and Enterprise plans at $0.50 and $2.00 per device per month respectively to cater for these needs – and more – which I’ll discuss below.

Role-based user permissions and unlimited administators

These two features go hand-in-hand for the management of devices in larger teams. While it is possible to have one admin logon shared between many administrators, there is no reliable audit log of changes on a per-admin level. Did Rick wipe that device? Did Emma push out Angry birds to the management team? As a company grows and device management becomes increasingly critical, having a breadcrumb trail to know who did what and when becomes very useful indeed.

In addition, limiting the roles an admin can have brings additional benefits. It means safely assigning Jill in HR the ability to keep an eye on her team’s mobile devices while preventing access to devices outside of her team. Similarly Ben, the new IT intern, can have full visibility of the entire solution while he shadows his colleagues without the risk of him changing critical configurations or system settings.

While unlimited admins are available in the Business plan, Role-based administration is an Enterprise feature.

Offline reports, notifications and API integration

I talked about the ability to export reports and email notifications in my business review, however in short Miradore’s Business plan allows for both email alerts and the exportation of report information for offline use.

The type of reports available range from how many devices are currently inactive on the platform (not checked in recently) to highlighting the number of iOS devices that aren’t supervised, or even how many employees have games or other non-productive apps installed. As well as being able to export these reports as an Excel spreadsheet, they can also be saved within the console for regular viewing.

Email alerts are more real-time and set up on a per-admin basis. This means the security team may get notifications when a device is detected as rooted, and the IT support desk can know when a new device is added or removed from the platform (something that comes in handy with self-service enrolment for employees).

The newer option released with the Enterprise plan is the ability to tap into the Miradore Online API in order to fetch reports on the fly. Reporting applications within the business can obtain and manipulate Miradore report data without the need for human intervention, creating opportunities for things like scheduled reports delivered with pie charts, graphs and high/low/average figures for enrolments, app installations and more – if that functionality exists in the software making the API calls of course – Miradore only supply XML formatted, basic reports by default when an API call is made.

By contrast, Miradore’s free offering will only provide online reports. They too can be saved within the console for later viewing but there’s no way of exporting them without either copying and pasting manually or taking screenshots. Neither are an efficient use of admin time.

Location tracking

Tracking the whereabouts of corporate devices is a bit of a controversial feature in the EMM world, however ethics and corporate policies aside it is a useful and cost-saving addition to any MDM platform. Devices that are lost or stolen can be found and employees can be monitored if the business feels that is justified.

Miradore’s Business subscription includes location tracking using an approach different to other EMM providers; instead of turning it on or off globally, Miradore treats it as a configuration profile that can be assigned and pushed out to individual devices or groups. This makes managing the feature simpler and the legal/ethical issues less prevalent.

Even better, it’s now available on iOS too!

Application management

App management is a game-changer for Miradore. It’s a feature that instantly expands the platform from a standard MDM offering into EMM territory. Sure, it’s not yet a full-blown EMM suite (telecoms and content management please!) but this is an excellent first step.

Along with black and white lists for applications across iOS, Android and Windows Phone which prevent the installation of unwanted applications, Miradore can now additionally push out and remove App Store/Play Store apps and in-house apps for iOS and Android devices from the console. Even better, for supervised iOS and Samsung KNOX-enabled devices this can be done silently without end-user involvement.

This is an Enterprise subscription feature. Under the free subscription application management is unavailable, but inventory data will always show what applications devices have installed.

Business policies

Confusingly this is an Enterprise subscription feature and is not available under the Business subscription. With that out of the way, Business policies are effectively automated, dynamic assignments of pre-configured policies based on a matching criterion set within the console.

Similar to Mobile Iron Labels or AirWatch Groups, business policies can be assigned to tags within Miradore Online. Once set up, any device assigned the relevant tag will have all associated policies pushed down to their device automatically. Along with the recent addition of tagging before a device is enrolled, this means all policies can be pushed down to a device the moment enrolment finishes. This feature has the potential to save administrators an awful lot of time in comparison to the free subscription where policies have to be pushed out manually.

Sound good? Find out more

The features provided in the subscriptions are designed to make life easier for a relatively low cost. At $2 per device, per month for the more expensive Enterprise subscription Miradore are still a good deal cheaper than the competition. What’s more, as new features are added having a subscription means getting the newest, best features as soon as they become available. The free subscription makes for an excellent starting point, but as a business grows and administration becomes more hands-on, considering an upgrade is well worth it; with ~73% of all devices on Miradore Online being managed under a business or enterprise subscription, clearly I’m not the only one with that opinion!

It is worth keeping in mind devices can be enrolled across many different sites (site1.online.miradore.com, site2…, etc) therefore if you feel some teams may need application management, while others do not, managing them across different Miradore Online sites may reduce the cost of using a subscription. It will however require switching between sites to support different devices and can end up causing additional overhead.

For more information on the Business and Enterprise subscriptions, click below. For a quick and simple guide to upgrading to a new subscription, check out my previous review.

Why upgrade to Business Plan?
Why upgrade to Enterprise Plan?

Still unsure, or want to speak to someone before making a decision? Email Miradore or leave me a comment at the bottom of the article and I’ll help you out.

What’s new?

Without a doubt it’s been a good year for iOS. Since my last review Miradore have added:

Bulk enrolment support through Apple Configurator
App management (mentioned above)
Additional restrictions (more to enable/disable)
Location tracking
Apple DEP support
Apple VPP support
Web clip support

Bulk enrolment and DEP support are two big upgrades that will save hours upon hours that would otherwise be spent manual enrolment. With Apple Configurator the only limit to the amount of devices which can be enrolled in one go is the number of USB ports on the Mac being used. I spent a lot of time with Apple Configurator last year provisioning iOS devices, working with up to 16 at a time using a giant, powered USB sync & charge station which only required one port on the Apple Mac Mini I was using.

DEP is even easier. The devices come directly from Apple (or a certified partner) already pre-setup to enrol directly into Miradore, this means to get up and running on the new device could be as simple as supplying a name, iTunes account, and potentially a server name before the device then enrols.

With VPP, managing paid applications after enrolment becomes substantially easier. For years I’ve listened to, read about, and taken part in discussions about ownership of applications, rights to expense purchases, loss of licenses when the employee leaves, etc. VPP fixes this by providing one central location for all app purchases, licenses can be pushed out to devices remotely and retrieved when no longer required, meaning employees no longer have to purchase apps themselves, and employers no longer have to approve app expenses they’ll never be able to re-use.

Miradore have from the start been incredibly Apple friendly. Even today Android is only supported to a relatively small degree in comparison, and the more granular restrictions rely on using Samsung devices. That said, Android has been given a little TLC also, with new features such as:

Encryption support, although only one-way at the moment (you can enable it, but not turn it off from the console) is another great addition for security-driven customers. Although some recent flagships have come with this enabled out of the box, the ability to turn this on for all supported devices guarantees just a little more peace of mind should a device fall into the wrong hands.

Messaging is a quirky little feature. A lot of MDM platforms support this and it makes it easy to send messages directly to an Android device. In support situations where an email profile may not have deployed (and as such the user doesn’t have access to emails), a quick message from the console will pop up as a notification on the device in question, offering a one-way communication channel between an admin and end-user.

Hopefully as time goes on we’ll see support for other manufacturers like HTC, LG, Sony – all of which have some basic management capabilities over and above AOSP.

Windows phone hasn’t been excluded either, being already more fully supported than Android, WP got the following new functionality:

And finally, to the system itself:

Improved Active Directory support
An updated console with a more responsive layout, allowing for improved mobile administration
Expanded tagging functionality (which now allows for tagging before a device is enrolled)
Trials

Trials were added back in the 2nd half of 2015 and it’s great to see that option available. This is only for the Enterprise subscription, but it’s fairly easy to see what is and isn’t included between the different subscriptions and test accordingly. Here’s a handy comparison.

A few items have been ticked off my requested features list since I put it together in 2014, I’m particularly pleased about the responsive layout (which I think is due in part to my mentioning of it in my last review, and this article I wrote which caught their attention). They’ve done a great job of adapting the layout to mobile devices without impacting on that nice, clean and simple interface.

Hopefully I’ll see a few more of these ticked off in the future:
(NB: I’ve stated location tracking for all platforms, but I’m happy to cross it off with the support of both Android and iOS).

~~Improved device management~~ including Android for Work support
Telecoms & content management
~~Location tracking for all platforms~~
User-friendly naming on reports
~~A mobile-friendly administration client (native or web)~~
Scheduled reports
Active Directory enrolment
More Android vendor support
Business plans without a VAT number requirement

Do you use Miradore Online? Are you considering their subscriptions? Let me know in the comments or tweet me @jasonbayton with the tag #MiradoreSubs

Lenovo Yoga 300 (11IBY) hard drive upgrade

2016-02-19T14:33:15Z

I recently took delivery of a Lenovo Yoga 300, the lower-end model of their impressive convertible line.

This otherwise perfectly usable Laptop with 4GB RAM and a Celeron N2840 chip unfortunately ships with a traditional WD Blue hard drive (at the time of writing) and it’s noticeable. With a slower processor, the least I could do to alleviate some of that performance bottleneck is swap the HDD out with a nice, speedy SSD.

The reason I’m documenting this is due to the lack of information online. I ended up following the official service manual supplied by Lenovo which still leaves a little to be desired, though allowed me to get the job done.

The below is documented under the assumption that:

You have an OS already installed on the SSD
or
You’re going to reinstall with a USB stick after booting up with the new drive

Remove the bottom cover

Lenovo have used a combination of M2 screws and plastic clips to secure the bottom panel to the laptop chassis. While the screws come out with ease, the plastic clips take a little more persuasion.

Remove all screws. These are 6.5 M2’s and a suitable screwdriver should be used.
NB: The 4 screws at the front are angled slightly. Not an issue now, but bare this in mind later.
Start by lifting the corners at the hinges first. These should pop up with ease, so don’t lift too forcefully.
Gently pry the bottom panel away from the chassis between the hinges. This will require a little more effort and will ‘pop’ 3-4 times.
As the bottom panel is quite tight to the sides of the chassis, gently pull upwards between the hinges, this will effectively lever the panel clips ever so slightly away from the sides of the frame, requiring very little effort to then pull the sides up either with fingernails or a spudger.
Once both sides are up, the front of the panel will still be securely fastened using slightly different clips. I found the best way of releasing them was to take a firm hold of one of the corners, pull away from the front of the chassis and down while levering against a spudger or finger placed close to the front corner (on the same side, naturally). This should effectively pull the panel away from the chassis and up, resulting in a satisfying pop as it releases. Repeat this pulling motion while gently manipulating the front of the panel. It will become increasingly easier to pop the remaining clips as each releases.

Remove the hard drive

With the front of the laptop facing you, the hard drive is easily accessible on the left.

Remove the SATA connector
Remove the 3 4mm M2 screws using a suitable (different) screwdriver. My model used three to secure the hard drive on the bottom left, right and top right as pictured.
Once free, remove the hard drive from the chassis and put the laptop to one side.
The hard drive has a metal adapter screwed on to each side, transfer these to the new SSD making sure to match orientation of the plates when doing so.

Reassemble

At this stage the old hard drive should be out and the new SSD in, all that remains is to reassemble the device in reverse order.

Screw the SSD into place and reattach the SATA cable
When refitting the bottom panel, do so in the reverse of the way it was removed; fit the front first and lever the panel down. It will likely require some gentle persuasion to slot back into the sides.
Gently click the plastic tabs back into place from front to back. The front will require a little more force but not much. Remember the back corners will not clip (so don’t force them), but between the hinges will.
Screw the bottom panel down loosely, double checking all plastic clips have clipped before fully tightening the screws. Remember the front screws are at a slight angle, be aware of this and don’t cross-thread the screws!

Power on

Or actually, before you do, flip the laptop the right side up and give it a gentle shake. If there’s nothing rattling about you’ve done a good job. While you’re at it, test the volume rocker on the side to ensure it’s still “clicky” and hasn’t been fouled by the case.

When ready, power on.

Enjoy the added benefits of an SSD and if you need any assistance leave a comment below or @jasonbayton on twitter.

I bought a Lenovo Yoga 300, this is why I'm sending it back

2016-02-19T14:24:34Z

This week I ordered a Lenovo Yoga 300 to replace an ageing and underpowered HP Stream 14.

The model I chose was the 11.6″ (11IBY) Intel Celeron N2840 with 4GB RAM and a 500GB HDD, a step up from the HP’s AMD A4 with 2GB RAM and a 32GB storage chip (well.. perhaps not in the CPU, but more on that later). I wanted a small, light convertible with a touch screen and the Yoga seemed to tick those boxes.

At least until I got it.

Size

For a laptop that houses a 11.6″ screen it is large. Pictured above the Yoga is sat on top of a Thinkpad x240 – a laptop that houses a 12.5″ screen with reasonable bezels. While the Yoga is undeniably slimmer than the i5-wielding business powerhouse, it matches the Thinkpad’s width and depth with ease.

Speaking of bezels, the Yoga’s are ginormous.

They don’t look particularly small on Lenovo’s website, but actually seeing them in person reinforces how much of that whole screen area is completely wasted. I’m not sure of the technical reasons as to why they couldn’t have made the Yoga physically smaller to better match the screen they opted for, but the end result isn’t pretty.

Lenovo don’t appear to publish the dimensions on their product pages for the Yoga here and here. Amazon do, but given they also provide dimensions for the x240 and there’s almost no comparison between the dimensions listed (41.4 x 27.2 x 8.2 cm vs 30.6 x 20.9 x 2 cm for the Yoga and x240 respectively) I couldn’t trust them.

It’s also around 1.4kg. It doesn’t feel particularly light.

Performance

As mentioned above I opted for the cheaper of the two models with 4GB RAM which came with a Celeron. On paper (and internet benchmarks, which I should really stop referencing..) it didn’t look like there was much in it between that and the Penitum N3540 and I therefore didn’t see the ROI on spending an extra £80 on the better chip.

With the combination of Celeron CPU and a slower WD HDD it ships with however it became something of a combined bottleneck as I started putting it through its paces. The Yoga stalled frequently while browsing with too many (10+) tabs open, and ground to a halt continuously while updates were being installed “in the background”. Task manager often showed high disk I/O which undoubtedly had a knock-on effect on the CPU.

Everything got a little better once I’d spent the evening upgrading it to Windows 10. For some reason it ships with 8 directly from Lenovo whilst Amazon and other retailers ship with 10 preinstalled. It was also at this point I opted to remove almost all of the bloat by going for a fresh install over a standard upgrade. As much as I appreciate Lenovo trying to help (“help”) by bundling their own tools, obtrusive AV, games and a garish battery indicator, I’d rather not have any of that (of course, we know Lenovo isn’t unique in filling their laptops with junk). I’d like to think performance benefits were had once the declutter and upgrade had completed, but that may have just been my imagination.

I’m being critical, I admit. But then I’m used to even the cheaper laptops running on EMMC chips or SSDs, leaving the CPU to spend time on the important things and not scheduling I/O. Luckily, it’s easy to swap the HDD for an SSD using only a screwdriver.

Usability

As a touchscreen device I can’t really say anything negative. The screen is responsive and worked well with touch, even if the resolution is a little below what I’m used to. The various positions the screen can be folded into with the Yoga’s unique hinges all worked well. The hinges feel sturdy and provide just enough resistance as the screen folds. They do not, however, prevent screen-wobble when touching the screen in “laptop mode”.

It wasn’t until after I’d finished setting it up that I started noticing problems. As I settled down with a cup of tea for the evening to do some writing – the reason I got this laptop – it became evident the keyboard was a little unresponsive. Particularly the spacebar and keys towards the top right-hand corner would depress fine, but not type the resulting character(s) every time.

I’m not sure what that’s like for most people, but for me it’s a little like struggling with slow internet.

The keyboard itself, ignoring the issues, is a good size with adequate (but not great) travel. Just as with the screen there would be nothing wrong with bringing the edges of the laptop in closer to the edges of the keyboard to result in a smaller and lighter device, however Lenovo chose not to.

Interestingly I had a similar issue with the volume rocker on the side of the Yoga; turning the volume down worked fine however it required an uncomfortable amount of force to turn the volume back up. This however was less important as the volume function keys on the keyboard did work fine.

The trackpad feels nice, though could be larger. I’m not a big fan of having to click them generally, and that’s what’s required for a right click (two finger click) for some reason with the drivers pre-loaded. There’s also an option to click the bottom right corner (one finger click) to generate a right click but I’m not too fond of that either.

Thanks, but no thanks

So with the issues around the keyboard (apparently a common problem usually resulting in a keyboard swap by Lenovo on other models), the volume rocker, the so-so performance and size of the machine, I’m not particularly happy with it.

While I’ve no doubt some won’t mind the extra size and weight associated with putting an 11.6″ screen into the body of a 12.5″ laptop, it’s not for me.

I may have put up with it had everything worked as intended, but I’m actually a little glad it’s faulty as it’s motivated me to send it back and look elsewhere for a laptop that’ll suit my needs more closely.

The search continues…

Restricting access to Exchange ActiveSync

2016-02-03T19:53:56Z

Note:
– This guide uses Microsoft IIS configurations to restrict access. For firewall configuration this guide is not suitable.
– The directions outlined below will only restrict access to ActiveSync, leaving OWA (Outlook Web Access) traffic untouched.
– Although aimed at the EMM industry, this guide is suitable for any ActiveSync proxy, or just to keep ActiveSync locked down.
– Despite being shown on a Windows 2012 R2 server, the same steps apply on earlier versions of Windows Server.