I've been recently speaking with Oukitel about their vital apps configuration while testing their devices for Android Enterprise. I raised the issue during earlier testing and it was passed to engineering, but having now brought the WP68 Air into testing, I'm seeing it again. It's come up on the WP100 Titan, the WP68, and now the WP68 Air, with optional consumer apps remaining available in the managed environment after enrolment.

On the latest device, the WP68 Air, Facebook, LinkedIn, Instagram and Block Blast are appearing as unapproved apps. Separately, earlier testing of the WP60 also turned up problems accessing the files/downloads UI, alongside unwanted promotional shortcuts in the launcher.

I've covered what vital apps are before, but the recent testing seemed a good opportunity to go through the configuration files and how manufacturers can use them to address this.

Android Enterprise provisioning disables optional preloaded system apps by default on fully managed devices and in work profiles. Android retains essential components, and the manufacturer supplies the additional apps that should remain available. Apps without launcher icons generally remain enabled automatically. Google's device-management implementation guide describes this behaviour.

An app such as Facebook can be preloaded for consumer use without needing to remain available by default in a managed context. Organisations that use it for work can have their admin deploy it through their EMM.

Manufacturers maintain separate XML resources for each provisioning mode, with required lists defining which apps to retain and disallowed lists specifying apps to remove. Google's guide names the required files, while the corresponding disallowed lists are referenced in the AOSP implementation.

In current AOSP, these resources live under frameworks/base/core/res/res/values/, and manufacturers customise the arrays through their product/device resource overlays. For Android 8.x and earlier, the archived implementation guide places the device/profile resources under packages/apps/ManagedProvisioning/res/values/. A work-profile entry follows the structure of the AOSP required-app resource.

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string-array name="vendor_required_apps_managed_profile"
                  translatable="false">
        <item>com.example.requiredworkcomponent</item>
    </string-array>
</resources>

I've used a placeholder package above to show the format. When adapting this for a product, the array needs to retain the full set of required packages, including any applicable Google requirements. The example on its own isn't a complete configuration.

For an OEM fixing this, I'd start by reviewing the effective resources in the shipping build, including the overlays, and removing optional consumer apps from the required lists. The corresponding disallowed lists need reviewing too, along with any missing components needed for the device to function properly. This needs doing separately for fully managed devices and work profiles, since the apps appropriate for one won't necessarily belong in the other.

The corrected resources then need to be compiled into the firmware; copying an XML file onto an enrolled device won't change the configuration.

The framework's app-selection code combines platform and vendor lists and applies further exceptions, including system input methods, required Mainline modules and the device-management role holder.

There's also a discrepancy in AOSP to be aware of when reviewing conflicting entries. The vendor required XML comment says that list takes precedence over the disallowed lists, but the current framework implementation adds disallowed packages back into the removal set after excluding required packages. For an ordinary app listed in both, that makes it disallowed in this implementation, subject to the later exceptions. I'd remove conflicting entries and check the code on the branch being shipped before relying on either outcome.

I'd then want to test fresh enrolments on the corrected firmware with optional system apps disabled, checking the package state in the managed user/profile as well as what's visible in the launcher. That should include opening and picking files, plus any camera, gallery or other system functionality intended to be available. As I found with the WP60, seeing an app listed as enabled doesn't guarantee a user can actually access it.

Already enrolled devices need testing separately, since updating the resources through an OTA shouldn't be assumed to repeat the original provisioning cleanup. Administrators with system-app controls in their EMM can use those to enable missing apps or block unwanted ones.

Keeping these configurations up to date as preloads change, and testing managed provisioning before each release, would help manufacturers catch this across new devices too. For organisations, that means starting enrolment with the expected apps available and less configuration to work around afterwards. If you're seeing similar behaviour on a device you're testing or deploying, the checks above should help narrow down where it's coming from.

#androidenterprise