yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] chris.davis925:
I see. Good to know. I am going to try my final attempts with two things this morning.

1) Try to assign the WLAN the same IP that the Kenwood eth0 is being assigned by default. My hope is that possibly lunux will bridge the two connections since it's not good technical practice to have the same IP on the same device. Perhaps it will result in something good, perhaps not.

2) Make changes to update.zip using the master key exploit. Previously I tried to do this only by making changes to a system\app APK and then downloading onto the unit. We know that doesn't work because unknown sources option is not enabled. My hope is that by having it process the entire update.zip it will only verify the signature on a per APK basis and not an expected hash of the entire update.zip file.

With that being said, I decompiled settings.apk and made changes to settings_headers.xml for the id development_settings and changed the ID to development_settings_force.

Also made the change to values/ids.xml as indicated here: http://xdaforums.com/showthread.php?t=2184207

I now have two more questions.

1) Assuming this works, is there a better area I should be modifying to display the developement settings area? It appears that settings.apk has XMLs for a lot of settings that aren't displayed on the unit. For example, development_pregs.xml or bluetoothsettings.xml.

2) development_prefs.xml has this lline:

<CheckBoxPreference android:title="@string/enable_adb" android:key="enable_adb" android:summary="@string/enable_adb_summary" />

Makes me wonder, how are the default values set? Is it the values/ids.xml file? If so, perhaps it's enough set the default value of ADB to on?

---------- Post added at 06:59 PM ---------- Previous post was at 06:56 PM ----------

Actually, after thinking about this for a while, perhaps a better question is:

Where is it defined what will and will not show in settings.apk? I am pretty sure it must be defined somewhere else to hide a lot of the values?
[Android Head-Units] aplusmiami:
Attached are pic's of the CPU and Circuit Board, you will see a 4 pin connector on the circuit board which look like the outer pins go to ground. The other two go to a chip resistor and onto the CPU... There is a window on the side but I do not see any connections on the side of the unit. Does anyone have the CPU partno where we could possibly get the pin outs / ports. Also the SD card only has Garmin Map information and a linux partition with additional Garmin Map information.
[Android Head-Units] donaldta:
I don't think that will work since most network operating systems will refute the IP address of a pre-existing device on the same network. The best case scenario is that your router will be confused where to send the packets. A better plan would be to assign it an address within the same subnet. Since the DNN990HD's eth0 is set up with "10.0.2.15 netmask 255.255.255.0", it means the network subnet is 10.0.2.0 and has valid IP address ranging from 10.0.2.1 to 10.0.2.254 with 10.0.2.255 as the network's broadcast address. You might be able to disguise your other device as the default gateway "10.0.2.2" or one of the three DNS servers, "10.0.2.4, 10.0.2.5 and 10.0.2.6".

Btw, have you tried looking for a SSID in the 2.4Ghz range that appears/disappears while the DNN990HD has power/no power?

Wait. Why didn't it work? When you install an update via the recovery bootloader, it does not have any relevance to the "unknown sources" option. The recovery bootloader isn't checking the individual signatures within the packages of the /system/app directory in the update.zip file. It is checking if the file matches the signature listed for the update.zip's key certs. This is similar to the individual files within a signed APK that is checked. If you are able to inject files then maybe it would be better to inject /system/xbin/su and /system/app/SuperSU.apk to gain root access.

The "unknown sources" option is a setting that tells Android's package manager whether or not is okay to install APK other than the Android Market / Google Play. So, if you were able to sneak in an APK through the recovery bootloader with a update.zip file then you bypass the need to install the APK through package manager.

Wait. Huh?

Interesting. I have to look into that because as far as I know the settings.apk is signed with the platform key for the SharedUserID, "android.uid.system", which makes it impossible to change without altering everything tied to that key/id. Which is essentially part of the initial steps in making a custom ROM.

The default settings are set in the following files if they exist.

/default.prop

/system/build.prop

/system/default.prop

/data/local.prop

Whereas the current settings are stored as a sqlite database in /data/data/com.android.providers.settings/databases/settings.db

That actually depends. The Settings.apk is kind of still magical to me because there is no single point where that determines which settings are available. Some settings are added because an APK is present, other settings are available because of certain .xml files are available in the /etc/permissions directory, and other options are loaded because certain jar files are loaded from the /system/framework directory.
[Android Head-Units] chris.davis925:
-No SSID popping up that I can see.

-Setting IP to the 10.0.2.15 address doesn't make any change. Unit still responds normally to that IP. I think the difference is that the SH script references eth0 and the kenwood calls the current WiFi dongle wlan0

"

Quote:

Originally Posted by chris.davis925 View Post

My hope is that by having it process the entire update.zip it will only verify the signature on a per APK basis and not an expected hash of the entire update.zip file.

Wait. Huh?

"

My point was that I was gonna try to inject a modified APK into the system\apps list of update.zip. That didn't work, it fails with the same android dead icon during the update process.

So, does update.zip have a signature that it checks? Does it compare expected hash size or something like this? It's interesting that depending on what you change it will fail at different point. I would think that if Android is checking update.zip as a whole it fail at the same place every time?

Also worth noting that there is a file that is required that sits next to update.zip (actually called update.kw) called program info.bin.

Comparing the different versions with a hex editor shows they are mostly the same but a few bytes change. I am curious if this is just use to check if the current version is higher than the the corresponding update.kw? Or perhaps, it's used to indicate how large the file is? I guess I am interested to see if it uses this file at all to check against update.kw in the update process or if it's just used to check update.kw BEFORE the update process.

I don't have any knowledge on how signing .zip files work much less how Linux/android is checking the zip file during the update process.

btw - changing settings.apk didn't work.

---------- Post added at 09:05 PM ---------- Previous post was at 09:04 PM ----------

Sorry if I am misunderstanding, but where you able to trace where this plugs in?

dl.xda-developers.com/attachdl/cf5eb8bd1cd06162a2078a4adb55bf1b/52f6940d/1/9/5/0/0/9/9/20130507_192307_1_.jpg
[Android Head-Units] aplusmiami:
It is a connector on the mobo and apparently the traces lead to two chip resistors then continue under the CPU. The USB connections are in the same neighborhood.. so maybe this is some sort of test plug or another USB port. I would like to know how many USB ports this CPU before plugging it into data - and data +.
[Android Head-Units] donaldta:
You might want to check to see if you can get the output of /proc/net/dev file and it will show your registered network devices.

Maybe consider reading the following link in regards as a precursor to understand why we "sign APKs and firmware" updates. Btw, the signing of APK and update.zip files is borrowed from Java and we still use jarsigner to write the signatures.

The recovery bootloader would look for a META-INF directory which contains CERT.RSA (X.509 certificate), CERT.SF (Signature File) and MANIFEST.MF (Manifest File) and this information is compared with the contained files to prove their authenticity. You can actually read the MF and SF files. They are plain text documents. Maybe you'll get better idea when you check their contents.

I do not know. Never seen that file before.
[Android Head-Units] chris.davis925:
The telechips diagram shows three. I'm not looking at it right now but in remember USB OTG?, usb host and USB 2.

I would say give it a test with a volt meter first?? But I'd think It's worth giving a shot
[Android Head-Units] aplusmiami:
Can you upload what ever info you have on the CPU. I will measure to see if any dc voltage exist. And then I need to come up with a pigtail.
[Android Head-Units] chris.davis925:
I can't find a manual or diagram per say, but here are some interesting links on the TCC8800. It's worth noting that the manufacture distributes test boards with Android 4.0.4. I wonder if Kenwood used the same base? If so, maybe the same keys?:

http://androidfragmentation.com/dat...hips TCC8800 Evaluation Board/carrier/Unknown

http://wenku.baidu.com/view/1123f60eba1aa8114431d9fc.html

This link answers your question about how many USB controllers etc:

http://www.csselectronic.com/joomla/index.php?option=com_zoo&task=category&category_id=6&Itemid=56

Here is a link on clockwork mod for 8900x series telechips CPU with a driver. Might be worth looking into?

http://www.slatedroid.com/topic/861...recovery-for-telechips-based-android-tablets/

Update:

Also there is this link that was posted earlier that shows a generic block diagram of the motherboard. It shows Ethernet, serial and USB. I would be interested (if the USB doesn't work) to see if we can get an Ethernet cable pinned out from the board. This might give us our eth0 assigned that we have discussed earlier which can lead to getting ADB to work via network.

http://www.telechips.com/eng/Product/consumer_pro12.asp
[Android Head-Units] donaldta:
I believe he was looking for the number of "ports" not "controllers". Since you can have many ports from each controller. You might be able to get this information from your browser by getting the output of "/proc/bus/usb/devices". I believe you were using "file:///system/build.prop" to get the output for /system/build.prop file, so you should be able to get the same syntax with this to get more information about USB. Btw, did you happen to get the output of /proc/net/dev ?
[Android Head-Units] aplusmiami:
I believe this processor had physical USB ports. So if three is what they list. Then we are stuck.
[Android Head-Units] donaldta:
There's nothing that says its only three, chris.davis925 was referring to a block diagram which is an overview of the technology that it supports. Not how many USB ports it supports. For that, we'd need a data sheet for the processor. Btw, you had took a picture of the CPU but the identification numbers were not legible. Anyways, would you mind jotting it down?
[Android Head-Units] aplusmiami:
That's is exactly what I need (data sheet). I thought we knew what CPU it is.. Not just the family. - I will get you the part no in the morning.
[Android Head-Units] chris.davis925:
I tried this and it doesn't work. For starters it's a pain because the browser doesn't list directory lists. Good news is that it will give an error if you type something that doesn't exist.

bad news is that extensionless files just display a white page.

I think maybe the browser gets confused with a directory or it just doesn't know what to do with an extension-less file

---------- Post added at 04:43 AM ---------- Previous post was at 04:04 AM ----------

I am willing to be wrong about this, but I am pretty sure that DNN900HD contains a a TCC8801. I know you are going to look at it tomorrow.

If that ends up being the case, here is a CPU spec sheet I found:

http://www.bidouilles-numeriques.co...ownloads/articles/TCC8801_CHIP_SPEC_V1.02.pdf
[Android Head-Units] aplusmiami:
FYI- This connector has been removed in the two units I have.

---------- Post added at 03:15 PM ---------- Previous post was at 03:07 PM ----------

It is indeed a TCC8801 - There are 3 USB ports and that's it.. 1 USB2 OTG, 1 USB2 and 1 USB 1.1.

In addition to the connector on the top side, I found a flex connector on the bottom side of the Mobo.

I will upload detailed pics of the Mobo when I get to work. I removed the CPU board from the unit.

Maybe we can find a Kenwood Engineer that can anonymously give us some instruction...
[Android Head-Units] siralsmooth:
Maybe call one of the service centers and talk to a tech. I was thinking about it myself, but they're usually tight lipped.
[Android Head-Units] donaldta:
What about on the back of the unit? There are three spots that are not labeled which have potential.

If there is truly a 1:1 relationship with the USB ports and the CPU pinouts then the connector for the USB2 OTG should provide the ability to connect to the unit as a USB client necessary to connect to ADB from a PC. I noticed on the connecter at CN901 and CN903 there are 5 / 10 wires. Are these for the external USB cables? Since Host USB ports only require 4 pins; 5VDC, Data -, Data + and Ground, then check to see if there's a loop in the ground cables for either a short or a resistor between them

For more information the Table 4-2 on page 10 of the "On-The-Go Supplement to the USB 2.0 Specification" pdf. Particularly these lines, "A dual-role device is required to be able to detect whether a Mini-A (host) or Mini-B (client) plug is inserted by determining if the ID pin resistance to ground is less than RA_PLUG_ID or if the resistance to ground is greater than RB_PLUG_ID. Any ID resistance less than RA_PLUG_ID shall be treated as ID = FALSE and any resistance greater than RB_PLUG_ID shall be treated as ID = TRUE.".

Good, that might give us a better reference.

I highly doubt that.
[Android Head-Units] chris.davis925:
I am excited to see the pics.

Excuse my ignorance here, but if we have identified the three USB interfaces, is it not as simple as pinning out the USB OTG?
[Android Head-Units] donaldta:
o_0 Did you post this without reading a single word I just wrote in the previous message?
[Android Head-Units] chris.davis925:
lol you must have just posted that in between the time I clicked reply and wrote my response.

I am excited to see the result of of attempting to get USB connectivity to work!!!!

Update:

In case you haven't had a chance to reference it yet, this PDF lists the correlation between USB and the CPU: http://www.bidouilles-numeriques.co...ownloads/articles/TCC8801_CHIP_SPEC_V1.02.pdf

page 3-20
[Android Head-Units] dgerryts:
Been shopping around for a decent head unit...

Had anyone tried Settings>About "Device" > tap build number 7 times? This usually enables developer options on some devices. It is also where usb debugging and unknown source toggles usually live....

Just my two cents....
[Android Head-Units] donaldta:
Yes, thanks. I have already looked it over after you initially posted it. More importantly, table 3.12 on page 3-24 points out the "USB2.0 OTG (PWROTG33A) Group I/O Pin Description" and specifies ball K24 as the OTG_ID. However, it is impossible to know where that is based on the current pictures. I'm afraid even with high resolutions pictures it may not even be quite as obvious since this processor is a Ball Grid Array (BGA) so the traces begin under the processor as opposed to its sides.

---------- Post added at 12:13 PM ---------- Previous post was at 12:09 PM ----------

It doesn't hurt to try, but that is actually specific to Android 4.2 and above as specified in the Android Developer site. That would be a weird thing to backport though into a year old 4.0.4 Android device.
[Android Head-Units] chris.davis925:
I'm glad and thankful that you know far more about that than I do. :o

[/COLOR]

Already tried this long time ago and of course, it doesn't do anything.
[Android Head-Units] aplusmiami:
Detailed images of CPU board part 1

Here are some detailed images
[Android Head-Units] aplusmiami:
Detailed images of CPU board part 2

Part 2
[Android Head-Units] aplusmiami:
Detailed images of CPU board part 3

and part 3.

The underside image shows the flex connector that is not connected.
[Android Head-Units] aplusmiami:
Top far right is the Parking Brake/Reverse/Relay connection

The idatalink is for Maestro (Ford Sync) and Steering Controls.

The others are not documented I will have to investigate.

---------- Post added at 05:29 AM ---------- Previous post was at 05:21 AM ----------

Just to keep interest up - Kenwood is coming out with a newer model 991HD which will have a new LCD, their own store, a Verizon air card and more apps built in. Apparently the hardware remains the same. They just force everything to work through their portal. Which from what I have heard will have and annual subscription after 2 years. We need to crack this thing. I have tried the Chinese stuff and it does not come close to the quality of this unit.
[Android Head-Units] chris.davis925:
Can you try to identify the Pinout for USB otg per the manual?
[Android Head-Units] chris.davis925:
aplusmiami is that something you can check/ do?
[Android Head-Units] chris.davis925:
While we wait for his reply, I want to ask what might be a really dumb question....

when you say test the ground / create a short in the USB wire, can this be done with the standard USB wire coming out of the back of the unit?
[Android Head-Units] donaldta:
There are no dumb questions. Only irrelevant questions not concerning the topic. Like, "Why is the Sky Blue? If we turn the clouds pink can we get root access?"

Anyways, the answer to your question is "yes" and "no" because the modification would have to be done near the internal connector for the USB wire coming out of the unit. Let me explain why.

The top row of the illustration are full sized USB ports. Their roles cannot be switched. Type A are usually used for connections into a USB Host where as Type B are used for a USB (client) peripheral. Notice the amount of pins inside the connectors. There are only four.

+ 5.0 VDC (usually red)

Data - (usually white)

Data + (usually green)

Ground (usually black)

Now look at the next two rows for miniUSB and microUSB connectors. They have five pins.

+ 5.0 VDC (usually red)

Data - (usually white)

Data + (usually green)

ID (usually a short or resistor to pin 5 if present)

Ground (usually black)

If these ports or cables are connected to a USB Controller which supports On-The-Go (OTG) then the roles of port / cable can be switched regardless of its type. If there are no short or resistor between pins #4 & #5 then the cable/port remains to be a USB (client) peripheral. If there is a short or resistor between pins #4 & #5 then the port / cable becomes a USB host.

Now take a look at (what I think are) the connectors for the USB cables (since the colors match the typical wiring for a USB cabling).

The number of wires in the cabling would elude that there are 5 wires per port, yet a full sized USB connector only requires four. So, if there is truley a 1:1 USB port to CPU connection, then a portion of those wires in the full sized USB cables are connected to the CPU's USB 2.0 OTG pins. Which also means there has to be a short (or a resistor) between a pair of the black wires to force it to be a USB host port instead of a peripheral. If this is the case, then the black wire leading to the ID merely needs to disconnected and the port will become a USB (client) peripheral.

However, if it is not a 1:1 USB to CPU connection and the connector with the two sets of USB wires are actually bridged like a USB hub then I would suspect the 4 pin beige connector to the right of these cables is actually the USB OTG connection and is set to be a simple USB peripheral header.

It is possible because there are only two data traces coming from the CPU for each connector. If the connector with 10 wires have a 1:1 connection to the CPU then there would be two pairs of data traces not one. But, I cannot see the bottom side of these connectors as the pictures with the opposite side of the logic board has been cut off for this area.

Does this make sense?
[Android Head-Units] chris.davis925:
---------- Post added at 08:17 PM ---------- Previous post was at 08:16 PM ----------

[/COLOR]

Yes that mostly makes sense. Thanks for the outline.

Using that logic, I am going to make that the assumption that the following is true:

The reason why is because I am pretty sure this unit has at least four USB connections routed to the back acting like a USB HUB. One for Bluetooth, one for WiFi and two for USB accessories.

The Kenwood website actually lists the following:

And even if that wasn't the case, the question must be asked.... what is that five pin beige connector for?

Let's say for a moment that it isn't a USB header (which I think it is at this point), what else could it be? I saw the manual make reference to direct CPU JTAG connection. Excuse my ignorance, but what exactly is a "JTAG" port? Is that like a serial connection? can "JTAG" be done over USB?
[Android Head-Units] donaldta:
You mean the three cables on right shown in this picture?

/shrug

Answer:

Answer:

I suppose it could but I've never ever seen it implemented this way.
[MDA II, XDA II, 2060 General] jpm993:
Hi Guys,

Firstly, I've just got my O2 XDA and using the unlocking software I've now got my Vodafone SIM working, so top site!! 8)

I've got a very old Sony-Ericsson bluetooth headset (HBH-10) which I've had for years. I can find the headset when I search for it on the XDA, but I can't seem to get pass the bonding password. I've reset the headset to 0000, but it fails to bond.

The bluetooth on the XDA is fine as I've got it to bond with my laptop.

Any suggestions are most welcome!

Cheers - James

:D
[MDA II, XDA II, 2060 General] Rudegar:
have you installed the bluetooth tools ?

http://bluetooth.i-networx.de/index_e.html
[MDA II, XDA II, 2060 General] jpm993:
I'll give it a go, thanks for the VERY prompt response!
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] davebmx05:
I'm using Kii keyboard and for some reason the enter key is also the send key and I don't like that. I want it to be the enter key. is anyone else using this keyboard and can help me out. I've looked in the settings for the keyboard and unless I missed it I just couldn't find anything about it. Thanks
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] dima470:
If you don't like it, try another keyboard that doesn't have that option.
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] davebmx05:
I love the keyboard and everything about it except that