Jump to content

Android AOSP


Guest sebbo90

Recommended Posts

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 by Tom G
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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/

Link to comment
Share on other sites

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.

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.