[Miscellaneous Android Development] Peter1212:
Alright, I have been experimenting a bit as of late with the latest BS, Memu and Nox player although most of these things apply to every one of them per se. I have seen two different storage styles so far, BS has its own style while Memu/Nox/LDplayer have their own style which is the same.

The versions I have used for experimenting are as such: Bluestacks 5 (5.0.100.2106), Memu (7.5.0) and Nox (7.0.1.1)

In BS's case, the system partition is not being stored in an img file and instead is simply stored in a folder called /android/system (you can look at it via opening the root.vdi file with 7-zip easily). Hence all of its blocks are expandable and not constricted by size.

/android becomes the first block within the root.vdi file, known as sda1, ramdisk is stored within /android/ramdisk.img and system files are stored within the sda1 as well. If you want to remove bluestack's bloatware files you can do it via the next block named as dataFS, that'll make it sda2

For ex, bluestack launcher is stored in /dataFS/downloads/com.bluestacks.launcher

SO I mount sda2 to a temp directory, head over to the said directory and delete that folder (com.bluestacks.launcher) entirely. Now I simply install Nova Launcher or any other, set it as default and reboot. That'll remove BS's default launcher and thus removing any ads or etc, simply giving you a cleaner look.

In other emu's case, you'll find two vmdk files xxxx-xxxx.xxxx-disk1.vmdk and xxxx-xxxx.xxxx-disk2.vmdk where xxxx-xxxx.xxxx could be any string at all. They could even be renamed as anything else since the name does not matter much entirely. Anyways, one of them contains the system partition and the other, the data partition. The one which has the system partition will have a couple more img files and they'll just be named as numbers, 0.img 1.img 2.img and as such. One of these files will be containing the ramdisk within. You can verify which one by simply extracting them out and trying to view their content with 7-zip, if it errors out that is not the one, if it doesn't contain the ramdisk that is also not the one.

@evildog1 already found it for LDplayer it is the 0.img and for Memu 2.img

These are the boot.img file containing the ramdisk and kernel.

Now as @evildog1 found in one of his posts

those boot.img files are pretty small and chances are you won't easily be able to replace the ramdisk within it in case the patched ramdisk.img is larger in size. It won't get replaced no matter what you do, unless the size of the ramdisk is smaller or equal to the current/stock ramdisk.

The only option would be somehow to increase the size of the boot.img files first, and then replacing it within the vmdk files, moving the other partitions/blocks further ahead depending on the size increase. That is the size constriction I had talked about earlier.

Now as @evildo1 said he used https://github.com/shakalaca/MagiskOnEmulator/ shakalaca's scripts, they work as intended to even if you can't replace the ramdisk within memu/ldplayer/nox easily. The scripts did need a few modifications here and there, depending on the path of root/su as su might be placed in some other location (ex. Bluestack's su is placed within /system/xbin/bstk/su whereas others store it in /system/xbin/su), the block number containing the ramdisk and the subsequent path afterwards that the script needs to reach the ramdisk.

Along with how the ramdisk is named/stored as (ex. in BS it is stored as ramdisk.img which contains ramdisk whereas others store it as ramdisk which contains the ramdisk file)

As long as you take into account all of these and change the scripts accordingly, you could even use the Virtualbox method that is stated within the readme on the git. I did change and replace the ramdisk within Bluestack with the patched one which was made by magisk 21.4 23.0 and canary, and in all of the cases, Bluestack failed to launch.

Which raises another question, whether other emu's will work if one could replace the ramdisk successfully? Is there any file check that prevents booting from a modified ramdisk? Further testing is needed.