yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] donaldta:
It should be too much of a stretch to use. Much of using the actual JTAGulator is menu driven text. Since you are in IT and were able to do some research to try signing the update.zip file, I think you're probably the most qualified person in this thread that has the unit to use it with. I'm not sure what part of IT do you specialize in; however, if you have any experience with Linux then you can apply a lot of it to Android. Android runs on top of the Linux kernel afterall.

My advice, watch a couple of videos that are linked from the JTagulator home page. Read up on a few tutorials. It really should not be a far stretch to use by anyone in an IT position. They are designed it to be relatively simple to use. That was the whole point of the project. Besides, you may end up taking hardware hacking as a hobby and start opening devices you had never thought of just to see what you can do.

Or, if you are still uncomfortable just wait for someone else to pick up on it. Nobody will blame you either way.

Btw, I'm not sure if the following message was from a troll or if he was truthful... but you might want to check with this guy...
[Android Head-Units] sciallo:
Seems like he has too good of a posts-to-thanks ratio to be trolling, that's why I was curious to know what unit he was talking about...
[Android Head-Units] chris.davis925:
So I thought I would post that I tried to modify the contents of update.zip and got the dead android thing. It never quite rebuilt correctly after that and the unit crashes on video input (DVD, USB video and Reverse cam after the unit powered up). Kind of a bummer, but also interesting since that means it made some incorrect change to the system apps/settings to cause this.

I am looking into the JTag hardwarer thing. I am not worried about hooking it up per say, but more worried about the "Now what?" once I've purchased it.

---------- Post added at 04:24 AM ---------- Previous post was at 04:15 AM ----------

Just curious if you have any kind of update.

[MENTION=5389783]donaldta[/MENTION]: Do you own this unit? If so, it seems you pretty well versed in this kind of thing. Have you thought of giving this a shot?

If you don't own the unit, maybe we should get you one?
[Android Head-Units] donaldta:
I'd give it a try if I had one. It is just an incredibly expensive unit for its current (lack of) capabilities which is why I don't.
[Android Head-Units] chris.davis925:
The refurb units are around $600 bucks and work exactly like a new one. What would you consider a "good" price point that you would pay?

In other news I was able to detect two open ports on my unit.

Port 54006

Port 58058

I don't know how to attempt to communicate to the unit on either port, though, Seaching google didn't provide any useful information to me on what those ports mean, other than a reference to port 54006 on a Kenwood radio...for serial connection?

It appears (with very little testing though) that the first port opens only when my unit is in a quazi frozen state.

Anyone have any thoughts on this?
[Android Head-Units] donaldta:
That's the thing. I already have an Parrot Asteroid Smart, so I have don't have a need for a new/used head unit. Possession of it would only serve to pursue an intellectual curiosity for gaining root and seeing what it is actually capable of doing.

You might try connecting with telnet to those ports to see if it gives any feedback. Maybe install the Android Developer Kit to see if it will connect using "adb connect {ip.address}:{port}".
[Android Head-Units] aplusmiami:
Sorry been away - There are doing an freaking IT audit at work so we are under the microscope.. I don't want a non-company anything anywhere near my desk. And with two babies at home - I just do not have the time to look at the second unit I have here anytime soon.

I do have one question for those of you running this unit tethered.

I have an HTC LTE 4G on Sprint. Rooted - I can see and connect to the HTC with every device except the freaking Kenwood (Does not show SSID... I tried all WPA WPA2 etc.. etc..) The Kenwood does scan and see other routers, just not the phone.... Any ideas??? I am on CH 11 and have tried 4 6 and 7.
[Android Head-Units] donaldta:
I cannot find anywhere in the specification which 802.11 protocols it supports maybe that's part of your problem OR it doesn't like your SSID.
[Android Head-Units] jbeavis19:
You might be broadcasting 5ghz from your phone and the Kenwood doesn't support it.
[Android Head-Units] aplusmiami:
I tried forcing the phone to 2.4 GHz no go..

Also from the manual it is suppose to support (Not sure why the English manual is in Spanish):

Sección de Wi-Fi

IEEE estándar

: 802.11b/g/n

Soporte de seguridad

: 64/128 bits WEP/WPA & WPA2

Gama de frecuencias

: 2,401 - 2,473 GHz

Tasas de transferencia (MÁX.)

: 802.11n (150 Mbps)/ 802.11g (54 Mbps)/ 802.11b (11 Mbps)

Potencia de salida

: 16 – 18 dBm (CCK), 13 – 15 dBm (OFDM)
[Android Head-Units] donaldta:
Yeah, since it doesn't do "802.11a", it is pretty safe to assume it doesn't support 5 Ghz but you already tried 2.4 Ghz. Maybe try not having a complicated SSID like "fred" or "barney". Some garbage WiFi modules don't like fancy long names or special characters.
[Android Head-Units] aplusmiami:
Ok I had to first force 2.4 in Wi-Fi tether, change the ssid and start tethering. Now it sees it.
[Android Head-Units] donaldta:
Heh, heh. You'd think for a item that has a $1,600 MSRP, it would include a less crappy WiFi module.
[Android Head-Units] chris.davis925:
Last night I extracted some more APKs from the update.zip file and tried to install them to the unit to see if t would accept any of them. Each one (as expected) indicated that it cannot install because it doesn't allow installs outside of the "Android Marketplace".

So I started poking around some more to see if I could get file level access to the internal storage and found that the only way to do this is using the browser and navigating to file:/mnt/device etc. I was able to open to /system/build.prob etc using the browser.

So then I started thinking, maybe we can modify the configuration areas or copy and replace some configuration files to enable things like USB Debugging or Install from Unknown Sources, but of course the browser doesn't allow you to save/make changes. Same thing with the "HTMLViewer" which is the only other app I could think of.

So this led me to a few questions. Sorry for my ignorance of not being from a linux background, but I figured I'd ask.

1)Does Android have a build in terminal/command window of some kind? If so, maybe I can open it directly by navigating to the app? Which leads me to my next question....

2) I know APK files will install the app, but what is Android actually running? For example. Windows runs binary complied code in with a .exe file. What exactly is Android executing when it opens an app? Perhaps this information is useful to then try to manually execute a defualt app, like hopefully a terminal app?

3) Assuming that there is in fact some of kind of file that we can edit on the device that would help us "open" it up more (like USB debugging for example), what file(s) would be worth looking into?

a) Anyone know of any web apps that provide a directory structure of the connected device? I know this is a stretch, but I thought that maybe an online Java app (assuming Android can natively display this???) can query the local file system, and maybe even write changes back.

4) This one is kind of stretch, but can commands be executed from the browser window? Perhaps a command can be executed by referencing an installed app (like termnal?) with an appended command at the end?

For example, in windows if you type C:\Windows\System32\cmd.exe ECHO C:\Somefile.extension >> "Write some text to the file here" - in Explorer.exe it will actually execute cmd.exe and write a line of text. Just curious if Android has some kind of similar way.

Feel free to chime in on any of the above.
[Android Head-Units] donaldta:
Yes, it is called Android Debug Bridge (ADB). However, it is normally not available through the common user methods.

The main app runs as dalvik runtime code in a virtual machine. This code is contained within the APK (which is a zip file) as the classes.dex file.

The /system/build.prop but that is mounted on a read-only file system or /data/local.prop file. Sometimes you can add "ro.kernel.qemu=1" to the /data/local.prop which grants shell access to ADB port by tricking Android that it is running under an emulator.

The irony is that a Java runtime isn't normally included in the stock browser. Most stock browsers on Android only runs Javascript as far as I know. And despite the name there is no actual correlation from Java with Javascript. It's like making a correlation between Ham and Hamburger or Hamster.

If there was then there really wouldn't be this much problem unlocking any Android device.
[Android Head-Units] aplusmiami:
Excited to see someone probing this unit. I will try and disassemble my unit to try to identify the port.
[Android Head-Units] chris.davis925:
Thanks for those answers.

So I am gonna ask the obvious question here.... anyone know of any way (weather through the browser or not) to write back data to the internal storage? I am able to open build.prop. It only has two lines, but of course I have no way of writing changes back.

Also, anyone have an idea if the USB spec in general only works one way? The reciever has several USB ports that are female, does that mean that it is physically incapable of someone "tricking" it into not being a USB host and allow itself to be recognized by a PC?
[Android Head-Units] donaldta:
Yes, there are plenty of ways to do that however it requires third-party apps to be installed. Kinda stuck with a catch 22 there.

Btw... can you supply the output for the /system/build.prop and /data/local.prop files? Maybe try emailing a copy of them to yourself.

The full sized USB ports don't really have a way to change and are stuck as USB host or client port whichever is setup by the controller. The mini-USB and micro-USB ports are usually client USB ports but can signaled by the cable to switch its role through its 5th "ID" pin. This specification is known as USB On-The-Go (OTG).
[Android Head-Units] aplusmiami:
I am a novice at best so be gentle with me... - Couldn't we look at the binary files in the latest firmware and somehow decompile them? Just Brain Storming... I would love to think we could get at the unit at the adb level but maybe the only way is through firmware updates.
[Android Head-Units] donaldta:
You can decompile the APKs and JARs from the firmware update. However, I don't know if there's a way to decompile any of the other binaries.

What exactly do think you'll accomplish by decompiling binaries?
[Android Head-Units] chris.davis925:
I couldn't find a default.prop. Mind you, there is no explorer so I am just guessing locations. Below are directly copy and paste from the device. I also include build.prop since it looked like it might be useful too.

system\build.pop

default.prop:
[Android Head-Units] donaldta:
Thanks. I reformatted it for you since Windows has the deficiency of requiring a carriage return AND a line feed. The above is what I think it should look like with a decent text editor.
[Android Head-Units] chris.davis925:
GREAT NEWS!

I got ADB to connect after some fiddling.

I have no idea what to do now. Can someone help me out?
[Android Head-Units] donaldta:
Whoa! The Telechips TCC8800 processor included in the DNN990HD is a single core Cortex-A8 processor. Again, $1,600 MSRP is really expensive for a single core processor Android device.

---------- Post added at 08:53 PM ---------- Previous post was at 08:50 PM ----------

After "adb connect" try "adb shell" which will drop you to a linux command prompt. Try "id" to see what kind of user you are, and "mount" to see the kind of mount points are available.

Btw, how did you get ADB to connect?
[Android Head-Units] chris.davis925:
It says connected, but when I do adb devices it shows dissconnected for some reason. The device is also in a quazi frozen state now too. still responds but menus dont respond any more etc. I gotta get gas before I stall in my drive way. I'll be back soon.
[Android Head-Units] chris.davis925:
So i tried on different computers and I get the same result. ADB Connect IP:54006 results in a successful ADB connection, but then ADB shows the device as offline.

I checked on Google and the biggest result was that this might be because USB Debugging is not enabled.

The build.prop info seemed to make reference to it, and it seems like it might actually be enabled by default? Thoughts?

On another very random note, I found a .sh file which I assume to be the eq of a Windows .bat file for Linux and it seems to be notated very well by the Kenwood dev. Thought I would post it in case it helps generate any leads...

Also from a different file...
[Android Head-Units] oxman504:
Just want to say thank you all for trying to get root or at least some more apps. I just ordered one and it should be here Monday. I can't wait.

One question though, what about the internet going through Kenwood's servers? If we get root will that circumvent their servers so we don't have to paid the $60 fee at the end of our 2 year free script?

I don't know why Kenwood used Android just to lock down. The whole point of Android is OPEN SOURCE.

---------- Post added at 11:02 PM ---------- Previous post was at 10:50 PM ----------

Maybe try reloading the latest update?
[Android Head-Units] donaldta:
First, I have to ask how are you connecting? Your last message seems to elude that it is in a "confused state" when you can connect this way. So, I wonder if it is just another daemon that giving the correct responses but not actually allowing the connection.

Btw, can you point where in the build.prop seemed to make reference of it?

What are the relative filenames of the .sh files and where exactly did they appear?

This line "ifconfig eth0 10.0.2.15 netmask 255.255.255.0 up" tells me that one of the ethernet devices is being set up as 10.0.2.15 ip address with a netmask of 255.255.255.0 if this is true then perhaps you can set up your computer/laptop to 10.0.2.16 with a subnet of 255.255.255.0 and maybe try to connect to it via adb or other means.

The other one isn't really anything special and is just dumping an adb debug report & screenshot if the ro.build.type=xuser but the build.prop you shared indicates, "ro.build.type=userdebug ".

---------- Post added at 11:29 PM ---------- Previous post was at 11:10 PM ----------

Sorry, man. Unless you paid around $100 to $200, I think you got ripped off.

Maybe if someone can redirect those services to a private server offering the same services.

It is because they're trying to make money and provide a their users with a "consistent experience". And by the evaluating the hardware provided they're probably making an 80 to 90% margin on this device.

I love when I see people write this because it usually means they have no idea what that means. Yes, the core Android Open Source Project has been made available by Google but that doesn't stop companies from trying to protect their intellectual properties and make money from it.

The point that is open source is valid for the developers and manufacturers NOT for the end users. Because open source denotes that software for which the original source code is made freely available and may be redistributed and modified. Not that they give everyone free reign for end users on the devices. That's because Android is actually licensed under the Apache License 2.0 which allows commercial innovations to freedom of not having to donate back to the open source community.
[Android Head-Units] donaldta:
The line "ro.debuggable=1" means that all the applications running on the system can be debugged using the Java Debug Wire Protocol (JDWP) that is part of Dalvik Debug Monitor Server (DDMS) which is now a part of monitor.bat from the {android.developer.kit}\sdk\tools\ directory.

You are correct in your assumption that the "persist.sys.usb.config=mass_storage,adb" that USB can be used to connect as ADB but the other option refers for the internal storage of the DNN990HD having the ability to be mounted on a computer as a mass storage device. As opposed to being used with the Media Transfer Protocol (MTP). Are you sure that there aren't any microUSB or miniUSB ports anywhere on the radio? One possibility is that's the port on the side of the unit could be a USB client port for this very reason.

Actually, it looks like they are starting eth0 with a hard coded IP address whereas your WiFi is probably occurring on eth1. The init.goldfish.sh script by the way is one of the start up scripts that is used to setup the Android UI. I don't know if eth0 is a WiFi connection or maybe a physical ethernet connection with solder pads on the board. But, it is possible that the Android Debug Bridge is binded to eth0 but not eth1. Maybe check the 2.4 Ghz spectrum for 802.11 b/g/n for any SSIDs while the power is on and disappears while the power is off. Or even try using a wireless ad-hoc connection to the 10.0.2.15 ip address.

It is actually not only possible but probable. Many Android devices which require a hardware hack often uses methods similar to this to gain root.

---------- Post added at 12:25 AM ---------- Previous post was at 12:22 AM ----------

No worries. All that file is doing is setting up the environment (variables, prompt, command aliases) for terminal access. It is more relevant for when you have terminal access as opposed to getting terminal access.
[Android Head-Units] chris.davis925:
Interesting that the .sh file is being loaded on startup. I'm pretty sure you're also right that we can't get to via wifi. From I can gather Android is assigning wlan0 to the wifi adapter.

So we are back to our best bet being someone looking into that connector on the side of the unit and or hard wiring something to the board.

Personally, it's a little outside of my comfort range.

Just a question: Lets say we do rig USB or even adb via eth0, is this going to do us any good if usb debugging is not enabled since it appears you cannot enable it via adb?
[Android Head-Units] oxman504:
I don't know of any quality DD radios that you could get for $100-200. Every single business has a big mark up. Take a CD for example. It takes what .02 to make, but they sell them for $15. I got a refurbed for $700. That's not bad for a flagship DD radio. For all the things it can do without being rooted that is a fair price that I was willing to pay. I played with all the big three top of the line DD radios and am a Alpine fan, but the Kenwood has some better features like gold plated 5v preouts instead of 4v standard connections and the fact that you can use the sd card as a media device. If someone bought this DD just because it is an Android then yes they are getting ripped off. If they want an all around good DD with wifi they it's a great deal.

I miss understood what open source meant, but my point was why did they limit the apps that can be used? There are tons of apps that could be used in a car environment that wouldn't hinder the drivers focus on the road. Maybe it's not the best thing to come but it's a good start.
[Android Head-Units] donaldta:
Based on the crappy hardware on the Kenwood DNN990HD and the lack of any true Android customability, it would be easy for me to skip it and grab either a AN-21U which is offered at 1/4 of the price or the WD8801 that is offered at 1/3 of the price. Plus, I would have root access and the freedom to install any app from the Google Play store. And I wouldn't feel like Kenwood just ripped me off with a unit that I would compare to a $200 Chinese WinCE clone because of its bloated garbageware and limited functionality.

For something that has a $1,600 MSRP they could have at least included a 5Ghz radio with WiFi module that doesn't have limitation on the SSIDs it can connect to.
[Android Head-Units] oxman504:
Like I said I don't know of any QUALITY DD for $100-200. If you're trying to compare those Chinese DD to any of the big three you're sadly mistaken. I watched the video and the guy describes many bugs including the screen, a built in mic that isn't worth a poo, the fact that you have to factory reset just to get rid of some apps and you need a password to install any third party apps.

I like the fact that if something goes wrong with my unit I can send it back to the manufacturer and get it warrantied or fixed. Good luck sending it back to Hong Kong.

If the DNN990HD is such a crappy unit then why are you on a thread about making it better? Obviously you think it has some potential. I'd like to get back on the topic of making the DNN990HD better.
[Android Head-Units] donaldta:
It is because I feel sorry for those of you whom wasted so much money on it. Besides, it also doesn't appear that anyone that has one posses the technical ability to get root access. Most likely because anyone with the technical abilities would avoid it. So, that's why I am helping. I give my assistance to owners of all Android Head Units included the Sensus Connected Touch which is a $1,700 head unit from Volvo.
[Android Head-Units] oxman504:
Don't feel sorry for me. I am 100% satisfied with my purchase. Now if I spent $1600 then I'd feel bad for myself. I have friend that has a 990 so I got to play with it extensively along with talking to several high end audio shops that sell the big three. I've been eying it up since before it came out and have done a lot of research. The only way to get everything that you want out of something is to build it yourself.

Personally I think bluray and higher resolution screens are long overdue for car audio.

If they never get it rooted it's not the end of the world. If they do it will make it all that much better. A DD should be just that, something that gives you as many audio/video sources as possible with the best possible audio quality (given its swiss army knife package) and have good phone connectivity. I and many others think it does just that.
[Android Head-Units] chris.davis925:
Thank you for all your help. It is greatly appreciated :)

What do you think about my last question regarding the usefulness of usb or eth0 connection if usb debugging is potentially not enabled?
[Android Head-Units] donaldta:
Well, I don't believe in your previous attempts that you connected to eth0 since that has a hard coded IP address. Most likely, your attempts occurred on eth1 while it was connected to your WiFi gateway. As for USB Debugging being enabled or disabled, it shouldn't matter unless you're connecting to a USB port. The correlation between that setting is [persist.service.adb.enable] = 0 (off) or 1 (on) from the system properties. However, that doesn't mean adbd is not available from a non-user supported network interface or a TTL port on the logic board.

Let me give you an example on one of my Android devices (which all have USB debugging option turned off, I only turn it on when absolutely necessary because it is a security risk).

C:\dev\20130729\sdk\platform-tools>[COLOR="RoyalBlue"][B]adb start-server[/B][/COLOR]
* daemon not running. starting it now on port 5037 *
* daemon started successfully *

C:\dev\20130729\sdk\platform-tools>[COLOR="RoyalBlue"][B]adb connect 10.203.40.42[/B][/COLOR]
connected to 10.203.40.42:5555

C:\dev\20130729\sdk\platform-tools>[COLOR="RoyalBlue"][B]adb shell[/B][/COLOR]
$ [B][COLOR="RoyalBlue"]getprop | grep adb[/COLOR][/B]
[persist.service.adb.enable]: [0]
[init.svc.adbd]: [running]
[service.adb.tcp.port]: [5555]
$ [COLOR="RoyalBlue"][B]getprop | grep ipaddr[/B][/COLOR]
[dhcp.mlan0.ipaddress]: [10.203.40.42]
$