2.3 for San Fran

[Guest njustwenkui]

my latest rom

http://bit.ly/13dec10

some guy have flashed the 2.3rom ,but why the andriod linux kernal version is not latest?even older than the 2.2ROM.

and how to download the 2.3 google source code?

[Guest Matty-p]

some guy have flashed the 2.3rom ,but why the andriod linux kernal version is not latest?even older than the 2.2ROM.

and how to download the 2.3 google source code?

Beacause zte havent released the source yet nag them until we get it! The source for 2.3 isnt avqilibe yet this was thrown together from the sdk thats why stuff dosennt work on this like ril

[Guest nvidiax]

my latest rom

http://bit.ly/13dec10

I'll test it out for you :)

Hope it's better than the last one. Should be as now jit is enabled :)

[Guest stephen m]

I'll test it out for you :)

Hope it's better than the last one. Should be as now jit is enabled :)

Dowloaded and testing also. First thing - no network coverage. Should I have flashed over ?

[Guest cobhc]

Testing now, still kinda slow, but it's not too bad. Kinda nice to have a play with all the stuff and get a sneak peak of it all.

[Guest stephen m]

Dowloaded and testing also. First thing - no network coverage. Should I have flashed over ?

Ok - so far:

No market place

No Gmail

No mobile network

No screen rotation

No generic Android icons

No SD card recognition.

Any known fixes to this ?

Edited December 14, 2010 by stephen m

[Guest cobhc]

Ok - so far:

No market place

No Gmail

No mobile network

No screen rotation

No generic Android icons.

Any known fixes to this ?

Not at the moment, as this is a very very very alpha build. Don't expect any of this to work soon.

Edit: Used an old GAPPS zip that I had, this got me the google apps, although market doesn't want to search for anything. SD Card is still borked, and since I'm on Windows, I can't ADB in either lol. Still kinda fun to play with though.

Edited December 14, 2010 by cobhc

[Guest Matty-p]

Not at the moment, as this is a very very very alpha build. Don't expect any of this to work soon.

Edit: Used an old GAPPS zip that I had, this got me the google apps, although market doesn't want to search for anything. SD Card is still borked, and since I'm on Windows, I can't ADB in either lol. Still kinda fun to play with though.

here is a gapps zip i stuck together http://bit.ly/gappsblademttyp

[Guest cobhc]

here is a gapps zip i stuck together http://bit.ly/gappsblademttyp

Stopped trying for now. Usb didn't seem to want to work either, so no chance of ADB'ing in. It didn't give me any notifications or options about USB, just as if there wasn't a cable connected, but it seemed to charge ok.

[Guest goldengate]

just to advise the Nexus S (2.3) Kernel is now available:

http://androidcommunity.com/nexus-s-kernel...e-now-20101214/

Not sure if this will help with development coz i'm brand new to Android and dont really know what i'm talking about but lookin forward to seeing Gingerbread in some form on my SanFran in 2011. :)

[Guest gusthy]

just to advise the Nexus S (2.3) Kernel is now available:

http://androidcommunity.com/nexus-s-kernel...e-now-20101214/

Not sure if this will help with development coz i'm brand new to Android and dont really know what i'm talking about but lookin forward to seeing Gingerbread in some form on my SanFran in 2011. :)

Unfortunately it doesn't help.

It is something like that you have a Renault Scenic car with a 2.1TDi engine, and let's assume that there exists a 2.3TDi engine for that model. You cannot replace that engine with a 2.3TDi one built for an Opel Vectra.

[Guest Matty-p]

Unfortunately it doesn't help.

It is something like that you have a Renault Scenic car with a 2.1TDi engine, and let's assume that there exists a 2.3TDi engine for that model. You cannot replace that engine with a 2.3TDi one built for an Opel Vectra.

very good analogy

[Guest Danne_Swe]

very good analogy

+1

Best explanation I 've read on this forum!

[Guest -= 71baker =-]

Unfortunately it doesn't help.

It is something like that you have a Renault Scenic car with a 2.1TDi engine, and let's assume that there exists a 2.3TDi engine for that model. You cannot replace that engine with a 2.3TDi one built for an Opel Vectra.

Well you can , but it's way harder than switching for the same engine. :) (But it is a good example gusthy)

[Guest Twiggeh]

Unfortunately it doesn't help.

It is something like that you have a Renault Scenic car with a 2.1TDi engine, and let's assume that there exists a 2.3TDi engine for that model. You cannot replace that engine with a 2.3TDi one built for an Opel Vectra.

So that kernel is practically useless to us? :)

[Guest gusthy]

So that kernel is practically useless to us? :)

practically yes.

but it gives us hope that Android is not a dead technology.

[Guest samjam]

As long as the hardware drivers you need are present in newer released source;

or

as long as the interfaces or dependencies of the drivers haven't changed - such that you can used the drivers from the previous released kernel

AND

and as long as the new kernel interfaces are still usable by the user-space software (or a combination of new/old software to match old drivers ported to the new kernel)

THEN

you can take the new kernel, re-compile it with the same config file as your old kernel and expect it to work.

The kernel source is not a car engine, it is the blue-prints for a set of car engines. The kernel config file combines with the source to make blueprints for a specific engine, which can then be built.

One should not under-estimate all the ifs/or/and above though...

[Guest olionair]

any chance of modifying a dump form nexus s ?

[Guest gusthy]

As long as the hardware drivers you need are present in newer released source;

or

as long as the interfaces or dependencies of the drivers haven't changed - such that you can used the drivers from the previous released kernel

AND

and as long as the new kernel interfaces are still usable by the user-space software (or a combination of new/old software to match old drivers ported to the new kernel)

THEN

you can take the new kernel, re-compile it with the same config file as your old kernel and expect it to work.

The kernel source is not a car engine, it is the blue-prints for a set of car engines. The kernel config file combines with the source to make blueprints for a specific engine, which can then be built.

One should not under-estimate all the ifs/or/and above though...

Pretty sure, the analogy is really correct with the blueprint extension :)

Unfortunately this ifs and or's are very strict.

In this particular case, the Nexus S is a very different achitecture - it is based on a Cortex A8 CPU.

Everybody who spent some time in Pulse forum knows how hard it is to move between different2.6 kernels - the issue was from 2.6.29 to 2.6.32 there. Many people including BigBear, Flibblescan and others worked on it hard without final success.

Other option would be to ask the Cyanogen team to help porting the kernel, but it is a very hard job to make them do it.

So I guess, it is not the good way to have Gingerbread - it will run on 2.6.29 or .32 as well. First we should wait for official Gingerbread sources (not kernel, but Android), then wait for Tom G to do his build - if he will want to do it.

[Guest fonix232]

Pretty sure, the analogy is really correct with the blueprint extension :)

Unfortunately this ifs and or's are very strict.

In this particular case, the Nexus S is a very different achitecture - it is based on a Cortex A8 CPU.

Everybody who spent some time in Pulse forum knows how hard it is to move between different2.6 kernels - the issue was from 2.6.29 to 2.6.32 there. Many people including BigBear, Flibblescan and others worked on it hard without final success.

Other option would be to ask the Cyanogen team to help porting the kernel, but it is a very hard job to make them do it.

So I guess, it is not the good way to have Gingerbread - it will run on 2.6.29 or .32 as well. First we should wait for official Gingerbread sources (not kernel, but Android), then wait for Tom G to do his build - if he will want to do it.

We do not have to ask Cyanogen team, there are many other great kernel porters (like pershoot) to help us. But maybe making a diff to the mainstream 2.6.29 branch of the original android source code (somewhere must be a revision info, what contains which one is the one used for the ZTE kernel), and applying the patches manually would make something barely usable.

[Guest Frankish]

I think once we get a proper dump of the Nexus S rom with symlinks etc we might be able to get some useful stuff from that.

[Guest RichBayliss]

I think once we get a proper dump of the Nexus S rom with symlinks etc we might be able to get some useful stuff from that.

http://forum.xda-developers.com/showthread.php?t=875184

ROM dump from the Nexus S is here...

[Guest samjam]

We do not have to ask Cyanogen team, there are many other great kernel porters (like pershoot) to help us. But maybe making a diff to the mainstream 2.6.29 branch of the original android source code (somewhere must be a revision info, what contains which one is the one used for the ZTE kernel), and applying the patches manually would make something barely usable.

Yes, and the git tools will make that process more manageable.

Here's how I've worked in the past when I just ahd a kernel tar.

Take the new snapshot, and diff -Nru to a git-archive checkout.

Break the patches into obvious modules or chunks of functionality and find key lines in those, to google. It will help find the submissions of those patches and thus the tree into which they went. This can help you pull the contributing git trees and make a list of where things came from.

Then you can combine the patches in git as well as have access to conversation on those patches and upstream fixes.

If the source you have is in git, then it becomes easier.

[Guest Phoenix Silver]

Yes, and the git tools will make that process more manageable.

Here's how I've worked in the past when I just ahd a kernel tar.

Take the new snapshot, and diff -Nru to a git-archive checkout.

Break the patches into obvious modules or chunks of functionality and find key lines in those, to google. It will help find the submissions of those patches and thus the tree into which they went. This can help you pull the contributing git trees and make a list of where things came from.

Then you can combine the patches in git as well as have access to conversation on those patches and upstream fixes.

If the source you have is in git, then it becomes easier.

i agree with you git is the best way.

i think modifying a dump from a different phone is a harder way than begining from a real source.

Edited December 17, 2010 by Phoenix Silver

[Guest rjm2k]

Yes, and the git tools will make that process more manageable.

Here's how I've worked in the past when I just ahd a kernel tar.

Take the new snapshot, and diff -Nru to a git-archive checkout.

Break the patches into obvious modules or chunks of functionality and find key lines in those, to google. It will help find the submissions of those patches and thus the tree into which they went. This can help you pull the contributing git trees and make a list of where things came from.

Then you can combine the patches in git as well as have access to conversation on those patches and upstream fixes.

If the source you have is in git, then it becomes easier.

I think a lot of the ZTE changes can probably be ignored, stuff like FTM mode changes since we don't use it, just concentrating on actual important changes like new drivers and re-jigged hardware.