yashsingh1/xdaforums huggingface dataset:
[FYT Android Head Units] seb21:
Delete patched_boot.img and put in the 6521_1 file original boot.img
[FYT Android Head Units] hawkjm73:
That worked perfectly. Thanks!
[FYT Android Head Units] julien_blanche:
today i got a mail from joying regarding new firmware update for devices 1280x480, not tested yet but looks like mailing with them improve their speed so everybody should report their bugs to them maybe we make these devices bug free over the time if we act all together

https://drive.google.com/open?id=1EGO9HObE8fIvCcSETmdI60IwHBuBgf1v
[FYT Android Head Units] ojuniour:
so this is the june update (is it the Old or New UI) ?
[FYT Android Head Units] julien_blanche:
it contains old ui, you can change launcher.apk and make it look new ui..

i already explained the procedure above...
[FYT Android Head Units] ojuniour:
Much appreciated , I was just in the middle of extracting and swapping those apks. Now I won't have to.

And yes , I do prefer the old UI.

I'm still scratching my head as to why it's such a good idea to have a useless uncustomizable digital (analog) clock taking such huge space..:rolleyes:
[FYT Android Head Units] julien_blanche:
Actually their approach is good but without customization it is annoying, they made a windows apk to run that clock externally within to launcher and rest of the apk screen layout designed by that specific resolution. I think it is too much work for them to design dynamic launcher like bmw evo 7 (dasaita bmw head units have them and it is wonderfull). I tried to adapt bmw evo 7 (px6 platform) launcher to run on joying without success. It would be wonderfull to have these head units that launcher but it is a dream :)
[FYT Android Head Units] strawsy:
Is this to allow external volume control to apps outside of the default? If so is there a way to have that and track next/back as well? When I'm in waze and have Spotify up in waze the tracks can't be changed from steering wheel controls.
[FYT Android Head Units] bambapin:
This is to allow you to send a command from the outside to a native component. (in this case it is the volume but it can also be extended to the specific commands of other native apps such as Radio, Music Player and Bluetooth for example).

A more complete version of the app essentially allow to control the headunit using an external multimedia keyboard or, in my case, universal steering wheel controls that are not compatible with the Joying head units that use a CAN Bus decoder.

If i understand what you want to do, you need something that does exactly the opposite: starting from a native command (the steering button), it should send a command to android or to a non-native app (track change ).

The app doesn't do this at the moment, but i'm still working on it.

However, if you have a way of associating the steering buttons with Tasker, all you have to do is send a KeyEvent to change tracks in Spotify: KEYCODE_MEDIA_NEXT (87) and KEYCODE_MEDIA_PREVIOUS (88), my app is not needed.

these are the command line examples:

adb shell input keyevent 87

adb shell input keyevent 88
[FYT Android Head Units] surfer63:
How will you do that?

I have been in long discussion with Joying exactly about this. I have a VW unit with CAN bus, but no steering wheel buttons, so I have already three third-party universal SWCs lying around.

There are 2 resistors on 4 resistor positions on the motherboard. They are soldered two by two. See attached image for a PX5(!) motherboard. When in the outside positions it listens to the CAN bus (and to nothing else), On the inside positions (see the arrows), it only listens to the Key1/Key2 wires.

(And I still did not solder them. I'm a software technical guy, not a hardware technical guy)

So it is not software based, it is hardware based.

However, I f you have an idea on how to make this work you are a champ! And please share that with us.

That is exactly what I'm trying to accomplish in my FytHWOnekey.

Using these commands, using the KeyEvent.KEYCODE_MEDIA_NEXT and 2 other options, but I can't get it to work. I wanted to couple this for example to the EQ button on my head unit (in case you have hardware buttons on your unit).

Issuing the commands from the terminal works just fine.
[FYT Android Head Units] julien_blanche:
Hi [MENTION=2550900]surfer63[/MENTION] , have you tried below method, by putting copper solder suction wire on the resistors and heating the copper wire to suck up the solder;

https://www.youtube.com/watch?v=Ncc1YXNgf8c

actually it gets easier when you make a couple practice on some other boards..
[FYT Android Head Units] bambapin:
Yes i know but as i said in a previous post, i want to bypass the CANbus. I'm developing a software layer that uses system modules directly (you find the references in the com.syu.ipc package).

I don't modify the bytecode or the apk of the firmware, i make low level calls directly from my app (actually i reused as library some classes extracted from the firmware of march).

This works, at least for now, because

i need to communicate in one direction only

: from the outside of the system to the system modules: the opposite direction of FytHWOnekey which is triggered, if i'm not wrong, by a system hardware key.

Compared to the manipulation of the system apk or to the hooks with Xposed, this way probably resists better the obfuscation of the code, at least until the JNI interfaces will be changed (which is not the same as obfuscating the code with proguard).

In the app i developed an IntentService to receive commands from the outside, eg from Tasker (the first version used an activity) and an accessibility service to listen to KeyPress events and retransmit them to the system modules (eg the volume).

Using the accessibility service, you can connect a multimedia hardware keyboard via USB and send commands to the head unit, the software layer interprets the KeyCode and, if needed (eg again the volume), invokes the corresponding system module, or simply lets Android manage the KeyEvent.

At this point, to use the universal steering wheel controls, you need to turn them into an HW keyboard, to do this you can use an arduino micro that is already set up to be seen as an HID peripheral (there are a lot of sketches on the internet).

In practice, the control unit that receives the wireless commands from the steering wheel commands does nothing but emit on the 2 wires of the output signal a different voltage depending on the key that has been pressed.

If you connect these cables to the input pins of the arduino you can read the voltage and simulate the pressure of a key on the keyboard, so if the arduino is connected via usb to the headunit the key is received by the accessibility service and used (eg . to change the volume).

The arduino part still needs work, however this evening i send you the code i developed until now with the information i found on the commands to be sent to the various modules.
[FYT Android Head Units] surfer63:
;) Yes, I have seen multiple. It is not the complexity I'm afraid off.

But the very first thing to make this start is getting a "mini" soldering iron. I don't have a soldering iron: at all. Last time I did some soldering was around 13-15 years old in school, and that is more than 40 years ago (please don't start ;) )

---------- Post added at 11:25 AM ---------- Previous post was at 11:18 AM ----------

I have been looking at that as well. I did program arduino's and the like as I did some robotica in my house using those arduino boards, raspberry Pi's and esp8266 modules. But all via breadboard / dupont connections. Again no soldering. And putting it in the car would require soldering to keep "things in place".

I also have multiple raspberry-pi's and clones. But I actually hate to put all those hardware work-arounds in place to fix something that shouldn't have to be fixed.

anyway: I would really like to see your code.

EDIT: Earlier I had already coupled a raspberry-pi mini via wifi to the unit to use a webcam coupled to the rpi. That did work fine as well.
[FYT Android Head Units] bambapin:
I understand, however keep in mind that nothing must be soldered on the headunit, the only connection must be between the 2 wires coming out of the universal steering wheel controls receiver and the arduino (you could do it with dupont cables if you want), then the arduino connects to the headunit via usb.
[FYT Android Head Units] Caroline_Don:
Check this video to solve your problem:

https://www.youtube.com/watch?v=ANMeYtZuDmE&feature=youtu.be

Thanks
[FYT Android Head Units] edcam33:
Thanks Mate. Much appreciated.
[FYT Android Head Units] hawkjm73:
Am I understanding you right that the unit can ONLY have a CANbus module OR resistive SWC connected? If so, that really explains the issues I was having.

My car, a 2005 Prius, needs a CANbus module to make the stock amplifier happy, but does not have the SWC on the bus. They are the resistive ladder type. I tried a rather long time to get those buttons to work, but the head unit simply would not respond to any of them. My multimeter and I were very certain the wires were correct all the way to the iso connecter on the unit. I was starting to suspect the presence of the CANbus was interfering, but I'd given up trying to get Joying to understand the issue.

I'm now using a little module called a JoyCon EXR. It neatly reads the SWC resistances and outputs keyboard strokes over USB. I was able to use a spare harness plug from my trim unit to connect the SWC wires, so the thing is plug-and-play in the dash. One major bonus was built in long and short press customability.

The difficulty is getting something on the Android side to reliably catch the keypresses and act on then. Tasker plus the AutoInput plugin work wonderfully, but AutoInput requires an accessibility service, which gets canned and de-permited on every boot and wake. The AutoTools plugin can re-enable the service permission, but the accessibility service section in setting vanishes on boot until some unknown condition is met. I'm using the JET no-kill version of mainserver to keep Tasker from getting killed, but so far, it won't suspend, giving me a cold boot every time. Has anyone tried moving a user app into system to get it to keep alive?
[FYT Android Head Units] surfer63:
That is correct. Can bus units only listen to canbus binary pulse SWC signals, whether you have the canbus connected or not (I tried that and even reconnected the brown/pink key1/key2 wire from the can bus).

Universal models, those are the units/motherboards without can bus, use the Key1/2 resistance signals.

That is because Tasker sets a "wake lock" thereby preventing the unit from going into deep sleep. The MCU monitors that and if the unit is still not in deep sleep after 20 minutes, it simply cuts the power resulting in a cold boot instead of a "wake up from deep sleep".

Someone already gave the tip to not use the nokill version, but to assign tasker to the navi app setting and combine that with the setting "always auto start navi app".
[FYT Android Head Units] bambapin:
Ok, i recorded a very short video https://www.youtube.com/watch?v=L4gxbJ92DoE showing how the universal buttons with arduino are working now on my VW headunit, the mapping is random, just for demonstration purposes.

The arduino could be replaced by the device [MENTION=1575386]hawkjm73[/MENTION] was talking about, it depends if you want to have fun and save money or not, an arduino micro costs about 6€ on Amazon, less on AliExpress :)

I published the project, exactly in the state it is now, on github (https://github.com/MobeedoM-opensource/android-auto), the Arduino sketch that i used is attached here (it is is very very very rough), the voltage values ​​are hardcoded on my buttons, probably they must be adapted to others.

Essentially to translate a KeyCode into a command directed to the Joying modules, the app uses the system_UI.jar in the libs directory which has been extracted with dex2jar starting from the system firmware apk of March, and a little tweaked.

If you start from App.java, you can see that the main classes are com.syu.car.CarService and com.syu.car.CarServiceForSteer.

From these services you can get an instance of com.syu.remote.RemoteTools that allows you to interact directly with the system modules using a syntax like:

remoteToolsInstance.sendInt (MODULE CODE, COMMAND, PARAMETER);

the code of the modules is defined in com.syu.ipc.FinalMainServer eg

public static final int MODULE_CODE_BT = 2;
public static final int MODULE_CODE_CANBUS = 7;
public static final int MODULE_CODE_DVD = 3;
public static final int MODULE_CODE_DVR = 9;
public static final int MODULE_CODE_IPOD = 5;
public static final int MODULE_CODE_MAIN = 0;
public static final int MODULE_CODE_RADIO = 1;
public static final int MODULE_CODE_SOUND = 4;
public static final int MODULE_CODE_TV = 6;
public static final int MODULE_CODE_STEER = 10;

the COMMAND and PARAMETER instead are specific to the module you intend to use and are defined in the various Final... in the com.syu.ipc.data package.

For example the Sound module has code 4, the command to set the volume at a certain level is the constant C_VOL = 0 and the PARAMETER is the level at which you want to set the volume from 0 to 33.

The java call to set the volume to 12 then becomes:

remoteToolsInstance.sendInt (4, 0, 12);

The app also exposes a generic call to any of the modules as IntentService, the class is com.mobeedom.android.auto.jyhuremote.services.HUIntentService

from command line (or from Tasker) the previous one becomes:

am start-foreground-service -a com.mobeedom.android.hu.CUSTOM_MODULE --ei "MODULE" 4 --and "CODE" 0 -ei "PARAM" 12

Perhaps it is possibile to exploit the system modules to register a CallBack in reaction to system events, which would be very important since as you know there are no public broadcasts, i was looking for ACC_ON for example but i didn't find it (yet ?) :)
[FYT Android Head Units] surfer63:
This is great (and your code is way over my head).

So the KEY_NEXT and KEY_PREV (FinalSteer) could be added to some "private void mediaKeyManager" (for example) via some public voids keyNext/keyPrev, which call the "MODULE_CODE_STEER" to do the next/prev commands.

I think the ACC_ON and ACC_OFF are broadcasted by the MCU. There is a receiverMCU in the com.syu.ms.apk receiving the accon/off, which on its turn broadcasts the intents "com.fyt.boot.ACCON" and "com.fyt.boot.ACCOFF" (com.glsx.boot.ACCON and com.glsx.boot.ACCOFF on the older Sofias) in util/ToolkitPlatform to all "listening"/triggered apps on the unit.

EDIT:

Is that the int array ?

int KEYS[5] = {167,280,222,58,112};
[FYT Android Head Units] bambapin:
Actually i plan to use them in a slight different way because the MODULE_CODE_STEER, at least from what i understood by doing reverse engineering, is the one responsible form the mapping and not for the real usage. When you detect a standard android KEY_NEXT or KEY_PREV, you can forward directly to the specific modules: the video showed up the radio changing the channels, this was accomplished by forwarding the android standard KEY_NEXT/PREV to the radio module:

getTools().sendInt(FinalMainServer.MODULE_CODE_RADIO, FinalRadio.C_NEXT_CHANNEL)

Basically, in my opinion, there are 2 ways: the first one is to locate (it is convenient using the accessibility service) the app in the foreground and, if it is a Joying native app, to send the code corresponding to the module, or if it is a normal app to pass KeyEvent as it is and let Android work as if it were sent from a normal multimedia keyboard to a normal phone.

The second way instead is to always send the command remapped to all the modules, easier but makes more mess.

Thanks! i'll look at these intents.

Yes, i mapped only the right group until now, the final array must be of 10 elements. The numbers are the arduino average readings (there is some noise) when a key is pressed on the universal steering wheel.
[FYT Android Head Units] surfer63:
I agree. It was more to describe if I understood what needed to be done.

You mention the values are the "arduino average readings". How did you get these values from the arduino? Or are these measurements from a multi-meter and then added to the .ino?

Or the standard drawings of "unknown resistance" between 5V and A0, and "known resistance" between A0 and GND?

I can only see 2 wires in your youtube movie coming from the key1/gnd wires of the controller box (if I'm correct).
[FYT Android Head Units] bambapin:
The wires connected to arduino are key1 and key2, the + and the GND from the receiver are directly connected to the acc wire and to a common ground.

The arduino (micro) is powered by the usb.

The readings come from arduino, if you uncomment the Serial.println(localMin) you can see them in the serial output console.

I use the analog pins A2 and A3.

edit: it is important to use an arduino MICRO because it has an integrated circuit that allows it to be seen as a HID device, the other arduino don't have it
[FYT Android Head Units] surfer63:
Of course + and GND go to the head unit. Stupid I did not think of that :rolleyes:

I have nano's and pro(mini)'s. I will have to look.
[FYT Android Head Units] bambapin:
While you try the sketch to read the values, it is important to remove/comment the #include "HID-Project.h" and the Consumer.write(...) to avoid the arduino micro switch to Keyboard mode.
[FYT Android Head Units] Caroline_Don:
Joying iGO offline map can't work with 9853i head unit

Has anyone installed the joying iGO offline map in the 9853i unit?

https://drive.google.com/file/d/1biaXui51vTQGhJQZ-8f7PTicZ0ZU0CUI/view

It can't work now, please see the picture:

https://i.loli.net/2019/06/26/5d133131d511687259.png

https://i.loli.net/2019/06/26/5d1331573f1eb43475.png

Has anyone the same problem? How to solve it?
[FYT Android Head Units] surfer63:
I just ordered two micro's. The nano and pro-mini boards do indeed not work as HID devices.
[FYT Android Head Units] Stormbringer!:
is there a recommended PX6 unit with community support in mind? I'd prefer a unit that has hard buttons on the left with a volume knob. Something like this?

https://www.aliexpress.com/item/33007464320.html
[FYT Android Head Units] julien_blanche:
You can check out Dasaita products since they are releasing regular updates for their products and quality seems fine at overall.

https://dasaita.aliexpress.com/stor....html?spm=a2g1y.12024536.pcShopHead_5904672.1
[FYT Android Head Units] Stormbringer!:
ok, its a bit more but I think im going to go with a HA2153-MAX6

Thanks for the tip!
[FYT Android Head Units] victorvcunha:
Thanks, it works with 05.15 firmware too.

You could split your app into 3, each one as a function (volume up, volume down and mute), but without GUI, as [MENTION=2550900]surfer63[/MENTION] did with wifi on and wifi off for example.

It would be nice.
[FYT Android Head Units] bambapin:
Without GUI you mean to avoid the flicker? From where do you want to launch them?
[FYT Android Head Units] victorvcunha:
I want to say that when I launch the app 'volume up' (by the launcher) for example, the volume will increase without showing any interface. This way, is easy to custom car launchers.
[FYT Android Head Units] surfer63:
You can have 3 launcher activities each with its own icon packed in one apk still without using a gui. I only use a gui for the settings. The rest is "gui-less".

But please note that CarwebGuru only recognizes the first launcher activity. It scans the AndroidManifest and when it comes upong the first laucher activity, it stops reading. So that one will not show other icons. A few other launchers have these limitations as well. That's why I made my wifion/wifioff as 2 separate micro apks (13Kb), instead of one apk with 2 icons and 2 activities.
[FYT Android Head Units] victorvcunha:
In the CWG "drawer", a long click on the application gives the 'Explore' option, which allows you to access other activities of the application.
[FYT Android Head Units] surfer63:
Thanks. I didn't know that but it is still annoying. It will not allow a user to simply click an icon like for the BT app which also has 2 icons.

Especially for a car launcher where simplicity should be the very first requirement. Needing long-tap and "scrolling" takes your eyes of the road.
[FYT Android Head Units] bambapin:
Ok, i post 4 apps, not 3 :)

The first one is the base, the other ones will not work alone.

As bonus, if you enable the accessibility service on the main app, you will have a recents list toggle (i use in the JY floating button for example because i always use the full immersive mode, so no status bar visibile).

The 3 others simply send the intents VOL_UP/DOWN/MUTE.

You can uninstall the old one, by the way the intents are different in this version eg: am start-foreground-service -a com.mobeedom.android.hu.VOL_UP.

[MENTION=2550900]surfer63[/MENTION] i fully agree with you on CWG, it is the best android auto launcher but it has lot of little bugs/limitations, also the icons cache doesn't work well for example... it would take very little to make it perfect, it's a shame.
[FYT Android Head Units] victorvcunha:
There is a way to add shortcut to an activitie on CWG, I rec a video: https://youtu.be/tUvHCtulbt0

Thanks a lot.
[FYT Android Head Units] Cr4z33:
Yes!

Go into the Android Settings, Apps, scroll up to the phone dialer APK, enter and disable its foreground service.

From that moment on you will be able to use the native AA/HUR phone screen. :)
[FYT Android Head Units] bambapin:
Hi [MENTION=2550900]surfer63[/MENTION], i updated the code and the latest version of the apk on github, there are several changes.

https://github.com/MobeedoM-opensource/android-auto

The arduino code (is on github) now manages 10 keys and also the long press.

On the Java side for some events root is needed, however if you look at the class

com.mobeedom.android.auto.jyhuremote.helpers.MediaKeysMapper

you should understand everything (yes, I know there are not many comments :o)

The accessibility service now sends a broadcast with the hardware keycode received, the idea is to allow writing external apps that register for the intent and manage the keycodes, so the associations can be customized... i know, i should develop a GUI to let the users manage the associations but i don't have time right now.
[FYT Android Head Units] Black6spdZ:
https://img.gadgethacks.com/img/84/...gation-buttons-other-android-phones.w1456.jpg

How do we enable STANDARD android nav bar/buttons?
[FYT Android Head Units] zmylna:
Hi All

Anyone have any idea why HU shows a different (old) version of the Power Amp app than my phone?

If i enter Google Play on my phone and search for Power Amp then i see PowerAmp V3 from 31 may 2019

If i enter Google Play on HU and search for Power Amp then i see PowerAmp V2 from 3 sep 2016

So only way to get the newest version of PowerAmp is apk file :/

But this is not the end.

After installing the program from the apk file, Google Play reports the need to upgrade PowerAmp.

If I agree, this "update" fails because Google Play is really trying to replace the newer version with an older version.

Phone:

https://drive.google.com/file/d/117hvFSaf77jPY2CkCVdnUaeYQZrEsoRy/view?usp=sharing

HU:

https://drive.google.com/file/d/10zeergYJ1lKlGmhiyIIlYoENwQMdL7j-/view?usp=sharing
[FYT Android Head Units] surfer63:
Old Intel version versus new ARM version? Mail the guys from poweramp.
[FYT Android Head Units] bambapin:
I did it this way:

- installed the v2 from the Playstore

- started once to have the license checked

- uninstalled the Playstore version

- installed the latest v3 from the Poweramp site.

At the first launch it rechecked the license and then it worked.
[FYT Android Head Units] zmylna:
I confirm, it works in this way.

Thanx bambapin.