How to Inspect Per-App Language Preferences and System Locales on Android Using ADB dumpsys locale

Starting with Android 13 (API level 33), Android introduced a foundational architectural enhancement to internationalisation: per-app language preferences. Previously, multilingual users were forced to choose a single system-wide language that applied uniformly to the operating system and all installed applications. Modern Android decouples application presentation from global device locales, allowing users and enterprise administrators to configure different languages for individual apps while maintaining a distinct primary locale for the system UI. Behind this capability sits the LocaleManagerService in the system server. Using the Android Debug Bridge (ADB), mobile QA engineers, localization specialists, and enterprise fleet administrators can query dumpsys locale to inspect active language overrides, audit application locale configurations, and verify internationalisation compliance across devices.

Understanding Android Per-App Locale Architecture

The Android per-app language framework coordinates application resources, ICU internationalisation libraries, and system configurations through several distinct mechanisms:

• System Locales: The global, ordered priority list of languages chosen in device system settings (e.g. [en-GB, fr-FR, de-DE]). The system UI and apps without specific overrides inherit this primary hierarchy.
• Application-Specific Locales: A localized LocaleList configured specifically for an individual application package. When an app defines an override, Android generates a virtual Configuration object that masks system locales for that package’s process.
• App-Specific Locale Config: Declared in an app’s manifest via the android:localeConfig attribute, this XML resource informs the system which languages the app officially supports, populating the per-app language picker in Android settings.
• LocaleManager Service: Manages persistent storage of per-app preferences, handles inter-process notifications when locales change dynamically, and ensures data persists across package updates and reboots.

Prerequisites and ADB Environment Configuration

Inspecting per-app locales via ADB requires an Android device or emulator running Android 13 (API level 33) or later. Enable Developer Options and USB Debugging on the target device before establishing an ADB shell session.

Verify that your ADB client detects the connected device:

adb devices -l

Confirm that the locale service is registered with the Android Service Manager:

adb shell service check locale

The console should confirm: Service locale: found.

Querying Complete LocaleManager Dumpsys State

To inspect the complete runtime state of the LocaleManagerService, dump the service output through ADB:

adb shell dumpsys locale

The diagnostic dump provides a structured inventory of active per-app preferences and system locale configurations:

LocaleManagerService:
  Current User: 0
    System Locales: [en-GB, fr-FR]
    Per-App Locales:
      Package: com.example.bankingapp
        Locales: [de-DE]
        Source: App
      Package: com.example.messaging
        Locales: [es-ES]
        Source: User
      Package: com.android.vending
        Locales: [en-US]
        Source: System

The output explicitly categorises the origin of the configuration:

• Source: User: Indicates that the user explicitly selected the language within the App Info settings screen.
• Source: App: Indicates that the application programmatically invoked LocaleManager.setApplicationLocales() within its internal settings interface.
• Source: System: Denotes an administrative policy override or provisioning default applied by device management controllers.

Inspecting and Testing Application-Specific Locales via ADB

In addition to passive inspection with dumpsys locale, developers can interact directly with the cmd locale_manager service to audit, test, and inject per-app language configurations dynamically.

To check the current locale configuration of a specific application package:

adb shell cmd locale_manager get-app-locales com.example.bankingapp --user 0

To assign a specific language and regional dialect (e.g. French Canadian, fr-CA) to an application for localisation testing:

adb shell cmd locale_manager set-app-locales com.example.bankingapp --user 0 --locales fr-CA

Verify that the updated configuration was successfully committed in dumpsys locale:

adb shell dumpsys locale | grep -A 3 "com.example.bankingapp"

To clear the per-app override and restore the application to the global system locale:

adb shell cmd locale_manager set-app-locales com.example.bankingapp --user 0 --locales ""

Auditing Manifest Locale Configurations

For an application to appear in the system Settings per-app language selection menu on Android 13+, the package must declare its supported languages. If an app is missing from the settings menu despite running Android 13+, inspect the package’s manifest metadata using aapt2 or ADB dumps.

Inspect the package’s application flags and configuration dump via ADB:

adb shell dumpsys package com.example.bankingapp | grep -E "localeConfig|locales"

If the application relies on automated gradle locale generation, confirm that the XML resource res/xml/locales_config.xml correctly enumerates all supported BCP 47 language tags:

<?xml version="1.0" encoding="utf-8"?>
<locale-config xmlns:android="http://schemas.android.com/apk/res/android">
   <locale android:name="en-GB"/>
   <locale android:name="fr-FR"/>
   <locale android:name="de-DE"/>
   <locale android:name="es-ES"/>
</locale-config>

Troubleshooting Localization Fallback and Persistence Issues

When auditing multilingual enterprise deployments, review these common localization anomalies:

1. Dynamic Activity Re-creation: When an app’s locale is updated while running in the background, Android sends a configuration change event (onConfigurationChanged). If the application improperly handles configuration changes in its manifest without re-inflating views, text may remain partially in the old language until the process is terminated and restarted.
2. Multi-User and Work Profile Isolation: Per-app language preferences are isolated per user profile. When managing corporate Work Profiles (typically User ID 10), always include the --user 10 flag during ADB queries to inspect the managed container rather than the personal user space.
3. Locale Fallback Chains: If an application does not provide string assets for a requested regional subtag (e.g. fr-BE for Belgian French), the Android asset manager cascades to base French (fr) before falling back to the default system locale. dumpsys locale confirms whether the active request was received cleanly by the OS.

By auditing dumpsys locale with ADB, engineering teams ensure smooth internationalisation, verify regional compliance, and deliver consistent multilingual experiences across global device deployments.