Users who want to dive deeply into the architecture of a mobile operating system often wonder about the physical layout of interface elements. Android desktop is not just a beautiful picture on the screen, but a complex set of data scattered across different sections of the device’s memory. Understanding the structure of these files is critical for advanced users who customize firmware, recover data after crashes, or create their own themes.
Unlike the usual photo or document files, the system settings of the launcher are hidden from the eyes of the average user. They are protected by root access and are located in protected sections of the file system. However, knowing the exact paths allows you to manipulate this data through the console or specialized file managers, opening up opportunities for fine-tuning the device to suit your needs.
In this article we will look in detail at where exactly the operating system stores the configuration of the icon grid, widget database and wallpaper files. You'll learn the difference between user data and system resources, and receive instructions on how to safely access these hidden areas of memory.
Launcher Data Storage Architecture
It is fundamentally important to understand that Android divides data storage into two main categories: user files and system databases. The launcher, which is responsible for displaying the desktop, uses both types of storage for its work. Graphical elements, such as high-resolution wallpapers, are typically stored in user-accessible memory, while icon layout logic and grid settings are stored in encrypted SQLite databases.
The main component that drives the interface is the process com.android.launcher3 or its forks from manufacturers like OneUI from Samsung or MIUI Launcher from Xiaomi. These processes constantly access the application's internal storage to read the current configuration. Every time you turn on the screen, the system loads this data into RAM to instantly draw the interface.
If you plan to interfere with the operation of the launcher, you need to be aware of the risks. Incorrect editing of system files can lead to cyclic reboots of the device or the complete disappearance of icons. Therefore, before any path manipulations /data/data it is strongly recommended to create a full backup of the data section.
⚠️ Attention: Directly editing the launcher database files without SQL skills can lead to irreversible damage to the interface. Always make a backup before making changes.
System paths to settings databases
The most valuable information about the location of elements on the desktop is stored in the internal data directory of the launcher application. Access to this area is only possible with root access or via USB debugging using tools ADB. This is where the database file is located, which determines which icon is in which grid cell.
The main path to the configuration files is as follows: /data/data/com.android.launcher3/databases/. This directory usually contains a file named launcher.db or home.db. This database contains tables that describe the coordinates of shortcuts, folders, and widgets. The structure of the tables may differ depending on the version Android and the specific shell of the manufacturer.
To view and edit the contents of this database, you can use the console utility sqlite3. By connecting to the device via adb shell and obtaining superuser rights, you can export the database to your computer for analysis. This allows you to restore deleted shortcuts or transfer desktop settings to another device of the same model.
adb shellsu
cd /data/data/com.android.launcher3/databases/
sqlite3 launcher.db ".tables"
In addition to the main database, the same directory may contain transaction log files, such as launcher.db-journal. These files ensure data integrity in the event of a sudden power failure. It is not recommended to delete them manually, as this may lead to desynchronization of the launcher settings.
☑️ Preparing to work with system files
Storing graphic resources and wallpaper
While the logic for placing icons is hidden in databases, the graphic files themselves are often located in more accessible places. Desktop and lock screen wallpapers can be stored in either the system partition or the user storage, depending on how they are installed. The standard wallpaper that comes with the firmware is usually located in the section /system/product/media/wallimages/.
If the user installs his own wallpaper through the gallery or settings, the system copies this file to a special protected directory. In modern versions Android (starting from 10 and higher), the path to the current wallpaper is often located in /data/system/users/0/. Files can be named wallpaper or have an extension .png without explicitly specifying the name.
To extract the current wallpaper without root access, you can use the command via ADB, which copies the file from the protected area to a temporary folder that is readable. This is a useful trick if you want to save an image you like, but cannot find its source in the gallery.
adb shell pm grant com.android.settings android.permission.READ_WALLPAPER_INTERNAL
adb pull /data/system/users/0/wallpaper wallpaper_backup.png
The application icons you see on the desktop are not stored as separate image files in the launcher folder. They are retrieved dynamically from APK files of installed applications or from the icon cache. The icon cache is usually located along the path /data/data/com.android.launcher3/cache/ and is a set of optimized images for quick launch of the interface.
Why may icons be displayed incorrectly?
If the icon cache is damaged or the files in the cache folder have incorrect permissions, the launcher may display standard green Android icons instead of application logos. Clearing the launcher cache through application settings usually solves this problem, forcing the system to recreate the cache again.
Differences in stock and custom launchers
The data storage structure differs significantly between the stock launcher from Google and third-party solutions. Users installing Nova Launcher, Lawnchair or Microsoft Launchershould look for data in directories with the names of the corresponding packages. For example, for Nova Launcher the path will look like /data/data/com.teslacoilsw.launcher/databases/.
Custom launchers often offer the function of backing up settings to a file that is saved in the device's public memory (in a folder /sdcard/). This makes transferring settings between devices much easier than with stock solutions that require access to the system partition. Backup files usually have extensions .nbk or .json.
Some smartphone manufacturers, such as Xiaomi or Oppo, modify the stock launcher beyond recognition, adding their own databases and synchronization services. In such cases, standard paths may not work, and data may be scattered across multiple system processes related to the theme and the manufacturer's cloud services.
| Launcher type | Batch name (example) | Database path | Capability backup without Root |
|---|---|---|---|
| Stock Android | com.android.launcher3 | /data/data/.../databases/launcher.db | No (ADB/Root required) |
| Nova Launcher | com.teslacoilsw.launcher | /data/data/.../databases/nova.db | Yes (built-in function) |
| Microsoft Launcher | com.microsoft.launcher | /data/data/.../databases/launcher.db | Yes (via account) |
| Samsung OneUI | com.sec.android.app.launcher | /data/data/.../databases/home.db | No (Smart Switch only) |
Using ADB to manage desktop files table
The tool Android Debug Bridge (ADB) is a powerful tool for working with the file system without the need to obtain root access at some stages. With it, you can view the directory structure, copy files, and even run SQL queries against the launcher databases if the device is in debugging mode.
To get started, you need to enable “USB Debugging” in the “For Developers” menu. After connecting to the PC, you can run the command adb shell to enter the device shell. If you do not have root access, access to /data/data will be denied, but you can use the command run-as to access the data of a specific application, if it is being debugged.
The command run-as com.android.launcher3 allows you to temporarily gain launcher context rights. This makes it possible to read database files and copy them to a temporary directory /sdcard/, from where they can be taken to the computer with the usual command adb pull. This is a safe method of analyzing settings without the risk of damaging system files.
⚠️ Warning: The command
run-asworks only on devices with custom builds (userdebug) or some stock firmware. On many commercial devices with a locked bootloader, this command may return a permission error.
Use the command "adb shell pm list packages | grep launcher" to quickly find the exact name of your launcher package if you are not sure about it.
Restoring and transferring desktop settings
Knowing data storage paths opens up opportunities for migrating settings when changing devices. If you are moving to a new smartphone of the same model and with the same version, you can try to transfer the file manually. To do this, the file from the new device is replaced with a file from the old one, after which the access rights ( Android, you can try to transfer the file launcher.db manually. To do this, the file from the new device is replaced with a file from the old one, after which the access rights (chmod and chown) are brought into line with the original.
However, simply copying files is often not enough. Application IDs (Package Names) on a new device may differ, especially if different versions of system apps were installed. As a result, icons may appear but not launch, or widgets may disappear. In such cases, editing the database is required to replace old identifiers with new ones.
An alternative recovery method is to use cloud backup services, such as Google Drive or manufacturer's proprietary clouds. These services automatically save your desktop layout in encrypted form and restore it the first time you set up a new device. This method is less flexible, but much safer for the average user.
Manually copying the launcher.db database is effective only between devices with an identical OS version and the same set of installed system applications.
Frequently asked questions (FAQ)
Is it possible to change application icons, without installing a third-party launcher?
Yes, this is possible, but it requires root access. You need to replace the icon files in the system launcher resources or use specialized Magisk modules that replace graphics on the fly. You can also use applications to create shortcuts that overlay custom images on top of standard icons.
Where are the settings of hidden applications on the desktop stored?
Settings of hidden applications are usually stored in the same file launcher.db, but in a separate table, often called workspace or favorites, with a specific visibility flag. In custom shells (for example, MIUI or OneUI), this information can be duplicated in protected system files, access to which is prohibited even for root users without unlocking the bootloader.
Why do the wallpapers return to factory settings after a factory reset?
Because custom wallpapers are stored in the data section /data/, which is completely cleared when performing a Factory Reset. Factory wallpaper is in an immutable section /system/that is not cleared. Therefore, the system automatically pulls up the default image from the system folder.
How to find out which file is responsible for the current wallpaper?
In modern versions of Android, the name of the wallpaper file is often written into the system settings. You can try running command settings get system wallpaper_backup via ADB to get the path or file name. However, it is safer to simply copy the contents of the folder /data/system/users/0/ and visually check the images.
Is it safe to delete the launcher.db-journal file?
It is safe to delete this file only if the launcher is not currently running. The log file contains unwritten changes to the underlying database. If you delete it while the system is active, the latest changes in the arrangement of icons may be lost, but this usually does not cause a critical system failure.