yashsingh1/xdaforums huggingface dataset:
[FYT Android Head Units] surfer63:
When recompiling I asume you got the error:

W: Cant find 9patch chunk in file: "drawable-nodpi-v4/jiu_list_bk.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-nodpi-v4/jiu_d_line.9.png". Renaming it to *.png.

So the jiu_list_bk.9.png is renamed to jiu_list_bk.png, and the other likewise.

That is because they are no 9patch PNGs at all. I do not know if this is a clumsy error from FYT/SYU, or done on purpose to make it harder to alter the BT apk.

I copied the renamed PNGs into the drawable of "some" Android Studio project I had. I right clicked the png in Android Studio and selected the "create 9patch file". That will create a new jiu_list_bk.9.png next to the jiu_list_bk.png I copied in. That newly created one I double-clicked, added some "resize" pixels and saved it again. Same for the other one. These two I copied back into the drawable-nodpi-v4 and deleted the renamed jiu_list_bk.png and jiu_d_line.png. Now it compiles correctly.

To get your classes.dex in, I did an "apktool -s 190043001_com.syu.bt.apk" to not decompile the code. So I simply copied in your AndroidManifest.xml and the classes.dex (and those recreated .9.pngs) and recompiled and resigned. I also had to change your AndroidManifest.xml, which had dos line-endigs (CR/LF), to unix line-endings.

The recompiled and resigned apk simply does not work. If I use the "-c" parameter to use original signing, it will also copy in the original (binary) AndroidManifest.xml. So that doesn't help either as you added the bluetooth_privileged permission to the manifest.

What I did see though is that your classes.dex is 1.5MB whereas the original is 2.2MB. Is that correct?

If your only issue were the 9patch PNGs, not being 9patch PNGs, then please use mine (attached).

I tried all I could, but can't get a correct apk. It installs fine but can't be opened: "com.syu.bt cannot be launched", or something like that.
[FYT Android Head Units] surfer63:
How did you install? Simply double-clicking on it? creating an AllApp.pkg? Use a rooted copy?

It looks very "advanced"
[FYT Android Head Units] gamer765:
Actually figured out my problems were because my OS is 64bit, but i only had 32bit Java installed. Fixed it by installing 64bit Java as well.

Update: Even just decompiling and then recompiling the apk results in a smaller classes.dex. Try it yourself, decompile, then just recompile right away without any mods. Mine is even smaller because I stripped out debug info, but that only saves maybe 0.05MB. The problem might be it needing a signature.

Update 2: When test installing on another android device via adb, it complains about not being able to read the AndroidManifest.xml. Signed it, and on my other device it now complains about shared user ID, but i dont know if Joying is enforcing that. We'll see.
[FYT Android Head Units] Soiski71:
Yes , System shows RDS (at least Here in Finland) info.

---------- Post added at 06:35 PM ---------- Previous post was at 06:18 PM ----------

Installation is just "Double click" . I did not use any AllApp.pkg, just working with this single 190043001_com.syu.radio.apk which I downloaded from your site (your mod.)

I had installed the "2019-09-17-rootedboot_radio_mainserver" version prior so I guess mine is now rooted ...not 100% sure though.

I like you word Advanced...thats what I was looking for, as the stock version....well looks like something from 1990 :)

Hopefully people would test this as much as possible to get feedback from other regions also
[FYT Android Head Units] gamer765:
[MENTION=2550900]surfer63[/MENTION], can you verify on your end if decompiling and recompiling breaks it for you? Would help me determine if it's something on my end or not. And if you get good results, mind sharing the decompiled smali code and what version of apktool you're using? I'm using the latest. I'm already at work so I can't work on this anymore for today. It's strange though because my mods shouldn't cause total breakage. At most it'll crash when you try to pair. I'm thinking apktool is breaking something especially since it's producing much much smaller classes.dex files.
[FYT Android Head Units] surfer63:
You mentioned that you used Zipsigner, meaning that you changed the signature of the apk. Android does not accept the exact same apk with a different signature to update an existing apk. That is a security risk and already forbidden since many android versions.

That is why I asked how you installed it.
[FYT Android Head Units] surfer63:
Sorry, I do not understand.

"decompiling and recompiling" of what?

I used apktool 2.4.0. When "all failed" I switched to 2.4.1 but that didn't work either.

W.r.t. classes.dex size: When compiled against java 7 the classes.dex are much bigger. But I can't really believe FYT/SYU is still using java 7 considered the fact that java 8 is already out of support, although Google is still suing it for the apk compilation.
[FYT Android Head Units] Soiski71:
I getting similar "problems" like Gamer on APKTOOL so that why I needed to resign it. What ever I did on recompailing did not work correctly. As I needed to change also the radio.xml might that have caused it to change "enough" ?

I just installed also the 64 bit version of Java (based on your comment) and looking was my prior java culprit of this.

Did you try install this to your system already?
[FYT Android Head Units] gamer765:
decompile the stock apk with apktool to smali and then recompile it with apktool back to an apk.
[FYT Android Head Units] surfer63:
Just did that and installed it via an AllApp.pkg. It works OK.

apktool d 190043001_com.syu.bt.apk

Got the error message for the .9.png files

Copied my created .9.png files in

removed the renamed .png files

apktool -c b 190043001_com.syu.bt

copied the 190043001_com.syu.bt/dist/190043001_com.syu.bt.apk into an AllApp.pkg

Installed that one.

I hope not that I offend you by typing the below.

As you probably know (or as of now ;)), Android apps utilize code and resources that are found on the Android OS itself. These are known as framework resources and Apktool relies on these to properly decode and build apks (direct quote from the apktool manual). This is valid for a lot of FYT apps as well.

Before I start modifying any FYT apk for a certain firmware version, I always first import the framework-res.apk.

apktool if framework-res.apk

which replies something like

I: Framework installed to: /home/<my_username>/.local/share/apktool/framework/1.apk

(This is on linux)

Only then I start decompiling/recompiling FYT apks. It is not necessary for the radio apk as that only uses broadcasts back and forth with the MCU, but I do think the BT apk needs it. And the com.syu.ms server apk simply doesn't work if you do not have the correct framework-res.apk "imported".

So you need to take it out of the 2019-09-17 firmware. If that is too complicated you can take mine.

It is 30MB, so I can't attach it here.

Now it is here 23:15, so tomorrow the next action ;)
[FYT Android Head Units] gamer765:
Dont worry, I do know about the framework-res.apk, its the first thing I did otherwise I would get endless errors about not being able to decode certain resources. Guess I gotta revisit my code and figure out whats causing the breakage. I've got one more thing I want to try before I do that, it might be the whole messing with AndroidManifest.xml and just transplanting it. I did a new decompile with apktool d -rs to prevent decompiling resources and source, transplanted my classes.dex, binary encoded AndroidManifest into the original folder and just recompiled it with stock resources, so i didnt have to mess with the 9-patch pngs. I'll try to convert it to an AllApp.pkg and quickly run to my car during my break to test it.

Update: I've decided to start fresh and add my code little by little in smali instead of compiling to Java and converting and doing a test after every bit of code was added. So far I'm not getting any issues.
[FYT Android Head Units] gamer765:
Well I'll leave this here. Connected to my OBDLink MX and also have music streaming from my phone to the headunit in the background. Youtube link: https://www.youtube.com/watch?v=mK4F3FavKzA

Excuse the trash music, I just hit play in Spotify and that was playing.
[FYT Android Head Units] surfer63:
Very good.

Bummer that the screen is now upside down :p

---------

Edit: I just checked the new 2019-11-28 firmware (not on the unit. I completely unpacked it on my laptop). The 20190917 190043001_com.syu.bt.apk is binary identical to the 20191128 190043001_com.syu.bt.apk. Your BT "pair everything" mod can also be used on the new released (not on the website yet) 20191128 firmware.
[FYT Android Head Units] Soiski71:
Its like day before Christmas...or actually Christmas. Two things that I believe the unit was missing was the ability to import new Radio Skins and then getting the additional Bluetooths to work with the unit. Great work guy's!

Should "we" advertise these on the official Joying forums or ... ?
[FYT Android Head Units] surfer63:
Your radio mod works nice and looks really cool.

Thanks.

You can put your mod on the official forum. I think multiple users will like it. If users want to revert to the original users can simply uninstall it and it will revert back to the system (firmware) version.

I think a number of users should test the BT app.
[FYT Android Head Units] gamer765:
Hahaha, for some reason my phone uploaded it upside down but the screen is proper side up. Also mind sharing the new firmware?
[FYT Android Head Units] surfer63:
It's in the main thread: https://xdaforums.com/showpost.php?p=81203423&postcount=1398

Also mind sharing your BT mod?
[FYT Android Head Units] gamer765:
It's still not complete, gonna work on it some more today. I'll post once it's 100% done.
[FYT Android Head Units] gamer765:
I'm a little confused now, I flashed the new update just to see what's new and I'm now left confused. I deleted my OBDLink MX device from it and just tried to pair it fresh without any mods and strangely it paired just fine with pin code 0000. I went into torque to see if it's detected and it was. Next I paired my phone again and streamed music and that worked too. Before I get my hopes up, what devices specifically don't pair at all with the head unit? This is a very curious thing.
[FYT Android Head Units] surfer63:
As far as I know only phones pair, and that is every phone, and OBD2 devices do pair in most of the cases.

For the rest nothing.

I tried many hid devices: keyboards, presentation pointers, remote controls for phones, mice, etc. I tried bluetooth head phones, ear phones, headsets, speakers, etc.

And a couple of other BT devices which can't remember right now.

Most mentioned options are not useful, but I simply tried whether I could pair them. None of them paired.

I don't have an OBD2 device though.
[FYT Android Head Units] Soiski71:
For me It was specifically OBDEleven unit (https://obdeleven.com/en/). It uses passcode 1234 for pairing and needs to have it done on Anroid Bluetooth level, not in the actual app.

Also I did not get the standard ELM 327 (Cheap BT from ebay) with 000 to work. Pairing in BT module would show success ( in both cases) but neither the torque nor the OBDEleven app would actually connect.

Surfer / Gamer, can you post / or PM the BT mod for testing ?
[FYT Android Head Units] gamer765:
Ok, I'll try out some bluetooth headsets. ETA for release, probably tomorrow.

Update: I figured out whats wrong with the mod, Joying/FYT try to cover as many devices as possible with a single codebase, so the mods I was doing was applying to the Joying Sophia portion of the code. Im going to be adding some debug messages to find out what path the code will take for our 9853 units. Theres some conditionals in the code with mConf_Platform to differentiate what it will do for each model of headunit. Do we know if Xposed works on this device? It would greatly help figure this out.
[FYT Android Head Units] rigattoni:
[MENTION=2550900]surfer63[/MENTION],

as I updated to the new firmware and there is no nokill-firmware available I tried to use the nokill.prop to get my daily apps working without getting closed on deep sleep.

But I think I´m doing something wrong or may be I have overseen something.

The lines I added are:

com.tomtom.gplay.navapp.nds = -10
com.skype.raider = -11
robj.readit.tomefree = -12

I just edited the prop like this:

#OOM机制会杀掉的进程的oom_adj的值的范围为0~15，-15~-1的进程是不会因为OOM而杀掉
#最顶APK的oom_adj为0，也就是最后被杀的进程，小于0的基本是OS内部的服务或本地进程，不会被杀
#所以，APP要将我们自己不想被杀的进程的名字按以下填上，oom_adj的优先级根据需要配置大小
#如果进程的名字以包名开头，只要<包名>=<oom_adj>的值就会把以该包名开始的进程全都设定为oom_adj的值
#如果进程的名字不以包名开头，就要<进程名>=<oom_adj>进行设定就可以了

com.syu.ms	= -15
com.syu.ps	= -14
com.syu.us	= -14
com.syu.ss	= -14
com.syu.dvr	= -13
com.syu.canbus	= -14
com.syu.odb	= -13
com.android.systemui	= -14
com.android.phone	= -15
com.android.bluetooth	= -15
com.android.launcher1	= -14
com.android.launcher2	= -14
com.android.launcher3	= -14
com.android.launcher4	= -14
com.android.launcher5	= -14
com.android.launcher6	= -14
com.android.launcher7	= -14
com.android.launcher8	= -14
com.android.launcher9	= -14
com.tomtom.gplay.navapp.nds = -10
com.skype.raider = -11
robj.readit.tomefree = -12

com.syu.widget	= 0
com.syu.gpswidget	= 0
com.syu.air	= 2
com.syu.car	= 2
com.syu.unicar= 2

com.mapgoo.diruite=5
com.mapgoo.diruite:remote=5
com.ecar.assistantnew=5

After rebuilding the Allapp.pkg and adding the lsec6521update to the USB drive, the units installs "something", but the added apps are killed as before.

What am I doing wrong here?
[FYT Android Head Units] surfer63:
I do not know. Did you build a complete Allapp.pkg, or only a limited one?

Inside the com.syu.ms in assets/property, you will also find the unkill_app.txt. That one was always used in previous versions to list the apps not to be killed. Maybe it works better from that one. I still do not understand what the relation is between that file and the new skipkillapp.prop (if there is a relation).

I already built the extended com.syu.ms. I want to build the nokill tomorrow (if I succeed). Then I will release them as Allap.pkgs and in JET (for those who are still rooted).
[FYT Android Head Units] surfer63:
Updates for the 2019-11-28 firmware

Hi,

I added the new main server mods to post #3 for the 2019-11-28 firmware.

I also added the radio mod that user [MENTION=8930623]Soiski71[/MENTION] created (preview).

Changelog:

- I added a number of lauchers and automate/tasker apps to the unkill_app.txt for the com.syu.ms. Note that these are added to the extended and nokill mods.

Behind the "Click to show content", you will find the added apps. This should prevent those apps from being killed upon deep sleep.

# Several 3rd party launchers
ru.speedfire.flycontrolcenter #FCC Car launcher
com.iflytek.autofly #FCC voice plugin
altergames.carlauncher #AGAMA car launcher
com.autolauncher.motorcar.free #Car launcher free
com.autolauncher.motorcar #Car launcher pro
com.softartstudio.carwebguru #Car web guru launcher
gb.xxy.hr #Head unit reloaded
gb.xxy.trial #Head unit reloaded trial
com.teslacoilsw.launcher #Nova launcher
com.teslacoilsw.launcher.prime #Nova launcher prime
is.shortcut #Evie launcher
# Automation/tasks apps
net.dinglisch.android.taskerm	#Tasker
com.llamalab.automate	#Automate
com.arlosoft.macrodroid	#Macrodroid
ryey.easer	#Easer
ryey.easer.beta	#Easer beta
AutomateIt.mainPackage	#AutomateIT
AutomateItPro.mainPackage	#AutomateIT Pro

As Joying only adds iGo, Waze and Google Maps to the navi_app.txt next to the Asian ones, I added a lot of Western ones. Again, behind the "Click to show content", you will find the added apps where the last 6 apps are new apps for this version.

#Other Western/American nav apps
com.mapfactor.navigator	#Mapfactor Navigator Free
com.generalmagic.magicearth	#Magic Earth
com.route66.maps5	#Magic Earth Pro
net.osmand	#OsmAnd Free
net.osmand.plus	#OsmAnd Plus
com.here.app.maps	#HERE WeGo
com.mapswithme.maps.pro	#MAPS.ME
com.navfree.android.OSM.ALL	#Navmii
com.navigon.navigator_one	#Navigon
com.tomtom.gplay.navapp	#TomTom Mobile Go
com.sygic.incar	#Sygic In Car
com.alk.copilot.mapviewer	#CoPilot GPS
cz.aponia.bor3.offlinemaps	#Offline Maps & Navigation
com.google.android.launcher	#Google Now Launcher
com.turboled.enhancedtts	#Enhanced TTs improves TTS
com.tomtom.speedcams.android.map	#TomTom Speed Cameras
com.viamichelin.android.viamichelinmobile	#ViaMichelin
com.camsam	# camsam blitzer.de blitzerwarner
com.camsam.plus	# camsam plus version
cm.aptoide.pt	# Blitzer.de ?
de.blitzer	# Blitzer.de ?
de.blitzer.plus	# Blitzer.de Plus ?
nl.flitsmeister	# Flitsmeister
com.sygic.speedcamapp	# Sygic Speed cams and traffic
com.alpriority.alpconnect	# alpconnect
com.ventel.android.radardroid2	# Radardroid
com.nng.igo.primong.igoworld	# iGo nav app
es.codefactory.vocalizertts	# Voice vocalizer tts
com.acapelagroup.android.tts	# Acapela TTS Voices
com.emileferreira.bestee	# Bestee virtual assistant (tts)
com.tomtom.mydrive.eu	# TomTom MyDrive
com.bodunov.galileo	# Guru Maps
com.bodunov.GalileoPro	# Guru Maps Pro

I did not make a rooted boot image (yet?) as I am no longer interested in rooting my unit.
[FYT Android Head Units] rigattoni:
[MENTION=2550900]surfer63[/MENTION]

Because I need root for some special tasks in Tasker it is mandatory for me to get my head units rooted. So this was the first part I did yesterday.

I just did some tests with your moddings (radio mod is not tested as I don´t use FM at all) and these are my results:

The extended unkill_app.txt in 2019-11-28-com_syu_ms-ORG_extended does not work on my unit (at least not in combination with rooted boot.img), no single app was active after deep sleep.

I then edited the unkill_app.txt in the 190000000_com.syu.ms.apk for testing one special app (ReadItToMe (crappy developed), because the app looses always the notification listener rights at deep sleep , but without luck.

2019-11-28-com_syu_ms-NoKill is working fine! All running apps are still running after deep sleep, even ReadItToMe...

So thanks a lot for your support in providing the NoKill.
[FYT Android Head Units] surfer63:
If you have the that rooted boot image for me, I can add it to post #3 if you allow that (and of course I will give you the credits)

I have not done enough testing in the last 2 versions, I must admit.

I checked all firmwares for the 8953i when "it all started", but got less interested starting with the 14 August version.

In all previous versions up to and including the 2019-08-14 com.syu.ms, the internal unkill_app.txt was still used. I just searched the entire com.syu.ms for 2019-09-17 and 2019-11-28, and the unkill_app.txt is not used anymore. The loop that reads the package names from that file has also disappeared.

So my addition to the unkill_app.txt is completely useless for the new firmware versions.

This is in accordance with the new skipkillapp.prop that was already there in the first 9853i firmwares. (info from some intel spec sheet, the Google translated Chinese top lines in the file and a 4pda post mentioning exactly the same of what I had discovered from that translation)

I have decompiled all apks in the Allapp.pkg, but there is no reference to the skipkillapp.prop either, nor in in the MCU firmware. There is nothing in the properties either.

As I'm not really interested in the "nokill things" I only tested the skipkillapp.prop today, but I can't make it to work either.

However, I used an Allapp.pkg with only the skipkillapp.prop and the com.syu.ms (to have some filling). The flashing software clearly recognised whether it is a full Allapp or not. Maybe it only works with a full one. Need to test that (in the coming days).

So to repeat my earlier question: Did you use a full Allapp.pkg or also a limited?
[FYT Android Head Units] surfer63:
[MENTION=2534110]rigattoni[/MENTION]:

You added the following apps to the skipkillapp.prop

com.tomtom.gplay.navapp.nds = -10
com.skype.raider = -11
robj.readit.tomefree = -12

If you use some text editor or file manager to view "/oem/app/skipkillapp.prop", or do a "cat /oem/app/skipkillapp.prop" from a terminal, can you see whether your apps are in there?

EDIT: Correct path in above line.
[FYT Android Head Units] rigattoni:
[MENTION=2550900]surfer63[/MENTION]

Added as attachment. ;)

No not anymore, because I always flash the original file back before I try something else... I just want to beware of cross incompatibilities...

I´m just lucky with the nokill version, because it always keeps my 4 to 5 preferred apps alive. That´s simply what I need.

I appreciate your great engagement in here. Thanks a lot!
[FYT Android Head Units] surfer63:
Thanks a lot. I added it to post #3.
[FYT Android Head Units] diger:
After many strange problems with post-installed packages with AllApk.exe, I took a look at your customized packages.

What I noticed is that the individual packages are signed correctly, but not the changed files inside.

So I rebuilt the firmware completely from the original firmware, changed some files, built a rooted boot.img directly, and signed everything completely, including every single file, not only the packages.

That then just flashed as usual, and now everything works as it should. First of all, I replaced one of the launcher with FCC, and preinstalled the DAB-Z app and some other stuff.

Next I have to see what I can throw out, what is not really needed and replace it with usable apps.

It's not a custom ROM now, but I have adapted the original firmware so that I don't have to install and adjust so much after a new installation.

Next I have to see what I can throw out, what is not really needed and replace it with usable apps.

It's not a custom ROM now, but I have adapted the original firmware so that I don't have to install and adjust so much after a new installation.

In any case, there seem to be side effects when changed files in packages are not re-signed (so don't just sign the whole package). At least if you reinstall such packages.
[FYT Android Head Units] surfer63:
Which files did you change? build.prop, skipkillapp.prop and the like?

What do you mean with "signed everything completely, including every single file". Did you use the "java -jar SignApkv2.jar -w -v" on every apk? And then on ...?

Did you also manage to make a modidfied "system.new.dat.br"? No matter what I do with signing, it is never correct when flashing it.

I already did some and described that in post #1422 of the Joying Android 8.1 Intel .... thread.

If you did sign them yourself, the signature is no longer the firmware signature, meaning that some apks will loose some rights and authorisations that normal "same system signed" system firmware apks have.
[FYT Android Head Units] Texas_Dude:
Hello,

I have a SinoSmart SC9853i unit and HWGetInfo app shows that I have FYT unit. I tried using the latest Joying Extra Tools to update the Radio app for better RDS display, however its asking me to root the radio first. Is there a way to use the Radio Mod where it does not require rooting and im pretty sure a lot of SC9853i users dream of improved Radio App but don't have Joying firmware :D

Will the Joying Extra Tools allow for Radio Mods on non Joying HU?

Full ZIP extract of HWGetInfo:

https:// we.tl/t-llo99XitND

Thanks for the great work!