Author: Steven Grey

SLAX, the best Linux around. You’ve probably have heard all the praise and all that. But now you’re actually wanting it. So you get it on a VM. You power it up and- BANG, no install! And they say it’s the easiest OS ever!
You’re probably pretty frustrated with the no-install-policy. Well, as always, we’re here to lend a helping hand. The installation is pretty easy, but the prerequisites aren’t. More on that later.
A lot you would have come across lots of forums telling you to copy the contents and execute an elusive (nonexistent even) file, namely, “liloinst.sh”. Don’t blame the forums though, as it would probably work for other non-original versions of SLAX (WiFi SLAX, WinLinux, SabreSLAX etc.).

Now for the real how-to and the daunting prerequisites. If you plan on installing this in VMware, you’ll need a Windows XP (or above) VM already installed

First, the VMware method.
Attach a new “SATA” drive onto the Windows VM (8GB is more than enough). Boot up the Windows VM. Once booted up, mount the SLAX ISO on a drive.

Initiate the VMDK file as follows: MBR> NTFS> Label: SLAX (right click This PC > Manage> Disk Management). Copy all the contents of the SLAX ISO onto the hard disk.

Next, run as Administrator, “/slax/boot/bootinst.bat” (the one in the virtual HDD. Note: I’ve shown you the path from the CD for demonstration purposes. DON’T do that).

Read whatever the “bootinst.bat” file says. When it says “Boot sector written successfully” (or something like that), close the CMD windows.

Now we’re set. Shut down the VM, remove the SLAX VMDK from the Windows VM and make a new VM with the “SLAX.vmdk”. The VM will boot up fine.

Done! Hope that helped you in some way.

• 

• 

If you wanna install Guest Additions, you’ll need: |GConf| |Perl| |Python| |SDL| |7Zip| |Kernel-Devel|

How to Install ADB

For windows users, download this zip file and extract it to an easy-to-access folder. Then install the necessary drivers for your device from this website. Unfortunately, macOS and Linux users have to get the entire Android Platform SDK (200MB) in order to use ADB. Get it here. Once you have it installed, proceed to the next steps.

Note: Mac users should read this before proceeding .

Preparing Your Device for Use with ADB

Enable developer options in your device (Settings > About Device > Tap Build Number a couple of times until “Developer Options Enabled” appears).

Then enable “USB Debugging” and “Verify Apps via ADB/APT” in Developer Options.

Connect your Android device to your PC.

Use ADB

Navigate to where you extracted the above said zip file (Windows). Open a command prompt window in that folder. Type “ADB” followed by whatever commands you want to send to the device. For macOS and Linux users, just open a Terminal windows and type “adb” followed by whatever. Under some circumstances it might be necessary to navigate to ADB’s root directory and then executing commands (Unix-based).
Note: when connecting a device to your PC for the first time, a dialog box will appear on your device asking for permission to let your PC access your device, to which you must tick the “Remember This Computer” box and click “OK”.

Manage Your Device with ADB

ADB has a wide variety of functions for managing your device, moving content to and from your phone, installing apps, backing up and restoring your software, and more. Think of this as a general reference and not an encyclopedia. Remember to research your particular device before doing any of this! You can use ADB while your phone is plugged in to a computer.

adb devices

Function: Check connection and get basic information about devices connected to the computer. When using ADB, this is probably the first one command you’ll run. It will return a list of all devices that you have connected to your computer.

adb reboot recovery

Function: Reboot your phone into recovery mode. A lot of functions like flashing ROMs to your phone require you to boot into recovery mode. Normally, this requires you to hold down a particular set of buttons on your phone for a certain length of time, which is obnoxious. This command allows you to boot directly into recovery mode without performing the complex finger dance of your people.

adb reboot-bootloader

Function: Reboot your phone into bootloader mode. Along the same lines as the previous command, this one allows you to boot directly to your phone’s bootloader. Once you’re in the bootloader, ADB won’t work anymore. That’s where fastboot comes in (which we’ll get to in a bit). However, much like the recovery command, it’s much easier to boot into your bootloader with a command on your computer than a complex series of buttons on your phone.

adb push [destination]

Function: Copy files from your computer to your phone. The push command allows you to copy files from your computer to your phone without touching your device. This is particularly handy for copying large files from your computer to your phone like movies or ROMs. In order to use this command, you’ll need to know the full file path for both your source and destination (for all you newbies, here’s the path of your internal storage “/data/media/0” or /storage/emulated/0”. Host-side path should be easy. Ex. For a file named hellworld.txt in your downloads folder; “Users[username]Downloadshelloworld.txt” on macOS or “C/Users/[username]/Downloads/hellworld.txt”).

adb pull

Function: Copy files from your phone to your computer. The yin to push’s yang, the pull command in ADB allows you to copy files from your phone to your computer. When pulling files, you can choose to leave out the destination parameter. In that case, the file will be copied to the folder on your computer where ADB itself lives. You can then move it to wherever you’d prefer like normal.

adb install

Function: Remotely install APKs on your phone. You can use this command to install an app on your phone without touching it. While this isn’t a terribly impressive trick for an app that’s on the Play Store (where you can already remotely install, uninstall, and update apps), it’s quite handy if you need to sideload an app.

adb shell

Function: Open or run commands in a terminal on the host Android device. There are so many great things you can do with it. Most of us don’t tend to bother with the terminal in Android because we don’t want to type long text-based commands on a tiny touchscreen. However, the adb shell command allows you to open up a full terminal on the host device. Alternatively, you can type “adb shell” followed by a valid terminal command to execute just that one command by itself.

adb backup

Function: Create a full backup of your phone and save to the computer. Backing up your Android phone is already something you can and should be doing automatically. However, if you need to create a complete backup before hacking away at something particularly risky, you can create a full backup with a single command. You don’t even need root access (though this may mean that some protected data can’t be backed up). You can read more about the parameters for this command—and there are a lot of them—here.

adb restore

Function: Restore a backup to your phone. The corollary to the previous command, adb restore allows you to point to an existing backup file and restore it to your device. So, for example, type “adb restore “/Users/[username]/Desktop/[restorefile].zip” and your phone will shortly be back to normal.

adb sideload

Function: Push and flash custom ROMs and zips from your computer. This command is a relative newcomer to the ADB field and is only supported by some custom recoveries. However, you can use this single command to flash a .zip that’s on your computer to your phone. Once again, this allows you to flash whole OSs (or anything else you can flash with a .zip file) without touching your phone. These commands are just some of the more useful ones you can use with ADB installed on your computer. You may not want to use it all the time for everyday tasks, but when you need them, you’ll be glad you have them.

Unlock and Modify Your Phone’s Firmware with Fastboot

As stated above, fastboot allows you to send commands to your phone while in the bootloader (the one place ADB doesn’t work). While you can’t do quite as many things here, the things you can do are awesome, including unlocking certain phones—like Nexuses and certain others—as well as flashing custom recoveries and even some ROMs. It should be noted, though, that not all phones support fastboot and if you have a locked bootloader, you’re probably out of luck here. The devices that do support this are most Huawei, Oppo, LG, and anything (Including some high-end Samsung devices) with the “Unlock Bootloader” option in Developer Options . That being said, here are some of the most useful tools in fastboot’s arsenal.

fastboot oem unlock

Function: Unlock your bootloader, making root access possible. When people go on about how “open” Nexus devices are, this is what they’re talking about. Most phones require a root exploit to gain superuser access and the ability to heavily modify your phone’s firmware. With a Nexus device, you can unlock your bootloader with a single command. From there, you’ll be allowed to install custom recoveries or give yourself root access. It should be noted, this command will also completely wipe your phone. This means it’s a great command to run when you get a brand new phone, but if you’ve been using yours for a while, do a backup first.

fastboot devices

Function: Check connection and get basic information about devices connected to the computer. This is essentially the same command as ADB devices from earlier. However, it works in the bootloader, which ADB does not. Handy for ensuring that you have properly established a connection.

fastboot flash recovery

Function: Flash a custom recovery image to your phone. As with everything else in this list, you can install a custom recovery on your device without touching it by using this command.

Ever noticed how most of the commercial Android emulators are seemingly stuck at KitKat? Sure, there are a few that run higher like YouWave 5.1, Genymotion, BlueStacks N, etc. but they all use VirtualBox and, as we have found out, VB sucks when you compare it with the big players. So you’re better off with making your own emulator. “How” you ask? Well that’s what we’ll be covering today!

If you don’t know the wonderful people at Android x86 –who are the real spirit behind all the commercial folk- go there and check ‘em out. Anyway, what’ll we will be doing today is installing Android on a VMware Workstation VM (FIY: VMware > VirtualBox    🙂 ), but if you have a slow PC (2GB> RAM, Old CPU etc.) go with installing Android on your native hardware, it’ll be lots faster than running a VM on that junk. By the way; all the commercial emulators are really Android VMs anyway, so you’ll be installing a better version of Android than those emulators ;-).

However there are a few prerequisites before you make an Android Emulator. You’ll need a processor capable of hardware virtualization (Intel VT-x / AMD-V), a host PC with 3GB or more RAM, 20GB free disk space (a desktop with multiple drives (or an SSD) or a laptop with an SSD is recommended), VMware Workstation Player or (VMware Fusion if you’re a Mac user), a (32-bit) distro of Android x86.

 

When you get VMware Fusion or Player: the latest version 14 (Player) or 10 (Fusion) requires a Sandy Bridge (Intel Core-i 2^nd Gen or better) OR AMD Bob Cat or better processor. If your machine doesn’t meet these requirements, you’ll have to use Player 12 or Fusion 8 instead.

|VMware Workstation Player |14| |12|

|VMware Fusion |10| |8|

 

Picking a good, stable distro of Android x86 is of paramount to the success of this mission. If you would like to pick manually, keep in mind that you’ll need to pick one that is stable (in “Release” stages), and has proper hardware acceleration features. But to make your life painless, I’ve picked the best ones for you (all these are 32-bit (except the PhoenixOS one) ISO installation images):

|Android 6.0.1|

|Android 7.1.2|

| RemixOS(Android M) 3.207|

|PhoenixOS 1.5 (Android L 32-bit) | PhoenixOS 3.0 (Android N 64-bit)|

|Lineage OS 14.1|

|CyanogenMod 13.1|

 

Now that you’ve gotten all you need, let’s start. First, install the VMware product. Next, check whether you have an SSD, and check how many disk drives you have (by going to DiskManager), if you have no SSDs but have more than one Hard Drive or if you’ve got one SSD, you’ll see some major performance perks. But if all you’ve got is one Hard Drive, you may attempt to make the emulator, but keep in mind that speeds will decrease.

Open VMware Player/fusion and create a VM with the following characteristics: Guest OS “Linux 3.x kernel”,

1.5GB-5GB RAM (As a rule of thumb, leave at least 1.5GB of RAM for the host operating system and allocate the remaining amount to the VM),

16GB (Pre-Allocated) SATA Drive (if you happen to have multiple hard disk drives, place the image in a non-system drive OR on an SSD if you have one. But never on an external hard drive, unless you use a Thunderbolt port),

2 or more Cores/Threads (the core count is really not a problem, the more the merrier! Just make sure you leave at least one Core/Thread for the host OS. Since most newer PCs have 2 Cores (and at least 4 logical cores/threads thanks to HyperThreading), allocate 2 Cores to the VM).

Once you create the VM, head over to display and enable “Accelerated 3D Graphics” and assign 64-256MB of “Graphics Memory”.

Remove the printer.

Set USB driver to “USB 3.0”

Set network adapter to NAT (for Internet access) and set it to “Connected at power on”

Attach the Android x86 ISO, power-on the VM and install Android x86 according to the instructions here. But remember not to select “Run Android x86” and instead select “Reboot”. When you reboot to the GRUB screen, power off the VM.

Remove the CD Drive from the VM. And power it on. You may switch to full screen mode. After a few minutes you’ll be presented with the setup screen. Go through the setup normally.

 

 

When you are greeted with the Android home screen, you’ll know it’s all done! Enjoy 🙂

In order to maximize performance, boost productivity and enjoy the damn thing, you may follow these steps.

Get/Enable Taskbar (if you’re using Android 6.0.1 or CM 13.1) and enjoy desktop-like Android computing (with windows and stuff).

There is no shutdown button in AOSP android, so Taskbar’s “Power Menu” will come in handy when turning it off.

This slideshow requires JavaScript.

Go to “About” and see if graphics are accelerated (if there’s anything except “null” and “SwiftShader” in GL Renderer, you’re set).

Enable “Developer Options” and lower or disable animations.

Set the screen timeout to 30 minutes to avoid unwanted sleep in the VM.

Disable “Other Sounds”.

Obviously you won’t be making any calls with your VM. Disable useless apps.

This slideshow requires JavaScript.

Enable “Native Bridge” to run apps with ARM Native Libraries (Settings > App Compatibility).

Use ADB to install APK files. Here’s how to make ADB work in a VM.

Install Greenify and hibernate apps frequently to avoid performance issues.

 

 

EXTRA

If you used Android N (7.0), and you’re a cat person, enable the “Neko Land” easter egg. Go to settings and tap on Android Version until an “N” appears.

Tapping it a few times and then pressing ad holding it will bring up a small cat. A widget will appear with an empty dish (in the pull-down panel or as a launcher widget). You can tap that dish and keep “food” in it.

After a while, a cat will come to eat the food. There are hundreds of cats to find!

Windows users may create a shortcut of the VM and launch it with VMware KVM (Included with Player) to simplify the whole launch-a-VM thing.

Everybody knows that lowering your screen resolution reduces the strain on your graphic card and stuff on your screen becomes larger, but there’s no obvious way to change it in Android x86, is there? So, when you want to test an app made for portrait mode in Android x86, you have no way to do that, and you’re left feeling rather down.

In this post we’ll show you how to change the screen resolution and pixel density in Android x86. It’s applicable to VMs as well (but we don’t recommend Virtual Box, as it has quite a few problems).

A few pointers before we begin:

• Changing the screen resolution can only be done on stable kernels.
• You must have a preliminary knowledge of editing GRUB boot arguments.
• The distribution of Android x86 must have root access (to change DPI)
• Deprecated builds will not work (e.g. Android Jelly Bean builds (unofficial) will not work)

SCREEN RESOLUTION CHANGES

To change the screen resolution, line press E when presented with this screen (if you’re live (live image), press TAB to directly go to the list editor)

Press “E” (only if installed).

Then press “E” again. Remove “quite” and experiment with the following lines:

• Try adding “vga=ask”, if –when booting with just the command- you get no Android boot animation,
• Try adding “nomodeset”

NOTE: adding “nomodeset” depends on whether or not changing resolution makes Android unbootable or doesn’t give a favorable result.

Press “Enter” when you are finished editing. Your finished menu should look like this.

Press “B” to boot. You’ll get this screen.

Press “Enter”, you’ll be presented with this list. (In the format width X height X color mode)

Enter the number of the video mode you like and press enter (e.g. if you want “1024x768x32”, then enter “341” and press enter).

If everything went well, you’ll see the Android boot animation in a few seconds.

Notes on selecting a resolution:

• A 32-bit color mode is generally preferred by Android.
• Don’t set the resolution larger than your monitor’s native resolution! (It’s OK to do this in VMs)
• If you’re stuck on a blinking cursor for more than a few seconds after pressing enter, try adding “nomodeset” to the kernel argument.

If you would like to make these settings permanent, edit GRUB’s “menu.lst” file located at “/grub/” on the Android x86 install directory. (You will have to change your preferred resolution’s Hexadecimal number to a Decimal number first using a programmer calculator (there’s one in Windows).

• 

• 

Add the line “vga=<decimal>” to “menu.lst”.

When you boot up, it will set that resolution.

If you found that a tad-bit too hard, here’s the accompanying video tutorial.

DPI CHANGES

When you set a small resolution, everything becomes larger (relatively). So what do you do when that launcher icon takes up most of your screen’s space? You reduce the DPI of course!

A few notes about your DPI,

• The DPI value tells the Android how densely populated the pixels on your screen are
• Setting a lower value will make items smaller (and fuzzier)
• While setting a higher value will make everything bigger (and sharper)

Here’s how to change it:

If your version of Android is Android 7 or above, an option to change the “screen size” is present in Display settings. This is the recommended way to change the DPI as it doesn’t make things fuzzy.

• 

• 

Also, if you’re using PhoenixOS, CM 13 etc. there’s an option in Display settings to adjust DPI

• 

• 

But if you happen to use an Android distro not listed above or in applicable to the 7+ rule, here’s how to manually change it.

There’s a file called “build.prop” in “/system/”.

Open that file using a capable text editor (with root privileges). And the following lines (under Additional Build Properties)

“ro.sf.lcd_density<dpi>”

“persist.sys.disp_density=<dpi>”

Now save that file and restart. Your chosen DPI should take effect. (But adding those lines may have no effect on some versions :-(, if you do use one of them, excecute this on a terminal emulator “wm density <dpi> && reboot” with root access)

Here’s how powerful changing the DPI is. Both of these are screenshots of the same Remix OS VM running at 640×480.

• 

• 

This video encapsulates all the methods described above. Watch it if you found the whole thing too hard.

Have fun using Android x86!

As I’ve mentioned in a post long ago, Android x86 can be installed on USB devices. The “HOW?” sector is a bit harder than that.

Lately I’ve been searching on forums for methods to do just that. But all the sites claim you can achieve that by first formatting the USB to EXT3 then installing Android. Just two problems, one, Android along with all Linux based OSes use EXT4 file system. And two, EXT formats are not detected by Windows computers. So, that turned out to be a big no-no. With a damp heart I began to research on my own. And here it is, a way to use Android on your USB. I also recommend you to use a release that is not in “RC” stage but one in “Release” stage (or having a higher “Release Candidate” value. E.g. RC4). I used the CM 13 build of Android as it is pretty bugless and customizable (And it is R1).

|Android x86 CynagonMod CM 13|

|Android x86 LineageOS 14.1|

The path to your goal is a bit hard, but great for peeps with 4GB USBs. For this method, you will need 2 USBs (or one USB and a CD/DVD). One to hold the Android ISO and another as the install location. For the container drive I recommend at minimum a 1GB USB (or a CD/DVD). And for installation, anything with above 4GB of free space.

Firstly, image the ISO file of Android x86 onto the container USB/CD/DVD. Then boot your PC from that USB. Select “Install Android x86” in the boot menu.

When it comes to a GUI display, Plug in the second USB (Installation) and hit “Detect devices”. Once it detects your second USB device, highlight it and hit it to use it (helpful tip: before plugging in the second USB, remember the first USB’s ID (e.g.”sda”). then when the second USB is plugged, choose the one that is NOT the first USB’s ID (e.g. “sdb”) that way, you won’t format the wrong USB).

Now here’s where some of you part ways. If you used a small USB (4GB – 6GB), hit “Format to EXT4”. If you used a bigger (8GB or more) USB, use the “Format to NTFS” option. It will ask for a confirmation massage in which you have to choose “YES”.

Once it’s done formatting, it will ask to install “GRUB Bootloader” in which you have to select “YES” (It might ask “Install GRUB2 EFI” only select this if you have a UEFI computer). Then it will ask to make “/system directory read-write”, hit “YES” as this is the most crucial step (choose “NO” and you’ll have a USB which permanently read-only. You have been warned!).

It will install Android to the USB after that (if you were asked “Create boot option for Windows, select “YES”). If you used EXT4 back there, once the installation is complete, it will ask you to either reboot or run Android x86. You may choose either.

But if you used NTFS, you will be asked to create a “DATA.IMG” file, choose “YES” and key in the size in MB (minimum is 4GB=4096MB in order for Android to run).Once the IMG file is created, you will be prompted to a reboot or “Run Android-x86”. You may choose either.

If it all went well, you will now be running Android from a USB. Do whatever you please, just as you would if you’d installed on a hard-disk.

Just keep in mind that the setup screens will be agonizingly slow and crappy (it will tell you several times that “Process system has stopped” or something like that, don’t click “close app”, just hit “wait” or even “mute until device restart”). I assure you that after the setup, Android x86 will run smoothly (But if you use a sub-par device with a slow port (USB 1.0) it will fail to work entirely 😦 ).

• 

• 

• 

Tip: Use a high-end USB, like one built for Windows-To-Go, or one that’s been proven to work with high I/O live OSes. If you use a cheap one, you’ll end its life pretty soon :-(.

• 

• 

• 

• 

• 

• 

Note: You may use a 4GB USB if you plan to use anything below Lollipop, but be sure to use EXT4 as the file format! You also have to boot your computer from the USB if you want to use Android!

NOTE: I’ve tested this on the following Pen drives: Kingston DT Series, Kingston DT Workspace Series, Imation IronKey™ Workspace W300 / W500 / W700, Spyrus Portable Workplace, WD My Passport Enterprise, Samsung Evo Series.

I don’t recommend ADATA and SandDisk devices (too many I/O bugs).

ADB (along with “Fastboot”) is perhaps the best tool (along with “Fastboot”) for managing your android devices. With functions ranging from a simple app install to an entire data backup. We covered all the greatness of ADB in a past post.

And the “Android x86” project is also a significant asset for an application developer (to test your apps in a virtual environment), being faster than the Android Emulator provided by Google with their Android Studio kit (yes, they do provide an x86 based image but it’s got its own problems). You’ll be better off installing Android on a VMware virtual machine anyway.

But ADB use is kinda crappy (if not downright impossible) in a VM. If you googled how to achieve this, you’ll find people telling you to “excecute “netcfg” on a terminal console”, but the command “netcfg” is not available in all android versions. So you’ll be left with a half-useful development environment.

But we found a solution: a way to get ADB working on [almost] any Android VM running on a VMware product. Read on to find out how!

First, we’ll need a few things: A VMware hypervisor: Fusion/Workstation Pro (NOTE: you can try this with Parallels Workstation/Desktop, VirtualBox or VMware Workstation Player but there’s no guarantee it’ll work. Furthermore, if you use VMware Player, the “vmnetcfg” app won’t be there making the whole process needlessly complicated), a distribution of Android x86 including and after “Android 4.4 R1” already installed on a virtual machine and “Android Platform Tools” (Google’s fancy name for ADB + fastboot. It’ll be already installed if you have Android Studio installed if not, Windows users can use this without downloading the entire 2GB suite (Mac/Linux users have no choice. If you’re planning to use ADB to push files/install apps on the Android VM, you can just get the command line tools instead of the whole thing)

That said, let’s start!

Since this is part guesswork, open Virtual Network Editor (either through the shortcut, the “Edit” menu in Workstation or [VMware Fusion > Preferences > Network > + icon] in Fusion or through “vmnetcfg” located at the install directory. Excecute with Admin/Root/Superuser rights). Click “Add Network”, select whichever free node you prefer and click OK

Configure the new network to be “Host-Only” and click “DHCP Settings”.

• 

• 

Edit the last digits of “Starting IP Address” and “Ending IP Address” to be close (numerically). So if you have:

Starting IP: 192.168.245.128

Ending IP: 192.168.245.255

Change it to:

Starting IP: 192.168.245.128

Ending IP: 192.168.245.130

Why we did this will become clear further-on.

Now connect that network adapter to an Android VM (Connected at power-on). And power-it-on.

• 

• 

Once the Android VM finishes booting, go to Settings and enable USB Debugging + Verify Apps via ADB + ADB over network.

• 

• 

Open a console and execute “netcfg”. You’ll be presented with a screen similar to this.

Find “eth0” IP address and execute “adb connect eth0’s IP” in a console on the Host. You’ll be presented with “connected to eth0’s IP”. Done!

But not quite. ‘Cause as we stated above, some distros of Android don’t have the “netcfg” command, in which case you’ll be left in a pickle. So when you type “netcfg” you’ll probably get this:

So, what now? Now this is where that guesswork comes in. Remember how we made those start-end IP addresses nearer to each other? Well this is when that helps us. Now –in a console on the host- try all those IPs ‘till one of ‘em hits home (if your start and end is like in the example, try “adb connect 192.168.245.128/129/130”, and one them will work). If ADB says that it’s connected to an IP, use ADB like a normal device. Cheers! 🙂

If that didn’t work, here’s where it becomes even more of a pain in the rear; for some strange reason, only some builds of Android x86 work with ADB like this, while others just don’t connect and stuff. Here’s a list of builds that I’ve tested to work (if other builds work, please drop a comment below):

Android 4.4 R5 (“netcfg” works)

Android 5.1 RC1 (“netcfg” works)

Android 6.0 R3

Android 7.1 R2

NOTES

• You might need to change the network adapter to Intel 1000 in the VM’s VMX file (only on some builds).

• CyanogenMod/LineageOS x86 builds have a switch in the quick settings bar that tells you the IP of the VM, but network connectivity was often unreliable on 13.0/14.1/15.1 builds.
• Windows users will need to execute ADB commands in after chdir-ing to the installed directory as shown below.

• If, after sometime ADB no longer connects to Android VMs or netcfg displays “0.0.0.0” or an IP address outside of the zone you defined before, try restarting the host machine.

If everything went well, you will have a sandbox environment faster and easier to use than Android Studio.

How many times have you been frustrated with the fact that your Android is not rooted? Have you ever tried to backup app data and found out that it’s only for rooted devices? Are you bangin yeh’ head against the wall ‘cause you don’t have root access? Well…, here’s your savior!

In this post I’ll share with you a nifty little app I’ve found that can backup not only the app, but the app data itself. On a device with no root access! (Yep, no root 🙂  ). The second note is that you’ll need a PC (Mac, Windows, Linux anything. But preferably Windows) that has a fairly recent version of Google Chrome installed, and a USB cable to connect your phone (+ you will need to enable Developer Mode on your device by, SETTINGS > ABOUT DEVICE > BUILD NUMBER (Tap 7 times) > go back to settings main page > DEVELOPER OPTIONS). Windows users will need ADB drivers and other platform users will require the Android SDK (I don’t personally know ‘cause all my machines have Android Studio installed. But if you can manage without, drop a comment).

Got all that? Then let’s get started.

First of all, download the “Helium” app for Android. Next, install the Chrome app “Helium Backup Partner” on your PC. Then install ADB Drivers as stated above. Reboot your PC/Mac. From here-on, follow the steps in the EXACT ORDER. You have been warned (But even if you screw up, the worst thing that happened in my testing was a just a reboot 😉  )

Don’t attach Android to your PC yet. Open the Helium app on your phone. It’ll tell you to get Helium for desktop (you’ve already done that). It will then ask you to connect your device. Do so know.

Next up, it’ll ask for USB debugging. You will find that in Developer Settings.

  

It will then ask you to enable PTP (for some devices). The Helium desktop app should briefly read “connecting” (or something similar). If it all went well, the screen on your PC should now read as follows.

You can now disconnect your Android device (actually, you MUST disconnect it, or else weird things happen) 😉

After you’ve disconnected it, you will be presented with a screen similar to this.

Select the application(s) you want to backup and pull up on the green bar. You will be presented with this. As an added precaution, close the app you want to backup (from recent apps), and take care not to use the app being backed up while its being backed up (Don’t use any other apps while the backup is in progress either!)

Here, you can decide whether to back-up just the data or the whole app (including app data). This is totally your choice, but if your app is known to be not-so-backward-compatible, untick the “App Data Only” box (if you are unsure, backup the whole app). Once you decide, hit “Backup”. It will ask you where to save the backup. Select any of the options (internal preferred).

The time taken will depend on your hardware, amount of apps, weight of apps and what other tasks are running. When the backup is complete, the backup files will be saved in “/storage/emulated/0/carbon/” (Or in laymen speak Internal Storage > Carbon). If you want to move the backups to a different place, move/copy the entire “carbon” folder.

 

 

 

RESTORING APPS

You can restore any backups you take using Helium. Just place a previously created “carbon” folder on your internal storage (/storage/emulated/0/). Open Helium (you might have to go through the whole setting up thing again). Select Restore. Tick the apps you want to restore and click “Restore”.

The process will take quite a bit of time. So, have a cookie 🙂

 

NOTES:

Restoring can be cross-device and cross-platform. For example, you can restore a backup taken on a phone running KitKat and restored on to a tablet running Peppermint (P). But chances of getting an app specifically made for ART Runtime (Any version above and including Lollipop) to run on an older device. In our tests we backed up the application Opera Mini from a Samsung device running KitKat and restored it on a Google Pixel running Android 8. The application worked without any problems. But when we tried to restore a backup of the Messaging app present in a Samsung (Android 8.0) onto a Pixel (Android 7.1), it fails spectacularly with a colorful boot screen and a whole load of errors.

In my experience, normal apps like games, social media apps (WhatsApp, Viber etc.) and other apps meant for the end-user should work fine. But system apps (often requiring hardware features to functions) will result in lethal consequences (Just a reboot and some other annoyances, nothing fancy like a bricked device. 😉  ).

I hope you can now easily back up your most precious data!

Since its release a couple of years back, Chromium OS has been a favorite among low-end/old PC owners, with its simple, no-nonsense interface, cost free nature and fast and efficient performance. But with no official build from Google many have taken upon themselves to build Chromium OS. One of the better ones is Neverware CloudReady, providing a near Chrome OS interface, stable builds and regular updates. Although clean and efficient, it can be a right pain in the rear when installing with its non-standard “BIN” file format and eye watering amount of partitions. It can drive one insane if you plan to install it in a VM. That’s why you came here!

After scouring the internet for instructions on installing it on VMware Workstation, we came to a conclusion that there is no official (or for that matter, straightforward and proven) way to install it. Most people claim that they can use the linux tool “dd” to dump it. But on our tests we found that to be a tad bit difficult and time consuming (seeing as how one will need linux and quite a lot of time). So we brew our own portion: a straightforward, fool-proof method of installing Clouready on VMware products (tests on VirtualBox proved futile (no graphics) and only sometimes worked in Parallels). It’s so fool proof that you don’t even need VT-x/AMD-v. How cool is that?

To begin with, you’ll need a (separate) VM with either Windows, Mac or Linux already installed. Then you will need a marvelous little tool called Etcher (Available for all above mentioned OSs). Also, we found that working with the 32bit version of CloudReady plays better than the 64bit version (But the 64bit version is quite alright if you have a sufficiently powerful PC (with VT-x/AMD-v)that can run 64bit guests). And you will quite obviously need a VMware Product (Fusion, Workstation Player/Pro, ESXi etc.). We’ll be using VMware Fusion on an iMac Pro with a secondary Windows VM.

Note: a simplified summary of the entire process is at the bottom of the post. And here’s the accompanying video.

|Etcher|

First, extract the BIN file out of the ZIP file you downloaded into one of the shared folders of your Windows/Linux/Mac VM.

Create a VM (for Cloudready)  [“linux 3.x”, minimum 724MB RAM, 20GB SATA Disk, minimum 64MB Video Memory, Accelerated Graphics, USB 3.0 controller, no Optical Drive, EFI Boot enabled (no secure boot), NAT Network Adapter]

Now assign the disk you made in the above step on to the Windows/Linux/Mac VM and power that on.

When the VM has finished powering up, initialize the new disk (using Diskpart, Disk Utilities, fdisk, GParted etc.) with an MBR partition table (I did not make a typo. That is MBR not GPT), and format it as NTFS/EXT4/FAT32.

Then open Etcher inside the VM. Click on the cog wheel (Settings icon) on the top right corner.

Now set it to “Unsafe Mode” (and also disable “validate write”, to speed up the whole process)

Click back. Choose the ClouReady BIN file and the disk from the ClouReady VM and click flash.

The flash will take anything between 30 Seconds to 30 minutes. Once it finishes the flash, shutdown that VM and remove the CloudReady VM’s disk.

Now focus on the CloudReady VM. Open its VMX file (using a text editor) and put the following line at the end on the file (with the quotes on “FALSE”).

mouse.vusb.startConnected = “FALSE”

[If you’re worried what it’ll do: CloudReady has a mouse bug that makes it impossible to direct mouse clicks. This is technically the same as turning off “Mouse Integration” in VBox]

Save the VMX file and poweron the CloudReady VM. You will first get a fleeting glance at the CloudReady logo and the Startup screen in which you can login to your Google account.

CloudReady plays best with VMware. It’s even got full WebGL 2 Hardware Accelaration.

If you found that a bit confusing, he’s the summary: Get Etcher, CR (CloudReady) 32bit image, VMware virtualization product and a separate Windows VM (not the one that you install CR in).

Attach disk of the CR VM to the Windows VM.

Use Etcher to image the CR BIN file to that disk.

Remove disk from Windows VM, attach to CR VM, Power on CR VM. Done!

• 

• 

• 

• 

• 

If you’re someone who uses VMs in their day-to-day activities, you probably know about QEMU, or Quick EMUlator. What you might not know is that they have a GUI version for Windows. Yep, you heard me, the hard-to-learn-VM-with-CLI-in-QEMU times are finished. Instead, you can use QEMU like a Pro. I’ll show you exactly how!

Note: Tut only applicable for Windows.

Download QTEMU. For simplicity’s sake, QTEMU package already includes x86 and x86-64 emulation images, so you don’t have to install QEMU. However, if you want more architectures (like ARM and PowerPC), you’ll have to install QEMU and import them yourself!

First, install QTEMU.

Once QTEMU is installed, just open the shortcut on your desktop and enjoying QEMUing!

• 

• 

• 

• 

• 

• 

I know! The interface of a bygone era! But, until a better GUI interface for QEMU is created, this’ll have to do!

This is the only functional graphical front-end for QEMU for Windows that works properly. If you find a better front-end, to drop a comment and share the knowledge with the world!

If you’re a fan of Android, you must’ve heard about the fab project called “Android x86”. They port your favorite android flavors to Intel and AMD x86 hardware. But here’s the glitch –as you may have seen- they all have that drab boot animation with a pulsating android logo. You might have found this boring and not-eye-catching. You might have tried boot animation changer on the store but, chances are, it works out of sheer luck. Sometimes works, others don’t. So here I am showing you how to change the start into a much more exciting color.

Note: the method here is totally brick-free. The method given here’s 100% applicable to Android x86. But you may attempt this method for most Androids with root permissions (the notable exceptions being Samsung devices, as they store their animation in a different format). Also, if you’re using AOSP Android (like the generic Android x86 images, the default animation is triggered by either having the zip file or not)

Here’s what you’ll need:

> A flavor of Linux with a GUI like Ubuntu (not essential)

> An installed version of Android x86 higher than ICS (VMs, including BlueStacks and such like, are also do-able) with root privileges (only for the Linux distro free method) and Root Browser installed and given root permissions to.

> Preferred boot animation as a “bootanimation.zip” file (I’ll provide a few that work flawlessly, but you can experiment with other animations)

(rename them to “bootanimation.zip” before inserting them)

|Samsung SM-Series Animation|

|CyanogenMod 13 Animation|

|Lineage OS Animation|

|Remix OS Animation|

|Pixel Animation|

 

Now, let the fun begin!

If you are gonna use a Linux distro, power that on. (If it’s a VM, connect the Android x86 installed disk or if it’s an emulator, i.e. BlueStacks, mount the “system” disk. I’ll be using RemixOS as the target and Xubuntu as the Linux distro. OR power on the Android. If you’re using a physical machine as the target, boot it up with a Linux live disc (like Ubuntu or SLAX) you don’t need to install the Linux distro!

Download a boot animation and rename it to “bootanimation.zip” (if it was one of mine).

If you used a Linux distro, open a file manager with root and mount the Android x86 disk.

Navigate to “/%androidname%/system/media/” (where %androidname% has to be your distribution name, like RemixOS in my one). You will find a “bootanimation.zip” file there. Replace that with the new one. If you don’t have a linux distro, navigate to “/system/media/” on your Android (with a root priviledged file manager. I personally recommend Root Browser by JRummy Apps) and replace the “bootanimation.zip” file with your new one. (If no such file already exists, and you have the default android flashing boot animation, just put the new zip file and the system will use that instead of the default one).

If you used the “just-put” method, use Root Browser to set permissions of the “bootanimation.zip” file to 777 (-rwx-rwx-rwx). [Root Browser > /system/media > PressHold bootanimation.zip > Hamburger > Properties > Permissions > tick infront of X]. If you don’t do this, the system will just revert to the default animation.

Now power off your Linux or restart you Android and voila! Your animation is there. Enjoy!

🙂