A new opt-in feature has landed across my wallpaper and contacts generators, allowing the generated app to be woken by any AMAPI-powered EMM with application role support.
This now allows applications to initiate immediate background functionality upon installation, such as setting the wallpaper or syncing a contact list, without users needing to first manually open the app - as has been the case since the generators were brought online for AMAPI-based EMMs.
Both the wallpaper and contacts apps are particularly designed to mostly sit in the background and never really be opened; they have a UI, naturally, but it's for debugging and status, not for interaction. This is in contrast to kiosk and webapp, which, obviously get actively used on install, but also documents, which is used when it's needed as it holds content a user will interact with.
Since the wallpaper app sets the wallpaper and the contacts app syncs a directory into an app-owned account within the system contacts service, in either case you'd deploy the app so no one has to touch it, with the expectation it just works.
The problem with this approach is in Android's platform behaviour, and how it protects its users from malicious apps - they absolutely cannot run after installation without being first opened. Until then, an app sits in a stopped state essentially forever, or until a user taps the app icon.. whichever comes first.
While it's stopped it can't do anything. It's dead. A reboot won't help because it doesn't get a boot broadcast either. So in the AMAPI EMM context you force-install the app, and it does nothing at all until someone opens it. On a kiosk or a shared device, that first tap might never come if the app isn't exposed (and again, why would it be?).
This hasn't been a problem for my [insert EMM] - That'll be because for many EMM vendors still using the older - and in some ways superior - custom DPC approach for Android management, this was solved a long time ago. AMAPI on the other hand has made the ecosystem wait years for basic functionality time and time again, and background start of apps is one such affected feature.
App roles support landed just last year and isn't necessarily even designed for this use case, it's one component in a bundle of restriction exclusions Google have released that overall make applications function within a slightly less hostile environment. More detail about roles in general are linked above.
The new functionality in the generators with this release isn't needed for MDMs using custom DPCs.
With application roles, assigning an app a role in-policy triggers the on-device Android Device Policy DPC to wake the app directly, and that is enough to bring the package out of the stopped state.
The app wakes, runs its sync or applies its wallpaper, and from then on schedules itself and handles reboots normally. One wake is all it needs.
That's literally it.
Naturally because roles also handle restrictions on battery optimisation, apps assigned get the added benefit, as I mentioned above, of being less likely to be subdued by Android, improving efficacy of the app overall.
I've watched this work end to end on my managed devices with the wallpaper app. After deploying the app and applying the role in the EMM console, the wallpaper applied as if by magic, and without touching the app itself. The contacts app uses the identical mechanism for its background sync also.
There's a new toggle in each generator under behaviour. Once Enable application-role background activation is toggled on, the generated app builds, on-demand, the AMAPI SDK into it. It's entirely dynamic, so leaving it off leaves the SDK excluded entirely.
The app then incorporates a small listener to receive role assignment pings.. and the rest is as above.
It was important to me to make this as modular as possible. The SDK is chatty to Google in my testing, completely unnecessarily in my opinion, and so if background initiation isn't a requirement, privacy is a little stronger.
To use it on a device you'll need:
If you're torn deciding between the roles, my preference is SYSTEM_HEALTH_MONITORING as it's a bit of a catch-all. Be aware one app can have many roles, but a specific role can only be assigned to one app.
This is a small change, but it removes a genuine headache for AMAPI EMM admins.
As always, let me know if you run into anything, or if this unlocks a use case I haven't thought of. Likewise, if you feel there's a usecase for enabling role support on Documents, Kiosk, or Webapp.. I'm open to hearing why.