2004 to 2016 Mazda 3 Forum and Mazdaspeed 3 Forums banner

81 - 100 of 114 Posts

·
Registered
Joined
·
10 Posts
I already did that, thats part of the instructions here: https://mazdatweaks.com/androidauto/

It says "To compile a headunit binary for use in the car run:

cd ~/headunit/mazda && make clean && make"

But it doesn't say how to get this onto an AIO usb stick...

I already figured i need to copy the folder /headunit/mazda/installer to the usb stick and replace whats there, HOWEVER...i have more folders on my usb stick that i cannot find on ubuntu, where do i get these (updates to latest version) from? Example:


16-01-2019 09:03 <DIR> androidautohud
16-01-2019 09:03 <DIR> audio_order_AND_no_More_Disclaimer
16-01-2019 09:03 <DIR> bin
16-01-2019 09:03 <DIR> jci
16-01-2019 09:03 <DIR> ssh_bringback
audio order, no more disclaimer, ssh bringback are tweaks that you must have moved onto the usb drive previously. You'd probably want to wipe the USB drive and then move the contents of /headunit/mazda/installer onto the drive in order to just update AA with the newest build.
 

·
Registered
Joined
·
83 Posts
I already did that, thats part of the instructions here: https://mazdatweaks.com/androidauto/

It says "To compile a headunit binary for use in the car run:

cd ~/headunit/mazda && make clean && make"

But it doesn't say how to get this onto an AIO usb stick...

I already figured i need to copy the folder /headunit/mazda/installer to the usb stick and replace whats there, HOWEVER...i have more folders on my usb stick that i cannot find on ubuntu, where do i get these (updates to latest version) from? Example:


16-01-2019 09:03 <DIR> androidautohud
16-01-2019 09:03 <DIR> audio_order_AND_no_More_Disclaimer
16-01-2019 09:03 <DIR> bin
16-01-2019 09:03 <DIR> jci
16-01-2019 09:03 <DIR> ssh_bringback
audio order, no more disclaimer, ssh bringback are tweaks that you must have moved onto the usb drive previously. You'd probably want to wipe the USB drive and then move the contents of /headunit/mazda/installer onto the drive in order to just update AA with the newest build.
OK thats clear thanks. What about the android auto HUD
 

·
Registered
Joined
·
83 Posts
I believe it has been removed in latest release as it was buggy. Not sure what the effect would be if you left hud directory in.
Ok thanks bud! I just checked the directories that AIO creates and those that exist on ubuntu but the contents are not the same, can i ignore this?

Example:




These are contents of headunit/mazda/installer/config/androidauto and subfolders.

Left the AIO on image and right is ubuntu.
 

·
Registered
Joined
·
124 Posts
Cheers, that was it :).




I already did that, thats part of the instructions here: https://mazdatweaks.com/androidauto/

It says "To compile a headunit binary for use in the car run:
If it all compiles nicely the code destined for your USB stick is in ~/headunit/mazda/installer/ I tried copying all those files across and the install failed on my car. I see that Trez has posted to use the mazdatweaks installer to put current files on USB and then just replace the 'binary' - I take that to mean use the cmu_dataretrieval.up file you've just compiled rather than the mazdatweaks one.
 

·
Registered
Joined
·
812 Posts
@Tristan-cx5 I was wondering if you tried removing the <key_codes> tag and adding the <touch_screen> tag in any of your tests? My thinking is that if the <key_codes> are removed AA will fall-back on the next available input device which will be the touch screen and also that the buttons and key code mappings are still present in the code so they should continue to work correctly but no longer function as the main input device.
Also there is a <touch_pad> tag that would have <width>, <height>, <control_ui>, <physical_width>, and <physical_height> attributes. That one is probably not what we are looking for but who knows it may be the key. I just refuse to believe that those input devices cannot be activated somehow because they definitely exist in the code.
@Trezdog44:

Test results for removing the <key_codes> tags: Negative.

I tested with all your earlier mentioned variations (see my txt-files) and deleted the <key_codes> tag completeley, as well as just whats in between the tags. In both cases no input was possible at all after starting official AA (no touch, no commander knob). I also tried to just remove the <key_codes> tags (including themselves) from the original file, which led to the same result. :-(

My tested files (I renamed them after copying to the MZD):
If you have any idea where to add and how to test the <touch_pad> tag, I will be happy to test it. In my original file there is no such tag included.
 

·
Registered
Joined
·
1 Posts
Quick question about the Change Order of the Audio Source List tweak - does it happen to affect what audio source the MZD switches to when AA is unplugged? It's super annoying that MZD seems to always default to FM Radio, whereas Bluetooth would make more sense if the phone was actively already playing music when AA was unplugged..

I'm running v70.00.100 official AA (dealer upgraded) and just ordered the serial connection equipment so I'll be able to jump in with you guys soon re: testing / contributing.

Thanks for all the awesome work you guys have been doing, I'm excited to get these tweaks working and contribute however I can :)
 

·
Registered
Joined
·
10 Posts
Quick question about the Change Order of the Audio Source List tweak - does it happen to affect what audio source the MZD switches to when AA is unplugged? It's super annoying that MZD seems to always default to FM Radio, whereas Bluetooth would make more sense if the phone was actively already playing music when AA was unplugged..

I'm running v70.00.100 official AA (dealer upgraded) and just ordered the serial connection equipment so I'll be able to jump in with you guys soon re: testing / contributing.

Thanks for all the awesome work you guys have been doing, I'm excited to get these tweaks working and contribute however I can :)
Mine reverts back to the audio source I was using before initializing AA. Not sure if that was changed in v70 / official AA.
 

·
Registered
Joined
·
3 Posts
For holding down buttons I would have to figure out how to go about coding that up since it is not written into our code, it is probably not that difficult but it's just another thing to do that would take some time to figure out which is why I am trying to maximize the use of single pressing buttons for now.
I noticed that holding down the home button takes you to the Infotainment home when in AA. If I just press it it takes me to the AA home. I am in v70 with the AA/CP retrofit.
 

·
Registered
Joined
·
32 Posts
Here is aap_system_attributes.xml from another HU. Has some comments in it, doesn't seem immediatelly helpful, but still a good read. Especially this part:
<!-- If application wants to make use of touch screen, touch screen <type> tag is mandatory to provide.
Touch inputs can be provided from application or the stack can directly take the input events from the touch device.
If the application wants stack to directly read from input device, it is mandatory to have <use_internally> and
<path> tags.
NOTE: <use_internally> and <path> tags should be used only for testing purpose. In the production release,
the application has to provide the touch input events through aap_send_touch_input() API. -->
<touch_screen>
<!-- Set "TRUE" to enable. "FALSE" to disable. This field is mandatory. -->
<use_internally>FALSE</use_internally>
<!-- The below <path> tag will be considered only if <use_internally> is TRUE -->
<path>/dev/event1</path>
<!-- Default : "AAP_TOUCH_SCREEN_TYPE_CAPACITIVE". There must be
a single entry only for this tag. This field is mandatory
and must be the last child of touch_screen
Other possible values: AAP_TOUCH_SCREEN_TYPE_RESISTIVE -->
<type>AAP_TOUCH_SCREEN_TYPE_CAPACITIVE</type>
</touch_screen>
This comes from firmware taken from here: http://4pda.ru/forum/lofiversion/index.php?t785482-780.html. "Яндекс диск" link in "VW 5515" section (middle one).

Seems like AA support is built with help of these guys (filenames and configuration are suspiciously same): http://www.allgosystems.com/Android_Auto_Projection.php in both Mazda's implementation and this firmware. Maybe we can extract their aap_service and try replacing it? :)
 

Attachments

·
Registered
Joined
·
812 Posts
Thanks. In this aap_system_attributes.txt of the other Headunit (HU, no MZD) is stated, that there is no default, if all <key_codes> tags are removed. So my last (negative) test result of the files with removed <key_codes> tags is vaild. I assume, that the <touch_pad> tag only applies for cars with a separate touch pad - e.g near the commander knob/hand brake. I do not know of this feature at Mazda so far - this is why I don`t think this tag will help at the moment.

More interesting could be the <path> tag. @Trezdog44: Did you check that the 2 paths you provided really exist in FW 70? 1. <path>/devices/virtual/input/input0</path>, 2. <path>/dev/input/filtered-touchscreen0</path>. In the above file from the other HU is mentioned another path: <path>/dev/event1</path>. I will try to find/check these 3 paths via SSH in the MZD.

Is the above mentioned "aap_send_touch_input() API" somewhere in FW 70? If not, it probably gets difficult...

As far as I know the MZD has a capacitive screen, that`s why in the above file the <type>AAP_TOUCH_SCREEN_TYPE_CAPACITIVE</type> tag is default and the type "resisitive" is not used. So we do not have to test both types. Info: Difference Between Resistive and Capacitive Touch Screens

Seeing that these info help a litte to ease/simplify future tests. :)
 

·
Registered
Joined
·
166 Posts
Probably not a lot help to you, but I drove a Hyundai this week with Android Auto. This one did not have any kind of rotary commander knob and misses some icons which is there in Google Maps in the official AA from Mazda for panning/zooming...

Verstuurd vanaf mijn ONEPLUS A6003 met Tapatalk
 

·
Registered
Joined
·
812 Posts
Thanks for the reminder. That's correct. Someone posted photos - can't remember where & when. So probably there is more to do than just the activation of the touch screen.
 

·
Registered
Joined
·
166 Posts
Thanks for the reminder. That's correct. Someone posted photos - can't remember where & when. So probably there is more to do than just the activation of the touch screen.
Are you also trying to activate the button mapping in the AIO as in the OEM version of Android Auto, with the extra icons in Google Maps (for panning/zooming)?

Verstuurd vanaf mijn ONEPLUS A6003 met Tapatalk
 

·
Registered
Joined
·
812 Posts
No. All I try via trial and error is activating the touch screen of the official Android Auto. Even if I doubt that I can do it with my limited experience. I am not a developer, but I want to try it anyway. The AIO button mapping is way to complicated for me. My hope is that through the activation of the touch screen the Google Maps layout changes automatically from the official AA one to the one we know from AIO AA (which is capable of touch).
 

·
Registered
Joined
·
812 Posts
More interesting could be the <path> tag. @Trezdog44: Did you check that the 2 paths you provided really exist in FW 70? 1. <path>/devices/virtual/input/input0</path>, 2. <path>/dev/input/filtered-touchscreen0</path>. In the above file from the other HU is mentioned another path: <path>/dev/event1</path>. I will try to find/check these 3 paths via SSH in the MZD.

Is the above mentioned "aap_send_touch_input() API" somewhere in FW 70? If not, it probably gets difficult...
@Trezdog44:
After today`s tests I can answer some of my questions myself:
  • Path: Only path: /dev/input/filtered-touchscreen0 and /dev/input/event1 were in my FW 70.00.100A EU. The others not.
  • API: I could not find a file or folder called "aap_send_touch_input".
This is the content of folder /dev/ and dev/input/:
dev-folder mzd.JPG dev-input folder mzd.JPG

Unfortunately all test results of today were negative:
With all following 5 files no touch was possible. All the time the commander knob worked fine (because I did not delete the <key_codes> tags, like in the test before).
That`s it so far. I can not test any further unless someone tells me what to change in the code/files.
 

·
Registered
Joined
·
181 Posts
Thanks for the reminder. That's correct. Someone posted photos - can't remember where & when. So probably there is more to do than just the activation of the touch screen.

I did post the difference photos of AIO AA (touch style) and official AA (commander style). Since then i've installed the original kit and updated FW to 70. I'm all happy now as i can navigate everything with only using the knob (hate the touchscreen).

I believe, to get what you want (using touch screen in the official AA), you have to change working mode. Even in the AA simulator, if you open the AA in command only mode, it does not register any mouse clicks. If the pan/zoom buttons exist on the google maps for example, no matter what you do, touchscreen will not work. So, pan/zoom buttons means no touchscreen.


So pros for me:

+ Navigation on the map screen using only the knob like stopping active route, enabling/disabling traffic info, panning.
+ Visible volume level indicator on top of the screen.
+ Physical shortcut buttons for music and navi. Pressing the buttons goes to relevant screen.
+ Easily switching between Mazda interface and AA with holding home button.
+ Ability to enter words to search fields by selecting letters one by one with knob even while driving.
+ No sound stutter anywhere while playing music. Happens sometimes in AIO while zooming in and out.
+ High amperage USB phone charge. (Supposed to be 2.1A but I've rated 1.2 using Ampere app on my Oneplus 5T)
+ Connects everytime to AA.
+ Gets the video focus back after exiting reverse camera screen or PDC screen. (You have to open Android Auto manually from applications menu in AIO for that feature)
+ Gets the audio focus back for music after the phone calls every time.
+ Pauses music after pressing the mute button.


Cons:

- Call button on steering wheel does not go to call screen.
- Navigation instructions does not appear on the HUD like the AIO AA.

I've purchased the kit from dealer. Costs around 140$ here in Turkey. Worth every penny. Installed myself. Fairly simple as there are bunch of tutorials online.

I would like to thank everyone who has involved in developing the AIO AA. I've used AIO version nearly one year relatively problem free.
 

·
Registered
Joined
·
166 Posts
I did post the difference photos of AIO AA (touch style) and official AA (commander style). Since then i've installed the original kit and updated FW to 70. I'm all happy now as i can navigate everything with only using the knob (hate the touchscreen).

I believe, to get what you want (using touch screen in the official AA), you have to change working mode. Even in the AA simulator, if you open the AA in command only mode, it does not register any mouse clicks. If the pan/zoom buttons exist on the google maps for example, no matter what you do, touchscreen will not work. So, pan/zoom buttons means no touchscreen.


So pros for me:

+ Navigation on the map screen using only the knob like stopping active route, enabling/disabling traffic info, panning.
+ Visible volume level indicator on top of the screen.
+ Physical shortcut buttons for music and navi. Pressing the buttons goes to relevant screen.
+ Easily switching between Mazda interface and AA with holding home button.
+ Ability to enter words to search fields by selecting letters one by one with knob even while driving.
+ No sound stutter anywhere while playing music. Happens sometimes in AIO while zooming in and out.
+ High amperage USB phone charge. (Supposed to be 2.1A but I've rated 1.2 using Ampere app on my Oneplus 5T)
+ Connects everytime to AA.
+ Gets the video focus back after exiting reverse camera screen or PDC screen. (You have to open Android Auto manually from applications menu in AIO for that feature)
+ Gets the audio focus back for music after the phone calls every time.
+ Pauses music after pressing the mute button.


Cons:

- Call button on steering wheel does not go to call screen.
- Navigation instructions does not appear on the HUD like the AIO AA.

I've purchased the kit from dealer. Costs around 140$ here in Turkey. Worth every penny. Installed myself. Fairly simple as there are bunch of tutorials online.

I would like to thank everyone who has involved in developing the AIO AA. I've used AIO version nearly one year relatively problem free.
Hmmm, overhere the official AIO costs a lot more than 140 Dollars, so even if I would love to have that one, it costs me too much money at the moment. So I will stuck with the AIO version....

It would be nice if someone was able to make it optional to install the AIO version as rotary knob only. Me too hate the touchscreen for it is more difficult to use during driving and I hate the fingerprints which makes the screen less visible in direct sunlight....

Verstuurd vanaf mijn ONEPLUS A6003 met Tapatalk
 

·
Registered
Joined
·
29 Posts
I'm assuming you mean't that the official AA costs at lot more than 140? Where are you based out of? I got my kit for 150 on eBay, also self installed. Was tedious but a breeze and the trim came off and went back on a lot easier than I thought it would have.
EDIT: Should have looked at your sig, I see you're potentially in Belgium or The Netherlands, though more countries than that speak Dutch.

For this touch issue, what tarahumara said improves the likely hood of my suspicions in what I originally planned to post here:

Are we sure that the touch screen is actually disabled and the problem isn't that the head unit is registering the touch events but the Android Auto API is simply capturing the event but doing nothing with it?

Based on tarahumara's notes about the two different interfaces (command vs touch), its possible that there is some sort of switch available to car manufactures that allow them to choose which mode of AA to use. Then, in the onTouchEvent()method for AA's home view there is a simple 'if' check or switch for what mode is being used. If the traditional touch mode is being used there is an actual tree that properly directs the input to trigger the appropriate action, and if the command mode is being used it simply does nothing but return true to fully absorb the event and not allow any child views to interact with it. This variable would also be used during view inflation so that AA will use the correct layout for touch or command input, since they are not the same as confirmed above. If this was the case you wouldn't see any ripple effect or colorshift on touch as the event would never reach any of the child views/buttons, so the touch could still be enabled at least at the screen level and you would never know (unless the head unit files say otherwise).

i.e.

HUCom.java -
Code:
//Static global class that handles head unit communication

enum InputMode { TOUCH, COMMAND; }
//...

private static InputMode mCarInputMode;
//...

private void init()
{
    // Performs some kind of communication with the headunit to grab vehicle specific preferences
    //...
    mCarInputMode = //... set from processed information that came from headunit
}

public InputMode getInputStyle() { return mCarInputMode; }

Example_AA_Activity.java -
Code:
private Context mContext;
private HUCom.InputMode mCurrentIM;
//...

@Override
public View onCreateView(@NonNull LayoutInflater inflater, ViewGroup container,
                         Bundle savedInstanceState) {
 
    View rootView;
    mCurrentIM = HUCom.getInputStyle(); // "HUCom": communication

    switch(mCurrentIM)
    {
         case TOUCH: 
             rootView = inflater.inflate(R.layout.aa_home_touch_interface, container, false);
             break;
         case COMMAND:
             rootView = inflater.inflate(R.layout.aa_home_command_interface, container, false);
             break;
    }

    // Grab context
    mContext = getContext();

    // Initialize View
    init(rootView);

    return rootView;
}

@Override
public boolean onTouchEvent(MotionEvent e)
{
     switch (mCurrentIM)
    {
        case TOUCH:
            float x = e.getX();
            float y = e.getY();
            //... continued processing of touch event, may return true or false
            break;

        case COMMAND:
            return true;
            break;
    }
}

private void init(View view)
{
    //...
}

Its very unlikely its implemented in this exact manner and the mode to use is probably read from the head unit much earlier, but this is a shitty basic idea of what I'm talking about. Food for thought.

I am just lightly thinking about this and know almost none of the details, so if there is something within the head unit XMLs that makes it obvious the touch is disabled at the API level than never mind. :pinch:

If this is the case, then the goal would be to try and find this switch essentially, which may very well be a value or tag in the XML, but is in this case could very well have a different name/descriptor than what Trez initially has been looking for. The only thing that worries me is that even if it is found, the command wheel may no longer work properly since it seems that the touch variant is a completely different mode. May have to choose between one or the other and it isn't possible to have both at once without major hacking into the AA app via Xposed.
 
81 - 100 of 114 Posts
Top