Diving into Configurations

There are a number of new features in VTS 3.x, but the biggest change is the new Config system.

If you’re already a VTS user, you’ll be familiar with the Preset system, which allows you to quickly apply a saved group of settings to a new project. Using Presets, you could configure which settings were used to generate the decompiled files, and the finished apk/jar. However, the actual decompile/compile processes were hidden inside the machine. The new Config system peels back the layers, and gives you control over the whole process.

How does it work?

The first thing to say is the level of control is entirely up to you. Not everyone will want the advanced functionality that Configs offer, and that’s fine. On the surface, Configs can work just like Presets. You can configure your settings, and let VTS handle the decompile/compile process as normal.

Adding a new project works just the same as before, either by right-clicking on the Solution name and choosing to add a new project, or by dragging and dropping a file onto the open Solution. You’ll be presented with the Create new project window, which looks a little different, but works in much the same way.

The first tab is the same as always, where you choose the Project name.

The second tab is now the Config page, where can choose which config to apply.


VTS comes with a number of built in Configs, which should cater to most basic user needs. As you can see from the screenshot, the pane at the bottom gives a brief description of the selected Config.

The Options tab allows you to fine tune the Config – set framework tags, apktool/smali version, choose whether to generate Java source, etc. Note, the options displayed on this tab will depend on which Config was selected.


Once you’ve made any changes to the Config, you can use the Save tab to save your current setup as a new Config, for use in future projects.

Then click Ok, and create your Project. So far, not so different from Presets. For a lot of users, this level of customisation is all that’s needed. But if you want more, this is where the power of Configs really comes into play.

The power of Configurations

Configs allow you to control exactly what happens during the decompile, compile and push process. To understand this, we’ll first look at how Configs work.

Each Configuration consists of four so called Scripts. A Script is basically just a list of commands, or as they are named in VTS: Modules. All modules handle a very specific task and can be added to, or removed from, the script. Let’s take a closer look.

To access a project’s Config, right click on the project and choose Properties. You’ll be present with the following:


The main pane is the Active script modules one. This shows which modules are currently included in the selected script. You can switch between scripts using the dropdown menu in the top right


Clicking on a module in the Active script modules pane gives you a brief description of what the module does in the Module description (top right) pane, and any relevant options in the Module settings (bottom right) pane.

You can use this to alter the settings for individual modules. In the example above, you can change which framework tags are used, or which version of apktool. You could also edit modules in the Build or Push scripts:


Here, we can see where to change the push path for the compiled binary – app, priv-app etc.

To change the order of modules, you can just drag and drop them. To remove a module, you can either right click it and choose delete, or left click on the module and in the Module settings pane and uncheck the IsEnabled option. Disabled modules will appear grey.


To add a new module, click the Add module button at the bottom to open the module drawer.


Just drag your required module to where you want it in the script. We’ll have a look a bit later on how some of these modules can be used to streamline the workflow.

The Configuration window at the top shows which Config is currently active for that project. You can assign as many Configs to a project as you want, but only one will be active at any time. Clicking on the dropdown arrow will show 3 things: the list of assigned Configs; all available Configs; and a list of other projects with their assigned Configs.


This allows you to quickly assign another Config to the project. Or, if you’ve made some changes to another project’s Config, and you want to apply those changes to this project too, just find that project in the list and click on its Config. This saves you having to make the edits all over again. The currently active Config is also displayed in brackets at the end of the Project name in Solution Explorer:


There are 2 ways to view the script, either the default Module view, or as an XML script. You can click the buttons along the bottom tab strip to switch between them. The Advanced tab lets you change the name of the compiled binary.

Custom Configurations

So it’s all well and good being able to edit a project’s Config, but what if you want to use that same Config setup for other projects? Sure, you could create the new project, and then apply this config to it. But wouldn’t it be easier if you could make your own custom Configs that show up in the Create new project window? Well, you can, using the Configuration-Manager button in the top right corner. Clicking on this will open the config manager window.


Here you will see a list of all the Configs. Clicking on the name of one will show the description, and give you option of duplicating it, deleting it or restoring it to its default condition – useful if you managed to mess something up while trying to edit it (note, this will only restore the original Configs that come built-in to their default setup, it won’t restore your custom ones. If you mess those up, it’s back to start for you).

Expanding the Config will allow you to edit the scripts, same as we’ve seen above.


So you could either just edit one of the built-in ones, or duplicate one of the existing ones, tweak it to your liking, and rename it.

Just to give an example, here’s a screenshot of my Config list.


Why so many? Well, I have different configs for each framework tag, as well as for each push path – priv-app, framework, system/app etc. This way, I don’t have to keep changing these for each project; I just choose the appropriate config when adding the project.

But the modules allow for even more customisation than that.

The power of Modules

So, we’ve seen how to access the list of available modules. I’m going to use a couple of my modifications to give an idea how much control the modules give.

Custom binary output paths

As you know, compiled binaries get placed in the Binary folder of the Project folder in Documents/VTS. But wouldn’t it be handy if they could all be placed in one location, so they can be bulk added to your rom/zip without having to find each one individually. Well, with the Copy files module, they can be.

Let’s see an example:


In this case, I’ve added a Copy files module to the end of the Build script, which puts a copy of the compiled binary in a folder of my choice. You can set this folder path to wherever you want. A copy of the compiled apk still goes into the project’s Binary folder as well.

ADB commands

Anyone trying to work with HTC Sense 6 will have noticed that after reboot, the ADB connection needs restarting manually before the phone is recognised again.

I’ve added 2 Execute ADB command modules into the Push script, kill-server and start-server, which will automatically restart the ADB server for me whenever I push a compiled binary, saving me the effort of doing it manually.


ADB shell commands

Another common problem is the force close you get when pushing SystemUI.apk, or framework apks/jars to an active system. I got around this issue by using an Execute remote shell commands module, after the Mount /system via ADB module:


In the Module settings pane, I added stop; start in the Commands field; this stops the shell before pushing the binary, and restarts it afterwards.

You could replace this module with an ADB command module, using the command Reboot to reboot the system instead.

Looking again at the screenshot of my Configs, you can see that there seem to be duplicates e.g. m8 sense6 priv app [stock] and m8 sense6 priv app shell [stock]. I have created Configs with and without the Execute remote shell commands module, and I can choose the appropriate one when adding a new project.

Existing solutions

As you can imagine, the Config system is very different to Presets under the hood, so Solutions created using VTS 2.x are not directly compatible. However, Diamondback has created an Upgrade path. When attempting to open a Solution from VTS 2.x, you will be presented with the following screen


For each project in the solution, you can choose which Config to apply. Obviously, if you’re using VTS 3.x for the first time, the only Configs available will be the default ones, which won’t have your framework tags etc. However, you can enter the Configuration-Manager using the button in the bottom left, and create your own Config, as described above.

So that’s it…Configurations in a (large) nutshell. Hopefully you can see the potential of Configs in streamlining your workflow. There are endless possibilities, and we look forward to seeing what users come up with. Feel free to share your ideas on the VTS thread for others to benefit from, as well as suggestions for modules that you think are missing.