[FYT Android Head Units] surfer63:
Very high level overview of modding a Launcher.​

Modified: 14 Jun 2024

This post will describe how to modify the layout(s) of a launcher (or another APK) and mentions the minimum tools you need for this. It is a completely command-line based approach for which you preferably need a (simple) syntax-highlighting editor. This can be done on Linux, MacOS or Windows.

Note that below instructions only describe the most basic changes like I did for the launcher34.

Requirements:

apktool -> Download for your platform. If on Linux you can install it from your distribution package manager)

java -> Download for your platform. A JDK is sufficient. You do not need the SDK (development kit)

a syntax highlighting editor -> Notepad++ is excellent for Windows. Linux and MacOS have a huge collection of syntax-higlighting editors (I use mousepad). Sublime-text (multi-platform) is also excellent, but after a trial period you actually must purchase a license. And otherwise: Google for this search term, read the articles and find your preference.

Optional:

If you want to sign your modded launcher (or other apk), you need apksigner for windows. Install "signapk" for Linux via your package manager. Note that signapk also needs java, but that will be installed if not available.

A "left-right" comparing tool to compare the original code/XMLs with your modified code/XMLs. For example meld for Linux; for Windows Total Commander, or whatever has your preference. This is not necessary, but can be very handy. You can also use the "diff" tool with it's extenesive parameter set to compare folders, files, contents of folders/files, etc. The FC tool in windows can do the same but only file by file, like "FC file1 file2".

Note:

Every firmware, whether it is for our units or for Google Pixels, Samsungs, Motorolas, etcetera have a central framework.apk or framework-res.apk.

Our firmwares do have that framework-res.apk in the AllAppUpdate.bin in /oem/app.

The framework-res.apk contains "res" (= resources) folders with icons, images, values, arrays that are central resources for the firmware.

It is best to import them if you have a new firmware and you are a modder. Every firmware "can" come with new resources, but mostly this is when a new firmware is released for the first time.

Anyway: It is better to import it before doing any (de)compilation with apktool. But if you don't get errors when recompiling your modified apk, you are fine. If you get errors when recompiling the app about "missing ....." you should import the framework-res.apk.

apktool if <path_to>/framework-res.apk

You do this only once for a new firmware (or apktool installation). Not for every apk.

Unpack the apk:

We use apktool for this and take the launcher34 as example.

apktool d 190001034_com.android.launcher34.apk

The "d" for "decompile".​

This will create a folder "190001034_com.android.launcher34" containing the following relevant folders (there might be more, but we don't care).

"res" and "smali" are main folders. Below "res" a number of folders exist. Below smali also a number of folders exist.

res - these are the xml files/resources we will edit. Presented as graphics and xml files

drawable - graphics files in png and sometimes webp format.

drawable-1024x600, drawable-1280x720, etc - resolution specific image files.

layout - xml files specifying how elements are displayed on the screen

layout-1280x720., layout-2000x1200 - resolution specific

mipmap - application icons (also multiple resolutions)

values - text strings for editing translation, arrays for dropdown options, etcetera.

smali - decompiled code. Smali can be considered as the assembly language for java and kotlin.

XML layout

For the Launcher34 I only focused on two xml files (per resolution)

res/layout-1280x720/custom_layout_one.xml

res/layout-1280x720/item_app_list.xml

res/layout-1280x720/item_left_app_list.xml

The "custom_layout_one.xml" is the "home screen" and the "parent" and can/does contain "child" xml layouts.

The "item_app_list.xml" determines the size of the app icons and app names (size set to 0: no names) inside the bottom app bar. These are the xml files I modified.

The "item_left_app_list.xml" is the "hot seat" recent apps list. I did not "touch" this third one, but mention it here so you understand what it does.

These XML layouts (both parent and children) can also contain further child XMLs describing buttons that behave differently when not-active or tapped.

XML, like other "markup languages" like HTML, use <!-- --> as begin-end remark statements. Everything between these <!-- and --> characters is not interpreted, but treated as "comments".

In the XMLs for this launcher34, I do not separate "things". Below you will find the 1280x720 custom_layout_one.xml with the 3 different layouts I created.

The "<!-- Big Window with only bottom bar-->" is the active layout. The other two are made inactive as "comments" in the xml.

Spoiler content hidden.

Spoiler content hidden.

Note that I try to structure the unreadable/less readable FYT XMLs, to "grouped by and separated by empty lines" XMLs. It helps me ;)

smali

In case of the launchers with the big PIP-window, there is an if-then-else statement in "smali/com/android/launcher34/Launcher.smali". Of course the exact path and file name for other launchers can change, but simply search on "sys.lsec.pip_rect". You will find something like const-string v2, "10 65 1270 620", where the coordinates are absolute values for "top-left x", "top left y", "bottom right x" and "bottom right y".

Another change is the rounding of the corners of the pip window "persist.lsec.radius".

I removed the complete "setWindowLoc()" method and added extra if-then-elese for extra resolutions.

Spoiler content hidden.

In java this smali code would be:

Spoiler content hidden.

(Re)Compile

When you are ready with your changes we need to recompile our decompiled and modified launcher.

We step out of the decompiled launcher folder and specifiy the folder to apktool.

There are two options.

Option a:

This is the simplest but will not always work and certainly not with priv-apps like SystemUI and Settings, but not for Launchers either.

apktool b -c 190001034_com.android.launcher34

The "b" is to (re)build.

The "-c" is to use the original AndroidManifest, which normally gets updated for every compilation. Certainly for real Android compilation,

The "190001034_com.android.launcher34" is the folder containing our decompiled launcher (or other apk).

Option b:

You now sign the apk with the FYT system keys. This is how FYT signs their apks and 6315_1.zip / 6316_1.zip.

You need apksigner, which is part of Android Stuido but can also be installed separately on your OS.

apktool b 190001034_com.android.launcher34

apksigner sign --ks /<path to>/platform.jks "your.apk"

apksigner will ask for the password to sign the apk ("Keystore password for signer #1:"). The password is simply "android" (without the double quotes).

Installation

When you are ready, you can't simply install the apk as a normal apk. You need to install it via an lsec script. Once you have overwritten the original with your MOD, you next installs can be simple installs of the APK as side-load.

Spoiler content hidden.