⚠️ Attention: Any intervention in the Android system partition can lead to a “bootlap” (infinite reboot). Before starting work, it is strongly recommended to create a full backup of your data via custom recovery or PC.
Turning user software into system components is a powerful tool for advanced users that allows you to permanently secure important apps in the device’s memory. Standard Android settings do not provide the ability to force an installed application to be moved to a /systempartition, as this violates the integrity of the file system and Google's security policy. However, having received extended access rights, you can bypass these restrictions and integrate any APK file directly into the firmware.
Why do you need to make applications system-wide? The main reason lies in the operating system's operating mechanism. User apps are stored in a partition /data, which is often cleared during a factory reset (Hard Reset). System applications reside in a protected partition, which is retained even after the user memory is completely formatted. In addition, some Android functions, such as deep battery optimization or access to specific hardware APIs, are available only to software with system privileges.
Let's consider several methods for implementing this task: from using specialized applications with superuser rights to manually transferring files via the ADB console. The choice of a specific method depends on the availability of root access on your device and model smartphone. Owners of devices without an unlocked bootloader will be able to use only limited methods of emulating system behavior, while Root owners will have full control over the directory structure.
Preparing the device and obtaining root access
Without superuser rights (Root) direct writing to the system partition is not possible due to limitations of the Linux kernel on which Android is based. You will need to unlock the bootloader and install a custom recovery, for example TWRP, or use the utility Magisk to patch the boot image. The unlocking procedure differs for different manufacturers: for Xiaomi a wait of 7 days is required, and for Pixel or OnePlus the process takes several minutes.
After obtaining Root access, you need to make sure that the file manager or terminal you plan to use has permission to write to the system folders. Standard file managers usually do not display hidden system directories or block writing to them. It is recommended to install a specialized explorer, for example Root Explorer or Solid Explorer, and activate superuser mode in the application settings.
⚠️ Attention: Unlocking the bootloader automatically erases all data from the device. Be sure to make a backup of contacts, photos and important documents before starting the procedure for obtaining root access.
It is important to understand that turning an application into a system one changes its status in the eyes of the operating system. After this procedure, normal removal through the settings will become impossible - to uninstall you will need to again gain access to the file system with write rights. This creates an additional level of protection against accidental deletion of critical utilities, but requires caution when choosing a candidate for conversion.
Conversion method through converter applications
The easiest way for users who already have root access is to use specialized converter utilities. Applications such as App2System, System App Converter or modules for Magiskautomate the process of moving files. You do not need to manually search for directory paths or change access rights (chmod) - the app will do it for you in a few clicks.
The process usually looks like this: you launch the converter, give it superuser rights, select the installed user application from the list and click the “Convert to System” button. The utility automatically moves the APK file from /data/app to /system/priv-app or /system/app, and also creates the necessary .odex files to speed up startup. After rebooting, the device will detect the app as an integral part of the firmware.
It is worth noting that not all applications work correctly after a forced transfer. Some apps are strictly tied to the installation path in the user section and may generate errors when trying to update via Google Play. In such cases, the system may block the installation of updates, requiring you to first return the application to user status. This is a common problem for applications that actively use auto-update mechanisms.
Before converting, remove all application updates and leave only the basic version. This will reduce the risk of version conflicts and certificate signing errors.
Manually transferring files through a file manager
For those who prefer to control every step of the process, the method of manually moving files through an advanced file manager with Root support is suitable. This method requires understanding the Android directory structure. You need to find the APK file of the target application in the directory /data/app (the path may contain the package hash, for example com.example.app-1) and copy it to the system partition.
Where exactly to copy the file depends on the type of application. For regular system apps, the folder /system/appis used. If an application requires elevated privileges (access to contacts, calls, system settings without asking for permissions), it should be placed in /system/priv-app. After copying, you must change the access rights to the file: set the value rw-r--r-- (or 644 in octal system), otherwise the system will not be able to read the file when downloading.
☑️ Manual transfer checklist
Pay special attention to dependency files. Modern applications often use Split APKs technology, when the app consists of several files (base APK, screen configuration, language packs). In this case, simply copying one file is not enough - you need to transfer the entire folder with its contents or use tools that can work with the format .apks. Ignoring this requirement will cause the application to crash upon startup.
⚠️ Attention: Incorrectly set access rights (chmod) to files in the /system folder are the most common cause of a bootloop. If after rebooting the phone does not turn on, boot into recovery and delete the transferred file.
Using ADB and Shell console commands
For users accustomed to working with the command line, the most reliable method is to use USB debugging (ADB) and the Shell shell. This method allows you to perform operations even if the device's touch screen is damaged or the interface freezes. By connecting your smartphone to your PC, you can send commands to move files directly, bypassing the graphical interface of file managers.
First, you need to enter superuser mode in the device console. After connecting via ADB, enter the command adb shell, and then request root access with the command su. Make sure that a notification about granting rights appears on the smartphone screen and you confirm it. Only after the symbol appears # instead of $ at the beginning of the line you will have full access to the file system.
To move a file, use the command mv (move). The syntax is as follows:
mv /data/app/com.package.name-1/base.apk /system/priv-app/PackageName/It is important here to create the target directory before moving, since the command mv does not create folders automatically. Use the command mkdir /system/priv-app/PackageName before moving the file. After this, do not forget to change the access rights with the command chmod 644 /system/priv-app/PackageName/base.apk. Violating the sequence of actions will result in an execution error.
What to do if the /system partition is read-only?
If when you try to write you get the error "Read-only file system", you need to remount the partition with write permissions. Run the command: mount -o rw,remount /system. On some devices with the new erofs file system, this operation may be blocked at the kernel level.
Compatibility issues and errors after conversion
Even if you successfully transfer your files, you may encounter a number of problems. The most common one is a signature conflict. System applications are often signed with the firmware developer key (for example, key Samsung or Google), while user applications are signed with the keys of their developers. When you try to update such a “system” application through the store, the system may reject the installation due to mismatched signatures.
Another problem is related to updates to the operating system itself. When installing an OTA update (over the air), the installation script checks the integrity of the system partition. Presence of third-party files in folders /system/app may lead to a verification error and refusal to install the update. In some cases, the update may be successful, but your modified applications will be deleted or replaced with stock versions during the partition merging process.
| Problem type | Symptom | Possible solution |
|---|---|---|
| Signature conflict | Error installing updates from the Play Market | Roll back the application to user mode before updating |
| Bootloop | The phone freezes on the logo when turned on | Delete the file via TWRP or recovery mode |
| FC (Force Close) | The application crashes immediately after startup | Check access rights (chmod 644) and presence of dependencies |
| OTA error | Unable to install system update | Temporarily returning stock system files before updating |
Also worth considering limitations of the new version of Android, which implements Project Treble technology. It decouples the system framework and vendor implementations, making direct writing to /system less preferable. In modern versions of Android 10 and higher, it is recommended to use overlay mechanisms (Overlays) or Magisk modules, which are mounted dynamically into the system without physically changing the firmware partition.
Alternatives: Magisk and system partitions without writing
Instead of roughly copying files to the system partition, modern experts recommend using the system modulation Magisk. This approach allows you to "replace" system files or add new applications to the system context without actually writing to the partition /system. The module is mounted into memory at boot, creating the illusion to the OS that the application is a system application, but at the same time leaving the physical partition untouched.
The advantage of the Magisk method is security and the ability to easily rollback. If a module is causing problems, you can simply disable it in the Magisk Manager menu and the phone will boot normally. You don't need to search for a file in deep directories through recovery to save your device from a bootloop. In addition, this method allows you to pass the SafetyNet (or Play Integrity) check, which is important for the operation of banking applications.
Using Magisk modules is the safest way to make an application system-wide on modern versions of Android, since it does not violate the integrity of the system partition.
To create such a module, you will need a basic understanding of the structure of ZIP archives. You need to create an archive with a special folder system/priv-app inside, place the APK and configuration file there module.prop. When installed via Magisk Manager, the contents of the archive will be automatically redirected to the desired point in the file system every time the device is booted.
Is it possible to make an application system without root access?
It is impossible to fully make an application system (move to the /system partition) without root access due to the limitations of the Linux kernel. However, you can use the “Unremovable application” mode via ADB commands pm disable for standard software, but this will not provide the benefits of system privileges.
What will happen when resetting to factory settings after conversion?
The application will remain on the phone, since it is located in a protected system partition, which is not cleared when standard reset (Wipe Data/Factory Reset). To remove it, you will have to gain Root access again or reflash the device.
What is the difference between the /system/app and /system/priv-app folders?
The /system/app folder stores regular system applications with limited rights. /system/priv-app hosts critical system components that have access to protected APIs, contacts and security settings without asking the user for permissions.
Why does the application crash after moving to the system partition?
Most often the reason is incorrect file permissions (should be 644) or the absence of the .odex file. It is also possible that the application is not intended to work as a system application and requires specific paths to data in the user section.