I think some of the fun of Android is trying out various ROMs some have cooked up for their devices. Given what we know about this device in particular and what it may or may not share with other devices, what might we expect regarding active development on this device?
In other words, since some devices share worldwide adoption, their development is quite active given the sheer numbers who own those devices, whereas those devices which only have local or regional adoption usually have a less active development section.
Does this Glacier device have enough in common with another device or devices to allow for porting of new functions and/or ROMs easily enough?
Gingerbread port
Yea, Gingerbread port with Ice Cream on top.....
Related
I would like to buy this handset and I wanted to know if the developers from xda are going to work on ROMs for this phone too..
Is it important the hardware OR the operating system(android) when the developers come into play
Both hardware and OS are important, however I doubt anyone in this specific community will be working on it. XDA specialized in HTC devices.
SolemnWishing said:
Both hardware and OS are important, however I doubt anyone in this specific community will be working on it. XDA specialized in HTC devices.
Click to expand...
Click to collapse
Was just going to say that. A lot of other phone companies make it harder to hack them, plus XDA specializes in HTC phones.
uhm.. why is that? that they specialise only on htc devices
lol no idea, its just the main focus of the community.
I don't know that that is necessarily going to be the case...
1) There *are* non-htc devices listed in this forum... a couple of old palms.
2) This is *the* place for android-hacking, which makes it natural to expand on the android line rather than just sticking with HTC.
Time will tell, but I do suspect that there will be some focus on non-HTC android devices here.
Anyone knows when will we get a flashable android version to avoid the batterie issue.
Thanks.
all of us wait
people here working hard for that no one speak a bout definite time just wait
Actually I haven't seen any signs of preparation/progress on a nand bootloader (tinboot), if work has started its certainly is not happening here, which is the problem.
If all of our dev's here simply setup a dedicated thread and begin tracing/mapping nand memory access points we can get to work.
Once the data has been traced we can implement this into tinboot and begin the task of initializing the device hardware; currently winmo is initializing hardware for us.
There are developers available which I'm sure won't mind contributing their time to provide information on initializing the nand bootloader to our device, before my blackstone my last winmo device was a HTC Kaiser and you may or may not be aware but android is running on these old devices extremely well considering their hardware.
DZO is responsible for successfully porting android to the HTC Vogue but later went onto supporting the HTC Kaiser and the HTC Polaris, initially he loaded android via haret as we currently are but has successfully initialised tinboot onto all the above mentioned devices along with initializing hardware properly on boot. Now android is running somewhat natively on all of the above mentioned devices and even outperforming some of the actual Android phones available on the market.
If anyone is curious just how much DZO has contributed to the owners of the above mentioned devices then check out his website:
http://it029000.massey.ac.nz/vogue/
At the moment we are seeing a few nice builds being upped to XDA but the development itself seems to be slowly dying which for a device like the blackstone is a shame as I believe there is alot of potential and with the right optimization I see android outperforming winmo and extending the life of our devices...
Anyway I am done for now, and I am more then happy to contribute porting the bootloader tinboot to our quickly ageing and soon to be forgotten blackstone to keep the android blackstone community alive and to give the blackstone a new lease of life which I believe it deserves.
Best Regards,
ST1Cl<^^aN
I'm hoping somebody will be able to educate me a bit here on some deep technical questions. I've been searching for some information on this topic for a while now but without any luck. In a nutshell what I am curious about is this.. if I were to, lets say, build my own new handset, what would be entailed in getting android to work on it?
I know a kernel must be built with all the drivers and modules to communicate with any specific hardware/radios etc. But once you've got the kernel, is there still more porting that has to be done in the core android code? Are there significant CPU architectural differences or some other major differences between handsets that require more porting within the rest of the OS code? (Side question: if I want to build a kernel from source, what tools do I need)
To ask my question more specifically with the Epic, what is going to be necessary to get Gingerbread on it? If we already have the source for Eclair, or when we get the source for Froyo on the Epic.. what is it that makes it more than just a matter of pulling the drivers from those versions to make things work. Is android not built in a modular enough way to enable that?
I am myself a developer, but as I'm sure is obvious from my questions.. I'm not very experienced at OS level development. And what limited knowledge I do have mainly comes from making correlations to desktop OS, which is probably what is leading me astray.
I'm just really craving to know more about this stuff, so thanks ahead of time to anyone who takes their time to school me and help me understand. If there is any material out there that I should just go RTFM, I'd like to do that but please point me in the right direction.
Thanks!
FYI, your post/s do not pertain to any direct development. They are just generalized questions that can be answered with a simple search.
See Here
Reported as belonging in Q&A/general.
The most difficult part is porting drivers (if they're not already part of the kernel mainline) and device-specific glue code to the new kernel base. This is difficult becuase (i) it's a fair amount of code, (ii) the kernel does not have a stable API, so the necessary changes may be somewhat far reaching, and (iii) bugs that crop up are often more difficult to pin down and fix than in userspace programs. It also doesn't help the matter that Samsung's portion of the kernel code is messy, buggy, and just generally not in a state that would make it easy to port over to a new tree.
The reason why we can't just port Eclair drivers to Froyo, or Froyo drivers to Gingerbread, is that there's a fair number of proprietary modules on the phone (LCD, WiMAX, the entire storage stack, etc.) to which we don't have the source code. These modules are compiled against a specific kernel minor version (e.g., 2.6.29 for Eclair) and won't load in Froyo or Gingerbread. The version number can be faked, but if there's any change in the module API, or in the "API" (which isn't even formally defined) of dependent kernel code, all bets are off.
In theory if there's any Galaxy S device with a Gingerbread release, it might be possible to get a limited-capability kernel up and running, depending on how much the proprietary drivers change across devices (hopefully not much). The Nexus S doesn't count though as Google replaced the entire proprietary flash stoage stack with a GPL-based one. While we might be able to get such running on Galaxy S hardware, it would be incompatible with the existing storage layer and would necessitate a full device flash. Not really something you want to do when an official update with a complete set of drivers is going to be made in the "near" future.
Aside from the kernel, you would have to modify the parts of the Android userland that interface with hardware specific components, for example the "4G" (WiMAX) settings menu and such. I think much of the modem interaction also happens in userland. Then you have to port over whatever custom skin (e.g., TouchWiz) you have.
For some reason this is often believed to be the most difficult and time consuming part of a port, i.e., it's commonly complained that "HTC & Samsung delay releases to port Sense & TouchWiz, if they just dumped them and went AOSP updates would be a lot faster." Honestly it's not. It's an API update like any other Android app, and third party launchers don't seem to have significant problems here.
Mind you, I mention the difficulties of kernel porting without having actually attempted to do it myself, largely becuase it is so daunting. I know there's folks interested in doing this, and perhaps they have some tricks that make it a bit easier in a specific scenario. In general though, these are the difficulties one enounters when trying to port new Linux versions to any embedded platform.
I've often wondered this myself, as well as wondered why Google seemed to get caught with their pants down.
Now granted I don't know the nitty gritty details, but I don't understand why android wasn't written in a manner where as much of it as possible is just apps, and anything that is core is written where the handset makers just need to do the very low level stuff.
On top of that then it could have been made to be more easily themed, even rather dramatically.
Samsung/HTC should only be maintaining the low level "android wants the gps location, I know how to work this specific chip and give it back" and Sense/TouchWiz should just be a theme, and some custom widgets. Android itself should be virtually untouched between those two layers, and updates that don't change how it has to interact with the hardware or the themes should come straight from google.
Thankfully things have at least started to move this way. (you don't need to roll out a ROM update through sprint because Google updated the market like you used to, etc)
If Dell wants to customize Win 7 they add onto it, they don't roll their own copy of it, creating god knows how many fragmentation issues in the meantime. (And yes, I know Windows isn't open source, so they can't, but you get what I'm saying.) Because the second they did that they'd then take on a much larger QA burden, on top of everything else.
If android is untouched for the most part, it works, or it's a bug for everyone. You'd only need to test calls to your low level updates, which could for the most part be automated. The second you start changing a line here and there in the source code, now all of a sudden you have to do the "If I make a calendar item while on a call on a leap year the phone reboots" type QA/Support as well.
Edit: And of course it's very possible that is more or less how it is and the handset makers just flat out take longer to update then anyone imagined they would.
What language/s do you have to know to do all this?
nubsors said:
What language/s do you have to know to do all this?
Click to expand...
Click to collapse
C for kernel and Os. Java for apps(sdk). C and java(ndk/sdk) for apps that require native code implementations of things (eg. The VLC player that is coming. It wasn't possible until the latest edition of the ndk.)
Sent from my SPH-D700 using XDA App
Thank you mkasick for a great detailed answer. I didn't think about the fact there are closed source drivers to worry about as well, and that explains a lot.
@ghostrid3r: I did plenty of simple searches which did not answer my questions before posting, but thank you for the link. Also, not that it matters to me.. but is the development section just for releasing custom roms or something? If questions directly pertaining to development details don't belong there, seems to me the section should be renamed to "Epic 4G Custom Roms" instead.
Just a general thought/question about Android:
What really stops us from using newer versions of Android on our devices, without the need for a dev making a custom rom?
I know the short answer is compatibility. (i.e. drivers etc.)
But what would it take from manufactorers to allow us to uprgade to vanilla versions of Android ourselves?
Consider a desktop/laptop for example: It can continue to run many different versions of ubuntu. No need for customization for each PC. Today driver issues are becoming fewer and fewer as well.
Why can't my phone do the same thing?
Sent from my HTC Vision
different people like different things
some like how CM give you different options
some like MIUI allow you to change theme / icons / other stuff easily
some like the HTC sense widgets / layout
its just very difficult to combine all those into one rom, and retain the speed on all those
then there are manufacturer / carrier restriction a rom needs to add to "prevent us having too much control and brick the phone for warranty purposes"
just think HOW can you combine the miui folders into CM and add all those HTC widgets and other options available
if you can do it, you have made yourself a new ROM people will sought after,
maybe thats the ultimate rom for all ... and we dont need to keep looking forward to a new ones ....
From a development standpoint it could be done. Combining all the roms that is.
The development time on that would be astronomical though, you'd basically be creating a rom almost from scratch and unless you had a HUGE team working for you - updates would be in tiny increments at best, 1.00.00.01 updated to 1.00.00.03 for example. The worst case would be that they'd take forever. Look at how long it takes for a stable release of CM, and that a fairly modest team. Let's not even get started on size, yes most current phones could handle a rom of 250MB+ without any custom MTDs' but damn (sorry) - that's huge. To combine all the main desirable functions of each rom would end up being at least that big.
please devs if you guys get android ported to the sorround let the screen be unlocked with the button on top directly to home...... many of us are having trouble with the touch screens when we lock it..........AAANNNDDD people please be positive about the porting its the only way it'll give hope to the developers on doing this so if your bringing that negative energy go away
As an HD2 user who is looking into replacements (though none can really be found), I can give some tips on how to try.
First, you need to make a port of the HD2's cLK ROM Loader, an open-source bootloader that can dual-boot WP7 and Android. Cotulla's MAGLDR, the first of them, was no easy task to create, and it's Android booting function has not been replicated on other ports to my knowledge.
Next, you need to find a working kernel that is compatible, perhaps from a similar HTC Android phone. It just happened that HTC made the EVO 4G with the same parts to spite the HD2, but even then the kernel needed years of tuning and driver rewrites to get it to where it is now.
Finally, you need a huge worldwide userbase on XDA that is fully dedicated to making Android on your phone possible. For the HD2, it was a superpowered phone crippled by obselete software, so many devs got it cut rate secondhand and had a big motivation to make their phones usable again. Even so, this took a looong time to get a usable Android build, by then which Android phones were fast surpassing the power of the venerable HD2, sapping the initial benefits.
To the OP, we have an old adage where a mouse tells a group of mice that it would be a good idea to put a bell on the neighborhood cat. The mice agree, but seek advice from the elder mouse. The elder brings up a good point: "A good idea; But who will bell the cat?"
Sent fom my HTC HD2
It's pretty hard to do that because of the hardware compatibility and the structure build of the phone I guess but still I also hope that that day would come.
Sent from my Samsung Galaxy SII GT-9100T