Related
What I mean is, it seems to me that it would be more efficient to put any/all files that may be upgraded as packages and instead of flashing cooked roms, we could flash a generic rom and uninstall old/reinstall new packages
Am I making sense to anyone?
I understand you
I believe this is part of what chefs who create "lite" or "unbloated" or "clean" or "naked" (in Garmin's ROMs) are trying to achieve.
I personally like the idea, and hope we see more of them.
My personal favorite ROM of all time was the very first Hyperdragon III
mbarvian said:
I understand you
I believe this is part of what chefs who create "lite" or "unbloated" or "clean" or "naked" (in Garmin's ROMs) are trying to achieve.
I personally like the idea, and hope we see more of them.
My personal favorite ROM of all time was the very first Hyperdragon III
Click to expand...
Click to collapse
Up until recently the problem has been that cooks either created loaded ROMs with tons of stuff added to them, or lite ROMs, where they stripped this out.
The issue was however that it is quite easy to strip things out of a ROM. Making CAB packages out of those stripped out files however can be one of the more time consuming tasks and cooks didn't always offer those packages. In addition, CABs which were made available from other sources weren't always packaged in entirety and wouldn't always install.
Cooks have been getting better at this recently however. My new set of ROMS follows these concepts precisely:
http://forum.xda-developers.com/showthread.php?t=429117
I have been calling and advocating for this too basically since the dawn of UC
Previously I didn't post much under different nick, but I have "put up together" this concept in THIS thread finally, albeit with somewhat misleading "temporary" title, but it is good discussion if anyone is interested.
Granted, few apps have to be cooked-in in order to function properly, but those are really just very few. But as you can read there, most objections against this kind of "real lite" ROMs (where any "upgraedable apps" are NOT cooked-in) come from people who don't understand it, or don't know much about UC or Sashimi (BTW I'm for UC rather than Sashimi because UC is much easier for any newbies), or just don't know/have no clue how it works and are affraid it would make troubles to them if they don't have the same apps cooked-in.
Perhaps any of you could add your input there, since there isn't much sense in starting new thread about basically same thing.
Bengalih, I will test your ROMs with pleasure when I have bit m,ore time (or actually a second Kaiser would be great ).
But I can already give you my sincere congratulations now if you have created such ROMs
I have made ROM based on hang.tuah's ROMeOS (it was going to be an update, but ended in another ROM, LOL - not quite "lite" as I would want it, but I can't change the things that were "always there" now ). I try to steer its users into UC and use "extended packs" for things like dialers, comm managers etc. They'll have best proof that "cooked-in" is *worse* than "installed" soon, when they will have i.e. choice of Opal or Kaiser dialer in the extended pack - which obviously would be impossible if the dialer was cooked-in in the ROM...
@bengalih: your post is what got me to thinking about this again
I'm happy to see that you others share my attitude towards efficiency
I have not completely read thru both of your threads but I suppose what needs to be done is to create a universal standard
The way I see it, this type of system would be beneficial to cooks and end users alike. End users need a minimal variety of options to install these collections and a minimal variety of each basic rom release to install the collections to. Cooks need a simple system to adhere to that requires no more work to put together their collections than the current amount of work they do to create their roms.
Here is a sample proposal (what I'm thinking right now with a minimal knowledge of rom cooking )
A base rom of each flavor could be made available to download. By each flavor, I mean a different rom with each combination of files that must be cooked in to work. I haven't read anything like that before so if there are more than a couple combinations then no more than 4-5 with typcal combinations should be considered.
I need to do some reasearch to learn what benefits and/or caveats are associated with UC and Sashimi. I suppose cooks should be the ones to decide whether to make their collection(s) combatible one installer or the other.
selyb said:
@bengalih: your post is what got me to thinking about this again
Click to expand...
Click to collapse
In the future it might just be best to post in the thread about this then. As a topic that has been tread over several times putting additional input into an existing thread would be more effective.
selyb said:
I have not completely read thru both of your threads but I suppose what needs to be done is to create a universal standard
Click to expand...
Click to collapse
Perhaps you should read through the threads that are already out there before staring a new one that re-hashes the same information.
selyb said:
The way I see it, this type of system would be beneficial to cooks and end users alike. End users need a minimal variety of options to install these collections and a minimal variety of each basic rom release to install the collections to. Cooks need a simple system to adhere to that requires no more work to put together their collections than the current amount of work they do to create their roms.
Click to expand...
Click to collapse
Good luck trying to get cooks to follow anything you propose. Not that it might not be a brilliant idea, but cooks are going to do their own thing. I decided to take matters into my own hands and cook my own ROMs according to the principles I thought best. I put the ROMs and my principles out there in hopes others will adopt them, but that's the best you can do...
selyb said:
A base rom of each flavor could be made available to download. By each flavor, I mean a different rom with each combination of files that must be cooked in to work. I haven't read anything like that before so if there are more than a couple combinations then no more than 4-5 with typcal combinations should be considered.
Click to expand...
Click to collapse
Again, pretty much what I have done already with the HTC and AT&T official 6.1 releases. A base ROM for each with a set of CAB file to customize to your desires.
selyb said:
I need to do some reasearch to learn what benefits and/or caveats are associated with UC and Sashimi. I suppose cooks should be the ones to decide whether to make their collection(s) combatible one installer or the other.
Click to expand...
Click to collapse
No offense, because I realize I am coming off a bit gruff in this post, but you do need to do alot of research. I agree with alot of what you are saying, but it has been said before (by myself and others). Also, there is no reason that a collection of CAB files wouldn't work with SASHIMI instead of UC or vice-versa. To your own admission, you don't understand how these installers work, but when you do your research you'll see that in essence they are both just installing CAB and XML files (and with SASHIMI the capability for much more).
Again, please don't take anything here as a personal attack. I can see that you are coming off of inspiration from my posts and I don't disagree with your basic ideas. However you will get better reception from all if you do these things:
1) Research what is out there before posting so you don't retread old ground.
2) Don't just "propose" ideas, put them into action. Even the best ideas are unlikely to be adopted unless you put effort into implementing them youself.
I say these to you for your own protection before someone not as nice as me begins to bash you for not doing research
Ok, well, I will quit posting to this thread before someone not so nice does come along.
selyb said:
Ok, well, I will quit posting to this thread before someone not so nice does come along.
Click to expand...
Click to collapse
Heh... well seriously, take some time and learn more of what is currently out there and see where it is lacking.
I generally invite user feedback on my development projects. If you go back through the older threads, and take a look at what I am trying to do with my BRR ROMs, please feel free to comment in there about what additionally you would like to see and why.
Trust me, I very much welcome an open debate about what would be an effective way to do things. I just wanted to burst your bubble a little bit (seeing as you are a newer member) that your aspirations, although maybe valid, are most likely not going to get implemented by a majority of the cooks throughout the site.
I don't mean to shut down your thread, and you should continue posting if you see it as the best place to do so. I just feel that if you contribute to some existing projects that already have momentum then your ideas are more likely to get some attention.
As long as a Rom doesn't include googlebits it should be fine on google code right? It would be nice to use for bug tracking and a quick downloading service.
Doubt it, since I imagine that a lot of bits are closed-source and harvested from existing ROM dumps and so forth.
I believe quietblongs was the only dev here that actually built his roms from source. With that said. I mean the entire thing except some libs. But I'm not sure if anyone else is doing this. I think most of the aosp roms we have are ports with maybe compiled frameworks from source. Again that's just a guess.
But speaking of quietblongs... I wish he'd come back and make us a bad ass 2.1 aosp build.(a hint to quiet to build us another bare bones build)
I have a "generic" 2.1 AOSP build. The problem is getting the HTC vendor/oem stuff incorporated. I have tried following Cyanogen's lead with his "vendor overlay" in git, also borrowing from Lox's GSM hero stuff, but when I build it that way ((via "lunch htc_heroc-eng") I still end up needing to manually copy the proprietary files one-by one into build to get a resulting system.img. In other words, I'm missing a script that should do this during the build. Since nobody seems to be building for CDMA hero (I find directions for dream, magic, and nexus only), I basically don't trust my result enough to upload for others.
Building 2.1 as "generic-eng" is trivially easy, we could have a "nightly build" setup if we wanted. But getting the vendor stuff properly incorporated into the build (and having the build use these files to generate its source) is not a clear process to me yet. I'm learning but it takes time I don't always have.
On a side note, maybe someone could comment on whether a fresh build with the vendor stuff could/would solve ongoing issues like the camera or whether that is a 2.7/2.9 kernel issue that needs a backport.
5tr4t4 said:
I have a "generic" 2.1 AOSP build. The problem is getting the HTC vendor/oem stuff incorporated. I have tried following Cyanogen's lead with his "vendor overlay" in git, also borrowing from Lox's GSM hero stuff, but when I build it that way ((via "lunch htc_heroc-eng") I still end up needing to manually copy the proprietary files one-by one into build to get a resulting system.img. In other words, I'm missing a script that should do this during the build. Since nobody seems to be building for CDMA hero (I find directions for dream and magic only), I basically don't trust my result enough to upload for others.
Building 2.1 as "generic-eng" is trivially easy, we could have a "nightly build" setup if we wanted. But getting the vendor stuff properly incorporated into the build (and having the build use these files to generate its source) is not a clear process to me yet. I'm learning but it takes time I don't always have.
On a side note, maybe someone could comment on whether a fresh build with the vendor stuff could/would solve ongoing issues like the camera or whether that is a 2.7/2.9 kernel issue that needs a backport.
Click to expand...
Click to collapse
Yeah u will always need proprietary files to build aosp. That's what vendor is for. I've started gathering and trying to setup a community vendor for cdma heros. But just been to busy to finish. Will try soon though an put it on github for all to use.
But as for camera drivers and stuff like that. Ur gonna find that making libcamera build isn't gonna happen as of yet in 2.x aosp. Because it is broken as of the moment and doesn't make. The only solution to gettin camera into an aosp build is to use the libcamera and other camera libs from mine and Flipz HTC Rom. But even then ur gonna need a compatible kernel camera driver to work with it. As of now we haven't got that working fully. But also even once we get the driver working ur gonna have issues in aosp builds with camera as the gsm hero devs have found. As it stands now the aosp camera doesn't fully support our camera. Leaving them left with a 3m camera and I believe no video. It seems that HTC did some extra work in their camera.apk to finish up and give full support for our camera. The problem with that and aosp is like most HTC apks work in and with a HTC modified frameworks. So it goes deep into the framework.jar and many other frameworks files. I won't say it can't be hacked in some how but I will say it won't be easy. But if u manage to pull it of please share because a lot of devs have tried and haven't managed to pull it off as of yet.
Maybe you can point me in the right direction. Attached is my "vendor overlay" attempt. In the first case it's just Lox's stuff for hero with "heroc" in all the right places. The "extract" script is mine, modified by me given Cyanogen's nexus overlay example.
If you can create a git of a proper overlay, that would be great. Even if, as you say, it doesn't get us all the way to a working AOSP ROM.
Lox's language in his extract script is like Cyanogen's in his git repo, ie "who the hell knows if this is right, just guessing". So in that spirit, here is my attempt: a little experience mixed with vendor hatred mixed with voodoo
Feel free to correct me as you can, I would be grateful for a leg up from someone who has been at this longer.
P.S. I can't believe I had to "zip" up a tar.gz tarball to get it to attach to a dev forum (Invalid file). Man, I'm getting old.
P.S.S The included "kernel" file is a zImage I built from your toastcgh 2.7 sources in git. The wlan.ko was built against that...I should double-check that fact...
Ah well, maybe when they redo the forums here they'll think about bug tracking etc but I doubt it.
I did build my aosp rom from source, just built it using the gsm hero's vendor tree, made small adjustments to it for the heroc files. so yea, my rom is from google code to answer the OP's question.
darchstar said:
I did build my aosp rom from source, just built it using the gsm hero's vendor tree, made small adjustments to it for the heroc files. so yea, my rom is from google code to answer the OP's question.
Click to expand...
Click to collapse
EDIT: OHH, I completely misread your thread title, I probably could use google code for my aosp rom to track bugs
darchstar said:
EDIT: OHH, I completely misread your thread title, I probably could use google code for my aosp rom to track bugs
Click to expand...
Click to collapse
Right, I think we all misread it, I believe he was asking why we don't host our code somewhere, like Google Code, with a real bug tracking system, versioning controls, etc. He's got a great point, actually. It would be very nice to have a shared AOSP space, somewhere to see the files and track the issues and changes. ROM development based on AOSP could go on as usual on XDA with that base.
5tr4t4 said:
Right, I think we all misread it, I believe he was asking why we don't host our code somewhere, like Google Code, with a real bug tracking system, versioning controls, etc. He's got a great point, actually. It would be very nice to have a shared AOSP space, somewhere to see the files and track the issues and changes. ROM development based on AOSP could go on as usual on XDA with that base.
Click to expand...
Click to collapse
I got it
The issue is that Google Code won't allow you to host anything you don't have the right to distribute.
5tr4t4 said:
Right, I think we all misread it, I believe he was asking why we don't host our code somewhere, like Google Code, with a real bug tracking system, versioning controls, etc. He's got a great point, actually. It would be very nice to have a shared AOSP space, somewhere to see the files and track the issues and changes. ROM development based on AOSP could go on as usual on XDA with that base.
Click to expand...
Click to collapse
It would minimize on duplicate bug reports at least.
jonnythan said:
I got it
The issue is that Google Code won't allow you to host anything you don't have the right to distribute.
Click to expand...
Click to collapse
Understood, but the proprietary stuff can be pulled from the phone and/or from official releases for other HTC devices given the right script. That's why we need the vendor overlay.
I suppose the follow up question is, "why not just contribute to Android's AOSP core code in git, why create a forked AOSP repo?". That might be right, but we still need the overlay to pull the right files from the device. Perhaps taostcfh or quietblongs or darchstar already have this stuff ready and I'm just late to the game (probably ). Fine, I'd love to see that work so I can help out where possible.
<mini-rant>
This OEM/vendor crap really sucks...should I just repeat what has been said everywhere (and knocked down for very sound business reasons): Google should have released Android under GPL.
</mini-rant>
5tr4t4 said:
Right, I think we all misread it, I believe he was asking why we don't host our code somewhere, like Google Code, with a real bug tracking system, versioning controls, etc. He's got a great point, actually. It would be very nice to have a shared AOSP space, somewhere to see the files and track the issues and changes. ROM development based on AOSP could go on as usual on XDA with that base.
Click to expand...
Click to collapse
Exactly, thanks.
What keeps one of us from leasing a server to share for our (XDA) own CVS, bug-tracking and compiling?
ffolkes said:
What keeps one of us from leasing a server to share for our (XDA) own CVS, bug-tracking and compiling?
Click to expand...
Click to collapse
The fact that someone has to pay for it.
jonnythan said:
The fact that someone has to pay for it.
Click to expand...
Click to collapse
I've got a server but I'm not too familar with CVS, if anyone wants to lend a hand...
ffolkes said:
I've got a server but I'm not too familar with CVS, if anyone wants to lend a hand...
Click to expand...
Click to collapse
I have one too, but I would advocate for something more public, like git or sourceforge or Google Code, XDA, etc. You would want to make sure that you were gaining sharing capabilities and not just isolating yourself...either from upstream improvements or from other community stuff here and on other forums. A thousand people sharing is better than 10-20 people with a server, IMHO XDA has already proven that.
Plus, getting a development server going with all of the niceties of CVS et al is not easy...and there are ready-made solutions already available. None of this addresses jonnythan's point that some of this development is in legal limbo...what happens when someone , even by accident, pushes the google bits onto your public server?
...maybe you would get a cease and desist letter and become famous, LOL.
5tr4t4 said:
...maybe you would get a cease and desist letter and become famous, LOL.
Click to expand...
Click to collapse
Someone needs to combine the power of a forum with the legal protection of a public download site and the bug tracking of google code.
Apparently, I'm too lazy to code that all myself
i would love to learn how to incorporate this functionality into a rom (i'm an owner of a htc phone and primarily use sense roms). from what i've read, it's only a matter of adding a couple of files (phonewindowmanager$12.smali and phonewindowmanager$13.smali) and modifying phonewindowmanager.smali. if done right, this functionality can be added to any rom.
i've been comparing the cm7 smali file to a sense smali file to see what the differences are in terms of code but it just makes my eyes go wonky since i know nothing about reading/writing code.
until yesterday, i had no idea how to extract classes.dex from android.policy.jar nor was i aware of any of the information mentioned above. in other words, i'm a noob at this. i would like to learn how to do this and by the looks of it, many others on the forum are interested as well.
is there a dev out there that would like to share his/her knowledge/wisdom/experience on this with the rest of the xda community? i realize this is a lot to ask but i thought i'd try. thanks in advance.
I'd also be interested in this, for phones where Cm7 isn't available
Me too. Am going to put this thread as my signature until some kind soul comes up with an tutorial. Or at least a rhetoric answer.
By the way, the only guy that i know is, Andy Thompson, who's always update his mod/hack for MIUI roms
http://miuiandroid.com/community/threads/mod-skip-track-via-volume-press.7356/
and also CosmicDan
http://miuiandroid.com/community/th...hold-volume-to-skip-tracks.17381/#post-131527
Must have skill/mod/hack or even app for music lover and flashaholic.
So I have thought about this for a long time. There are some great custom roms/mods/hacks out there. But even they can lack features or have features you don't want.
I mean like choosing individual options that show up in the settings menu, etc...
Isn't it possible to have some source code that contains all the features of all the roms, and have an application that you use to design your own custom version of that rom. Say I want to fix my homescreen to have 4 screens and each screen to have its own background image... If we could just hardwire that capability into the OS via a custom designer/compiler off the source code, and flash it to the phone, that would be awesome...
Maybe that is asking a bit too much, but it seems possible. Although I am on the lower end of the spectrum when it comes to coding and modding, so I may just have no idea what I'm talking about. Maybe there are others out there who have thought of this, or are working on it, or maybe it already exists, but anyway... Just an idea...
Kinda hard with all these different devices and UIs, making compatibility an issue.
Ummm there is an app that lets you have different wallpapers for each home screen
ya... I mean it would have to be restricted to certain devices or something... but i dunno... just a thought.
If only every phone company only released 1 or 2 models.
Sent from my HTC Incredible S
govindadas said:
So I have thought about this for a long time. There are some great custom roms/mods/hacks out there. But even they can lack features or have features you don't want.
I mean like choosing individual options that show up in the settings menu, etc...
Isn't it possible to have some source code that contains all the features of all the roms, and have an application that you use to design your own custom version of that rom. Say I want to fix my homescreen to have 4 screens and each screen to have its own background image... If we could just hardwire that capability into the OS via a custom designer/compiler off the source code, and flash it to the phone, that would be awesome...
Maybe that is asking a bit too much, but it seems possible. Although I am on the lower end of the spectrum when it comes to coding and modding, so I may just have no idea what I'm talking about. Maybe there are others out there who have thought of this, or are working on it, or maybe it already exists, but anyway... Just an idea...
Click to expand...
Click to collapse
I completely understand what you are trying to achieve over here. But there are various factors in place. You are trying to make a kitchen more advance so we can fully customize it but it is not possible with the number of device that are out there and the number of processors. Its not impossible but quite hard to achieve
I am very pleased with the thought and don’t feel like adding anything in it. It a perfect answer.
robertsmigel22 said:
I am very pleased with the thought and don’t feel like adding anything in it. It a perfect answer.
Click to expand...
Click to collapse
Which answer.....?
Android with a WebOS UI=Better than Sense.
that's a good idea actually.
Well, I mean, start with one phone model on a specific carrier that is very popular among developers and general users. If a large number of people who work on mods/roms and other customizations got together... then they could probably whip up something.
But, yeah... doing it for a large number of phones would be very difficult...
but starting off simply, could slowly add in features, or a select your phone and carrier type thing...
In other words, an xda phone. Well gluck rounding up the devs to a particular phone.
$1 gets you a reply
Great
Thank you for your work
Kailkti said:
In other words, an xda phone. Well gluck rounding up the devs to a particular phone.
$1 gets you a reply
Click to expand...
Click to collapse
So everyone should get an HD2?
that's a good idea actually.
I really would like to see a newer HD2 like device. I mean like the phone that runs everything. but those come with time they aren't made that way
It's not impossible. I mean it would take a lot of time to complete but you could do it device by device. First you achieve the idea within 1 device. Combine all the roms and put features together and maybe if you add a UI to the application End Users can pick the features they want and tailor their own rom. Developers instead of updating roms they'd add new features to the application. After that you could combine phone's from the same company. Like the Sony X10 & X8. They're not that different and porting won't too hard. And then eventually you get to a General app. Some phones have some features other don't but it'd be just like Market. Some apps are compatible with your phone some aren't. It's a good idea~
Sent from my X8 using XDA App
That's a good idea actually.
What about a GUI rom "cooker"? Devs build their standard roms, but let the end users crunch them through a GUI that lets the users filter what little things they want or dont want to keep in the rom. GUI then repackages it and then we flash it.
Skv012a said:
What about a GUI rom "cooker"? Devs build their standard roms, but let the end users crunch them through a GUI that lets the users filter what little things they want or dont want to keep in the rom. GUI then repackages it and then we flash it.
Click to expand...
Click to collapse
Ya, thats pretty much what i mean. So you can choose what options show up in the settings menu, completely customize the power/lock button menu and actions, etc...it seems like it should be possible. Just take a highly customized rom and create an intetface to remove features and compile it. It could all be done in the cloud and notify you when its ready for dl.
Hi
NLS stands for National Language Support.
This package completes Beastmode's CM10 great ROM (coming in English) with all CM supported languages.
Instructions :
1. Flash CM10 V2 by Beastmode.
2. Flash cm10_nls_sgs4g.zip
3. Fix Permissions
4. Optionally flash 4.1.2 Gapps.
5. Reboot (go to System --> Display and turn off notification light).
6. In Settings - language and text - choose your language.
Enjoy!
mine
The build I am compiling will have rtl support in advanced settings!
But IDK if it will have languages in built.
airfluip1 said:
The build I am compiling will have rtl support in advanced settings!
But IDK if it will have languages in built.
Click to expand...
Click to collapse
Airflip, talk about it after you actually post a build. This whole "Look what I'm gonna do" is getting really old. I wish you the best in your quest to build ROMs but at some point you actually have to build something.
I have built roms. I have posted screenies, and I have posted some beta builds. Just because it isn't in the dev section doesn't mean that I haven't done anything with it. Right now AOKP seems to be having a lib issue, and I have exams, so I can't really build until then. Also, I don't see a problem with it since all the other devs do it. https://github.com/airfluip1/androi...mmit/cf07012b06b4ae3bcf2914fe698778a3c31b3cd4 is where you can see this change I made.
Also if you didn't catch it, http://d-h.st/Lke is a link to one of my builds
airfluip1 said:
Also, I don't see a problem with it since all the other devs do it.
Click to expand...
Click to collapse
None that I respect do it. It's one thing to say your going to do something. It's another thing entirely to come into other Devs threads and say "I'm gonna fix this" or "My ROM will have this". It comes across the wrong way. It would be like AOKP members coming into a CM thread and trying to one up them. It doesn't ever happen and that's because those guys have mutual respect for each other. I'm just letting you know how it comes across in print. It's up to you to figure out what to do with that info.
I apologize if it came across the wrong way though.
First of all - both of you are off thread topic !!!
Second, Airfluip has built things in the past and he has the capabilities.
I see no difference in posting "what I am doing" comparing to "who's ready for a flood" or "who wants some audioXX loving" which were all posted by our best and proven devs.
Third, RTL support is built in since ICS was out, there's no need to add anything.
I think the few contributors we still have here need a little more respect than given, that's all.
Even this simple resource adding required about 250 de/re-compiling and content copies, and it took some hours.
Now back on topic.