[FYT Android Head Units] surfer63:
Last revised: 14 June 2024.

More about Firmware(s)​

This post is valid for FYT uis7862(s) (ums512) and uis8581a (sc9863) units running Android 10 or fake Android 11 or 12.

Contents of a firmware zip:

Note that the firmwares for the uis7862 and the uis8581a only differ on the flashing binary and the kernel zip. Configuration files are the same. Some resellers deliver a firmware that contain two kernel zips and two flashing binaries, as the flashing binary will only work on the hardware it is intended for flashing the correct kernel zip.

Kernel:

6315_1.zip: the kernel zip for the uis7862(s).

6316_1.zip: the kernel zip for the uis8581a.

The 6315_1.zip or 6316_1.zip zip file contains all "standard" Android software, drivers and apks. It also contains the the boot.img; the system/vendor/oem partitions and a few other things. This 6315_1.zip for the uis7862 "should" be interchangeable between all 800x480, 1024x600 and 1280x720 models. The same for the 6316_1.zip for the uis8581a. Special resolutions come with specific lcdconfig.txt files.

The binaries that do the flashing of the firmware:

lsec6315update for the uis7862(s)

lsec6316update for the uis8581a.

These are the binaries that do the flashing of the firmware, optionally install a boot image or boot animation, optionally run scrips from the lsec_update folder after the flashing process itself has finished. These binaries can also be used to only flash a boot image, boot animation, or run scripts.

AllAppUpdate.bin: Special zip file that contains all FYT apps (This can be (un)packed with any (un)zipper, but I prefer 7-zip). This file also contains special files with reseller specific configs. This one is only interchangeable between the same reseller-id, unless you change that reseller-id or use the scripts from post #3, bullet #4.

config.txt: file comparible to the build.prop which can contain additional properties.

oem: (OPTIONAL) Folder containing some additional apps. These are not automatically installed, but can be found in folder /oem/oem in your internal memory (internal SC card called USB) via the internal FYT file manager. Do not confuse this with the oem partition itself where the AllAppUpdate.bin will be installed to. So it is a folder oem inside the /oem partition, therefore: /oem/oem. I use this folder upon flashing to add some of my preferred apps that I want to have available, but not directly installed.

vital-app (OPTIONAL): apks that are inside the vital-app folder inside the AllAppUpdate.bin are treated as apks to be installed AFTER the normal flash. So if a flash has been executed, and your system reboots, it will perform an "update". That is that it will at that moment install the apks in the folder vital-app.

updatecfg.txt: Contains instructions for the flashing process

Stm32ud.bin: (OPTIONAL) binary to flash the MCU

GD32_E230_64K_Flash.Hex: (OPTIONAL) the hex file that contains the MCU firmware itself. These are very limited cross-compatible. do not flash these if your do not know exactly what you are doing.

I. (Factory) Firmwares

Mekede Software Download Previous: Mekede Support site

Joying

T'eyes: CC3 | SPRO | CC2+ | General/All

Sinosmart (approx. April 2023)

(Please share official (!) download links for other resellers so I can add them here).

* Modded Firmwares:

Mario Dantas' modded firmware (MD-Edition). (This is an optimized kernel, not a complete firmware.)

My modded kernels.

PeaceOS - A modded application layer by @LLIyT_HuK. He changed the look & feel of almost all apps and added expanded functionality to the SystemUI.

See for compatibility between firmwares the below header "Compatibility between firmwares".

==================================================================================

Some commands that can be put inside updatecfg.txt

twipe_all # Wipe entire system.
twipe_data # Will wipe data partition (but not /sdcard, internal memory). Wiping the /data partition will wipe all config, all 3rd party apps and updates of system apps. This is the same as a "reset to factory defaults"
twipe_cache # Will wipe the cache of the apps thereby removing the temporary files that are stored for those programs.
twipe_sd # Will wipe internal memory /sdcard (but not the data partition)
dellapp # Remove all 3rd party apps
make_updates # Make an upgrade U-disk boot file
test # test unit and firmware before flash

Some properties that can be put inside config.txt. Say you live in Brazil and you want your locale settings immediately on Brazil, you can add that. As a second example we take a "Tesla style" unit which is actually a rotated horizontal unit. You see that we specify 0 from the rotation. This is because android is normally for portrait like screens. Our landscape models have a value ro.sf.swrotation=90 decrees as they are actually 90 degrees rotated. A Tesla style unit therefore is again 0 degrees and sometimes 180 degrees.

ro.product.locale = pt_BR
ro.sf.swrotation=0

Or you want to improve the microphone function a little, you can add or modify the following lines:

persist.sys.zlink.mic.vol=9.9
persist.audio.mic.senstivity=1
persist.btmic.gain=10
persist.btspk.gain=7

If you decide to download a 4pda Russian modded firmware, make sure you remove the settings from this config.txt file that makes this a Russian firmware (unless you are Russian, but in that case you probably would not be here).

28-05-2023: I added two scripts in post #3 under bullet #4 to let you flash any AllAppUpdate.bin to your uis7862(s) or uis8581a unit.

II. AllAppUpdate.bin

The AllAppUpdate.bin is actually a password protected zip archive. You can use any zip, but preferably 7-zip for your platform (Linux, MacOS, windows) to create, modify or extract it.

Specifications: zip format, non-compressed (store), password 048a02243bb74474b25233bda3cd02f8

Unzip is simple: you only need to specifiy the password.

When (re)creating a new AllAppUpdate.bin, make sure you follow the specifications. (like for example from inside a folder "AllAppUpdate" from an unzipped AllAppUpdate.bin.

When using zip you can do "zip -r -0 --password 048a02243bb74474b25233bda3cd02f8 ./AllAppUpdate.bin *".

When using 7zip you can do "7z a -r -tzip -m0=Copy -p048a02243bb74474b25233bda3cd02f8 ./AllAppUpdate.bin *".

Inside this AllAppUpdate.bin you will find all FYT based apks and libraries and next to that also two other files: fyt.prop and skipkillapp.prop.

The fyt.prop is identical to the build.prop but gives the option to add extra properties or replace/modify properties in the build.prop. And the fyt.prop contains the ro.build.fytmanufacturer=<xy> and the ro.fyt.uiid=<z>. This is in 90% the only distinction between the several firmwares.

The skipkillapp.prop contains apps (package names) with values from -15 to 15.

In the old Sofia-3GR and PX5 GYT units, the packages not mentioned in this list would be killed when going into "deep sleep".

Nowadays on the sc9853i, the usi7862(S) and uis8581 and 7870, this is a "Out of Memory" configuration file, meaning that when memory resources get low, applications with higher numbers get swapped out first. Apps with the lower numbers -13, -14 and -15 will be swapped out last. So if you want DAB-Z and Tasker to be kept in memory as long as possible, you could use.

com.zoulou.dab = -10
net.dinglisch.android.taskerm = -10

(I would suggest not using values like -15, -14, -13 to make sure you do not really interfere with the real system apps).

And then you need to add this file (again) to your own AllAppUpdate.bin

NOTE: In the previous version for the sc98531 you had the Allapp.pkg. You could put one or a few apks in there and it would simply only install/overwrite the apks inside that Allapp.pkg. The AllAppUpdate.bin will always completely erase the FYT apks on the oem partition. This means that you either need a full AllAppUpdate.bin with your (modded) FYT apk(s), or (advised) use the 7862lsec.sh script approach to only add/overwrite/remove one or a few FYT (modded) apk(s).

NOTE 2: In the "main server" apk com.syu.ms, there is now inside assets/property an new file called unkill_app.txt. I "think" that file now contains the apps that should not be killed upon going into sleep mode. I still don't have my unit and I am actually not interested at all in "unkilling" apps, but it might be useful to test with this file.

==================================================================================

III. The 6315_1.zip or 6316_1.zip

Again: the 6315_1.zip is the kernel for the uis7862. The 6316_1.zip is the kernel for the uis8581a.

(Inside also "III-a. More details about the files inside the 6315_1.zip/6316_1.zip and how to decompress and unpack/"open" them" and "III-b. Recompress uncompressed images from the 6315_1.zip/6316_1.zip to squashfs format for small (!) and easy access. (Not for flashing.)")

The 6315_1.zip/6316_1.zip contains the "standard" Android software for this unit. This is more or less what every "plain vanilla" Android 10 release will contain, with hardware drivers and kernel modules and "the basic Google apks" , but without additional unit application layer apks like the launchers, radio, music player, etcetera.

Note: Mentioning that this is "standard" Android is actually wrong. FYT modified the USB and bluetooth stack. In effect: they crippled it to only allow the USB and BT devices that they consider "allowed".

Note 2: They also added drivers to this "plain Vanilla" Android to support their own hardware, mostly through the MCU.

This 6315_1.zip is theoretically identical for all FYT uis7862 units and can therefore be used on all FYT uis7862 units. This 6316_1.zip is theoretically identical for all FYT uis8581a units, apart from T'eyes units. (DISCLAIMER: Experimenting with this falls under your own responsibility).

You can unzip the 6315_1.zip or 6316_1.zip and replace the boot.img (and root it) or modify the install script in "META-INF/com/google/android/updater-script", and then rezip it.

All the other files in the zip are system signed files, which means that you can further unpack them, but not modifiy and recreate as you will never get the signing certificates from FYT.

Other files inside the zip are mostly used to create and install the necessary partitions where the system software and Android software is installed to.

III-a. More details about the files inside the 6315_1.zip/6316_1.zip and how to decompress and unpack/"open" them

You will find for example the system*, vendor* and other "pairs of three" files. Next to these files you will see a number of bin files including the u-boot files, which are the bootloaders. You can consider these u-boot files like the BIOS on older, or UEFI on newer pcs.

As example we look at the system.new.dat.br, system.patch.dat and system.transfer.list files. This set actually contains the system partition. The system.new.dat.br is a brotli compressed image. The patch files can contain patches and is implemented after the system.dat (but on our firmwares always empty). The transfer.list contains the "blocks" on how the system partition should be created.

Let's unpack such a set of files.

First we need to "brotli decompress" the system.new.dat.br (note that this binary doesn't show output and takes quite long).

brotli -vd system.new.dat.br -o system.new.dat

Now we need sdat2img to convert our created system.new.dat "sparse data image"(1) into a "disk image file"(2) being system.img. Note that sdat2img is a python script, so we need python as well (standard on linux, unix and MacOs).

sdat2img.py system.transfer.list system.new.dat system.img

On linux/MacOS we can now easily "mount" this system.img image file and check the contents:

mkdir system
sudo mount -o loop system.img system
ls -Rl system

(1) sparse image: To make the images smaller, and to reduce transfer time, Android generates system.img, vendor.img and other img partitions in sparse format. The image is split into chunks of multiples of 4096 bytes. Any chunks that contain no useful data are marked as "Don't care" and no data is sent.

(2) disk image file: A disk image (file) is a type of file that contains an exact copy of a certain disk or partition. On Android (and linux) these are mostly ext4 partitions/disks but can also be Fat32/squashfs (compressed, often used in older Androids)/DMG (MacOS, also for installers)/NTFS, etcetera.

III-b. Recompress uncompressed images from the 6315_1.zip/6316_1.zip to squashfs format for small (!) and easy access. (Not for flashing.)

So you have your brotli compressed system image (system.new.dat.br) of approximately 500MB, which you can't use at all in this state.

And you have uncompressed it to a system.img of 1.3GB (see previous section), which you need to "mount loop" to view it contents.

Can I do this differently?

Yes, you can with squashfs (explained for linux and/or MacOS), for which you first have to install the squashfs tools.

Mount your system.img like mentioned above and then create a squashfs image.

sudo mount -o loop system.img system
sudo mksquashfs system system.img.sqsh
sudo umount system

Now you have a squashfs compressed system image of about 550-600 MB instead on an uncompressed system.img of about 1.3GB.

To examine its contents you mount it like

sudo mount -o loop system.img.sqsh system

==================================================================================

IV. Some info on partitions

This info is referring to the partitions being created from within the 6315_1.zip and 6316_1.zip. Note that T'eyes does it slightly different.

Starting with Android 10, Google introduced "dynamic partitions". Below a quote directly taken from the Dynamic partitions page.

Apart from the /oem partition and a few others, the /system, /vendor and /product partition are read-only. In earlier FYTs, you could use the lsec script to make them read-write and then modifiy content, add/remove files/apks, etcetera from these partitions. The big disadvantage for modders with these new dynamic partitions is that you can't make them read-write anymore.

V. The lsec_updatesh folder, lsec6315update/lsec6316update binary and 7862lsec.sh/8581lsec.sh script (and what about "universal" scripts)

The flashing process consists of a number of steps:

flashing the core/kernel software (6315_1.zip for uis7862(s) and 6316_1.zip for the uis8581a)

flashing the unit applicable apps and libraries plus initial properties (AllAppUpdate.bin)

scripts that do "post flash" activities.

The "flashing" executable/binary also starting the scripts, is the lsec6315update file on a uis7862(s) and lsec6316update file on a uis8581a.

A USB-stick used to execute a script on a uis7862(s) or a uis8581a should contain:

lsec6315update (uis7862(s))
lsec_update/7862lsec.sh (uis7862(s))
lsec6316update (uis8581a)
lsec_update/8581alsec.sh (uis8581a)
"stuff that needs to be copied/moved/installed"

Practical applications:

Making patches, an alternative to creating the AllAppUpdate.bin file by simply specifying an apk (or so) in your script.

Delete unnecessary files or applications (who uses the calculator app?), or overwite/change files like the fyt.prop, config.txt or others.

Set properties that normally require root/admin rights.

Create a nearly flashable backup using this script (to be added) by creating backups of your FYT apps and config files and immediately zip them to an AllAppUpdate.bin and add some more necessary files.

Creating backups of your partitions using the dd command. This can be handy on a device for which you do not have a firmware yet as backup.

Rooting your unit, also if you do not have a firmware from your supplier.

Make a "modded" ROM by simply doing all kind of modifications after the "normal" firmware flash using the 7862lsec.sh script on a uis7862 or use the 8581alsec.sh script on a uis8581a. Note: 99.9% of the time these scripts are identical as you work on the application layer.

Flash a new config.txt to your unit: Simply copy your modified config.txt and the lsec6315update or lsec6316update binary onto a clean USB-stick.

For more info on writing scripts, see below.

==================================================================================

Creating your own lsec script to copy/replace a modified FYT apk.

If you want to create your own script to flash a modified FYT apk to your unit to replace an existing FYT apk, you can use the following steps.

Below is described for a uis7862 (ums512) and for a uis8581 (sc9863a). These units are compatible.

On your USB-stick you need to have the following files.

lsec6315update (binary)
lsec6316update (binary)
lsec_updatesh (folder)
7862lsec.sh (shell script)
8581lsec.sh (shell script)
OEM_APP (folder)
190000000_to_be_replaced (folder of the apk)
190000000_to_be_replaced.apk (some apk we want to replace)

Inside folder "lsec_updatesh" you have to create two shell scripts (on Windows NOT with notepad, but a good ascii editor).

The binary "lsec6315update" and shell script "7862lsec.sh" are for a uis7862.

The binary "lsec6316update" and shell script "8581lsec.sh" are for a uis8581.

(You can do the same for two other type of FYT units: the "lsec6521update" and "lsec.sh" for a sc9853i. And the "lsec6523update" and "lsec.sh" script for a 7731. Note that these two units are also compatible. I have created scripts (for other purposes) that contain 4 binaries and 3 scripts, as the lsec.sh script is the same for the sc9853i and the 7731).

Note that for replacing FYT apks, the 7862lsec.sh script and the 8581lsec.sh script can be identical as they use the same firmware when it comes to AllAppUpdate.bin.

Let's say we have an apk called 190000000_to_be_replaced.apk.

The following is for ALL 7862 and 8581 FYT units, but not T'eyes units. Those T'eyes guys do it differently (and let you pay for a lot of things).

On ALL the other non-T'eyes FYT units, the apks are installed in folder "/oem/app" inside their own folder "190000000_to_be_replaced". In that folder we then copy the "190000000_to_be_replaced.apk".

We use the following template for our script.

#!/system/bin/sh

#Remove the current app data/program cache/cache. This is only necessary for some applications, but it never harms
rm -rf /data/dalvik-cache/profiles/190000000_to_be_replaced
rm -rf /data/data/190000000_to_be_replaced
rm -rf /data/dalvik-cache/arm64/*190000000_to_be_replaced*
#
# Copying file to /oem/app
#
cp -r /storage/sdcard1/OEM_APP/* /oem/app/
#
# Updating folder/file access rights
#
chown -R 0.0 /oem/app/190000000_to_be_replaced
chmod 755 /oem/app/190000000_to_be_replaced
chmod 644 /oem/app/190000000_to_be_replaced/190000000_to_be_replaced.apk

If your script needs to do other things you can take a look at some of the scripts in my github repository.

See this post #228 for more info about the "The lsec_updatesh folder and lsec.sh script" as it was used on the SC9853i (and now again on the sc7731 (uis8141e).

==================================================================================

VI. Compatibilty between uis7862 (ums512) Firmwares

As mentioned under the relevant topics above:

The 6315_1.zip should be identical between all uis7862(s_ units. The same is valid for the 6316_1.zip for usi8581a units. Of course newer releases can contain updates, etcetera.

The AllAppUpdate.bin is application wise compatible between same aspect-ratio compatible screens like 800x480, 1024x600, 1280x720. The great separator here is the ro.build.fytmanufacturer property. If you flash an AllAppUpdate.bin from a Mekede firmware (with id=1 or id=116) to a Joying (with id=43 and lately also id=1) or vice versa, you might get a perfectly working unit, but a big yellow bar in the top of your screen mentioning that the MCU is incompatible. However, due to real differences in MCU firmware (which is in general not compatible), you might also encounter serious issues. Not because the software is incompatible, but because it behaves differently on another MCU.

The optional MCU firmware. This is definitely NOT compatible!

So what can you do when seeing upgrades from other suppliers?

You could take the 6315_1.zip (of 6316_1.zip for a usi8581a) if it "seems" to be (far) more up-to-date than your currently installed system (/system, /vendor, /product). You can copy it to a clean USB-stick and copy the lsec6315update binary onto the USB-stick and flash it to your unit. In case of doubt, always ask

If it contains a (much) newer AllAppUpdate.bin, you could unzip it, find the fyt.prop and update the ro.build.fytmanufacturer id to the id in your original firmware/fyt.prop and repack the AllAppUpdate.bin. Then you copy to a USB-stick:

the just (re)created AllAppUpdate.bin.

an "update.cfg" containing "twipe_all (preferred) or "twipe_data".

the original or a modified "config.txt" onto it.

the lsec6315update onto it (or the lsec6316update for a usi8581a).

In case of questions, always ask.

Another option will be described here, but not ready yet

Some remarks about current "seemingly different" FYT units.

The uis7862 (ums512) versus the sc9863a (uis8581a) : These units are compatible on AllAppUpdate.bin, but note the ro.build.fytmanufacturer. That is also of importance here. They are NOT compatible on kernel/core level so you can't flash the 6315_1.zip (uis7862) or 6316_1.zip (uis8581a) to each other. However, with above mentioned measures you could flash a newer AllUpdate.bin from a uis7862 onto a uis8581a, or vice versa.

The sc9853i versus the sc7731 (uis8141e): Also these units are compatible on AllAppUpdate.bin, but note the ro.build.fytmanufacturer. That is also of importance here. They are NOT compatible on kernel/core level so you can't flash the 6521_1.zip (sc9853i) or 6523_1.zip (sc7731) to each other. However, with above mentioned measures you could flash a newer AllUpdate.bin from a sc9853i onto a sc7731, or vice versa.

==================================================================================

VII. FYT firmware types over the different CPU configurations

To be written.

VIII. Flashing a Full firmware, an AllAppUpdate.bin or a new system/kernel/core from another reseller

To start with: If you do not have a T'eyes unit, do not flash T'eyes firmware. T'eyes uses all kind of paid extensions, which you can only activate by paying and registering your T'eyes' unit id (which you do not have of course because you do not have a T'eyes). Next to that: If you do not use their extensions, the "normal" programs like Google Voice/Assistant can be blocked.

Before flashing:

First heck the FYT reseller id of your firmware. Install a good file manager like Total Commander. Go to /oem/app. In that folder you will find a file fyt.prop (In Total Commander, right-click the file, "Open As" -> Text".

Inside this file you will find a line with ro.build.fytmanufacturer=43, where the number is the id of the reseller id of your unit (43 is Joying). Write down that number!

Inside this file you will find a line with ro.fyt.uiid=<x>. Write down that number as well!

Another option to get all this info is running my HWGet_Info.apk on your unit which will immediately show some FYT properties and give a zip with a lot of info. This zip file is completely anonymous and does not contain any user data!

Inside that same folder /oem/app you will find the file config.txt. Copy it to a USB-stick and save it carefully. In case you still have the original firmware of your supplier, you can find inside that zip/rar file the same config.txt. Make sure your have the config.txt belonging to your unit!

If you copy a firmware from another reseller, or a modded AllAppUpdate.bin, this config.txt may have more or optimized options. Some options from the config.txt from your unit must be copied into the config.txt of this new firmware before flashing.

The options that need to be copied from YOUR config.txt into the new config.txt:

Find the line ro.sf.swrotation=xy (values 0, 90, 180, 270) . Use the value from YOUR firmware in the config.txt for this new firmware.

find the line with sys.fyt.bluetooth_type=x. The value is normally 0 or 1, but can sometimes even have other values. Use the value from YOUR config.txt for this new firmware.

What option to flash do I have:

There are 3 options to flash:

Full firmware

System/kernel/core only: this is only the 6315_1.zip

Application software: this is only the AllAppUpdate.bin (plus some additional files).

Actually you have a few more options:

You can flash a new bootanimation.zip and/or boot logo to your unit by copying the lsec6315update binary and your bootanimation.zip and/or your LOGO.bmp onto a clean USB-stick (This does not work on Teyes units unless you use the Vincent Vega mods from @gordgelin).

You can flash a new config.txt to your unit by only copying that config.txt and the lsec6315update binary onto a clean USB-stick.

Create the USB-stick for flashing:

For a System/kernel/core only flash, copy the lsec6315update and the 6315_1.zip to a clean fat32 USB-stick. Connect it to your unit and flash it.

For an Application software flash, copy the lsec6315update, AllAppUpdate.bin, updatecfg.txt and config.txt to a clean fat32 USB-stick. Connect it to your unit and flash it. Note the above mentioned fyt.prop and config.txt

For a Full firmware, copy the lsec6315update, 6315_1.zip, AllAppUpdate.bin, updatecfg.txt and config.txt to a clean fat32 USB-stick. Connect it to your unit and flash it. Note the above mentioned fyt.prop and config.txt

During flashing, let the software do its job and don't start playing with buttons, knobs, air conditioning, etcetera. After reboot wait 3-8 minutes more for some post-flash steps.

IX. If everything goes wrong and your unit ends up in a boot loop or doesn't get past the boot logo.

- Download a fresh firmware from your reseller.

- Unzip it to an SD-card/USB-stick (as normal)

1) Simple solution: Put the USB-stick/SD-card in your unit and wait till it reboots and starts the flashing.

2) More complex softbrick:

Put the USB-stick/SD-card in your unit

"push" the Reset (RST) with a paperclip or something like that.

When the boot logo appears, reset the unit again. Now the flashing process should start.

3) Most complex softbrick:

Put the USB-stick/SD-card in your unit

"push" the Reset (RST) with a paperclip or something like that.

When the boot logo appears, reset the unit again. Now the flashing process should start.

Sometimes you need to reset up to 3x times.

If after 3 times resetting the flashing still doesn't start, your recovery partition is damaged.

(or use your self created backup using the script from post #4)