Set Default Apps on Managed Android Devices

Android lets the user pick which App handles core system roles: which browser opens a link, which App places a call, which one receives SMS. On a corporate fleet that choice is rarely something you want to leave open. If half your Devices open corporate links in a browser you do not manage, or a technician answers work calls from a personal dialer, you lose both consistency and control.

Default Applications let you decide those roles centrally. You define which App should handle each system role, Applivery pushes it through the Android Management API (AMAPI) defaultApplicationSettings Policy field, and the user can no longer change it while the setting stays active.

Typical uses:

• Force a corporate browser, such as Chrome, as the default browser.

• Fix the dialer or the SMS App on company Devices.

• Set the default voice assistant or digital wallet across a managed fleet.

• Pin the launcher (Home) on Fully Managed Devices.

How it works

Each default App you set is one entry in the defaultApplicationSettings array of the Policy, and every entry is built from three elements:

The prioritized list is what makes this practical across mixed hardware. List your preferred App first and a fallback second, and each Device resolves to whichever one it actually has.

For a non-system App to become the default, the fingerprint of its signing certificate on the Device must match the one obtained from the Google Play Store, or one of the entries declared in signingKeyCerts for that App in the Policy.

Supported default application types

Scopes

• SCOPE_FULLY_MANAGED: applies to Fully Managed Devices (Device Owner).

• SCOPE_WORK_PROFILE: applies to the Work Profile, both on company Devices with a Work Profile (COPE) and on personal Devices with a Work Profile (BYOD).

• SCOPE_PERSONAL_PROFILE: applies to the personal profile on company-owned Devices with a Work Profile.

When you set a default App for SCOPE_FULLY_MANAGED or SCOPE_WORK_PROFILE, that App needs a matching entry in the Applications section of the Policy, with an installType other than BLOCKED. When the target scope is SCOPE_PERSONAL_PROFILE, you can only set preinstalled system Apps as defaults.

Compatibility by management mode and Android version

Before you start

• A Device running Android 14 or later. Android 16+ is recommended, since it unlocks every default App type.

• A compatible Android Enterprise management mode — Fully Managed, COPE, or BYOD with a Work Profile — depending on the type of default App you want to set.

• The candidate Apps added to the Applications section of the Policy with an installType other than BLOCKED, except for preinstalled system Apps in the personal profile.

• The exact packageName of every candidate App.

• Confirmation that the same Policy has no persistentPreferredActivities entry for the same intent domain, to avoid conflicts.

Configuration

1

Navigate to Policies

Once in the Applivery Dashboard, go to Policies 1 and select the Android Policy you want to modify.

2

Add the candidate Apps

In the Apps 2 section of the Policy, add every App you plan to use as a default — browser, dialer, and so on — with an installType other than BLOCKED, such as AVAILABLE or FORCE_INSTALLED.

3

Access All properties

From the left-hand menu, click the All properties 3 section.

4

Find Default Application Settings

In the search field, type defaultApplicationSettings to locate the Default Application Settings configuration object.

5

Define the default App

Set the three values for this entry:

• Scope: Fully Managed, Work Profile, or Personal Profile.

• Type: Assistant, Browser, Call Redirection, Call Screening, Dialer, Home, SMS, or Wallet.

• Package Name: the package name of the App you want as the default for the type you just selected.

Repeat for every role you want to pin.

6

Enable status reporting (optional)

If you want feedback on which defaults actually landed, enable defaultApplicationInfoReportingEnabled inside statusReportingSettings.

7

Save and sync

Save the Policy and sync it with your Devices, either automatically on the next check-in or by forcing a manual sync from the Device detail page.

Example Policy

This Policy sets Chrome as the default browser and defines a prioritized dialer list, with status reporting enabled:

{
  "applications": [
    {
      "packageName": "com.android.chrome",
      "installType": "AVAILABLE"
    },
    {
      "packageName": "com.google.android.dialer",
      "installType": "AVAILABLE"
    },
    {
      "packageName": "com.samsung.android.dialer",
      "installType": "AVAILABLE"
    }
  ],
  "statusReportingSettings": {
    "defaultApplicationInfoReportingEnabled": true
  },
  "defaultApplicationSettings": [
    {
      "defaultApplicationType": "DEFAULT_BROWSER",
      "defaultApplications": [
        { "packageName": "com.android.chrome" }
      ],
      "defaultApplicationScopes": [
        "SCOPE_FULLY_MANAGED",
        "SCOPE_WORK_PROFILE"
      ]
    },
    {
      "defaultApplicationType": "DEFAULT_DIALER",
      "defaultApplications": [
        { "packageName": "com.google.android.dialer" },
        { "packageName": "com.samsung.android.dialer" }
      ],
      "defaultApplicationScopes": [
        "SCOPE_FULLY_MANAGED",
        "SCOPE_WORK_PROFILE",
        "SCOPE_PERSONAL_PROFILE"
      ]
    }
  ]
}

Here, AMAPI tries to set com.google.android.dialer as the default dialer. If that App is not installed on the Device, it falls back to com.samsung.android.dialer, following the priority order of the defaultApplications list.

Status reporting

From Android 16 onwards, Device status reports include a defaultApplicationInfo field whenever defaultApplicationInfoReportingEnabled is turned on in statusReportingSettings. For each application type, the report tells you:

• packageName: the App currently set as the default for that type, whether it was pinned by the Policy, set by the system, or chosen by the user.

• defaultApplicationSettingAttempts: the outcome of each attempt to apply the Apps on your prioritized list. This is what you read when a higher-priority App did not take effect and you need to know why.

On Fully Managed Devices the report covers every application type. On Devices with a Work Profile it covers only the types supported for that profile.

Non-compliance reasons

Important considerations

• Never configure defaultApplicationSettings and persistentPreferredActivities for the same intent domain, such as web browsing, in the same Policy. The behavior becomes unpredictable.

• Every candidate App must exist in the Applications section of the Policy with an installType other than BLOCKED, except for system Apps in the personal profile.

• For non-system Apps, the signing certificate on the Device must match the one from the Google Play Store or an entry declared in signingKeyCerts.

• Actual support depends on the Android version and the management mode of each Device. Check the compatibility table above before you roll anything out.

• For cross-profile roles such as DEFAULT_WALLET, you cannot pin the default in the Work Profile and in the personal profile at the same time.

• Once the Policy applies, the user cannot change the default App for that role manually while the setting stays active.

Verification and troubleshooting

Default Applications turn a user preference into a managed setting. Combined with a prioritized candidate list, they give you one predictable behavior across a fleet that mixes hardware, Android versions and management modes, and they take the guesswork out of which App handles the roles your organization actually depends on.