Jump to content
AVIC411.com

Recommended Posts

So you are single handily deciding to slow progress for the development community, when you may know something that can greatly speed up our progress. That is not what this post and topic is about. It is about cooperation and working together to create software for our radios, that the manufacturer has decided to neglect. 

 

So either help us and be constructive, or don't waste everyone's time.

 

.

Share this post


Link to post
Share on other sites

You'll have a lot of time together with vke/whatis..for hard work and longtime awaiting...

Тhese people take a time and make a lot of progress for us , you make nothing , only promises , and now you say to us,  that we became nothing , it's realy good turn :)) it seems ,that you have nothing to give to us , only a game that you play hере ,  Ðндрей....

Share this post


Link to post
Share on other sites

Found some interesting stuff digging through the 1.10 backup image from my 8000nex.

 

Looks like carplay is called "DIO" internally. Smoking gun are dio_demo.jpg files that are screenshots or ads for carplay. Additionally the functionality of the classes referencing DIO look like they are working with carplay.

 

 There are a handful of classes so far relating to DIO. The jp.pioneer.ceam.mode.modescreen.DIO.SCR_DIO_Base class, which is found in the mode.apk,  has most of the basic functionality in it. This includes the display of the caution screen. First thing I am going to try is disabling the caution screen by editing the smali for this class. 

There are more references to DIO in other classes, mostly classes that manage the state of the UI/audio services. 

 

There are also many references to AAM. The base class for AAM in mode.apk looks MUCH more complicated than the carplay classes. I think this is appradio, but am not sure. I will take a look at the 8100nex image and compare to see if AAM is possibly android auto.

 

Attached the carplay DIO image file below. 

 

AV.apk -> /res/drawable-mdpi/dio_nex_demo_image.jpg

 

Dio Nex demo image

Share this post


Link to post
Share on other sites

Found some interesting stuff digging through the 1.10 backup image from my 8000nex.

 

Looks like carplay is called "DIO" internally. Smoking gun are dio_demo.jpg files that are screenshots or ads for carplay. Additionally the functionality of the classes referencing DIO look like they are working with carplay.

 

 There are a handful of classes so far relating to DIO. The jp.pioneer.ceam.mode.modescreen.DIO.SCR_DIO_Base class, which is found in the mode.apk,  has most of the basic functionality in it. This includes the display of the caution screen. First thing I am going to try is disabling the caution screen by editing the smali for this class. 

There are more references to DIO in other classes, mostly classes that manage the state of the UI/audio services. 

 

There are also many references to AAM. The base class for AAM in mode.apk looks MUCH more complicated than the carplay classes. I think this is appradio, but am not sure. I will take a look at the 8100nex image and compare to see if AAM is possibly android auto.

 

Attached the carplay DIO image file below. 

 

AV.apk -> /res/drawable-mdpi/dio_nex_demo_image.jpg

 

 

Agreed that DIO = Carplay. 

 

There are Services in the bin folder that get started by the init scripts on system property changes.

 

 

If you are familiar with mkboot, you can dd the 1st partition on the big image to a smaller image, then run mkboot to open it up and change it.  The init scripts are there on the system property changes.

 

The apks then seem to change system properties when you change modes.  Some start a DIOService others do Xm and etc.

Share this post


Link to post
Share on other sites

Nice!!

 

also, noticed adb daemon in the sbin folder on the /boot partition.

Has anyone tried having this run in rc.local or something? Maybe combo of enabling USB OTG and running the daemon? 

/wordlists/nex/boot/ramdisk/sbin# ls
adbd  andsnap  snapshot  ueventd  watchdogd

Share this post


Link to post
Share on other sites

Actually, what about changing the sys.usb.config to adb?

 

init.usb.rc

# adb only USB configuration
# This should only be used during device bringup
# and as a fallback if the USB manager fails to set a standard configuration
on property:sys.usb.config=adb
    write /sys/class/android_usb/android0/enable 0
    write /sys/class/android_usb/android0/idVendor 18d1
    write /sys/class/android_usb/android0/idProduct D002
    write /sys/class/android_usb/android0/functions ${sys.usb.config}
    write /sys/class/android_usb/android0/enable 1
    start adbd
    setprop sys.usb.state ${sys.usb.config}

Can we change this in default.prop?

#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
persist.sys.usb.config=mtp

Share this post


Link to post
Share on other sites

 

Actually, what about changing the sys.usb.config to adb?

 

init.usb.rc

# adb only USB configuration
# This should only be used during device bringup
# and as a fallback if the USB manager fails to set a standard configuration
on property:sys.usb.config=adb
    write /sys/class/android_usb/android0/enable 0
    write /sys/class/android_usb/android0/idVendor 18d1
    write /sys/class/android_usb/android0/idProduct D002
    write /sys/class/android_usb/android0/functions ${sys.usb.config}
    write /sys/class/android_usb/android0/enable 1
    start adbd
    setprop sys.usb.state ${sys.usb.config}

Can we change this in default.prop?

#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
persist.sys.usb.config=mtp

 

 

I have not tried that method yet as I thought it just gets overwritten. 

Share this post


Link to post
Share on other sites

I have not tried that method yet as I thought it just gets overwritten. 

 

 

Sorry, im a noob at this, not sure what the best way to change these android system properties are. I'll do some more research on this and how the init scripts work. 

 

I want to take a closer look at the debug proxy class as that may have some hints on how to enable adb just through the av debug menu, which is much more ideal

Share this post


Link to post
Share on other sites

Hmmm this looks promising: http://android.stackexchange.com/questions/55674/how-can-i-enable-adbd-during-boot-on-cyanogenmod

 

We can disable adb auth requirements and make it so when mtp is enabled, adb also gets enabled. 

 

I don't have access to my internal sd card till this weekend when I can pull the thing out of my car so just throwing suggestions in the air for now. 

Share this post


Link to post
Share on other sites

Found the DebugModeServiceProxy class . It is in framework/framwork2.jar, along with a lot of interesting pioneer classes.

 

The setting the usb device mode change method calls a native JNI function though, so have to do some more digging to find out exactly what that JNI is doing when setting usb to device mode

    private native int SetUsbPortMode(final int p0);

Also have been exploring the 8100 /system partition extracted from the PRG using the methods in AVIC.sh. 

 

It looks like the av.apk debug mode  indeed has a ton more stuff than that of the x000 series av.apk. Unfortunately, we can't just drop the x100 series av.apk in since it at the very least relies on new functionality in framework/framework2.jar. We will have to transplant both the app and framework folders into the x000 series. 

 

Has anyone already tried  replacing the x000 app and framwork folders with the x100 app and framework folders? 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×