[Android Head-Units] donaldta:
Last night, chris.davis925 gave me the opportunity to remote into his computer last night and we were able to root the device and install a few packages. We didn't get everything squared away but at least there is a processes. Chris performed a few things, so I do not know exactly what he did but I can give you a brief idea of how we managed to attack the issue at the end of our session.

First, thing is to of connect the USB peripheral cable between the DNN (with the power off) and your computer then start adbd on your pc, "adb start-server". Append the following lines to a copy of the build.prop file and place it into the platform-tools directory where the adb.exe command is located:

persist.sys.usb.config=mtp,adb [COLOR="Silver"]# sets up how the usb devices are perceived [/COLOR]
ro.secure=0 [COLOR="Silver"]# allows adb commands to be ran as root[/COLOR]
ro.debuggable=1 [COLOR="Silver"]# allows the system to be debuggable[/COLOR]
persist.service.adb.enable=1 [COLOR="Silver"]# enables adbd to run at boot[/COLOR]
persist.service.mount.playsnd=0 [COLOR="Silver"]# disable mount/umount sounds[/COLOR]
persist.service.debuggable=1" [COLOR="Silver"]# enables usb debugging [/COLOR]

I've added attached a copy of the file but if you're editing manually, make sure to use a program, like Notepad++, to ensure CR (Carriage Returns) characters aren not added to the end of the lines which other generic Windows editors do. This can cause Linux to parse the file inappropriately, as it only expects the LF (Line Feed) characters at the end of each line. In fact, I recommend to "View >Show Symbol > Show All Characters" to make sure only the LF characters are used in the file.

Insert a USB drive with the valid update files then power on up the machine allow it begin the update. Sometime during the update pull the drive out (timing of this will have to be verified by chris). This will allow you to connect to it with adb from your computer. The command "adb devices" will show "{android.serial#} recovery" where {android.serial#} is the hexadecimal serial number of your device.

You'll be able to use "adb root" to allow the commands to be processed as root. If you waited long enough in the update process then /system partition would have mounted and will have written some files. This will give you the opportunity allow you to overwrite the update's build.prop with the modified version using, "adb push build.prop /system". Then re-insert the USB drive to allow the update to complete.

It was late last night / early morning and we had a few unsuccessful tests. So, we also did a few other things which I am not entirely sure is necessary, like supply a copy of "sh" command. Because it appeared that the update.zip file did not include it. Chris also kept spamming "adb push build.prop /system" as the update process completed and even a little bit after. It would have been nice to know the appropriate timing for this or if spamming was at all necessary. But, it was pretty late and we were at a point where we just wanted results.

After the update sorted itself out and the DNN booted, the MTP and ADB devices appeared in the Windows Device Manager. We were then able to use "adb install" and "adb push" which was a great news. We used "adb install ES File Explorer_3.1.0.2.apk" and that installed the application and it worked according to Chris.

We also pushed a copy of Android Market to /system/app but it kept force closing upon launch. I suspect it also needed working copies of other files; Google Services Framework, Google Account Manager, Google Play Services and Gmail as suggested by this article, "How to Install Google Apps on the Kindle Fire HDX. (Yes, I know this isn't a Kindle Fire HDX but Kenwood left you pretty much in the same boat as Amazon since there is no Android Market / Google Play Store).

Anyway, there was a lot of unresolved issues which remained before calling it a night, like enabling "install from unknown sources" that need to be addressed. Hopefully, the following commands "am start -a android.settings.SECURITY_SETTINGS" and "am start -a com.android.settings.APPLICATION_DEVELOPMENT_SETTINGS" from "adb shell" as root will bring up some of the hidden screens in the Settings app. If Chris finds some time today we'll try to iron out the rest of the issues.