Develop Bugs

[ThinkTank] Getting an AOSP Eclair build for Hero

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.

FroydVillain 1.3.x/2.x Roadmap

FroydVillain 1.3/2.x roadmap
EDIT: Due to unforeseen issues rapidly accelerating the release of 1.3 (more framework changes), I'll edit this roadmap to reflect 1.4 as well as what we hope to accomplish depending on how many of the 1.3 promised features make it into the accelerated release. Thanks for your patience.
Now that FroydVillain 1.2.x is somewhat stable we can concentrate on the next releases.
First, any and all "WHENNNNNNNNNNN???????!!!!!111oneeleven" posts will be ignored. As usual, "when" = "when it's done".
Features/items in this roadmap are things you can definitely look forward to unless otherwise stated, ie, something happens that renders that feature impossible. Like an asteroid hitting my house, for example.
First, the preliminary work.
I promised the guys over at Cyanogenmod that my new build profile for the Hero (and other MSM7xxA based phones, so the Dream, Slide, G1, etc etc) will be tidied up and offered up in a pull request. I will be cleaning up my tree and submitting my changes before I begin work on the next release of FroydVillain. The main reason for this being, the closer the CM tree is to my tree, the less work involved in keeping the FroydVillain tree up to date with upstream fixes.
Right, so the changes.
Version 1.3.x:
Obviously it is customary to break some **** with each major revision just to give me an excuse to release another release after that broken release.
So for 1.3.0 I nominate, umm...nah I'll let you find out. A release post isn't complete without at least 20 posts asking if anyone is having xxxxx problem and a further 20 posts complaining about the said problem after I post that we're aware and we're very sorry and those responsible shall be flogged.
FroydVillain 1.3.x:
Further changes to the build base and source code to move Froyo-on-Hero further away from reliance upon Eclair libraries. We aim to be building a native libcamera.so in the same vein as the D/S guys are. This combined with already eliminating proprietary liblights makes it easier to...
Switch over to the Froyo prelink map. If you don't know what prelinking is, don't ask. Either don't worry about it or do some Googling. The upshot for you the end user should be better stability and maybe even some added performance improvements.
Along with the addition of the CPU profile to the CM base I'm hoping to get VFP support fixed in the kernel and in the dalvik source. VFP is your phone's ability to offload number crunching to a dedicated number crunch piece of hardware. The cpu the Hero has supports it, however support for VFP on ArmV6 architecture is a bit...well, pants. Accomplishing this should also give another measurable boost in dalvik performance since currently the only enhancement to dalvik, is the optimised binary, the source itself still trudges along with only armv5te support which again rather pants.
Giant /data partition. Thanks Maxisma and co. I'm not going to bring this in until we next need to do a wipe, ie, 1.3 since it resizes the mtd partitions. Coupled with old school apps2sd there should never be a single whine about space on /data ever again. Even dkelley could fit all of his dalvik cache data on it with his encyclopaedic collection of apps. Be aware this will be accompanied by an updated recovery.img so the different layout is supported. You have been warned.
Debugged Exchange support. I can't promise that this will appear in a 1.2.x update but I will get it in for 1.3. I don't use Exchange and so have to rely on others to help find the cause of the issue, debug it and test it. I can't believe after nearly 10 years dodging it, I'm back troubleshooting Exchange bollocks again.
Theme revival. Because Google were kind enough to provide no theming engine what so f**king ever (cheers lads) theming is a pain in the behind that involves hacking the framework. However because we now build from source rather than trying to crowbar bits in and out of a prebuilt HTC tree, it's significantly easier to produce themes from the newly built source tree. I'm working with Alex24 on a project to go with 1.3.x which will put Themes back into the OTA app and they'll be available at the same time as the new releases are. This also allows us to easily add more themes over time.
CMSettings/CMParts. After having a chat with the folks at Cyanogenmod they're more than happy for me to make the menu entry in settings feel more at home within FroydVillain instead of looking like a kicking and screaming rip off from the Cyanogenmod ROM itself. So those of you that have been hopping up and down for CMSettings functionality, it's coming.
Better GPS functionality/better radio functionality overall. For various reasons, changes made by Google, the fact we'll never have official "Froyo supporting" radios, bugs creep into the OS when it comes to using newer Google based apps that make use of the radio. We'll have some fixes for the slow GPS locking and the random reboot/crash when looking for a GPS signal. We're hoping we have mobile data+gps properly nailed down as well.
We're also going to look into different Gallery implementations. Gallery 3D is annoying as hell and the bugs with it are likely due to us relying on the Eclair GL libs. So no further ground is likely to be made until/if/when another MSM7xxA class phone gets Froyo which if any will likely be the Legend. That's a big if though. Imagine if you will, 50 metre tall letters I and F, draped in neon coating with a flashing, strobing sign above them announcing "THIS IS A BIG IF." But no whining if the best you get is the old 2D Gallery as I'm really struggling to find any decent Gallery implementation. Which is somewhat surprising. Perhaps we should offer a bounty for a new decent one.
Add further language support
That's all for 1.3.x for now I think. I'll update this as new things occur or as things appear to be impossible.
FroydVillain 2.x:
Kernel 2.6.34.
What? That's not enough? Wtf is wrong with you? Ok fine.
2.6.34 will provide official support for the newer Froyd features such as in built Tethering and no more annoying bull**** surrounding connecting a simple USB phone to a simple USB port on a simple Windows system. Apparently the Windows driver stack is easier to confuse than a 90 year old Alzheimers suffering dementia patient.
We'll also be looking to bring the Hero Froyo platform closer in line to the more complete Cyanogenmod D/S platform. There's really no reason why we shouldn't be able to especially once 2.6.34 is available since as far as the hardware is concerned the phones are practically identical.
More will be added to the 2.x branch as we discover it. Don't be surprised if in the course of working on 1.3.x some features get pushed back to the 2.x release due to practical limitations or it just making more sense.
Now is the time for feature requests from you the user. 1.2.x is now critical bugs only, I do not want to have to make you wipe/flash 1.2.x now until 1.3 hits so any fixes involving a framework rebuild won't appear until 2.x. 1.2.x is now considered feature complete in the scope of features we want to have supported. New features will appear in 1.3.x or 2.x depending on the work required to make them appear.
So the forum is now yours, dear users, to get those feature requests in. We'll endeavour to get as many implemented as we can. Any ridiculous or unobtainable goals will be identified as such as quickly as possible so people don't get their hopes up only for me to dash them like an abusive husband.

Thanks for all of the Froyo deliciousness you've provided us with! I myself will be waiting with baited breath for the next installments of Froyd.
p.s.
If you need more people with access to Exchange, or if you'd like an Exchange environment to play around with, let me know. I've got an Exchange 2010 machine sitting next to me.

Looking great! Hope you'll get that all working!

acolwill said:
Thanks for all of the Froyo deliciousness you've provided us with! I myself will be waiting with baited breath for the next installments of Froyd.
p.s.
If you need more people with access to Exchange, or if you'd like an Exchange environment to play around with, let me know. I've got an Exchange 2010 machine sitting next to me.
Click to expand...
Click to collapse
Ah, now that -would- be useful. [email protected] if you want to hit me up on GTalk.
maxisma said:
Looking great! Hope you'll get that all working!
Click to expand...
Click to collapse
Cheers bud! Check your PMs.

wow keep on the great work...

Flash? 10char

dpi295 said:
Flash? 10char
Click to expand...
Click to collapse
Impossible, it doesn't work on ARMv6 CPUs.

Ah, now that -would- be useful. [email protected] if you want to hit me up on GTalk.
Click to expand...
Click to collapse
Req sent. Gimme a nudge

dpi295 said:
Flash? 10char
Click to expand...
Click to collapse
Best we can do is see if we can hack over the Flash Lite stuff from Sense, but don't hold your breath.
In fact, you all should start a campaign and hammer the **** out of Adobe to provide an armv5te or armv6j version of the flash library. It's their fault, make them fix it.

Hacre said:
Best we can do is see if we can hack over the Flash Lite stuff from Sense, but don't hold your breath.
In fact, you all should start a campaign and hammer the **** out of Adobe to provide an armv5te or armv6j version of the flash library. It's their fault, make them fix it.
Click to expand...
Click to collapse
They won't do that, they aren't powerful enough..

I'd appreciate it if you would make an optional patch for people who want their phone unlocked by double clicking menu button.

Amazing work! Data Partition, Themes, VillainSettings... cant wait!
As for Feature Requests, +1 for a quick 2D Gallery

Nice post ninpo.

Thanks for your great ROM. I'd love to see better rtl language support in your ROM.

Really lame request, and probably easily fixed just by finding the pictures myself, but could you put all the nice wallpapers you had back into the releases?
It's obviously a very trivial request, but the wallpapers were always exceptional compared to my attempts of being sophisticated. I always ended up with either breasts or something Xbox related...

mobydeek said:
As for Feature Requests, +1 for a quick 2D Gallery
Click to expand...
Click to collapse
+1 for the standard 2D Gallery.
Tanks guys for your hard work.
Sent from my HTC Hero using Tapatalk

Woah, that's a lot of things to do, and some big ones too. Good luck on that, would be awesome to see these things done in the next months, though, take your time, no rush .
As for Feature-Requests: I only have one, and I don't have any idea if it's already done (I don't test many ROMs that often, I'll prefer to stay on my 2.1 Vanilla ROM ) or if it's even possible, so sorry for my Noobishness in advance. Now, I would love to be able to control the Music Player with the volume keys. Short presses change the volume, like before, and long presses skip the songs.

Screatch said:
I'd appreciate it if you would make an optional patch for people who want their phone unlocked by double clicking menu button.
Click to expand...
Click to collapse
Blue-K said:
Woah, that's a lot of things to do, and some big ones too. Good luck on that, would be awesome to see these things done in the next months, though, take your time, no rush .
As for Feature-Requests: I only have one, and I don't have any idea if it's already done (I don't test many ROMs that often, I'll prefer to stay on my 2.1 Vanilla ROM ) or if it's even possible, so sorry for my Noobishness in advance. Now, I would love to be able to control the Music Player with the volume keys. Short presses change the volume, like before, and long presses skip the songs.
Click to expand...
Click to collapse
We'll be putting a modified CMSettings back into FroydVillain in 1.3, so these features will be there automaticallymagically.
Yeah, it's a fair bit of work, but with HTC pretty much ditching the Hero we can take the project and make sure it's all done and done right.
There's collaboration with other developers on other projects for a lot of this, it's not just me or Team Villain making it all happen. I'll be pushing the fixed cpuprofile up to cyanogenmod and they can then work on it too, I'm working with Elemag on the 2.6.34 port, Maxisma brought the repartitioning stuff to everyone's attention for the Hero, etc. Proper open source development at its best.
It's well worth it too. Look how different the Hero runs with FroydVillain 1.2.1, I'm quite frankly disgusted that HTC never, ever, tapped all that potential.

I can't believe it, my hero will never die!
This is indeed great news and I can't wait!
I just wanna thank everyone involved, all the developers are doing a fantastic job bringing us things i never thought was possible on the hero, and I totally agree Hacre, it's a real shame that HTC ditched ther hero when there's still juice left in it!
Cheers!

e2zippo said:
I can't believe it, my hero will never die!
This is indeed great news and I can't wait!
I just wanna thank everyone involved, all the developers are doing a fantastic job bringing us things i never thought was possible on the hero, and I totally agree Hacre, it's a real shame that HTC ditched ther hero when there's still juice left in it!
Cheers!
Click to expand...
Click to collapse
Not to mention juice they never, ever bloody gave us. Grr.

Android 2.3 (Gingerbread) Being Pushed To AOSP

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

Attempting development for Gingerbread. (Long post/discussion)

Hello everyone...I'm planning on trying to develop a gingerbread kernel for AOSP because we don't really have support anymore and everyone has moved onto developing for ICS (not that this is a bad thing). I figure in my spare time I might as well try to learn and develop for our phone. Let me start by saying I was never really into phones/smartphones/rooting, or software development, but I've always been fascinated by Linux in general. I've played around using a number of Linux distros, but I've never really done anything intensive with them (modified their kernels, etc.) but I am vaguely familiar with terminal usage.
Anyways that was just my introduction. I've been running an ICS kernel on my AOSP GB system (specs/stuff in my signature) and while most advised against it, I find it to run pretty well. I'm not sure why it seems to run so well on my phone, but it's basically solved most of my problems (or at least it appears to have done that), but I know the kernel isn't "optimized" for my phone. Some major things people have said are that the ramdisking operations/system is totally different when comparing ICS and GB. This kernel that I'm using is running pretty well, even knowing this fact. What I was wondering is if I could basically get the ICS kernel, then "merge it" with a GB kernel's parameters that pertain to the ramdisk/other major options of GB. That would probably make it better. Also, people stated that multitouch issues for the DINC2 occured on Aeroevan's 0.8 kernel, but not on the 0.7 kernel. This was the changelog stated by aeroevan:
v0.8: Upstream CyanogenMod changes + small touchscreen driver update from HTC. Only tested on my CM7.2 Kang build.
Click to expand...
Click to collapse
So maybe this "small touchscreen driver update" is the thing that caused it, but I'm assuming many other kernels applied this update too? Maybe there is a way to roll back to whatever was in 0.7 in this sense to get rid of the multitouch bug that plagues some people.
I have a pretty powerful laptop, so development shouldn't be too bad. I plan on running Ubuntu 11.10 (or whatever people find suitable these days) in a Virtual Machine and I plan on compiling stuff from there. I am not claiming I know everything or that these things are correct....I am simply just throwing out some brainstorming to get some ideas out there. I know GB is "old", but I (and some others as well) enjoy it's stability and that it generally functions perfectly. Maybe this thread will get a look from popular devs, or maybe it'll get a look from people who just know this stuff. Thanks for reading, and sorry for the length of the post.

Looking forward to your progress on this.
Sent from my ADR6350 using xda premium

It would be nice to have another kernal for AOSP other than aero.

Your help in developing AOSP kernels would be fantastic.
Thanks given. Because I am hard of hearing I cannot use any of the kernels (even Evan's) and have to stick to Sense

[Q] The problem with ROM developement?

The problem with a lot of these popular high maintenance ROM's is that if the Dev's ever get taken away from their work on the ROM at any time, the project can collapse. This seemed to be to me, kind of what happened with AOKP.
What I've suggested in the past and still wondering if it's possible... is to create an app with access to "mount /system..." root privileges etc that is able to add mod's as installable updates/patches? If we had a system like this then all the developers could create mod's instead of an entire ROM and base it off a AOSP, which is technically what all ROM's are based off of anyway.
Then you could install each mod as you wish, just making sure it's compatible with your current firmware/software version.
This would be somewhat of a Cydia approach, the way jailbroken iPhones apply patches to the ROM.
I personally think this is a better idea than having a dedicated Developer OR Set of Developers for each ROM that continually have to be relied upon in order to maintain updates.
Does anybody think I'm speaking any sense here??

AOKP, first off, is very much alive.
Secondly, projects LIKE this exist.
FNV, for example, where everyone is encouraged to push their commits over for review.
There is no "lead developer" and it is the closest you'll get to what you're describing.
As far as just...installing patches and such to get a "flash what you want" type experience...
It isn't that simple.
Even if an open commit is left alone for a few days; it may need rebasing to merge into the branch.
Each little piece of each commit has to build on the previous merges and not interfere with them.
It's a cool thought, bit I can't see it being even slightly plausible.

Jubakuba said:
AOKP, first off, is very much alive.
Secondly, projects LIKE this exist.
FNV, for example, where everyone is encouraged to push their commits over for review.
There is no "lead developer" and it is the closest you'll get to what you're describing.
As far as just...installing patches and such to get a "flash what you want" type experience...
It isn't that simple.
Even if an open commit is left alone for a few days; it may need rebasing to merge into the branch.
Each little piece of each commit has to build on the previous merges and not interfere with them.
It's a cool thought, bit I can't see it being even slightly plausible.
Click to expand...
Click to collapse
Yea I see what you mean, im just wondering how Cydia for iOS interacts with the ROM to apply patches then..?? how have they managed to implement this kind of system?
FNV looks interesting but a little dead. On the other hand, I like how actively updated CM10 is, and it doesn't look like support is going to stop there anytime soon which is a big plus.

UKROB86 said:
The problem with a lot of these popular high maintenance ROM's is that if the Dev's ever get taken away from their work on the ROM at any time, the project can collapse. This seemed to be to me, kind of what happened with AOKP.
What I've suggested in the past and still wondering if it's possible... is to create an app with access to "mount /system..." root privileges etc that is able to add mod's as installable updates/patches? If we had a system like this then all the developers could create mod's instead of an entire ROM and base it off a AOSP, which is technically what all ROM's are based off of anyway.
Then you could install each mod as you wish, just making sure it's compatible with your current firmware/software version.
This would be somewhat of a Cydia approach, the way jailbroken iPhones apply patches to the ROM.
I personally think this is a better idea than having a dedicated Developer OR Set of Developers for each ROM that continually have to be relied upon in order to maintain updates.
Does anybody think I'm speaking any sense here??
Click to expand...
Click to collapse
Remember, the performance of a jail broken iPhone once you install those tweaks, let's just say, all hell breaks loose. My friends who jailbreak and use the simplest of jailbreak scripts and stuff all complain of lag on their iPad 2/3. I personally think its a hack job.
We have the source code unlike iOS, in the spirit of open source, developers download the source, make modifications, compile and make ROMs. They also give out the source to the public again so if anyone wants to base off any existing work, its okay. A great example is cm and perhaps Paranoid Android. And this method is flawed as other devices don't have AOSP support. I'm talking about S2/S3/HTC One X, etc. How are we supposed to make a single stable rom for them that's a clean aosp rom? Usually lots of hacking and tinkering and waiting for kernel sources is required to get AOSP on those devices. Its unlike the nexus where we have everything (source, proprietary drivers, etc) straight from Google. Anyway, that's my view. From the practical standpoint, you have to talk with other developers as ROMs come with their own framework and things.
Sent from my Galaxy Nexus using Tapatalk 2
---------- Post added at 01:31 PM ---------- Previous post was at 01:27 PM ----------
And another note, have a problem with a dead rom? Its probably stable enough for the developer. Or the developer has other important things in life. You can't blame them. What you can do is switch your ROM easily. If your looking for AOKP like ROMs, there's slimbean, CNA and Sourcery and even more that cram in all the tweaks. If you want a clean and minimal ROM, fast and stable, there are roms like Minco and rasbean jelly. Its seriously a different ecosystem than the apple cydia stuff, but it isn't a bad thing.
Sent from my Galaxy Nexus using Tapatalk 2

akash3656 said:
Remember, the performance of a jail broken iPhone once you install those tweaks, let's just say, all hell breaks loose. My friends who jailbreak and use the simplest of jailbreak scripts and stuff all complain of lag on their iPad 2/3. I personally think its a hack job.
We have the source code unlike iOS, in the spirit of open source, developers download the source, make modifications, compile and make ROMs. They also give out the source to the public again so if anyone wants to base off any existing work, its okay. A great example is cm and perhaps Paranoid Android. And this method is flawed as other devices don't have AOSP support. I'm talking about S2/S3/HTC One X, etc. How are we supposed to make a single stable rom for them that's a clean aosp rom? Usually lots of hacking and tinkering and waiting for kernel sources is required to get AOSP on those devices. Its unlike the nexus where we have everything (source, proprietary drivers, etc) straight from Google. Anyway, that's my view. From the practical standpoint, you have to talk with other developers as ROMs come with their own framework and things.
Sent from my Galaxy Nexus using Tapatalk 2
---------- Post added at 01:31 PM ---------- Previous post was at 01:27 PM ----------
And another note, have a problem with a dead rom? Its probably stable enough for the developer. Or the developer has other important things in life. You can't blame them. What you can do is switch your ROM easily. If your looking for AOKP like ROMs, there's slimbean, CNA and Sourcery and even more that cram in all the tweaks. If you want a clean and minimal ROM, fast and stable, there are roms like Minco and rasbean jelly. Its seriously a different ecosystem than the apple cydia stuff, but it isn't a bad thing.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Yea I get what your saying.
Im not complaining about dead ROMs just was trying to think if there was a workaround. But yes I see your point about how a ROM developed from source would be less likely to lag.
I've been on CNA for awhile now, since AOKP slowed right now, and CNA is amazing. I guess CM10 is always a good backup if any of these ROM's stop updates.
thanks anyways.

Dont worry, you'll get your precious roms - this is an aosp device, after all.
Sent from my i9250