Android AOSP

[Guest Tom G]

Seems like a good idea to switch to Code Aurora then. I'm using the JJ boot.img so I should have the /sbin/usbconfig in place but I didn't add the USB device id line in build.prop so I suppose it might not work without it.

However with since I'm not using a kernel compiled with 3G vmsplit it's propably the main cause for it not to boot. Oh, well...

Btw, I haven't come that far yet but I suppose I will need to solve the 180 degree rotation issue when/if I get that far. How did you get around that problem? Did you modify PhoneWindowManager.java?

The devid in build.prop doesn't matter. If the boot image is good but you have the wrong VMSPLIT you should see the device with 'adb devices' but shell and logcat will fail with a linking problem (shell might work).

The rotation problem is fixed.

diff --git a/libs/surfaceflinger/SurfaceFlinger.cpp b/libs/surfaceflinger/SurfaceFlinger.cpp

index b9ab1c0..9b0dafe 100644

--- a/libs/surfaceflinger/SurfaceFlinger.cpp

+++ b/libs/surfaceflinger/SurfaceFlinger.cpp

@@ -1883,16 +1883,16 @@ void GraphicPlane::setDisplayHardware(DisplayHardware *hw)


	 // initialize the display orientation transform.

	 // it's a constant that should come from the display driver.

-	int displayOrientation = ISurfaceComposer::eOrientationDefault;

+	int displayOrientation = ISurfaceComposer::eOrientation180;

	 char property[PROPERTY_VALUE_MAX];

	 if (property_get("ro.sf.hwrotation", property, NULL) > 0) {

		 //displayOrientation

		 switch (atoi(property)) {

		 case 90:

-			displayOrientation = ISurfaceComposer::eOrientation90;

+			displayOrientation = ISurfaceComposer::eOrientation270;

			 break;

		 case 270:

-			displayOrientation = ISurfaceComposer::eOrientation270;

+			displayOrientation = ISurfaceComposer::eOrientation90;

			 break;

		 }

	 }

This isn't the greatest way to doing it. It should be switchable from the device config, but it is basically what is needed. It needs some #ifdef's to choose normal or inverted. If your code is only used for devices with inverted screens then this is fine.

Edited January 24, 2011 by Tom G

[Guest kallt_kaffe]

The devid in build.prop doesn't matter. If the boot image is good but you have the wrong VMSPLIT you should see the device with 'adb devices' but shell and logcat will fail with a linking problem (shell might work).

The rotation problem is fixed.

diff --git a/libs/surfaceflinger/SurfaceFlinger.cpp b/libs/surfaceflinger/SurfaceFlinger.cpp

index b9ab1c0..9b0dafe 100644

--- a/libs/surfaceflinger/SurfaceFlinger.cpp

+++ b/libs/surfaceflinger/SurfaceFlinger.cpp

@@ -1883,16 +1883,16 @@ void GraphicPlane::setDisplayHardware(DisplayHardware *hw)


	 // initialize the display orientation transform.

	 // it's a constant that should come from the display driver.

-	int displayOrientation = ISurfaceComposer::eOrientationDefault;

+	int displayOrientation = ISurfaceComposer::eOrientation180;

	 char property[PROPERTY_VALUE_MAX];

	 if (property_get("ro.sf.hwrotation", property, NULL) > 0) {

		 //displayOrientation

		 switch (atoi(property)) {

		 case 90:

-			displayOrientation = ISurfaceComposer::eOrientation90;

+			displayOrientation = ISurfaceComposer::eOrientation270;

			 break;

		 case 270:

-			displayOrientation = ISurfaceComposer::eOrientation270;

+			displayOrientation = ISurfaceComposer::eOrientation90;

			 break;

		 }

	 }[/code]


This isn't the greatest way to doing it. It should be switchable from the device config, but it is basically what is needed. It needs some #ifdef's to choose normal or inverted. If your code is only used for devices with inverted screens then this is fine.

Many thanks for your help, do you have a BoardConfig.mk with all all the wifi stuff and other things setup? How far have you got with compling Android for the blade? My first goal is to get something to boot so that I also could start having a look at getting the RIL working. I haven't looked much at it so far but I'm pretty sure an important part of the integration is hidden within Phone.apk and the extra .jar files in /system/framework. Have anyone tried just signing Phone.apk from the Chinese or Japanese build with AOSP certs, grab the .jar files and libcm.so + libril-qc-1.so and put it into an AOSP/CAF compiled 2.2?


Deleted my AOSP repo before I had a "DOH!"-moment where I relealized I could have easily ported 2G prelink changes over to it so it took a while to sync the Code Aurora repo but it's currently compiling. Will take a while though since my machine is rather slow. 


However I think I now know, why I didn't even get my adb working on the first attempt. I'm using my jellyfish boot.img and doesn't start any services until userinit.sh has set the filesystem.ready property and setprop uses toolbox and toolbox propably fails due to the 3G prelink setup so adb never got started.

[Guest Tom G]

Many thanks for your help, do you have a BoardConfig.mk with all all the wifi stuff and other things setup? How far have you got with compling Android for the blade? My first goal is to get something to boot so that I also could start having a look at getting the RIL working. I haven't looked much at it so far but I'm pretty sure an important part of the integration is hidden within Phone.apk and the extra .jar files in /system/framework. Have anyone tried just signing Phone.apk from the Chinese or Japanese build with AOSP certs, grab the .jar files and libcm.so + libril-qc-1.so and put it into an AOSP/CAF compiled 2.2?

Deleted my AOSP repo before I had a "DOH!"-moment where I relealized I could have easily ported 2G prelink changes over to it so it took a while to sync the Code Aurora repo but it's currently compiling. Will take a while though since my machine is rather slow.

However I think I now know, why I didn't even get my adb working on the first attempt. I'm using my jellyfish boot.img and doesn't start any services until userinit.sh has set the filesystem.ready property and setprop uses toolbox and toolbox propably fails due to the 3G prelink setup so adb never got started.

I have most things working (and have had for months) although I haven't done a lot of testing. I have issues with egl. The camera doesn't work. RIL doesn't work. I haven't really looked at the egl and camera problems as without RIL the rest doesn't really matter. I will look at put my device config on github.

[Guest rjm2k]

I have most things working (and have had for months) although I haven't done a lot of testing. I have issues with egl. The camera doesn't work. RIL doesn't work. I haven't really looked at the egl and camera problems as without RIL the rest doesn't really matter. I will look at put my device config on github.

can you provide some instructions on which tag you used and generally getting a basic build up and running? each dev seems to have to spend time re-inventing the wheel in order to get the ball rolling rather than being able to concentrate on the real issues such as ril.

thanks

[Guest fonix232]

I have most things working (and have had for months) although I haven't done a lot of testing. I have issues with egl. The camera doesn't work. RIL doesn't work. I haven't really looked at the egl and camera problems as without RIL the rest doesn't really matter. I will look at put my device config on github.

For camera and EGL, you need the specific camera and egl so libraries (proprietary files like on HTC) copied into your build, and also some modifications to the build system too (to build the AOSP source for the specified hardware).

By the way my site is up again, so you can freely discuss there (highly moderated, anyone who is working on it and contacts me in PM here can be a moderator to assure everything will be clean).

http://fonix232.co.cc/index.php?/topic/8-wip-ril-reversing/

[Guest hecatae]

http://www.flickr.com/photos/cocaman/5273408519/

found this picture, anyone know the source?

[Guest IronDoc]

http://www.flickr.com/photos/cocaman/5273408519/

found this picture, anyone know the source?

Yeah Tom G (I think) had a vaguely working gingerbread. Very slow and no ril among other things.

[Guest hecatae]

Yeah Tom G (I think) had a vaguely working gingerbread. Very slow and no ril among other things.

got to same point, looks pretty though.

[Guest hecatae]

just occurred to me that Stackbladroid is built on AOSP 2.2.1

http://android.modaco.com/content/zte-blad...-san-francisco/

I wont be able to build a new kernel til later, can someone have a go and post a new boot.img based on the new source from

https://github.com/ZTE-BLADE/ZTE-BLADE-2.6.32

[Guest fonix232]

just occurred to me that Stackbladroid is built on AOSP 2.2.1

http://android.modaco.com/content/zte-blad...-san-francisco/

I wont be able to build a new kernel til later, can someone have a go and post a new boot.img based on the new source from

https://github.com/ZTE-BLADE/ZTE-BLADE-2.6.32

It is just a partial build, not a whole 2.2.1 AOSP compile.