[One (M8) Themes and Apps] fisha21:
General tips

Working with Sense 6

By now people have found that Sense 6 apks are a little troublesome and it takes a bit of effort to decompile/recompile some of them. The main thing, as Raymond Ebertt stated in his post, is to make sure you are using the most up to date files. There is some conflict about which version of apktool to use, 1.4.2 or 2.0.0. It is complicated by the fact that the public release version of VTS doesn't yet work with apktool 2.0. Either version of apktool will work fine, but both might require a little tinkering with the apk. Now that the new version of VTS is out, it makes things a lot simpler, since apktool 2.x is now supported.

Those people using manual apktool, I would suggest making sure you use apktool 2.0.0beta9 - that's worked me for me where earlier versions of 2.0 failed.

As for smali, I have been using 2.0.3 since Sense 6 dropped, and not had any issues with that.

If you're using VTS, you need to put the updated binaries in the appropriate folders in C:\Program Files (or Program Files(x86))\Virtuous Ten Studio\External. The newest version of VTS ships with apktool 1.4.2 and 2.0beta9, and smali 1.5.2 and 2.0.3, so you shouldn't need to add any additional binaries.

There are also a few special-case apks:

Troublesome apks

You may have found that there are some apks that give you public.xml errors on trying to recompile them. The cause seems to be some broken images in the apk itself, and seem to affect the images used in the Sense 6 themes. You can see which ones they are by opening the apk as a zip archive and looking in the drawable-*dpi folders - the broken images all have a filesize of 0bytes.

The easiest way to fix this is to replace those images in the apk before decompiling it. Once you've done this, the apk should recompile without the above errors.

You can get all the required files from com.htc.resources.apk, but to make things a bit easier, I have zipped up the required files for most of the faulty apks.

You can download them here​

Note that these zips contain compiled 9.pngs, so you need to copy them into the apk before decompiling - they won't work properly if you put them into an already decompiled project.

If there are any problems with the zips, please let me know.

If your apk still fails to compile, just double check all the drawable-*dpi folders and make sure there are no 0byte images. If there aren't, then there is another issue with your project.

========​

Phone.apk. This app often fails to compile due to some issues with strings.xml. Basically, there is a special character (٪) that gets replaced with a normal % on decompiling.

You have 2 options to fix this:

1. use the error log to identify which symbols need replacing (the log will tell you which xml, and which line, needs fixing)

2. grab the fixed files I added to the folder I linked above :D - these are decompiled files, so will need to be placed into your decompiled apk

========​

There is another reason I've found for some apks not to compile. Some of the apks, eg Messages, have issues with apktool 2.0 whereby the package name of the apk gets altered.

If you get an error saying that it could not find resources for package com.htc, you need to check the AndroidManifest.xml - you'll find that package name has been changed to com.htc.

Two ways to deal with this - either re-edit the package name to the original (which can usually be found somewhere further down in the AndroidManifest.xml, or use apktool 1.4.2 to de/recompile the apk. Thanks to [MENTION=4457281]hawknest[/MENTION] for pointing out the cause of this one.

Frameworks and tags

Just a short note on frameworks, since many people seem to misunderstand them. When you install a framework, the resources.arsc is taken out of the file and put inside an .apk file in your C\:<User>\apktool\framework folder, where it essentially acts as a look up table for decoding the resources inside any given apk. By default, framework-res gets installed as 1.apk, com.htc.resources as 2.apk. Go take a look in your installed framework folder, you'll see what I mean.

The reason you need to install frameworks for each Android distro you're using is precisely because of their function as a look up table. Let's say you install AOSP frameworks - great, you can now decompile AOSP apks just fine. But what if you're using a MIUI rom, or Sense, or Touchwiz? These distro variants all contain resources that the stock Android doesn't and so when you try to decompile a Sense apk that has non-standard resources within, the AOSP frameworks will fail. Ok, no problem, install the Sense rom frameworks instead and it'll work just fine. Problem is, when you installed the Sense frameworks they overwrote the AOSP ones. So now, if you want to go to use an AOSP apk, you first need to reinstall those frameworks again. What a pain, right?

This is where tags come in. If you install the frameworks using a tag specific to the Android distro, in the apktool/framework folder you'd see 1-aosp.apk, 1-sense.apk, 1-miui.apk etc. Now, when you're decompiling apks from a particular distro, just use the tag you assigned the frameworks to let apktool know which set of frameworks to use. This way, you can have frameworks for multiple distros installed at the same time.

Just to clarify, all the frameworks from a given distro need to have the same tag. So, for example, your installed frameworks from AOSP would be called 1-AOSP.apk, 2-AOSP.apk, 127-AOSP.apk etc. When you decompile using a tag, you're telling apktool to use all the frameworks with that tag as reference tables for the decompile. If all your frameworks from one distro have different tags, apktool won't find all the references it needs, and you'll get an error about missing resources and a failed decompile.

As for when you need to install frameworks - as I said, the purpose of installing them is to provide a lookup table for decompiling resources. So you really only need a set of frameworks when you're working with something that's likely to have unique resources. This will either be when dealing with different distros - AOSP, MIUI, Sense etc - or when there has been a version change - 4.3 to 4.4, or Sense 5 to Sense 6 etc. If you're working with a Sense 6 build of one rom, say Renovate, and you want to decompile an apk from InsertCoin, you can use the same frameworks for both, since they are both based on Sense 6, and we rarely tend to add new resources to framework files.

Public id's

Public id's are how smali code call on a particular resource. Public.xml lists all the public ids for every resource contained within a particular apk. Pretty much all apks use a public id format of 0x7fxxxxxx, which means that the resource attached to that id can only be used by the apk it is contained in. So, if for example, you're looking in smali and you see the id 0x7f100000. You search public.xml and you see that 0x7f100000 is allocated to type="string" name="app_label". So you know that that bit of smali code is setting the app label. This can also work the other way round - say you have an image and you want to find the smali code that draws it on screen. Find the name of that image and look it up in public.xml. Say it has an id of 0x7f000010. So you just search all the smali for that reference and have a look at the resulting files.

This is true for all apks in HTC roms except for three. Since com.htc.resources.apk, framework-res.apk and framework-res-htc.apk act as central repositories of resources for other apps to use, they each have their own unique public ids so system apps know which one to call a resource from.

framework-res = 0x01xxxxxx
com.htc.resources = 0x02xxxxxx
framework-res-htc=0x03xxxxxx

So, next time you're looking in smali and you see an external reference with one of the above 3 formats, you'll know exactly which framework apk to look in :)

Note: the formats shown above are how they appear in the decompiled public.xml of that apk. When other apps call these public ids in smali, the first 0 after the x is dropped.

For example, say the clock widget wants to use an image from com.htc.resources. In com.htc.resources/public.xml, that image might have the public id 0x02000001. But in the clock widget smali where that image is called, the public id would be given as 0x2000001.