You reset your phone. The setup screen loads, you log into Wi-Fi, and before touching anything else—apps begin to install. Some are familiar. Others feel random. None asked for permission. You didn’t open the Play Store and you didn’t press install.
Dig into the system and you’ll find something called android.autoinstalls.config.*. It has no icon and if you try to figure out what it is, you’ll run into speculation, warnings, and half-truths. Some call it spyware. Others say it’s just an executable script.
Let’s get rid of the noise and explain what ConfigAPK really does, how it works, what happens when it breaks, and whether you can safely remove or disable it.
What ConfigAPK Actually Does
ConfigAPK is not a user-facing app. It’s a system-level stub that runs once—right after a factory reset or firmware flash. Its only job is to silently install the default apps specified by your device’s ROM. This is called provisioning.
It doesn’t stay resident in RAM and it doesn’t track you, talk to servers, or request permissions. But it reads an XML file located in /system/etc/ that lists what apps should be installed, then passes those package names to the system’s package manager.
The provisioning process often depends on a working internet connection and a correctly inserted SIM card. Some devices use Play Auto Install (PAI), which works in tandem with ConfigAPK to install region-specific or carrier-defined apps. Others rely purely on pre-bundled packages.
You’ll see different package names depending on the brand:
android.autoinstalls.config.samsungandroid.autoinstalls.config.googleandroid.autoinstalls.config.Xiaomi.modelandroid.autoinstalls.config.carrier.*
They all perform the same job: deliver pre-selected apps during first boot. Once done, ConfigAPK exits and does not re-run until another reset. Think of it as a disposable installer embedded in your firmware—not an ongoing process.
Why You Can’t Disable or Delete It
On stock Android, ConfigAPK is stored in the read-only /system partition. You can’t uninstall or disable it using Settings or standard ADB commands. Even force-stopping it accomplishes nothing—it’s already done its job by the time you find it.
If you’re rooted, you can technically remove ConfigAPK using tools like ADB or Titanium Backup. But doing so comes with real risks. Setup wizard components may fail in future resets. Essential apps—like System WebView, Google Services Framework, the default launcher, System UI, or your keyboard—might not install properly.
On some devices, carriers will flag a phone as non-compliant if they detect a missing provisioning service. That can lead to disabled features, blocked SIM activation, or boot loop issues. Even most custom ROMs include a dummy ConfigAPK package because Android’s provisioning system expects it to be there—even if it’s empty.
Removing ConfigAPK doesn’t prevent bloatware. It only breaks setup. The better option is to let it run and disable or uninstall what it installs afterward.
What Can Go Wrong with ConfigAPK?
When provisioning fails, the system starts misbehaving. But the problem isn’t ConfigAPK—it’s the conditions it depends on.
One common issue is corrupted or missing XML provisioning files, either due to bad firmware, failed Over-The-Air (OTA) updates, or a mismatched regional ROM. If your device expects apps from a region specific carrier, and you flash firmware from a different one, ConfigAPK won’t know what to install—or worse, it will install incompatible packages.
Inconsistent network access during setup can also cause failures. Play Auto Install depends on a working internet connection to pull certain apps. If Wi-Fi drops or the SIM card isn’t recognized during those first minutes after boot, provisioning can stall or fail silently.
Some users experience errors like “ConfigAPK has stopped working” or see phones that boot without core apps like Messaging, Dialer, Contacts or the Play Store. Others report endless setup wizards or broken OTA systems.
But none of these are caused by ConfigAPK itself. They’re caused by missing, mismatched, or incomplete provisioning data—and that data comes from your firmware.
How to Fix ConfigAPK Crashes or Setup Failures
If your phone is missing apps after reset, shows ConfigAPK crash messages, or gets stuck during setup, here’s how to fix it cleanly.
For Stock Devices (No Root)
Steps may vary slightly depending on your phone’s brand (e.g., Samsung, Xiaomi, Pixel) or Android version, especially the reset menu location and setup screen layout.
- Perform a full factory reset properly:
- Go to Settings > System or About phone > Reset > Erase all data
- This wipe user data and ensures ConfigAPK runs from a clean state
- Reboot the phone and let it load to the welcome/setup screen
- Connect correctly during setup:
- Insert your original SIM card for your region or carrier
- Connect to a stable Wi-Fi before doing anything else
- Don’t skip or delay this — many installs depend on live internet + SIM validation
- Let the phone sit idle after setup:
- Once you reach the home screen, do nothing
- Leave the phone alone for at least 10–15 minutes
- Don’t remove the SIM, don’t switch Wi-Fi, don’t reboot — just let Play Services work
- This gives time for background provisioning and auto-installs to silently complete
- Check for pending software updates:
- Go to Settings > System > Software Update
- Download and install the latest software version
- This ensures any failed or pending apps from setup get patched
- Trigger auto-install manually via Play Store:
- Open Play Store > Settings > Network Preferences > Auto-update apps
- Set it to “Over Wi-Fi only” which can re-trigger pending installs that failed during boot
For Rooted Devices
- Watch provisioning in real time using ADB:
- Connect via USB and run:
adb logcat | grep autoinstall - Look for errors mentioning XML, package manager failures, or app install rejections
- These logs confirm whether ConfigAPK ran, failed, or skipped certain apps
- Connect via USB and run:
- Inspect provisioning config files manually:
- Use a root file explorer to check
/system/etc/ - Look for files like
autoinstall_config.xml, default_app_list.xml, or anything under/vendor/etc/ - If the XML is corrupted, malformed, or empty, ConfigAPK may silently fail
- Use a root file explorer to check
- Reflash the correct firmware for your model:
- If you flashed custom firmware or changed regions, you may have mismatched provisioning logic
- Download the stock ROM that matches your model + region exactly
- Flash cleanly using Odin (Samsung), Mi Flash (Xiaomi), or fastboot
- Always wipe /data when changing base OS:
- If switching from one OEM build to another (e.g., Global to EU), run:
fastboot erase userdata - Skipping this leads to provisioning conflicts, missing apps, and boot loop risks
- If switching from one OEM build to another (e.g., Global to EU), run:
How to Tell What ConfigAPK Installed
There’s no official record showing what apps came through ConfigAPK, but you can figure it out manually.
Sort your installed apps by installation date. Apps that show the exact same timestamp immediately after setup are likely part of the provisioning payload. You can also go into each app’s info page and look for “App details in store.” If that option is missing or shows “Installed from system,” it’s likely it came through ConfigAPK.
If you captured logcat output during boot, you’ll see installation lines like:PackageManager: install [com.facebook.katana] triggered by provisioning
These confirm exactly which apps were delivered—and which ones you didn’t install yourself.
Why It Feels Like Spyware — But Isn’t
People often accuse ConfigAPK of being bloatware, spyware, or a hidden background service. But the truth is, It installs the bloatware—but doesn’t run it.
Apps like Facebook, Samsung Free, GetApps, or carrier-specific services may include telemetry, analytics SDKs, and aggressive background processes. These apps often show up immediately after setup and are granted permissions you didn’t approve. So naturally, users assume the thing that delivered them must be malicious.
But ConfigAPK doesn’t connect to servers, read your files, or persist beyond setup. It’s simply a script. The apps it installs, however, are a different story.
If you care about privacy, target the payload. Use apps like TrackerControl or App Manager to audit newly installed apps. Strip background permissions. Freeze or uninstall what you don’t want. Or better yet, flash a ROM that includes an empty provisioning file.
Final Take
ConfigAPK isn’t what’s bloating your phone. It’s the firmware that tells it what to install. You can’t stop ConfigAPK from running—but you can control what stays after it’s done.
Audit your system after every reset. Don’t chase the stub. Chase the source.
Frequently Asked Questions
Custom recoveries don’t block ConfigAPK outright, but they do change how firmware gets applied. If you flash only the system or boot partition without wiping /data or running a full OTA-style update, ConfigAPK may never trigger. Some TWRP users also skip vendor or preload partitions—breaking the provisioning XML dependencies ConfigAPK relies on. That means no crash, no log—just silent failure.
Yes—OEMs can skip provisioning for internal testing, enterprise builds, or dev-factory units using flags like ro.setupwizard.mode=DISABLED, or by omitting the config XML entirely. Some phones boot with a clean AOSP image that includes a dummy or blank ConfigAPK just to pass setup without triggering installs.
Absolutely. Even within the same region, ConfigAPK installs are tailored by SKU. A Lite model may get fewer background apps to conserve storage, while a Pro variant gets camera bundles or preloaded extras. The provisioning XML is often split by model name—not just carrier or region. It’s controlled by your ro.product.model and ro.build.fingerprint at boot.
They do—but with far less baggage. Pixels include a lean ConfigAPK that works with Google SetupWizard and Play Auto Install to restore apps like Gmail, Photos, and YouTube. What’s missing is the bloat: no carrier apps, no third-party deals, no regional payloads. Same engine—cleaner list.
