Lucca Posted August 12, 2015 Report Share Posted August 12, 2015 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. . Quote Link to post Share on other sites
LeshyLeshy Posted August 12, 2015 Report Share Posted August 12, 2015 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ере , Ðндрей.... Quote Link to post Share on other sites
fuzznec Posted August 12, 2015 Report Share Posted August 12, 2015 I've just brought 2 SD Cards to do some tests. Will give feedback soon. Quote Link to post Share on other sites
Meto Posted August 13, 2015 Report Share Posted August 13, 2015 This is great news.. So happy to see this is happening Quote Link to post Share on other sites
e0x70i Posted August 13, 2015 Report Share Posted August 13, 2015 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 Quote Link to post Share on other sites
bass_rock Posted August 13, 2015 Author Report Share Posted August 13, 2015 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. Quote Link to post Share on other sites
e0x70i Posted August 13, 2015 Report Share Posted August 13, 2015 Oh nice! Ok I'll take a look at those scripts Quote Link to post Share on other sites
bass_rock Posted August 13, 2015 Author Report Share Posted August 13, 2015 All, new developer menu that was discovered: http://avic411.com/index.php?/topic/81482-avic-development-mod-developer-debug-menu/ Quote Link to post Share on other sites
e0x70i Posted August 13, 2015 Report Share Posted August 13, 2015 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 Quote Link to post Share on other sites
e0x70i Posted August 13, 2015 Report Share Posted August 13, 2015 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 Quote Link to post Share on other sites
bass_rock Posted August 13, 2015 Author Report Share Posted August 13, 2015 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. Quote Link to post Share on other sites
e0x70i Posted August 13, 2015 Report Share Posted August 13, 2015 Have you found which apk or jar the jp.pioneer.ceam.widget.DebugModeServiceProxy.* package is in? Quote Link to post Share on other sites
e0x70i Posted August 13, 2015 Report Share Posted August 13, 2015 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 Quote Link to post Share on other sites
e0x70i Posted August 14, 2015 Report Share Posted August 14, 2015 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. Quote Link to post Share on other sites
e0x70i Posted August 14, 2015 Report Share Posted August 14, 2015 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? Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.