1. About
    1. Welcome
    2. Project News
    3. Architecture
    4. Community Wiki
  2. Get Involved
    1. Get the Code
    2. Mailing Lists
    3. Contributing
  3. Virtual Device
    1. Building
    2. Running
  4. Server Components
    1. Install
    2. Configure
  5. Client — Android
    1. Build & Install
    2. Using
  6. Client — iOS
    1. Build & Install
  7. Wire Protocol
    1. Protocol Description
    2. Extend and Build

Installing and Running the VM


In the build-svmp.sh script at the “Images to Build” screen, choose the “ovf-vbox” option. This will initiate a preset build with 2 virtual disks attached via a SATA controller in the resulting VM appliance.

Import the resulting ${SVMP_AOSP_ROOT}/out/target/product/svmp/svmp_vbox.ova file via the VirtualBox File menu.

Note for laptop users: VirtualBox will pass ACPI data from the host into the VM by default. If you start the VM while running on battery, VBox will incorrectly pass a “sleep” command to the VM causing it to immediately shutdown right after it’s finished booting. To correct, either plug in to the wall or configure VBox to not do ACPI pass-through.

Note 2: You can add a serial port device to the VM to get access to dmesg and init console log. If you attach an interactive pty to that serial port, you can also get a local root shell.


In the build-svmp.sh script at the “Images to Build” screen, choose the “ovf-vmware” option. This will initiate a preset build with 2 virtual disks attached via a SCSI controller in the resulting VM appliance.

Import the resulting ${SVMP_AOSP_ROOT}/out/target/product/svmp/svmp_vmware.ova file via the VirtualBox File menu.


There is not yet an appliance build for KVM, so a slightly longer approach is required.

  1. In the “Image to Build” screen of the build script, choose “qcow2”.
  2. At the “Drive Type” screen, choose the appropriate model for the drive controller type you will be using. For virtio para-virtualized disks (recommended for best performance), select the “vdx” option.
  3. Select “all-in-one” or “separate” system and data disks per your preference

This build will create one or more qcow2 files in ${SVMP_AOSP_ROOT}/out/target/product/svmp/

Convert android_system_disk.img and android_data_disk.img to QCOW2 format using qemu-img.

OpenStack (with KVM compute nodes)

  1. Build QCOW2 virtio images as per the KVM instructions above
  2. Upload the resulting images to glance.
  3. Create a cinder volume based on the android_data_disk glance image. This will become the master copy that every new user’s persistent data disk is cloned or snapshotted from.
  4. Launch a new VM instance from the system disk image. Use a flavor that has at least 1GB for the root disk and 1GB of RAM. Ephemeral disk can be left as zero.
  5. Configure the security groups as needed. See below.
  6. [Optional] Connect a VM to the “gold image” volume made in step 3 and install any applications and configure any settings you’d like all users to have (keep in mind the entire environment will be cloned). Detach the VM when you’re done.
  7. Create a cinder volume for each user account using the “gold” snapshot from step 3 as the base. Attach this new volume to the now running VM.
  8. Hard Reboot the VM instance so it can find the now attached data volume.

Security Groups

Openstack security groups can be used to effectively create host-based firewalls for the SVMP instances. If you use this feature, these are the ports that must be allowed access.

SVMP Server


Debugging (ADB and SSH shells)

Data Disks

SVMP 1.5.0+

In SVMP 1.5.0 and newer, the data disk is automatically created from scratch by the build system based on the settings in the BoardConfig.mk and image_build/svmp_*_image_layout.conf files in device/mitre/svmp/.

Also in 1.5.0, the cache partition has moved from data disk to the system disk. For backwards compatibility, the data volumes created will still contain a partition in the slot previously occupied by cache, so old data volumes will still work on newer VM versions.

To customize the data partition size simply alter the value (in bytes) of BOARD_USERDATAIMAGE_PARTITION_SIZE in BoardConfig.mk to something of your choosing. If necessary, also adjust the “num_lba” value in the layout.conf file so to sufficient size for all the contained partitions.

SVMP 1.4.1 and below

The default data disk created by the build system and output as android_data_disk.img is a 5GB disk with 4GB assigned to /data and 1GB to /cache.

Several alternate images in a variety of sizes can be found in ‘device/mitre/svmp/data-disk-blanks’ named by the size of the /data partition. All contain a 1GB cache partition.

If the prebuilt images don’t fulfill your needs you can create a custom blank data disk with the following steps.

  1. Create a sparse file of the desired size

    $ dd if=/dev/zero of=android_data_disk.img bs=1 count=0 seek=
  2. Create partitions within the image for /cache and /data. The /cache partition should be approximately 1GB and /data is configurable, but should be at least 1GB itself.

    $ fdisk android_data_disk.img
    Command: n
    Select: p
    Partition number: 1
    First sector:
    Last sector … or +size{K,M,G}: +<SIZE of /data>
    Command: n
    Select: p
    Partition number: 2
    First sector:
    Last sector:
    Command: w
  3. Scan the image and add the new partitions to /dev. Note the loopXpY names the first command for the next step.

    $ sudo kpartx -l android_data_disk.img
    $ sudo kpartx -a android_data_disk.img
  4. The two partitions should have appeared in /dev/mapper called something like loop0p1 and loop0p2 and should have been printed out by the kpartx -l command.
  5. Format the two partitions. Replace the device names in the example with the real names from step 3.

    $ sudo mkfs.ext4 /dev/mapper/loopXp1
    $ sudo mkfs.ext4 /dev/mapper/loopXp2
  6. Unmount the loopback devices

    $ sudo kpartx -d android_data_disk.img

For future consideration, all this could probably be scripted up nicely with libguestfs.