Jump to content

Android 2.2 Development


Guest eckengucker1

Recommended Posts

any news on the froyo front?

Nothing new.

I found that the different wpa ctrl_interface dir in the Huawei roms is inherited from the codeaurora source. I don't know why its different in codeaurora to aosp.

I'm now trying to figure out why the current source gives an mReady loop, but my 6 week old source works. There are about 4000 lines of differences between the 6 week old aosp froyo code that works and the android-2.2_r1 code (which loops), but most of the changes are to documentation and language translations (which should have no impact). Actual code changes don't look like much.

Unfortunately finding the problem is a very slow process. For each small change that I make I need to do a clean build which takes a couple of hours. I've spent the last couple of days on this, but keep end up with compile problems.

Once I find and fix the problem I will release the device config stuff I'm using and write a brief guide on building it for anyone else that wants to try building from source. Hopefully if others can build it we will start seeing more active development.

Link to comment
Share on other sites

Guest flip360

it seems that we must have the kernel sources damn huawei. Thanks Tom G, you are doing a great job (Huawei certainly dont), there`s no rush, i have tried your froyo rom and although without wifi and audio it was working beautifully. If there`s anything i can do to help (try ROMS, compiling, dont know how to code) please let me know,

cheers

Edited by flip360
Link to comment
Share on other sites

I'm now trying to figure out why the current source gives an mReady loop, but my 6 week old source works.

It looks like I have found the cause (haven't really found the problem yet, it is very strange).

The only changes I made to the source in my working froyo builds was to turn on debugging output in varies components to help identify problems. Those debugging options should make no difference to the operation of the programs, they just print additional messages to the log, so they were the last thing I tested in trying to find the problem.

If debugging output is enabled in NativeDaemonConnector the rom works, if it is disabled it loops at waiting for mReady. It is really unusual because I can't see how enabling debugging output effects the logic of the program (other than writing to the log).

The below patch worked for builds against the android-2.2_r1 and android-2.2_r1.1 branches.

diff -uNr -x out -x .repo -x .git b/frameworks/base/services/java/com/android/server/NativeDaemonConnector.java a/frameworks/base/services/java/com/android/server/NativeDaemonConnector.java

--- b/frameworks/base/services/java/com/android/server/NativeDaemonConnector.java	   2010-08-09 20:44:43.000000000 +1000

+++ a/frameworks/base/services/java/com/android/server/NativeDaemonConnector.java	 2010-08-12 19:38:57.000000000 +1000

@@ -40,7 +40,7 @@

  * protocol.

  */

 final class NativeDaemonConnector implements Runnable {

-	private static final boolean LOCAL_LOGD = false;

+	private static final boolean LOCAL_LOGD = true;


	 private BlockingQueue<String> mResponseQueue;

	 private OutputStream		  mOutputStream;

I still want to have a good look through the code and try to understand what is really causing this problem, but at least now I know where to look. Hopefully I can get it to run without the need for a patch.

Going to newer code didn't magically make any more features work. :D

Edited by Tom G
Link to comment
Share on other sites

Guest The Innocent X
If debugging output is enabled in NativeDaemonConnector the rom works, if it is disabled it loops at waiting for mReady. It is really unusual because I can't see how enabling debugging output effects the logic of the program (other than writing to the log).

Timing! Debugging will slow down the execution of the code, possibly meaning that by the time it gets to the key part of the code something else is available (in another thread/program), whereas with the quicker non debug code it is not ready. Just a theory

Link to comment
Share on other sites

Guest gusthy
Timing! Debugging will slow down the execution of the code, possibly meaning that by the time it gets to the key part of the code something else is available (in another thread/program), whereas with the quicker non debug code it is not ready. Just a theory

That was my idea too... reading the particular code won't help too much, so I would turn debugging on, go forward on development and after that going back to fix this issue.

Link to comment
Share on other sites

Guest Epic-Emodude
Bad news!!!

Just found that Froyo for U8220&U8230 is not in schedule now at Huawei.

:-(

http://www.huaweidevice.com/community/thre...&orderStr=9

Cheers

You mean it was schedualed?

I think that everyone assumed that we werent going to get an official 2.2 update, and anyway most phones only get one update, seeing as the manufacturer gets nothing out of the update, but would be better off making a new device with the update that they can seel and make a profit.

And anyway we will probably port it ourselves first. T-mobile released the uk 2.1 update after HTC released Froyo updates for the Evo and Desire

Also you do realise that the guy who said that it just some guy

Edited by Epic-Emodude
Link to comment
Share on other sites

Guest Zizi Bolygó

Not god marketing from huawei. The first popular phone is the 8220 from huawei. I think all the users need 2.2 because the jit etc. I dont need 3.0 later, but 2.2 is important upgrade for all the "slow" phones. So huawei know what they do with the firs big group(u8220) of users. If not coming offivaly the 2.2 i dont buy any huawei in the future...

Edited by Zizi Bolygó
Link to comment
Share on other sites

Guest DanWilson

If they just made the damn .32 kernel and gave us it we'd have the bloody Froyo!! :D

They only need to make the kernel! How hard is that when you have the source, the drivers, the blueprints to the phone, and a mega huge team of devs how know the phone and get payed alot!

Jesus...

Link to comment
Share on other sites

Sorry about the slow progress recently. I've just got audio working using the codeaurora source, so I will try to get an image up later. There are some serious stability problems at the moment, but at least its moving forward.

Link to comment
Share on other sites

Guest gusthy
Sorry about the slow progress recently. I've just got audio working using the codeaurora source, so I will try to get an image up later. There are some serious stability problems at the moment, but at least its moving forward.

does it mean you can make phone calls?

Link to comment
Share on other sites

Sorry about the slow progress recently. I've just got audio working using the codeaurora source, so I will try to get an image up later. There are some serious stability problems at the moment, but at least its moving forward.

how is the the progress on WiFi going? wifi is the most important thing for me (after audio), so please please fix that if you havent done so..

and BTW i love the work that you are doing. i never thought we would have froyo running on our "high-end" device. :D

Link to comment
Share on other sites

how is the the progress on WiFi going? wifi is the most important thing for me (after audio), so please please fix that if you havent done so..

and BTW i love the work that you are doing. i never thought we would have froyo running on our "high-end" device. :D

I wasn't getting anywhere on wifi so I moved on to other things for a while. I will get back to it.

Audio was a top priority. I haven't done any real testing yet, so I don't know if it is completely working, but I expect it will be with a little configuration (which I can steal from the official roms).

The next priority is some form of data connection, either wifi or ril.

If I can get it to run stable with those features working it should be usable.

Other things like lights, sensors and camera would be nice but I don't consider them requirements for a usable rom.

The codeaurora source includes some qcom specific changes that are not in the aosp source. A few more features may be easy to get working.

The move to the codeaurora source has increase the size of the system image a fair bit. I am almost out of space (6MB left) using the old 1.5 partition layout (I would like to keep it in within the 1.5 layout if possible for the bigger data partition).

Link to comment
Share on other sites

Guest Simon O
The move to the codeaurora source has increase the size of the system image a fair bit. I am almost out of space (6MB left) using the old 1.5 partition layout (I would like to keep it in within the 1.5 layout if possible for the bigger data partition).

Well considering most people had serious issues running Android 2.1 on devices with 1.5 partitions I personally would consider it a bit silly. The official Android 2.1 roms update more things on the phone that just the partition sizes and you could potentially either be struggling getting hardware working that requires these updates or worse bodging the code to work on 1.5 devices which ends up causing problems for anybody using 2.1.

Update using the UK 2.1 ROM. The data partition is larger than other 2.1 roms.

Link to comment
Share on other sites

Well considering most people had serious issues running Android 2.1 on devices with 1.5 partitions I personally would consider it a bit silly. The official Android 2.1 roms update more things on the phone that just the partition sizes and you could potentially either be struggling getting hardware working that requires these updates or worse bodging the code to work on 1.5 devices which ends up causing problems for anybody using 2.1.

Update using the UK 2.1 ROM. The data partition is larger than other 2.1 roms.

I do realise that there may be a need to move to the newer firmware, but the only function I know of that breaks between them is the vibrator (which could be fixed with the kernel source). The issues I would expect to see are related to stability (force closes etc), which isn't really an issue until the functions necessary for the phone to be usable work. I will move to the newer firmware later if necessary.

It looks like the mReady problem really needs to be solved properly before this can continue. The rom with working audio will not boot most of the time. I have played a bit with NativeDaemonController this week and understand the problem a little better (it is definitely timing). I can fix the mReady loop by adding a delay in NativeDaemonConnector but it causes some instability. Back to reading the code...

Link to comment
Share on other sites

Ah sure, that makes sense. Thanks Tom :D

Just seen that there's a test rom of Froyo for the Pulse Mini at http://android.modaco.com/content/t-mobile...the-pulse-mini/

It doesn't appear to be based on your work, but I could be wrong. Any use for you?

I doubt the Mini rom will be any use unless the device config is released.

I haven't changed much, but the rom is working much better. I put a sim in it (I only have 1. I should get another for testing) to try make some calls only to find ril has died with the move to the codeaurora code.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.