[OnePlus 5 Guides, News, & Discussion] guitardedhero:
I would like to add the additional solution of simple file management, as this is certainly the most fundamental method as well as the method through which most insight is gained as to the nuances of a device's partitions and folder/file structure.

Assuming superuser privileges are available, acquire a capable file manager application that supports root for access to the entire filesystem and partitions on the device such as Root Explorer, Mixplorer, FX Explorer, etc.

The objective sought by the user is to make a system application from an existing user or data application installation.

The determination for an installed application to be either a user or system application is nothing more than the partition on which the .apk exists, and exists with appropriate permissions, ownership, context, etc.

The "app data" often mentioned throughout Android discussions is a constant, located in /data/data/, for all sufficiently installed applications - system and user/data.

User application installations appear in the /data/app/ directory beginning with a unique directory of the application's package name, in some cases, with even more alphabetical and numerical characters in the folder's name. Targeting this /data/app/<installed-app> directory is the first step.

Once discovered, peering inside will yield a generic base.apk and a directory containing the apk's optimized code used with Android Runtime. The .apk is all that is of interest with this particular procedure.

Copy this "base.apk" and paste somewhere into /sdcard for convenient handling - I suggest creating an empty folder named to represent the application "Chrome", "Maps", etc. beforehand so that you can then apply the same name to the .apk while ensuring that the .apk extension is kept.

At this point, this is often sufficient for performing the /system tasks.

System application installations exist in multiple locations on the /system partition as well as the /vendor partition for those particular devices.

I suggest focusing only on /system/app and /system/priv-app directories, although, I almost exclusively use /system/priv-app for custom system installations myself.

A capable file manager application with access to superuser can simply copy the folder containing the .apk retrieved from /data/app (it's a good practice to share the same name for folder and . apk) and paste directly into /system/priv-app/.

I hate to introduce a possible "curve ball", but this is where I must address a most certain likelihood for rooted users:

Magisk's primary identity is a result of thorough symlinking (symbolic link) of the entire /system partition, making the physical /system partition immune to write operations since the entire /system partition is moved to /sbin/.core/mirror/system (as hard links, the actual content) before symlinking everything inside /sbin/.core/mirror/system/ to the /system directory.

Essentially, the physical /system content exists "symbolically" in /system once the boot operations are completed during each device boot. Changes to a symbolic system partition leave the hard, physical contents, from which this symlinking is sourced, unmolested.

I do not doubt that I may be describing more than necessary, so this the take away I intend:

Actions purposed to modify physical system content where the superuser privilege granting such ability is presented in a purely symbolic /system filesystem in the case of the Magisk root solution, must be targeting the physical content or source of the symlinked /system directory!!

As of version 16.4 (1642), Magisk executes various operations resulting with a booted device whose system contents are located in:

/sbin/.core/mirror/system/

One could perceive it as system merely being three levels deeper. Anything to distinguish the physical and symbolic system contents is perfectly acceptable as long as there is no blurring of symbolic system contents in /system and its actual, physical contents in /sbin/.core/mirror/system.

You may notice /sbin/.core/img/ as well, this is where installed Magisk modules can be observed.

An example to close this scenario:

Objective: Add a build property and value to build.prop permanently rather than "systemless-ly".

Solution: Navigate to /sbin/.core/mirror/system, open build.prop with a text editor function, add the desired build property and its value, save changes, and reboot to complete the task.

File management of /system content during recovery sessions such as TWRP will take place in the typical /system directory and partition as the symlinking operations only take place when booting into userspace.

Assuming the apk targeted is Chrome's .apk, the flow of events appears as:

Create folder named "Chrome" in /sdcard --> Copy /data/app/com.chrome/base.apk --> Paste /sdcard/Chrome/base.apk --> Rename /sdcard/Chrome/base.apk --> /sdcard/Chrome/Chrome.apk --> Copy /sdcard/Chrome folder --> Paste /system/priv-app/ or /sbin/.core/mirror/system/priv-app/ --> resulting in /system/priv-app/Chrome/Chrome.apk or /sbin/.core/mirror/system/priv-app/Chrome/Chrome.apk

To complete the manual installation, the folder and .apk attributes must be known and adjusted if necessary.

If not well-versed in the variety of default folder/file attributes, begin with the most common and basic attribute set for /system content:

Folder permissions:

0755

File permissions:

0644

Folder ownership:

root root

File ownership:

root root

Folder context:

u:object_r:system_file:s0

File context:

u:object_r:system_file:s0

It helps a great deal if working with a file manager application supporting attribute adjustments in a clear manner.

To finalize your /system partition operations, a full device reboot is required.

I encourage this manual method in every scenario as there is no action performed but the user's actions and any "hiccup" along the way is presented to the user in full view precisely during/after an action that the user can then observe in order to obtain progress by having both the reported error/impossibility and the precise cause of action. :good:

Edit*

I neglected to account for the now common Magisk root solution and its expansive symlinking measures.