Jump to content

Android 2.2 Development


Guest eckengucker1

Recommended Posts

Yap I will have a brief look at that, but I think the cahnce that this will run on our Pulse is even smaller than with the emulator image :D

Already saw that on twitter, I follow Paul and AmonRA :rolleyes:

So the emulator image didn't work out?

Link to post
Share on other sites
Guest kamikase

what we really would need is the interface definition to the different parts of the phone like how to "speak" to the radio ic etc so we ould write our own drivers even for android 3.0

but i guess this is too much to ask because this is the entire blue-print :rolleyes:

kase

Link to post
Share on other sites
Unfortunately not.

It just freezes at the (animated) Android logo.

But is it possible for you to replace the drivers of this N1 ROM with drivers from 1.5 U8220?

(noob question :rolleyes:)

Link to post
Share on other sites
Guest BigBearMDC
what we really would need is the interface definition to the different parts of the phone like how to "speak" to the radio ic etc so we ould write our own drivers even for android 3.0

but i guess this is too much to ask because this is the entire blue-print :rolleyes:

kase

Wow, hold on!

You want to write your own drivers?

Sorry, but are you NUTS?? :(

That's a little bit too much for only one person I guess (assuming you are in the age between 18 and 25 and not a professional Dev :D).

But if you're intersted in that:

What I got from the TS driver is that the SW talks to the radio through the I2C bus.

Every device has it's own identifier and the communication is package oriented.

Link to post
Share on other sites
Guest BigBearMDC
But is it possible for you to replace the drivers of this N1 ROM with drivers from 1.5 U8220?

(noob question :D)

Nope.

At leasat not for me :rolleyes:

You would have to patch the already compiled kernel, which is practically impossible.

Link to post
Share on other sites
Nope.

At leasat not for me :rolleyes:

You would have to patch the already compiled kernel, which is practically impossible.

Too bad, but can you use the ones from the 2.1 ROM that you and Paul put together?

(sorry for all the questions, I'm just curious! ^^)

Edited by Guest
Link to post
Share on other sites
Guest BigBearMDC
Too bad, but can you use the ones from the 2.1 ROM that you and Paul put together?

(sorry for all the questions, I'm just curious! ^^)

Once the 2.1 kernel source is out we might use it's drivers and patch them into the 2.6.32 kernel.

But I think it should work with the .27 kernel drivers too (Android 1.5 kernel).

The main functions (and the main differences) are not the drivers but other functions in the kernel.

So my thought is that it should not make a big difference which drivers we use, as they nearly stay the same even with never kernel versions.

Why should the drivers be changed if the hardware stays the same?

But that are just my thoughts...

Edited by BigBearMDC
Link to post
Share on other sites
Guest kamikase
Wow, hold on!

You want to write your own drivers?

Sorry, but are you NUTS?? :D

That's a little bit too much for only one person I guess (assuming you are in the age between 18 and 25 and not a professional Dev :rolleyes:).

But if you're intersted in that:

What I got from the TS driver is that the SW talks to the radio through the I2C bus.

Every device has it's own identifier and the communication is package oriented.

well sometimes i ask ymself if i'm nuts but no this was a seious thing

the problem with writing a driver is that you need the definitions of the original desing of the phone

the interfaces must have been declared at some point so that the software guys at huawei can write them to that which the hardware guys build

having the original code and definitions would be ideal

the problem with writing the driver without the interface definition is that one does not know hw they build all of that - the bus system itself dos not give us enough

kase

ps i'm 28 and in the process of finishing my studies in "telematik" which is a kind of unique mix of computer science (Informatik) and electrical engineering (Elektrotechnik) at graz university of technology

i have not writen drivers mself but it can't be that hard if you have the interface or at least the sourcecode of the original drivers

the bigger problem for me is that i'm currently writing my thesis so my freetime is very limited ...

Edited by kamikase
Link to post
Share on other sites
Guest BigBearMDC
well sometimes i ask ymself if i'm nuts but no this was a seious thing

the problem with writing a driver is that you need the definitions of the original desing of the phone

the interfaces must have been declared at some point so that the software guys at huawei can write them to that which the hardware guys build

having the original code and definitions would be ideal

the problem with writing the driver without the interface definition is that one does not know hw they build all of that - the bus system itself dos not give us enough

kase

ps i'm 28 and in the process of finishing my studies in "telematik" which is a kind of unique mix of computer science (Informatik) and electrical engineering (Elektrotechnik) at graz university of technology

i have not writen drivers mself but it can't be that hard if you have the interface or at least the sourcecode of the original drivers

the bigger problem for me is that i'm currently writing my thesis so my freetime is very limited ...

Ah okay, I see.

So you're 10 years older than me, I'm still attending the HTL (Telecommunication; in the 4th grade).

Yeah okay just have a look at the driver section.

Some things are pretty well documented.

Also, some of the drivers are pretty much stock Android kernel drivers, which haven't been heavily modified.

Of course we can't get the whole blueprint, but look at it that way:

The basic structure is the same on every device, as (or if) they use the same kernel.

You could help us with our Froyo project, if you want :rolleyes:

Link to post
Share on other sites
Guest kamikase
Why should the drivers be changed if the hardware stays the same?

But that are just my thoughts...

the drivers might change if the routines in the kernel that access the drivers changed

espacially if they want to make android more update friendly

if you write a driver for android until now you write it so you can access yor hardware

if you need to change some lines in the original android code it was no problem

2.x has - i think - different ways on how to interface with the drivers, otherwise we could use the 1.5 drivers anyhow

but google has a problem right now that there are many different phone on the market and like huawei the companies are slow to bring their phones to the lates version because it brigns them no money: the hardware was already sold and the next phone has the new version anyway - they dont profit from a new software

google might want to - and as far as i understood so far - will define the interface to the drivers so that if there is a new android version the driver still has the same interface android <> standarddriver-interface

driver<>phone can stay the same then

kase

ps

correct me if im wrong pls

always eager to learn something :rolleyes:

Link to post
Share on other sites
Guest BigBearMDC
the drivers might change if the routines in the kernel that access the drivers changed

espacially if they want to make android more update friendly

... [snip] ...

kase

ps

correct me if im wrong pls

always eager to learn something :rolleyes:

I thought this already was the aim of the Android kernel?

It's very inefficient to change the kernel interface within a new kernel version.

This definetly breaks driver backwards compability.

I thought the interfaces stayed the same in the different kernel versions.

It should theoretically be possible though to patch the older drivers into a newer kernel, if you just use the new routines.

I've heard some time ago that I would be possible to just diff and then patch the .27 and .29 kernel, so we'd have a .27 kernel with .29's functions.

Edited by BigBearMDC
Link to post
Share on other sites
Guest kamikase
Ah okay, I see.

So you're 10 years older than me, I'm still attending the HTL (Telecommunication; in the 4th grade).

Yeah okay just have a look at the driver section.

Some things are pretty well documented.

Also, some of the drivers are pretty much stock Android kernel drivers, which haven't been heavily modified.

Of course we can't get the whole blueprint, but look at it that way:

The basic structure is the same on every device, as (or if) they use the same kernel.

You could help us with our Froyo project, if you want :rolleyes:

well in that kind of htl you learn everything you need - its a good one i heard

i was stupid enough to attend ahs back then - so i needed to catch up a lot at the university

helping wih the project is a nice idea but like i said i'm currently writing my thesis and that has priority

altough it sounds very intriguing

Link to post
Share on other sites
Guest BigBearMDC
well in that kind of htl you learn everything you need - its a good one i heard

i was stupid enough to attend ahs back then - so i needed to catch up a lot at the university

helping wih the project is a nice idea but like i said i'm currently writing my thesis and that has priority

altough it sounds very intriguing

Yap I also have some things to do for school that have a high priority.

But if we patch the kernel we will add a more detailed description of what this piece of code is doing I guess :rolleyes:

Especially in the driver section.

Link to post
Share on other sites
Guest kamikase
I thought this already was the aim of the Android kernel?

It's very inefficient to change the kernel interface within a new kernel version.

This definetly breaks driver backwards compability.

I thought the interfaces stayed the same in the different kernel versions.

It should theoretically be possible though to patch the older drivers into a newer kernel, if you just use the new routines.

I've heard some time ago that I would be possible to just diff and then patch the .27 and .29 kernel, so we'd have a .27 kernel with .29's functions.

i thought so too but what is it that keeps all the phones back in the stoneage of 1.5 and 1.6

i read somewhere (i think it was futurezone or heise - sry both german sites) that there are significant differences in the routines of the different versions

if its possible to pack the old drivers into the new kernel then what is the problem for huawei ???

they could have at least released a vanilla version for the 8230 if its that easy

as far as i understood google wants to simplify this process with one of teh next versions - i'm not shure if froyo is the coming standard or if its the next version

it might also be that if that starts for real with froyo then huawei might weit for a few weeks and finish the next software with froyo

that elimniates also the problem with the small memory since 2.2 has a2sd build-in

and the comunity can build the next version themselves ...

which pulse-source do you have?

2.1 or 1.5?

Link to post
Share on other sites
Guest BigBearMDC
i thought so too but what is it that keeps all the phones back in the stoneage of 1.5 and 1.6

i read somewhere (i think it was futurezone or heise - sry both german sites) that there are significant differences in the routines of the different versions

if its possible to pack the old drivers into the new kernel then what is the problem for huawei ???

they could have at least released a vanilla version for the 8230 if its that easy

as far as i understood google wants to simplify this process with one of teh next versions - i'm not shure if froyo is the coming standard or if its the next version

it might also be that if that starts for real with froyo then huawei might weit for a few weeks and finish the next software with froyo

that elimniates also the problem with the small memory since 2.2 has a2sd build-in

and the comunity can build the next version themselves ...

which pulse-source do you have?

2.1 or 1.5?

Okay, I see.

So the drivers need to be patched too.

I have the .27 QMR kernel source (from Huawei) and the .32 kernel source (from code aurora) + Android 1.5, 1.6, 2.0 and 2.1 source

Link to post
Share on other sites
Guest kamikase
Okay, I see.

So the drivers need to be patched too.

I have the .27 QMR kernel source (from Huawei) and the .32 kernel source (from code aurora) + Android 1.5, 1.6, 2.0 and 2.1 source

i beleave so

the .27 QMR is te one where the drivers vor vibrate etc are missing, right?

well the rest is working so that might be a start

if you are right and there is a way to integrate the drivers into .32 the functionality of 2.1 r6 might be portet to 2.2

otherwise it wil become difficult and timeconsuming :rolleyes:

Link to post
Share on other sites
Guest DanWilson

/off

BigBear, are you really here? Because on my laptop, it says that in Vienna its about 1:05AM... Thats late. Very late. :rolleyes: I mean, I tired now, but I dont know why I'm still awake. Meh.

/on

I really wish you guys good luck with this, and you always know you have a beta tester. (Unless theres a 75.9% chance it'll break my phone...) And I'd help if I knew how to code... Oh well...

[i think I posted right as Bobo went away... lol]

Edited by DanWilson
Link to post
Share on other sites
Guest kamikase

/off

you are right its past 1am here in austria

*tryinghardtokeepmyeyesopen* ...

see you tomorow :rolleyes:

Edited by kamikase
Link to post
Share on other sites
Guest BigBearMDC
/off

BigBear, are you really here? Because on my laptop, it says that in Vienna its about 1:05AM... Thats late. Very late. :D I mean, I tired now, but I dont know why I'm still awake. Meh.

/on

I really wish you guys good luck with this, and you always know you have a beta tester. (Unless theres a 75.9% chance it'll break my phone...) And I'd help if I knew how to code... Oh well...

[i think I posted right as Bobo went away... lol]

I'm still here :(

But I'll leave now.

See you guys tomorrow :rolleyes:

Best regards,

BigBear

Link to post
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.