Hey guys,
I'm searching for an Android version that has everything working, i.e. Camera, GPS, WiFi...
I know this was possible with Android 1.6, there were several versions, some had the camera working, some had WiFi working - but none had everything working.
But it proves that it's possible.
Why are people only working on Android 2.x anymore, when there are so many things not working and probably never will?
And why make so many different versions with none of them working 100%? Can people not work together and create ONE version that has everything?
Please, if there is any Android (likely 1.6, cause 2.x seems impossible to get fully working) version that has everything working, direct me to it. If not, why not come together and try it?
If you feel it is this easy, why not do it yourself?
I believe noone has made a fully working distribution yet due to the fact that it is difficult. Add the fact that most of the chefs does this as a hobby, and you might understand why it is hard to get developers to spend a lot of time on it.
My two cents.
-KJ
-------------------------------------
Sent via the XDA Tapatalk App
Well, if you actually read my post, I said all the necessary stuff is there for Android 1.6. It IS possible.
The problem is just that people can't work together. There have been 1.6 versions with the camera working, and others with WiFi working, and others with GPS working, but none with everything.
But it's clear that it would be possible, if people put the pieces together.
Unfortunately, nobody seems to be working on 1.6 anymore. It's clear that 2.x will NEVER be fully working on the Touch HD, so why do people waste their time on that?
I am sure we could have a fully working Android version. It doesn't have to be the newest one, but at least it would be good for everyday use.
Well camera was never working on Touch HD and stuff you mentioned aren't about Android version. Those hardware issues are mostly linux kernel related and only way to fix them is to write a proper drivers and modules - and that's the tricky part. Simply put: Android version has nothing to do with non-working hardware on our devices.
I remeber I had the camera working... or was that another device? I have too many phones lying around here, but actually I am pretty sure I had the camera working in an older Android version.
shaundalglish said:
blah blah...
I know this was possible with Android 1.6, there were several versions, some had the camera working, some had WiFi working - but none had everything working.
...blah blah...
Click to expand...
Click to collapse
hey man, wake up!
You 're just frustrated but you do not propose anything.
Thx for this usefull thread
shaundalglish said:
Well, if you actually read my post, I said all the necessary stuff is there for Android 1.6. It IS possible.
The problem is just that people can't work together. There have been 1.6 versions with the camera working, and others with WiFi working, and others with GPS working, but none with everything.
But it's clear that it would be possible, if people put the pieces together.
Unfortunately, nobody seems to be working on 1.6 anymore. It's clear that 2.x will NEVER be fully working on the Touch HD, so why do people waste their time on that?
I am sure we could have a fully working Android version. It doesn't have to be the newest one, but at least it would be good for everyday use.
Click to expand...
Click to collapse
This is a TOTALLY misleading post.
The number of devices, the variation in hardware and memory is quite extensive... yes, somebody MIGHT get the camera working on ONE specific device... this is hardly a version of Android everybody can enjoy.
For the large part most of the developers ARE sharing knowledge, but there are people screaming "why isn't MY device supported, and other saying why are your bothering with old version of Android, and others screaming, where's Froyo???"
XDAndroid's come a long way. But there are only a handful of developers working on it, and they don't have every single phone at their disposal (not to mention every operator variant with slightly different radio code and configuration).
Each week the development takes two steps forward, and one step back... but it's progress. All that you're asking for is more progress.... and the only way you can get that is by contribution the code changes to the dev team.
If you can't do that, then you just have to sit back and wait.
shaundalglish said:
It's clear that 2.x will NEVER be fully working on the Touch HD, so why do people waste their time on that?
Click to expand...
Click to collapse
How is it clear? It's being worked on... perhaps at a pace that's not to YOUR liking, but it's being worked on.
What evidence do you have to suggest it will NEVER be fully working?
It is true that it's proving to be difficult, but it's also true that it's very hard to stay with 1.6 when many new apps stop working with it, or new features NEED 2.x, and all the latest source code will include support for newer devices and 1.6 won't.
The developers aren't working on HD alone, they are working on a release that works on multiple devices. If someone wanted to focus on HD, they'd be welcome to, but nobody is. They are sharing their knowledge for the greater good of all devices.
To be frank, if someone is truly that crazy for Android, then they are fools to be using a WinMo device. They should have bought an Android device.
If I want OSX, I should buy a Mac. The fact that I can run OSX on my PC is nice, but I should expect issues. The same applies to XDAndroid. Expect issues.
TheBrilliantMistake said:
How is it clear? It's being worked on... perhaps at a pace that's not to YOUR liking, but it's being worked on.
What evidence do you have to suggest it will NEVER be fully working?
It is true that it's proving to be difficult, but it's also true that it's very hard to stay with 1.6 when many new apps stop working with it, or new features NEED 2.x, and all the latest source code will include support for newer devices and 1.6 won't.
The developers aren't working on HD alone, they are working on a release that works on multiple devices. If someone wanted to focus on HD, they'd be welcome to, but nobody is. They are sharing their knowledge for the greater good of all devices.
To be frank, if someone is truly that crazy for Android, then they are fools to be using a WinMo device. They should have bought an Android device.
If I want OSX, I should buy a Mac. The fact that I can run OSX on my PC is nice, but I should expect issues. The same applies to XDAndroid. Expect issues.
Click to expand...
Click to collapse
Very well said. These people never stop complaining.
shaundalglish said:
I remeber I had the camera working... or was that another device? I have too many phones lying around here, but actually I am pretty sure I had the camera working in an older Android version.
Click to expand...
Click to collapse
Sorry buddy, but you're not recalling right, the camera has never worked on the Touch HD, no matter how old the version was (and GPS support only came recently a few weeks ago).
Camera support & GPS are a kernel feature (simply put, the kernel is all the drivers for the hardware in the devices and the way to properly communicate with them) it is not an android feature (android operates on top and apart of the kernel).
I can't comment on the other devices but I don't recall having a winmo device having his camera supported in android, they have a really hard time implementing camera support in the kernel, so they did go on with the other things such as better stability, speed and battery life...
But if you have the resources, feel free to help, xdandroid team will be happy to welcome another dev.
Becoming a bit of a flame war and I see no end result.
Thread closed
Related
We have had alot of activity over the last few days, what with the first 2.0 releases from the main players and now even some 2.1 builds. Which is excellent.
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd.
The reason I raise this point, is because I dislike the Rosie/SenseUI on my Hero, I would rather have the good, old Android standard like I had on my G1 - just what I prefer. However there are only beta versions of the AOSP eclair for Hero.
Would it be possible to build an AOSP eclair firmware, using the Qualcomm? proprietory drivers from someones leaked 2.1 image (working on an assumption that 2.1 has the same kernel base?) to produce a fully working Eclair 2.0 for Hero?
If I am way off the mark with this, please say, I'm just trying to think it through with the help of the people in the know.
Ditto. I am all for AOSP 2.0
richbayliss said:
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd
Click to expand...
Click to collapse
I think part of the "issue" is that whilst Google have release some 2.0 code to AOSP, it is not currently complete (see here). In addition, many of the Google apps (e.g. Gmail) are closed source, so you have to rely on prebuilt components which may, or may not, be compatible.
The long and short of it is that Lox is already doing what you are asking. The prerelease of HTC's 2.1 has possibly served as a distraction to the AOSP 2.0 build, but I'm sure once Google properly drops AOSP 2.1 code that work will be of direct relevance to the AOSP project.
Regards,
Dave
yeah exactly. just sit tight and wait for Lox_dev to finish his 2.1 Then he might look after the AOSP 2.0. and as AOSP 2.0 is running pretty fine without much hassle its fine if Lox takes some time before working on AOSP 2.0 . cheers
I'm with this idea!
I mean, just compare the 2.1 and 2.0 aosp videos; android 2.0 has much cleaner, and better transitions imo.
Design choices in 2.1 by HTC are, imo, bad as usual; the transparent notification drawer for example; what is the purpose? It's only jerky. And so on..
I suggest suspending judgement on HTC's 2.1 until they've actually released final code! Remember this is a leaked internal build - what ends up in the final ROM may be quite different.
Regards,
Dave
I think I have a clearer picture now, thanks guys.
I just wish that we could be in a scenario where we could flash a standard AOSP build onto our Hero's, sans the whole SenseUI, and have a basic usable phone.
I really dont get the whole "gmail is closed source" crap with Google. I mean, I can have Gmail on WinMo, S60, etc - but only on Android IF I have a license?? WTF! Crazy! Luckily, now that Gmail does support Exchange Activesync I don't need the standalone app anyway.
So the word on the street is wait.... which I guess is what we will have to do
I am keen to be able to build from source so I can start on a project I have in mind. Think along the lines of SenseUI, but a bit different.....
richbayliss said:
We have had alot of activity over the last few days, what with the first 2.0 releases from the main players and now even some 2.1 builds. Which is excellent.
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd.
The reason I raise this point, is because I dislike the Rosie/SenseUI on my Hero, I would rather have the good, old Android standard like I had on my G1 - just what I prefer. However there are only beta versions of the AOSP eclair for Hero.
Would it be possible to build an AOSP eclair firmware, using the Qualcomm? proprietory drivers from someones leaked 2.1 image (working on an assumption that 2.1 has the same kernel base?) to produce a fully working Eclair 2.0 for Hero?
If I am way off the mark with this, please say, I'm just trying to think it through with the help of the people in the know.
Click to expand...
Click to collapse
Forgive me if I'm missing the point, but we already have a fully working AOSP Eclair image for the HTC Hero. I've been using it for over a week, on a daily basis and other than the looping sync issue (which we are working on) it works fantastic..
jnwhiteh said:
Forgive me if I'm missing the point, but we already have a fully working AOSP Eclair image for the HTC Hero. I've been using it for over a week, on a daily basis and other than the looping sync issue (which we are working on) it works fantastic..
Click to expand...
Click to collapse
I wasn't aware that all issues apart from the syncing were fixed. I thought we still had issues with camera stability etc?? Is this not the case??
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
jnwhiteh said:
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
Click to expand...
Click to collapse
Believe me, I'll come back to AOSP soon with great things
That's an awesome news ! Thank you Lox !
Lox_Dev said:
Believe me, I'll come back to AOSP soon with great things
Click to expand...
Click to collapse
Thanks Lox, appreciated.
Lox_Dev said:
Believe me, I'll come back to AOSP soon with great things
Click to expand...
Click to collapse
Great news man! Thanks a lot! Holding my breath...
jnwhiteh said:
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
Click to expand...
Click to collapse
I agree. The only reason I am now using Lox_devs Hero 2.1 1.4 instead of the pure Eclair one is that Eclair does not sync my exchange calendar. I just cant see why the calendar has been left out.
Hi, developers.
I think that maybe we are losing focus on building a stable and nearly all-functional version of android for kaiser.
Everyone of us has a new app, new feature, requiring an all new mod or version to be installed. We are just replicating the millions of flavours of linux.
That means different energies that, in my opinion, could be collate in one or two major version. This is the spirit of open source community and xda community.
Why simply stopping developping hundreds of mods, backgrounds, subversiones, etc. etc. and focalize on making camera working ? And voice search ? The new google voice maps uses it and having it fully working should be awesome.
Thanks for attention. Just my 2 cents, as someone said
TheMac
Myn's Donut is 100% working as far as I know. There are bugs still, but everything works.
The problem with a lot of Android builds is that they focus too much on a customized UI, rather then fixing existing issues and improving stability and performance.
Dukenukemx said:
Myn's Donut is 100% working as far as I know. There are bugs still, but everything works.
The problem with a lot of Android builds is that they focus too much on a customized UI, rather then fixing existing issues and improving stability and performance.
Click to expand...
Click to collapse
its the same as in WIMO dev. builds are easy. you take the tree and add some tweaks or themes or apps.
fixing problems requires work on the kernal and experience. dont complain about current status unless you intend to do something about it. the people releasing builds usually dont dev the kernal. i know i cant do either.
donate money (to dzo) or do some work or quit complaining
BTW if you spend time reading you would know that there are only two major trees. MOST come from cmod 5.0.7 and mmissions work porting them. wyn seems to be using another branch closer connected to his donut work.
Constructive criticism is not the same as criticism. For example, this thread expresses the concern over charging.
There lots of developers who deserve praise and more, and then there's people who like to put Donate buttons in their sig for no good reason. Not pointing out anyone.
Dukenukemx said:
and then there's people who like to put Donate buttons in their sig for no good reason. Not pointing out anyone.
Click to expand...
Click to collapse
id say most people here dont deserve donation, especially me
still fun to hope i guess
Dear Reefermattness and arrrghhh !
I apologize for making a new thread but I just want have your attention on the Neopeek Release for Rhodium.
In this forum stays that in FRG83.R5 release
http://www.neopeek.com/en/forum/Android-ROMs/2183-ROM-FRG83-Build-Froyo221-05-11-2010
Bluetooth IS WORKING !
I have no idea what this release can, but I saw its structure. Basically EXT2 Partition for Neopeek is the same thing that system.ext2 file for FRX03 !
And in andoidinstall.tar.gz file is the same stuff as in system.ext2 and roofts.img together.
Why we just not pick the working Bluetooth "driver-package-what-ever" from Neopeek and combine it with FRX03 ? I could do it by my self, but I don't have deep system structure know-how.
I must say that FRX03 is lot easier to handle (getting ready, install, edit etc) thats why I'd prefer working with it as with Neopeek.
And besides I just reached almost 8 hrs of working time with one charge on it with new kernel and startup change. Thats why I want to improve it. Can you help me to understand the structure of driver packages for BT ?
Thank you
-------------------------------------
----------------
EDIT:
Here it is, a repack of SuperFroyo in system.ext2 file.
http://narod.ru/disk/27385762000/system.zip.html
I didn't test it yet. But if some one want to try out - please download and report back !
d0nate110 said:
Dear Reefermattness and arrrghhh !
I apologize for making a new thread but I just want have your attention on the Neopeek Release for Rhodium.
In this forum stays that in FRG83.R5 release
http://www.neopeek.com/en/forum/Android-ROMs/2183-ROM-FRG83-Build-Froyo221-05-11-2010
Bluetooth IS WORKING !
I have no idea what this release can, but I saw its structure. Basically EXT2 Partition for Neopeek is the same thing that system.ext2 file for FRX03 !
And in andoidinstall.tar.gz file is the same stuff as in system.ext2 and roofts.img together.
Why we just not pick the working Bluetooth "driver-package-what-ever" from Neopeek and combine it with FRX03 ? I could do it by my self, but I don't have deep system structure know-how.
I must say that FRX03 is lot easier to handle (getting ready, install, edit etc) thats why I'd prefer working with it as with Neopeek.
And besides I just reached almost 8 hrs of working time with one charge on it with new kernel and startup change. Thats why I want to improve it. Can you help me to understand the structure of driver packages for BT ?
Thank you
Click to expand...
Click to collapse
1) as far as I understand Neopeek uses large parts of Xdandroid projects, starting from the kernels/rootfs. This is not hidden/secret, so he and xda devs may know each other pretty well.
Therefore I can't understand how he can have bluetooth working and Xdandroid not.
then ...
2) maybe he shares branches of code and patches with our devs, but while our devs decided that the code to make bluetooth working is still too buggy, he could have decided to shoot it in for good. In fact reading comments on the thread you posted you will see that at the end the people crying for not-working BT are a lot ...
I'd be interested to see if BT works fully. I've seen some where they scream that BT works, but then when they actually try to use BT... it fails. So if it pairs and nothing else, that's what state our build is in as well.
I just installed it, on a blank 2Gb I had spare.
At start it's quite a pain in the arse ...
cmdline was a little different, I just set correct keyboard.
But I immediately put the latest kernel (24.11.2010). Both in installer and main.
Much faster than Xdandroid. Much faster at boot, much snappier in launcher etc., but this may be related also to the age (of the FAT32 file system) of the other SD I use for Xdandroid. Will format it and see what happens swapping.
But then, when it went to sleep it just crashed.
I tampered with the startup, added pmsleepmode=2, this worked, tried =1 and works quite well.
As I expected, BT doesn't work on my RHOD100.
This neopeek build comes nearly all from xdandroid, so it seems it's not as up to date.
But while that guy takes most of development from XDA, he must work a lot on tweaks, therefore XDA should take something back ...
I'll try cleaning the other SD and check what happens.
Installed on extra card. Rhodium 400 . It is fast. Boots quicker. The initial setup screens are very friendly. Power off and other buttons work more like winmo. Bluetooth will not turn on. Phone works. Data does not work. Have to use WiFi for data. USB while in Android does work (sweet). Key board backlighting not working. I am going to reinstall with bluetooth enabled initially in winmo.
Neopeek SuperFroyo Repack into system.ext2
arrrghhh said:
I'd be interested to see if BT works fully. I've seen some where they scream that BT works, but then when they actually try to use BT... it fails. So if it pairs and nothing else, that's what state our build is in as well.
Click to expand...
Click to collapse
Here it is, a repack of SuperFroyo in system.ext2 file.
http://narod.ru/disk/27385762000/system.zip.html
I didn't test it yet. But if some one want to try out - please download and report back !
reinstalled Bluetooth not working. Rhodium 400
Only things that could make improvements to XDA android are Speaker phone is working. USB in android does work. Buttons function as they should. It works with SIM card installed. Speed. Boots faster. Screen adjusts to right profile on start lockscreen.USB headset works without line in startup.
Still not working
Data does work but have to manually set APN. Headset does not work ( Does work with line in Startup and calling during boot). Problems with the market downloading.
Does work tethering. pretty much everything
One nice thing is they have a seperate install folder so if your system is corrupted you just reinstall with file manager in winmo. It reformats the ext2 partition on the card. I assume the sizing of partition is in place of the sizing the data.img file on the card.
Being open source borrowing a few items should not be considered crossing a line.
d0nate110 said:
Here it is, a repack of SuperFroyo in system.ext2 file.
http://narod.ru/disk/27385762000/system.zip.html
I didn't test it yet. But if some one want to try out - please download and report back !
Click to expand...
Click to collapse
wait a minute.. you didnt test it and are spreading it like wild fire ?
before you cry wolf, at least pretend you saw one ..
First Full Day Of Testing
[ACL] said:
wait a minute.. you didnt test it and are spreading it like wild fire ?
before you cry wolf, at least pretend you saw one ..
Click to expand...
Click to collapse
I've tested this strange build a whole day today... I must say...I'm confused...
First of all I charged my battery to full 100% in WinMo. Then I've just replaced old system.ext2 with this one (my other files incl. kernel were untouched) and booted a clean Haret and saw, that this Android Learning Demo just didn't want to go on if I taped on it...
My device was locked and I must reboot it...then I delete my data.img file and tried again... success - SuperFroyo booted well.
- Bluetooth doesn't work as pessimistically expected
Other stuff works same like in our Froyo Reference.
- flash 10.1, loudspeaker, camera, usb connection and headphones don't work
- sleep_mode=1, wifi, phone, wake up on call and Market are working.
But Battery life was little better according to JuicePlotter... and I had a feeling, that all the system works little bit faster... I don't know if it is just placebo effect, but I thing its true...
I'll keep testing it for another 3-5 days and report back... and BTW you can test it too.
d0nate110 said:
I've tested this strange build a whole day today... I must say...I'm confused...
First of all I charged my battery to full 100% in WinMo. Then I've just replaced old system.ext2 with this one (my other files incl. kernel were untouched) and booted a clean Haret and saw, that this Android Learning Demo just didn't want to go on if I taped on it...
My device was locked and I must reboot it...then I delete my data.img file and tried again... success - SuperFroyo booted well.
- Bluetooth doesn't work as pessimistically expected
Other stuff works same like in our Froyo Reference.
- flash 10.1, loudspeaker, camera, usb connection and headphones don't work
- sleep_mode=1, wifi, phone, wake up on call and Market are working.
But Battery life was little better according to JuicePlotter... and I had a feeling, that all the system works little bit faster... I don't know if it is just placebo effect, but I thing its true...
I'll keep testing it for another 3-5 days and report back... and BTW you can test it too.
Click to expand...
Click to collapse
I'm on nand, so i cant run that abomination. However i did run the real cyanogen and it was a lil faster. But it took too many changes to the rootfs to get it to run.. i havent tried it since..
Also im not sure why neopeek isnt using our rootfs structure so you can swap the system.imgs easier .. maybe you should ask him
too buggy things would work then stop working. I could plug in a usb headset have it work in a call or music unplug it then plug it back in and it does not work. Many other things like that. Same with the 3.5 jack trick it would work sometimes then sometimes not. If u left it stock it works great and is very fast. Diamond users were happy. I have a diamond that I will try it on sometime next week, but it is not good for rhodium. It did something to the usb on my Rhodium in winmo would not work so gave me a chance to jack in energy rom like that so far.
[ACL] said:
I'm on nand, so i cant run that abomination. However i did run the real cyanogen and it was a lil faster. But it took too many changes to the rootfs to get it to run.. i havent tried it since..
Also im not sure why neopeek isnt using our rootfs structure so you can swap the system.imgs easier .. maybe you should ask him
Click to expand...
Click to collapse
Sorry for silly question, but what do you mean with "being on nand"?
And, lol, why abomination!?!?!?
It's clearly taken from FRX02 Xdandroid build, but tweaked to be more speedy.
These tweaks are something that Xdandroid should port back to main project.
I have only one crash a day with Neopeek's FRG83.R5, while Xdandroid FRX03 is not only slower on my TP2 rhod100, even with around 100Mb ram free, but keeps slowing down even more while using, so that I have to restart.
In the last week this led to process ".acore" crashing almost immediately after boot, with no solution known to me except reinstalling.
That's once a day.
Neopeek did this only once.
Still have to understand what leads to ".acore" process chain crashes.
I would prefer to use Xdandroid FRX03, because it's more up to date and standard compliant, but, strangely, it's not as stable as Neopeek's FRG83, on my phone.
Cheers.
EDIT:
uh, oh, d0nate, I think we are messing it a little bit here. I am testing FRG83.R5, not SuperFroyo.
They are 2 different builds.
What are you effectively testing?
Sorry about that
sad0felix said:
EDIT:
uh, oh, d0nate, I think we are messing it a little bit here. I am testing FRG83.R5, not SuperFroyo.
They are 2 different builds.
What are you effectively testing?
Click to expand...
Click to collapse
First of all I AM NOT Donate - I'm donatello written with numbers
I don't want any donations and hate money
Second I apologize, but I can't implement FRG83.R5 to use without formating my SD-card thats why I use a SuperFroyo. The member DmK75 gave me this link to system.ext2 file with SuperFroyo release in it...
I try though to repack FRG83.R5 also in system.ext2 file later... I just don't have the know-how yet...
sad0felix said:
Sorry for silly question, but what do you mean with "being on nand"?
And, lol, why abomination!?!?!?
It's clearly taken from FRX02 Xdandroid build, but tweaked to be more speedy.
These tweaks are something that Xdandroid should port back to main project.
I have only one crash a day with Neopeek's FRG83.R5, while Xdandroid FRX03 is not only slower on my TP2 rhod100, even with around 100Mb ram free, but keeps slowing down even more while using, so that I have to restart.
In the last week this led to process ".acore" crashing almost immediately after boot, with no solution known to me except reinstalling.
That's once a day.
Neopeek did this only once.
Still have to understand what leads to ".acore" process chain crashes.
I would prefer to use Xdandroid FRX03, because it's more up to date and standard compliant, but, strangely, it's not as stable as Neopeek's FRG83, on my phone.
Cheers.
EDIT:
uh, oh, d0nate, I think we are messing it a little bit here. I am testing FRG83.R5, not SuperFroyo.
They are 2 different builds.
What are you effectively testing?
Click to expand...
Click to collapse
Ahh you poor soul.. nand meaning i no longer have wince so i cant run his installer. Abomination is a strong word.. so i take it back . But i do think it's wicked and it's not a child of xdandroid like you think. The main chunk of the project comes from cyanogen. The only parts that were pillaged from xdandroid appear to be some of the roofs files (including the hardware libs). And of course, our kernel runs the whole show.
Now why would i run some hacked up version if i can run cyanogen directly? Plus cyanogen has everything open, so we can easy work and modify it as we need. I have not seen anything shared by neopeek, so i dont feel its fair to the xdandroid team since we pretty much share everything.
If it's stable for you.. awesome.. maybe there is future for it.
[ACL] said:
Ahh you poor soul.. nand meaning i no longer have wince so i cant run his installer. Abomination is a strong word.. so i take it back . But i do think it's wicked and it's not a child of xdandroid like you think. The main chunk of the project comes from cyanogen. The only parts that were pillaged from xdandroid appear to be some of the roofs files (including the hardware libs). And of course, our kernel runs the whole show.
Now why would i run some hacked up version if i can run cyanogen directly? Plus cyanogen has everything open, so we can easy work and modify it as we need. I have not seen anything shared by neopeek, so i dont feel its fair to the xdandroid team since we pretty much share everything.
If it's stable for you.. awesome.. maybe there is future for it.
Click to expand...
Click to collapse
Woah ... I am feeling soooo noob ... dang you!!!
Since I wrote my previous post my knowledge grew about ten times ... from 0.001% to 0.01%, so now I can see what you mean about Cyanogen and all the rest.
I know it's everything but a good excuse, but please notice that I got to Android just in the form of Xdandroid, and only in the last few weeks.
So I am learning. Maybe faster than mean people, still much slower than hardcores like you or the other devs.
----------------
In the meanwhile I reverted back to FRX03.
Mainly because of stabilities (better, instabilities are regular so that can be forecasted and behaviors provoking them can be avoided with good success rate).
Still I think that maybe (and I cap it, MAYBE) Xdandroid could (I don't say should, it would be excessive) benefit from the Neopeek/Cyanogen "thing".
You know, like when you have a crate of stuff, you dive hands in it and choose and pick up just the good things/those you like.
I just dream a Xdandroid snappy like Neopeek's whatever build (I tried 2).
... the speed ... the speed .... (put here Marlon Brando's voice in Platoon, when he repeats "the horror" ... ).
Cheers!
EDIT:
I fear that you did it all by yourself, but in any case I ask you.
Is there any public documentation about going nand? What are the advantages?
You put a thermite in my left ear, you know?!?!?!
Here's the PPCG thread on NAND boot testing. Not for the faint of heart...
sad0felix said:
Woah ... I am feeling soooo noob ... dang you!!!
Since I wrote my previous post my knowledge grew about ten times ... from 0.001% to 0.01%, so now I can see what you mean about Cyanogen and all the rest.
I know it's everything but a good excuse, but please notice that I got to Android just in the form of Xdandroid, and only in the last few weeks.
So I am learning. Maybe faster than mean people, still much slower than hardcores like you or the other devs.
----------------
In the meanwhile I reverted back to FRX03.
Mainly because of stabilities (better, instabilities are regular so that can be forecasted and behaviors provoking them can be avoided with good success rate).
Still I think that maybe (and I cap it, MAYBE) Xdandroid could (I don't say should, it would be excessive) benefit from the Neopeek/Cyanogen "thing".
You know, like when you have a crate of stuff, you dive hands in it and choose and pick up just the good things/those you like.
I just dream a Xdandroid snappy like Neopeek's whatever build (I tried 2).
... the speed ... the speed .... (put here Marlon Brando's voice in Platoon, when he repeats "the horror" ... ).
Cheers!
EDIT:
I fear that you did it all by yourself, but in any case I ask you.
Is there any public documentation about going nand? What are the advantages?
You put a thermite in my left ear, you know?!?!?!
Click to expand...
Click to collapse
nand is for the brave.. so if you are just starting. then stay away since we already had a brick happen. I also corrupted something myself so it can get nasty. Once we stabilize it will get better. The main advantage is that you no longer have windows. lol.. but the disadvantage is that you dont have windows to fall back on. It also lets us develop as if the phone would be native to android. Believe it or not but wince does alot of the dirty work for us. So the nand project lets us recreate all that ourselves.
Cyanogen is just a different animal. Xdandroid is based of pure google code as it was meant to be. It also lets us modify it for our devices that were never meant to have android. Cyanogen only supports devices that already came with android. You can modify it to run on other devices, but the main builds themselves are for specific devices. Xdandroid supports all with just 1 build. We forget sometimes about our other winmo htc brethren like topaz and blacstone. But they need a build too.. .
If you are really interested in this, you can clone both codes and compare just how different we are. If you find something you think will benefit, try it out and see what happens. Gotta love opensource.
[ACL] said:
nand is for the brave.. so if you are just starting. then stay away since we already had a brick happen. I also corrupted something myself so it can get nasty. Once we stabilize it will get better. The main advantage is that you no longer have windows. lol.. but the disadvantage is that you dont have windows to fall back on. It also lets us develop as if the phone would be native to android. Believe it or not but wince does alot of the dirty work for us. So the nand project lets us recreate all that ourselves.
Click to expand...
Click to collapse
Hep, I am just a curious guy.
One of those many that want to put their nose everywhere, but also one of the few that:
a) most of the times will need to read the guide just once (if guide isn't enough there are FAQs and Google),
b) will follow instructions easily because normally understands what they mean/what they are for
c) will never give it up until success
d) will never come to the forum writing: "I have a phonez, tried to put some android on it, doesn't work HELP1!!1!!1!"
Moreover, my TP2 is just 6 months old, is a gift, I use it for work, so to not void the warranty I didn't even install HardSPL on it.
So do not worry.
I am just curious to read how you can do it.
But will not die if I don't know yet
Cyanogen is just a different animal. Xdandroid is based of pure google code as it was meant to be. It also lets us modify it for our devices that were never meant to have android. Cyanogen only supports devices that already came with android. You can modify it to run on other devices, but the main builds themselves are for specific devices. Xdandroid supports all with just 1 build. We forget sometimes about our other winmo htc brethren like topaz and blacstone. But they need a build too.. .
If you are really interested in this, you can clone both codes and compare just how different we are. If you find something you think will benefit, try it out and see what happens. Gotta love opensource.
Click to expand...
Click to collapse
Basically you are suggesting me that all the (amazing) speed of Neopeek's builds comes just from using direct EXT/SWAP partitions on SD.
So, is there anyone trying to build a Xdandroid with EXT/SWAP structure?
sad0felix said:
Basically you are suggesting me that all the (amazing) speed of Neopeek's builds comes just from using direct EXT/SWAP partitions on SD.
So, is there anyone trying to build a Xdandroid with EXT/SWAP structure?
Click to expand...
Click to collapse
Not to my knowledge. I guess we should *try* it just to see if there's a big difference... perhaps Neopeek can help us here muhahahahaha!
But I think the theory was the tradeoff would be small - a lot more work for very little reward. However, I would be interested to see if there is a difference, and if it is big or not. At the very least just to know if it's our build or just the ext2 partition that's making it feel snappier.
In addition, AFAIK swap partitions on SD cards should be avoided, unless they have a write-levelling scheme (I believe they only put these in SSD's... I don't think any SD card has this tech because it's typically unnecessary) - I've heard swap partitions can just destroy a normal SD card because of writing and re-writing to the same area of the card many, many times... I mean physically on the card, not just logically in the folder hierarchy.
Just installed it on my diamond Bluetooth does work but it doesnt pair. The screen eventually graduates to the center dividing it in opposite. I thought maybe because I was running the hot version. Repartitioned reinstalled the normal clock version runs for a time then the same. Its no better than XDA
http://www.androidpolice.com/2010/1...3-gingerbread-being-pushed-to-aosp-right-now/
go, go, go! )
These are very good news
I already see my Hero running CM 7
:happy face:
Excellent News Lets see who get's their GingerBread ROM out first
Sweet, if the hero really will be supported!
Cooooooooooooooool man very nice go go go go gooooooooooooooogle
Tchuup-tchuup! Hotness train is leaving the stations
ummm...
yea. will be interesting to watch... if it works on hero it will be fun... I don't expect devs will take the time on the hero any more like they used to but if someone out there has the know how and time and dedication then it's probably possible.
dkelley said:
ummm...
yea. will be interesting to watch... if it works on hero it will be fun... I don't expect devs will take the time on the hero any more like they used to but if someone out there has the know how and time and dedication then it's probably possible.
Click to expand...
Click to collapse
Feeyo...
Good news
Sent from my HTC Hero
C0mpu13rFr34k said:
Feeyo...
Click to expand...
Click to collapse
should be interesting to watch his progress
I wish the technical know-how would be something well documented.
What I mean is, ive seen lox/benocharm (sp?) progress in the last year in terms of Android knowledge, almost from the start. Ive seen one of these two guys post about initial questions about how things work, then edit his own post to do a mini-FAQ on ROM cooking. Now today it would look like they would kick some major ass at doing it if they were still able to give time for this, because they know the Hero hardware by heart; they know the usual glitch when porting (ie: how to make camera/bluetooth work, etc), all the minor details that makes a ROM usable or not for a day-to-day ROM! However, this kind of knowledge seems not so well documented.
What i'm basically saying is if a developer bails out the documentation about how to rebuild a custom ROM does too. It looks like (from a non-cooker point of view) that there is no centralized Wiki or webpage about the usual generic steps or roadblocks when porting from another device or when starting from AOSP to build FOR an Htc Hero (or any device, too).
Personally i know enough about linux in general, ive build a few updates.zip for my own knowledge's sake (nothing fancy though, removed/added apks ), but I have my questions on how to properly make something not built specifically for an Hero work with all the hardware functioning. I'm sure many others are in the same boat (plenty of tech knowledge but lack of Android ROM resources). For example, the question I had in mind were in the form of:
Does specific hardware components (gps, wifi, bt) relies on linux kernel modules? Does it need some kind of special APKS or Jars to make it work along with the framework, or just kernel modules are enough once loaded?
Following up on the point above: would copying modules from another device specific ROM would be sufficient? (I guess not), what about Android release versions (Eclair, Froyo, Gingerbread, etc)? Can modules work regardless of the Android version being run on?
ETC...
Well its pretty much a long rant, but since i'm stuck with a 3 year contract on Telus with an HTC Hero, I wouldnt mind giving a bit of my free time to make a working ROM out of it. However I am/was under the impression that the Hero ROM development scene went to a stop once Cyanogen started supporting Hero (seems to me there are only two *major* roms out there, CM and VillainRom), and due to that ROM cookers stoped caring about the Hero since it was well enough supported as it is (with CM on board).
Thanks for listening, doctor
I'm actually in the process of setting up an Ubuntu virtual box to dive right in, when I saw the AOSP sources getting pushed I thought why wait? Why not try it myself?
Don't expect anything soon. First of all I am just going to build off the Cyanogen tree and see if I can make a working ROM, then I will look into the deep dark hell that is porting software to HTC's proprietory-drivered-up-the-ass Hero
l0st.prophet said:
I'm actually in the process of setting up an Ubuntu virtual box to dive right in, when I saw the AOSP sources getting pushed I thought why wait? Why not try it myself?
Don't expect anything soon. First of all I am just going to build off the Cyanogen tree and see if I can make a working ROM, then I will look into the deep dark hell that is porting software to HTC's proprietory-drivered-up-the-ass Hero
Click to expand...
Click to collapse
Any luck with it? I had the same idea, reading now a lot of information about building a rom.
Maybe we can post some useful links or tutorials about building ROMs in this thread so that we can kind of collaborate?
That would be a great idea, i really like the idea of building my own rom. or at least try to build one.
Here you can find how to setup your own machine to build android roms
http://source.android.com/source/download.html
if you have problems with installing sun-java5-jdk follow the instructions on this page:
http://blog.enea.com/Blog/bid/32050/Ubuntu-9-10-Java-5-and-the-Android-Open-Source-Project
Also checkout Cyanogen's wiki, they really did an excellent job there:
http://wiki.cyanogenmod.com/index.php?title=Compile_CyanogenMod_for_Hero
I'm progressing... slowly. Downloading Ubuntu 10.10 iso, 200MB of updates, the SDK, Eclipse, the ADT plugin, all the platform updates and GIT is taking a while on < 2Mb connection...
Especially the repo syncing... that just takes ages ;
krispijn_s said:
Especially the repo syncing... that just takes ages ;
Click to expand...
Click to collapse
Gives me time to read I spose! I totally understand how to build off Cyanogen's code, that sounds simple, but I get a little lost when it comes to syncing with AOSP or branching Cyanogen to make changes... but I got hours of dowloading yet so I can read up about it then!
Make sure you download the x64 version of Ubuntu. Since 2.2.1 you need a 64-bit system to compile the Android OS project.
Also don't expect to get it compiling right away, I reckon somekind of cpu-profile is missing (could be named different). Third I heard that the sound and camera (again) systems got changed, could be buggers to get those working.
Just my two cents
Hi!
I have great respect for the people that give us our great ROMs, and i KNOW that that is hard - but my question is: why exactly is it that hard?
This is just a question out of curiosity, because I would really like to understand the unerlying problems that cause all the other issues.
I was under the impression that the Android stack runs on top of the Linux kernel.
Usually, the Linux kernel is the Hardware Abstraction Layer, and apps and ROM, in theory, should be kind of hardware agnostic?
e.g. the Bluetooth Issue on our Captivate Glides: I would guess that Android communicates, through some API, with the kernel's BT stack/driver. There must be some (open or closed source) driver available (worst case: some .so module ripped out of an official ROM, maybe?). So why does the headset profile not work? Did the APIs change? Are custom ROMs forced to use another version of the driver?
It also happens to this 50$ chinese tablet i have here: some ROM screw up the touchscreen, some break audio, and so forth. Why can't there be some way of installing a generic ROM, and then side-loading the OEM's drivers?
Thank you again to all ROM developers! This is NO WAY a complaint. Just pure curiosity!
I may be out of my league when trying to describe this, but the processor in our phones is somewhat different to the processor in the bulk of other phones. This is where majority of the issues came from in porting ICS to the glide before ATT released it. Even after the first official ICS update, the modders here were the ones who fixed the keyboard lights... I changed up to JB because the GPS wasn't locking quick enough and PACROM had all the quick toggles and the speed/gps lock I needed.
Sure the kernel is the underlying part that pulls it all together, even still there is all the drivers that need to work with it. If there isn't a bluetooth/wifi/HW Video driver for the version of the kernel, then it gets really tricky and now its coding for a piece of software to speak with the hardware ..... We have things that partially work, but not fully ...as with everything computers, in theory things that "should" work, don't always... I'm an IT tech.. I run into weird **** all the time that "should" work ... takes time, but with persistence and the right skillset, majority of the time a resolution can always be found.