Problem Think Tank: Sensors Issue

[xPhoenix777]

Wow, I missed a lot... but at least we have another bright mind in the mix!

I will try my best to keep up with the thread and throw in my 2 cents when needed. I won't be able to do much testing until 6pm est.

 

[buryboi]

Symlinks a no go just tried it.

I'll give libdrv a try later on.

@jamezelle, D2 and D2G Libdvm.so have the same md5sum. Thanks for your help too, by the way! If you think of anything else, let us know, we'll give it a shot.

Sent from my DROID2 GLOBAL using DroidForums App

 

[buryboi]

Alright, I've tried a few more things (still no solution) but wanted to throw them out there to help eliminate redundancy.

As mentioned previously, D2G does not have a gestures .so file and the sensor hardware is different between the D2G and the D2.

First problem, what are gestures. As far as I can tell, these are gestures related to the sensors. In addition to having a gestures .so file, D2 and DX have a folder in /system/etc called contextawareness, this folder contains an algorithm.xml file that discusses gestures, things like "faceup, facedown, tap, doubletap, still, walk, run, jump." These "gestures" would seemingly allow, for example, the phone to detect that it is facedown and silence the ringtone (like some other phones "etiquette" mode). I assume the D2G has this same kind of functionality, but it must be implemented differently.

The D2G sensor .so file, references "gesture", while the D2 does not. This leads me to believe that maybe, on the D2G, gestures are handled in the one sensor.so file rather than in two separate files.

Additional info...in the D2 services.jar in com/motorola/android/sensor there are gestures.smali files, the D2G does not have these.

So here is my hypothesis:
When the phone goes to sleep, a frameworks file (maybe services.jar) or a lib file (maybe libandroid_runtime.so or libandroid_servers.so) references this non-existent gestures .so file and causes a crash. With the sensors disabled, the phone thinks they dont exist at all, and somehow decides not to search for the gestures.

So what solutions have I attempted.

1. Under the assumption that the D2G sensors .so contains the gesture functionality, I created a symlink from gestures.droid2we.so to sensors.droid2we.so. That way, when the OS calls gestures, it gets sent to sensors...that was a no go.

2. I hex edited the D2 sensors and gestures files to reference the proper /dev mount points for the D2G hardware...also a no go. Not entirely sure hex editing strings would even tell the binary to do anything different.

3. I reverted to a D2 build.prop, sensor and gesture files, and created symlinks in /dev to point the sensors D2 calls to the right D2G sensors. For example, the D2G accelerometer is /dev/kxtf9 while the D2 is /dev/lis331dlh I created a symlink so that when lis331dlh is called by the D2 sensor file, it points to kxtf9 instead....this also did not work.

I wish I had some "good news," but for now, all I've got is an "I'm still working on it"

 

[draexo]

Keep working! Wish I could be of more help. I have too much on my plate to do anything more than send in a donation.


My two cents is this: If it was easy, Angdroid would release all the Fission builds at the same time. Can we reverse engineer his work and compare D2 to D2G Fission on build 2.4.3?

 

[buryboi]

My impression of Fission:

The D2 and DX are essentially the same, when Angdroid rebuilt the frameworks to be "AOSP Like" he built one set, and it just works on the other. The D2G, on the other hand is completely different. He probably (I'm maybe 98.42% confident), had to rebuild the frameworks the same way. This is why he hasn't released a new version for the D2G. While the version numbers coincide (2.4.3, 2.5.7 or whatever it is now) they share no similarities (other than maybe the framework images). I've compared Fission D2 vs D2G framework files and, aside from the maps.jar, none are the same. In fact, the D2G fission "Rom" only wipes and flashes 3 folders, /system/app, /system/framework and /preinstall. This gives us AOSP apps (which I'm pretty sure are actual AOSP), and AOSP "themed" frameworks, still mostly moto but it looks AOSP.

So there are two possible reasons why Angdroid has done it the way he has:

1. Since we didn't have SBF at the time 2.4.3 was released, he didn't want to risk trying D2 frameworks on the D2G, so he modified the D2G frameworks.

2. He was already aware of the sensor issues we've been having and rebuilding just the frameworks was less time consuming...

Let's hope it was option 1.

 

[draexo]

Yes. Option 1 would be best. I forget the SBF is new as I am new to all this. Could be why it is taking him so long to release Global Fission update.

Sent from my DROID2 GLOBAL using DroidForums App

 

[Asphyx]

His last post mentioned something about waiting for Gingerbread to be released.

I think BuryBoi is on the right track with the delay. But I have no inside knowledge here.

My guess is he needs to try and get the framework to work properly on the D2G and some of the same issues that GetRDone is having is likely to be happening to Ang as well.

The other issue is there aren't that many global phones out there to steal packages from.

I really am hoping more for a bootloader fix than Fission at this point.
The current version works just fine so no rush.

But if someone figures out how to unlock the bootloader waiting for a particular ROM goes right away!

 

[kptphalkon]

I am interested in figuring out what happens during an over the air update, and specifically what command or code or encryption key is sent to the phone before an update occurs.

I'd hate to presume but am probably on some kind of track when I think that the phone locks out any interaction or monitoring to prevent this from being found....but is motorola that smart or cautious?

 

[buryboi]

I've saved the OTA and have flashed it several times, so I'm not convinced that anything is "sent" from the network to unlock it.

I'm no expert, but my understanding is that when an official update is signed, the signature validates/acknowledges every file in the update, then the signature is validated by the phone/bootloader. If a file is changed, it breaks the signature. If you copy the signature from the OTA to a a custom update.zip, there will be files (probably all of them) that are not accounted for in the signature and it will fail the signature check.

Often we think of this as a key in the lock; like the software/update puts in the key, and the lock opens. I don't believe this to be how these updates work. I think it's more like the phone performs a "retina scan" to validate the signature. Except it can't just simply scan the retina, it needs to decrypt the retina then scan it. We can't recreate an official signature because it is encrypted with 2048 bits (or some ridiculously high level of encryption used only by the likes of NASA). This basically eliminates bruteforce as an option, as it would take longer than the earth has previously existed to "guess" the correct code.

So basically, in my opinion, the update does not hold the key, rather the internal hardware chip does...Theoretically, this means, that at least for some very tiny window of time, the key could be read...People have suggested cryogenically freezing the device to slow down the processing and thereby expand this window...That's another topic completely.

But hey, the XOOM is said to have an unlockable/relockable bootloader, so maybe there's a chance that someday, MOTO will afford us the same "convenience."

And now back to our regularly scheduled programming.

WoZzy has tested a method for having sensors with a D2 Rom on the D2G, however, it kills GSM. At this time it cannot be implemented with the Romer.zip and requires a particularly useful app from the market. Once I have all the details from WoZzy, I'll try it out myself, and see if it cant be packaged into an update.zip. Both he and I have full time, "real," jobs so I'm not sure exactly when we'll get to this...but hopefully, in time, we'll have a solution of some sort.

 

[Asphyx]

Buryoi is correct.

The Update itself is signed and that signature is the key to allow it to work.

Considering how new the phone is and how few updates have been released it will be very difficult to figure out the key to unlock.

Unless someone finds out that the same key is used on all Moto devices then there might be enough samples to reverse engineer that key.

And in many cases (such as the 2.4.3 OTA update) It is not a given that update does anything to the kernal. Moto could at some point just release a framework update that does not access the bootloader.

 

[kptphalkon]

There are working sensors??? This is great news! I dont care if it kills gsm, as long as cdma/ev do is still working.

 

[buryboi]

There are "theoretically" working sensors. It hasn't been released, and may not be for a while, depending on WoZzy's and my schedule.

 

[Asphyx]

And now back to our regularly scheduled programming.

WoZzy has tested a method for having sensors with a D2 Rom on the D2G, however, it kills GSM. At this time it cannot be implemented with the Romer.zip and requires a particularly useful app from the market. Once I have all the details from WoZzy, I'll try it out myself, and see if it cant be packaged into an update.zip. Both he and I have full time, "real," jobs so I'm not sure exactly when we'll get to this...but hopefully, in time, we'll have a solution of some sort.

Sounds like the issue was in one of the radio files and not just a sensor thing.
And it makes sense since the unit shuts down the radios when in standby and merely polls.
And the D2 and D2G would have different methods for turning the radio on and off.

You guys are so close, I can feel it!

 

[Patgt500]

What is the app?

Sent from my DROID2 GLOBAL using DroidForums App

 

[bobrowley]

For your information, hope this could help:

I am using Liberty v1.5, with GSM signal. The GSM signal used to be killed(when phone sleeps) when I had set the network type as GSM/CDMA auto(PRL), but it works well if I set the network type as GSM auto(PRL).