[Q] When will Omni be available to try? - Omni Q&A

I think I've looked everywhere, but I can't seem to find the answer to the question I am sure is on most people's lips right now; "When can we try it?"
It seems like the only way to try this yourself right now is to compile it from source. That's a huge barrier for most people. I assume we need to be keeping an eye on the device-specific forums for our own devices in the hope that someone posts a flashable zip? If that's the case, I am surprised to find that there's nothing available yet for MY device, the Nexus 4.
I have personally compiled CM myself, but even I am a bit nervous to try this in the absence of a step-by-step guide. Still, I think I just might give it a go!

StNickZA said:
I have personally compiled CM myself, but even I am a bit nervous to try this in the absence of a step-by-step guide. Still, I think I just might give it a go!
Click to expand...
Click to collapse
This is what I'm trying to use to build *haven't been successful yet, still downloading*
http://docs.omnirom.org/Build_for_mako

parker09 said:
This is what I'm trying to use to build *haven't been successful yet, still downloading*
http://docs.omnirom.org/Build_for_mako
Click to expand...
Click to collapse
Oh wow, thank you, this is perfect. Here goes nothing.

StNickZA said:
Oh wow, thank you, this is perfect. Here goes nothing.
Click to expand...
Click to collapse
I am sure this isn't the place for troubleshooting this kinda stuff, but I have already been stumped at the first hurdle. I can't init the repo.
Code:
Permission denied (publickey).
Permission denied (publickey).
Update: Thanks to pulser_g2 in another thread, it turns out that the command given here is incorrect. Should rather be using :
repo init -u https://github.com/omnirom/android.git -b android-4.3
Click to expand...
Click to collapse

Any luck in getting it to work - mine just keeps throwing errors.
Fetching projects: 7% (27/375) Fetching project android_device_lge_mako
error: gnutls_handshake() failed: A TLS packet with unexpected length was received. while accessing https://github.com/omnirom/android_bionic/info/refs?service=git-upload-pack
fatal: HTTP request failed
Click to expand...
Click to collapse

parker09 said:
Any luck in getting it to work - mine just keeps throwing errors.
Click to expand...
Click to collapse
Not really having much success. I have created the roomservice.xml file in local_manifests, but for whatever reason, repo doesn't seem to want to pull the mako blobs, and as such, brunch fails. Was there anything special you did there?
Update: Actually I don't think the blobs are the problem for me. The build is getting stuck at this point though:
Code:
make: *** No rule to make target `/home/stnick/android/Omni/out/target/product/mako/obj/KERNEL_OBJ/usr', needed by `/home/stnick/android/Omni/out/target/product/mako/obj/SHARED_LIBRARIES/libgenlock_intermediates/genlock.o'. Stop.
Any ideas?

nar I'm still downloading source(s). My net is terrible

StNickZA said:
I think I've looked everywhere, but I can't seem to find the answer to the question I am sure is on most people's lips right now; "When can we try it?"
It seems like the only way to try this yourself right now is to compile it from source. That's a huge barrier for most people. I assume we need to be keeping an eye on the device-specific forums for our own devices in the hope that someone posts a flashable zip? If that's the case, I am surprised to find that there's nothing available yet for MY device, the Nexus 4.
I have personally compiled CM myself, but even I am a bit nervous to try this in the absence of a step-by-step guide. Still, I think I just might give it a go!
Click to expand...
Click to collapse
The usual "no ETAs" rule applies here.
Among other things, one of the key aspects of making it easier to build for people (roomservice) was not possible until we publically launched as it had dependencies on github's APIs. Getting roomservice lit up is one of my top priorities.
I was considering posting images for find5, pollux_windy, and yuga, but I want to fix some stuff up on find5. Other people are handling figuring out our approach for automatic builds.
For me my top priorities are roomservice, some find5 bugs we discovered at BABBQ, and handling the large influx of new developers before returning to my additional role as "device thread maintainer". Now as excited as people are to try the end product, I'd prefer if anyone who plans on posting builds coordinate with the team before doing so. Obviously legally there's no reason you can't post a build, but coordinating with the team is just the right thing to do.

Entropy512 said:
The usual "no ETAs" rule applies here.
Among other things, one of the key aspects of making it easier to build for people (roomservice) was not possible until we publically launched as it had dependencies on github's APIs. Getting roomservice lit up is one of my top priorities.
I was considering posting images for find5, pollux_windy, and yuga, but I want to fix some stuff up on find5. Other people are handling figuring out our approach for automatic builds.
For me my top priorities are roomservice, some find5 bugs we discovered at BABBQ, and handling the large influx of new developers before returning to my additional role as "device thread maintainer". Now as excited as people are to try the end product, I'd prefer if anyone who plans on posting builds coordinate with the team before doing so. Obviously legally there's no reason you can't post a build, but coordinating with the team is just the right thing to do.
Click to expand...
Click to collapse
Understood.
Yeah I haven't really managed to overcome the issues I've already mentioned in this thread, and the helpful chaps on IRC ensured me that these were all things that they were looking at fixing soon enough so I'm happy to wait.
Looking forward to trying it!

Related

ROM-Dev madness!

Foreword: I mean this in the most constructive way possible. While I'm not a <android> developer, it occurs to me that with the wealth of Android ROM-devs and an excellent base of testers (like myself, an unexcellent but present tester), there has to be a better way.
I love XDA-Dev as a resource, and it's been a godsend since I got my MT3G. I've had the opportunity to use some very well done builds which have been time-invested by their developers. I've learned a lot about my device, and am beginning to understand Android as a platform. Here's the beef:
Some ROM-posts are 1000+ pages long. While I could read all 1000+ pages if warranted, it's simply inefficient. What information am I after? I want to know:
Does it work on my phone?
What's the latest version?
Where's it at?
Are there any specific bugs on my phone with this build?
Who else is using this build, and what hardware are they using?
What bugs are being worked on?
What workarounds are applicable to this build?
What bugs are open and need community feedback?
etc...
Is there some sort of bug-tracking setup that could be used to facilitate this? I don't mean or intend to steer *anything* away from XDA-Developers, per se, but this current forum method doesn't seem very conducive to making forward progress.
<shrug> I know, I know, I'm a noob around here and should just work with the herd. I've seen other comments touching on some of these issues, so I thought I'd throw it out there. I apologize if it's been brought up before and shot down.
Hey, what about this? I was looking for a semi-authoritative list of Android ROMs that matched what I outlined above and came across it.
If I had the resources I'd volunteer time/materials to help the cause in that light, but being the schmuck I am (ya' know, working full time and school part time), I can't offer anything substantive. So while this might sound like a gripe, maybe it will compel someone else to make some magic happen. That, or have my account disabled
Any thoughts?
I understand where you are coming from.. but I don't find it that hard to find the rom and information I am after.. all it takes is a little time..
Why not help out by adding to the wiki?
I dont see how this has to do with development, you are just as guilty as the people you speak of.
xyzulu said:
I understand where you are coming from.. but I don't find it that hard to find the rom and information I am after.. all it takes is a little time..
Click to expand...
Click to collapse
I hear ya, it's just not a very concise method and I'm sure you've seen "what's the best build" & "will this ROM work on my phone" and "hey are there any issues with this build", etc...
xyzulu said:
Why not help out by adding to the wiki?
Click to expand...
Click to collapse
I've thought about it, and went as far as the edit screen a few times. Then it's like "aww crap, here goes a few hours...". Back to homework
Jrbourque said:
I dont see how this has to do with development, you are just as guilty as the people you speak of.
Click to expand...
Click to collapse
I think it has everything to do with development, advancement of the builds flying around here, and support of the folks that put their time into it.
Maybe you misinterpreted what I was saying, but I surely wasn't trying to assign guilt to anyone. Things are the way they are because they got that way - doesn't make it right, 'doesn't make it wrong. I just thought maybe there's a better way to support the community.
It's all good.
Jrbourque said:
I dont see how this has to do with development, you are just as guilty as the people you speak of.
Click to expand...
Click to collapse
It's this kind of attitude that is putting a lot of people off. The OP has made some very good and valid points and deserves at least a response to the points he has made, not just a one sentence put down.

Android Development Idea

Just a thought as I'm having trouble locating up to date builds and differentiating between the builds for the vogue.
Why not zip the system files with a read me file with maybe the date and developer/editor name or contact info?
I think this will keep testers more up to date, and the feedback will go back to the right developers.
gnovak99 said:
Just a thought as I'm having trouble locating up to date builds and differentiating between the builds for the vogue.
Why not zip the system files with a read me file with maybe the date and developer/editor name or contact info?
I think this will keep testers more up to date, and the feedback will go back to the right developers.
Click to expand...
Click to collapse
the readme is a good idea. i did that for a couple builds. as far as the dates go the date the build is put up is on the google code site and if you click on the description it says who uploaded it. i also have threads for my builds. and mssmision has one thread covering all of his and vilord has his thread which is the google ion android 1.5 build. If you want i'll add the names to the descriptions in the vogue-android google code page.
yeah maybe adding tags to builds with developers names to the google code page might make it a little more oganized.
I think with threads theres always alot of clutter and new builds get over looked, not really getting the exposure they deserve.
I sell smart phones for Sprint and for Microsoft, this android - Vogue port is amazing and I would like to get more people involved. But i cant do so until its a little more accessable to the common user.
This is a looong overdue set of ideas. If this was JUST a hobby for you guys the disorganization would be ok (I guess) but since your sharing them with the world, anything you can do to make the builds more user friendly is great. It also helps user report bugs, glitches with more precision, and insures that they have a really awesome experience with your hard work.
gjbnh said:
This is a looong overdue set of ideas. If this was JUST a hobby for you guys the disorganization would be ok (I guess) but since your sharing them with the world, anything you can do to make the builds more user friendly is great. It also helps user report bugs, glitches with more precision, and insures that they have a really awesome experience with your hard work.
Click to expand...
Click to collapse
You do realize that you can report bugs on the Google code pages. There has been a lot of hard work getting to where we're at now. We are a group of people from all around the word coming together make android run on the vogue.
And i think what gjbnh is trying to say is that we would like to collaborate with you and maybe make it easier for other people to help as well.
The google page is an AWESOME idea, but truth be told, not everyone goes there to download android on their phone.
Direct links to older versions are sprawled out all over the internet, especially this forum.
When someone runs a search on "Vogue Android" the first three results are going to determine whether they will bother or move on.
gnovak99 said:
And i think what gjbnh is trying to say is that we would like to collaborate with you and maybe make it easier for other people to help as well.
The google page is an AWESOME idea, but truth be told, not everyone goes there to download android on their phone.
Direct links to older versions are sprawled out all over the internet, especially this forum.
When someone runs a search on "Vogue Android" the first three results are going to determine whether they will bother or move on.
Click to expand...
Click to collapse
I understand that and I'm all for organization but it seems right now we might be moving forums and hosting. I agree that from the perspective of a new person coming here and wanting to try android on their vogue/kaiser/polaris that it does seem a little confusing.
What kind of collaboration are you looking to do? dzo and vilord are the owners of the vogue-android google code page and it's their work which has put vogue android on the map. Aside from repackaging the builds with better more complete packages and a readme with clear instructions there isn't really a lot more that we can do. We have the forums here for questions and you can report bugs at the google code page too. I think the vogue-android page is set up quite nicely. The download page can be cleaned up a bit but the main bundles are right up at the top. You have mssmisions package, the google ion package, and the vogue-hero package.

Devs, Please don't hide your Known Issues

I really don't want this to come across wrong, but I just have to say it.
Developers, I appreciate all your hard work. I understand this is all beta/test/etc. I understand it is free of cost, even to those who did donate to one dev or another. You do it because you want to, not because you have to.
But please, for the love of all that's good - keep an updated list of Known Issues!
It sucks having to read 50 pages of posts to try to figure out if a particular release is reliable or not, to find out if there's a key feature broken or buggy. What makes it worse is you can't tell when reading these threads which users are on which release, because many still post issues after they've been resolved. Others post things that aren't really "issues" but user error.
You know what your issues are, you read the threads and you fix the issues. But trying to find a decent rom to flash is very, very difficult when your OP says "No known problems" and the thread that follows show that to be very untrue. It generates a lot of extra posts with people posting things you already know about, and it generates a lot of bad will when someone flashes something only to find that there are a number of game breaking issues.
All it takes is to update a post, say #2, in your thread, with KNOWN ISSUES. Once you confirm a bug, whether you intend to fix it on your next release or not, add it to that thread. It helps you, as a dev keep track of the bug, and it helps potential downloaders know what bugs have been confirmed and make an educated decision as to whether they want to install your release.
Hiding known issues is something I don't think anyone does intentionally, but it feels that way sometimes. It feels like devs are in a popularity contest, and any admission of flaws in their particular ROM is a weakness. Well, to tell the truth, I and many others are sick of installing something that was CLAIMED to be working perfectly, only to have glaring problems that have been there for many versions.
For a civil and productive development community. Please. Be honest with your known issues. It will go a long way in building trust with the people who you're providing ROMs to, and will mean fewer posts for YOU to wade through of users reporting known issues, without having read 500 posts first.
I have a hard time believing that most devs actively hide them. Most of the time it's probably just a bit of laziness. But, yes, it would be helpful when comparing roms if the descriptions had a well-maintained list of active bugs.
Since the developers here are NOT getting paid (NO your $20 donation is not sh*t for the time it takes to make one of these roms), yes WE will have to bear the brunt of testing these roms out and letting them know what bugs if any are in them
The other issue is the people flashing these roms, coming from Eugene's to Whiskey to the ASOP roms may generate some ghosts in the software that the developers cannot duplicate themselves. I know that when I went with the TW 2.2 roms I had plenty of issues, more issues than I have had even when I was stock. Odining back to stock and reflashing the 4.2 TW fixed ALL my problems. Dont know what caused it but since I have flashed a couple of roms prior to that (no problems), I will assume there were some ghosts in my system. This is an example that unless a TW team member is holding MY phone and working on it, they may not be able to duplicate
They don't care to list them. It's beneath some of them.
Maybe AirBus should list "midair exploding engines" as a known issue too...
kponti said:
Since the developers here are NOT getting paid (NO your $20 donation is not sh*t for the time it takes to make one of these roms), yes WE will have to bear the brunt of testing these roms out and letting them know what bugs if any are in them
Click to expand...
Click to collapse
+1. Hell, at work I run a $100,000.00+ software suite and even that company won't do what the OP suggests!
If you have a problem with them stop using their roms go back to stock and see how much better theirs is even with a few bugs, not one of you has any right to complain. They do damn good work for free with some donations that do not come close to what they should be paid for it but they do not whine at all.
The problem I find is the "spammy" and useless comments average and pretentious users make which is both hard for the developer and the end user to read the threads. A dev releases a ROM and there is a guaranteed "Oh I can't wait to flash this" comment that will pop up. And there are some issues that are minor and are sometimes not related to the release that are posted and some pretentious loser who extends his ego by trying to make simple matters complicated. This forum didn't much of this problem before and I could quickly flash ROMs easily since I could clearly grasp the status on the ROM project.
I wish they would start a new thread with new releases. It's a pain to try to read through a 500 page thread, and you comments about this or that, and you have no idea which version the person is talking about. I gave up on custom roms and just using the leaked tmo 2.2, thanks for that Eugene
kponti said:
Since the developers here are NOT getting paid (NO your $20 donation is not sh*t for the time it takes to make one of these roms), yes WE will have to bear the brunt of testing these roms out and letting them know what bugs if any are in them
The other issue is the people flashing these roms, coming from Eugene's to Whiskey to the ASOP roms may generate some ghosts in the software that the developers cannot duplicate themselves. I know that when I went with the TW 2.2 roms I had plenty of issues, more issues than I have had even when I was stock. Odining back to stock and reflashing the 4.2 TW fixed ALL my problems. Dont know what caused it but since I have flashed a couple of roms prior to that (no problems), I will assume there were some ghosts in my system. This is an example that unless a TW team member is holding MY phone and working on it, they may not be able to duplicate
Click to expand...
Click to collapse
A $20 donation is not worth the risk of bricking a $550 phone just because they got "lazy" and didn't notify donators/downloaders of [a] potentially show-stopping issue.
Posted a new Thread in Dev section for the purpose of reporting issues. So if you have an issue please shoot it to me and I will post it in that thread.
Update: Here is the link for the WIKI page.
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S_SGH-T959#ROMs
swehes said:
Posted a new Thread in Dev section for the purpose of reporting issues. So if you have an issue please shoot it to me and I will post it in that thread.
Click to expand...
Click to collapse
You are in a heap of trouble, a lot of people don't read, and you are gonna get 1000000000000000000000000000000000000000000000 repeats of the same issue.
"OMG! MY SD CAR DONES"T MOUNT< HELP ME!11!!111"
chui101 said:
I have a hard time believing that most devs actively hide them. Most of the time it's probably just a bit of laziness. But, yes, it would be helpful when comparing roms if the descriptions had a well-maintained list of active bugs.
Click to expand...
Click to collapse
The issue here is really that a forum is not the ideal place to manage software releases. A list of bugs emerges from community testing, but there's nowhere to "post" that list of issues, or attach it to a specific release. Since there's no way for the community to add such documentation, it falls on the ROM builder, who probably has other priorities.
This kind of project could be well served by using a real software project management software solution, such as say google code, which has an issue tracker and other useful features. But XDA does already give us a better tool than the forum - the XDA wiki!
I wish people would use the XDA wiki more extensively. This would be a good place to keep updated documentation such as this, without requiring the OP to keep a forum post updated with the latest findings. All the OP needs to do is link to the wiki page, and other people can help maintain it.
OK. Looking into Google Code.
(Update) So looking into the Google Code. What Licensing agreement are the ROMs under? Is it GPL v2 or v3 or another license?
swehes said:
OK. Looking into Google Code.
(Update) So looking into the Google Code. What Licensing agreement are the ROMs under? Is it GPL v2 or v3 or another license?
Click to expand...
Click to collapse
Depends on the project. The Linux kernel is GPLv2, so any kernels fall under that license. AOSP as a whole uses both GPL and apache code.
The issue with ROMs is that unless they're AOSP derived (like cyanogenmod) they often include binaries for which the license situation is murky at best, so google code isn't really an ideal fit for a "ROM" that's only ever released as a binary.
Really I was throwing google code out there as a well known example, there are tons of other ways to track issues. There are dedicated issue tracking systems such as trac, bugzilla, etc, but they require hosting. Most of the freely available hosted services require that you're running an open source project, which isn't necessarily true for the ROMs here.
IMO a serious project could very well benefit from such tools, but just using an XDA wiki page which community members can freely update is a great first step.
So looked into the Wiki for the Vibrant and have updated some information. Let me know what you guys think. Is this the way to go?
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S_SGH-T959#ROMs
swehes said:
So looked into the Wiki for the Vibrant and have updated some information. Let me know what you guys think. Is this the way to go?
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S_SGH-T959#ROMs
Click to expand...
Click to collapse
Not to be the "Spelling Nazi", and I am not even sure if you can change it, but it is "Kernel" not "Kernal". Also, the Dev on Team Whiskey is Sombionix, not Symbionix.
Otherwise, that looks like a great idea, and possible way of tracking things!
EDIT - I guess I could go ahead and make those tweaks, with it being a wiki and all couldn't I....
EDIT EDIT - Fixed it.
Stargazer3777 said:
Not to be the "Spelling Nazi", and I am not even sure if you can change it, but it is "Kernel" not "Kernal". Also, the Dev on Team Whiskey is Sombionix, not Symbionix.
Otherwise, that looks like a great idea, and possible way of tracking things!
EDIT - I guess I could go ahead and make those tweaks, with it being a wiki and all couldn't I....
EDIT EDIT - Fixed it.
Click to expand...
Click to collapse
Thanks. On both accounts.
Maybe this should be a post to Microsoft
To quote "there are known, unknowns and unknown, knowns and and even sometimes unknown,unknowns............but.........
Developers ----develop they do not become a bookkeeper of their development.........that is coordinating work...........good luck getting any developer in ANY Specialty to do that............. reporting bugs........
---Maybe this should be a post to Microsoft---
N8ter said:
A $20 donation is not worth the risk of bricking a $550 phone just because they got "lazy" and didn't notify donators/downloaders of [a] potentially show-stopping issue.
Click to expand...
Click to collapse
I have yet to see a REAL (completely dead) "bricked" vibrant from flashing a released Rom alone. I have seen a lot of user error cause boot loops or "soft-bricks" & HWL phones become unflashable because the end user didn't take the time to research though. As far as devs being "lazy" I dont really see that when the developer is coming here for us to tell him what else we find wrong. They are coding, you flash, you report back with a logcat. This is how development is made to my understanding. If ppl are to lazy to JUST do this then why shouldn't the developer discount long winded post or something they are not experiencing? If they know there is a bug its in the OP.
If you guys can change the interwebz & how 500 post per update are made completely useless please feel free to do so....
swehes said:
So looked into the Wiki for the Vibrant and have updated some information. Let me know what you guys think. Is this the way to go?
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S_SGH-T959#ROMs
Click to expand...
Click to collapse
I think it's a pretty awesome start for sure
As a matter of personal taste, I think having an individual wiki page per ROM (with the known issues and other detailed info) might be nice, although I'm not sure what the policy on new pages is with the XDA wiki.
Speaking from professional experience, the most challenging aspect of any documentation system is always convincing people to use it. It's great to compile the information, but unless ROM builders and devs post a link to the wiki in the forum threads nobody will ever see it. Having good, community based documentation is a benefit to everybody though, so hopefully people will recognize the utility of it and encourage its growth!

Assemble Dev Team for an ICS ROM

As our device is dying in support I feel that we need to develop a large development team (10+ people) that will work on ICS for our gtablet. I mean after all our device is capable of running it ( Tegra 250). If you would like to be part of this team shoot an email to [email protected] explaining why you want to be part of this team and what you can contribute. Thank you.
You know that you need a new kernel for ICS to work properly right? Ch3vr0n5 and dpw13 are currently working on it over at slatedroid.
lol. i was gonna post something similar to this in the next couple days. I made the n1 ics port and started work today trying to get ics booting on my gtab. I think first order of business is to start a room on freenode.
#tegratab_ics_dev
all interested parties please join
btw im drewis
texasice said:
lol. i was gonna post something similar to this in the next couple days. I made the n1 ics port and started work today trying to get ics booting on my gtab. I think first order of business is to start a room on freenode.
#tegratab_ics_dev
all interested parties please join
btw im drewis
Click to expand...
Click to collapse
guys,
pm jazzruby, tek112 or fosser2, ch3vron..they are also over @ slatedroid viewsonic gtablet forum..
they have been working on a kernel with hw accel for HC3.2 and ICS. There are been some teaser pics by fosser with ics running on his gtablet.
I'm sure they could use your help...
kernel dev in the gtablet laboratory forum as well.
Cyanogen: Our goal is to provide continued support to all CM7 devices back to the QSD8250 series of devices such as the Nexus One. (12/2/2011)
Click to expand...
Click to collapse
The CyanogenMod team has also said they will continue to support our gTabs so I am looking forward to CM9 which hopefully will drop some time in January.
sjmoreno said:
The CyanogenMod team has also said they will continue to support our gTabs so I am looking forward to CM9 which hopefully will drop some time in January.
Click to expand...
Click to collapse
uhm based on what you quote nothing is said there we dont have qsd in our gtabs...
If anyone is interested and has dev experience shoot me a pm and i'll get you up to date. thanks
Yea upon further investigation there are already a few people working on this. In fact a quick google search will find you a booting cm9 for gtab. (i dont want to post the link since it is pre alpha and not my rom) but the gtab is not lacking devs by any means. (they just arent on xda)
oh and forget my post about the irc room there is already one. but again you must find it yourself
dont know why the pic is green but whatever
texasice said:
Yea upon further investigation there are already a few people working on this. In fact a quick google search will find you a booting cm9 for gtab. (i dont want to post the link since it is pre alpha and not my rom) but the gtab is not lacking devs by any means. (they just arent on xda)
oh and forget my post about the irc room there is already one. but again you must find it yourself
dont know why the pic is green but whatever
Click to expand...
Click to collapse
I appreciate that you didn't post the link to this, and please anyone else who "finds" this build (yes its out there) please do not post it anywhere either. It is extremely beta and has many problems (to the point where you would have to open your tablet to push the internal reset button). Thanks
i really don't appreciate this elitist dev crap. "yeah there's a place where you can talk about it, and a build you can get to try it, but i'm not going to tell you where." i completely understand that the devs are doing work that we (I) can't do and that they're entitled to a bit of leeway for that but if they're going to talk about their work in public and post shots, they're just doing it to get a rise out of people. there is no valid reason to restrict people from trying out alpha builds except to keep others out of their club.
of course, if you want to install something against the advice of someone who knows a lot more than you do, that's your perogative but you assume all responsibility. it does absolutely make sense that the devs want ZERO whining or "bug reporting" from alpha builds. ostensibly, the devs and those with technical acumen are trying to protect newbs who might fry their tabs. to my thinking however, nothing would make someone learn faster not to flash random **** than a $300 brick. we're all intelligent humans and not children, however, so
links:
cm9 alpha (install script edited)
gapps
original file
note: THIS IS NOT A DAILY DRIVER. i tested it on a 1.2BL tab. i had to turn off the getprop script asserts to get it to install, which is usually bad form. it boots, but we have no hw acceleration, no wifi, no camera, no sound, no usb storage or adb... etc. this is just a taste, proof that work is being done.
irc is freenode #gtab_kerneldev
Notion ink adam is getting official ICS, I suppose that will help a lot?
iammuze said:
i really don't appreciate this elitist dev crap. "yeah there's a place where you can talk about it, and a build you can get to try it, but i'm not going to tell you where." i completely understand that the devs are doing work that we (I) can't do and that they're entitled to a bit of leeway for that but if they're going to talk about their work in public and post shots, they're just doing it to get a rise out of people. there is no valid reason to restrict people from trying out alpha builds except to keep others out of their club.
of course, if you want to install something against the advice of someone who knows a lot more than you do, that's your perogative but you assume all responsibility. it does absolutely make sense that the devs want ZERO whining or "bug reporting" from alpha builds. ostensibly, the devs and those with technical acumen are trying to protect newbs who might fry their tabs. to my thinking however, nothing would make someone learn faster not to flash random **** than a $300 brick. we're all intelligent humans and not children, however, so
links:
cm9 alpha (install script edited)
gapps
original file
note: THIS IS NOT A DAILY DRIVER. i tested it on a 1.2BL tab. i had to turn off the getprop script asserts to get it to install, which is usually bad form. it boots, but we have no hw acceleration, no wifi, no camera, no sound, no usb storage or adb... etc. this is just a taste, proof that work is being done.
irc is freenode #gtab_kerneldev
Click to expand...
Click to collapse
I realize you're just trying to show people where it is, but if the devs don't want you pouring out THEIR work to the world just yet, I think it's best to listen.
iammuze said:
i really don't appreciate this elitist dev crap. "yeah there's a place where you can talk about it, and a build you can get to try it, but i'm not going to tell you where." i completely understand that the devs are doing work that we (I) can't do and that they're entitled to a bit of leeway for that but if they're going to talk about their work in public and post shots, they're just doing it to get a rise out of people. there is no valid reason to restrict people from trying out alpha builds except to keep others out of their club.
of course, if you want to install something against the advice of someone who knows a lot more than you do, that's your perogative but you assume all responsibility. it does absolutely make sense that the devs want ZERO whining or "bug reporting" from alpha builds. ostensibly, the devs and those with technical acumen are trying to protect newbs who might fry their tabs. to my thinking however, nothing would make someone learn faster not to flash random **** than a $300 brick. we're all intelligent humans and not children, however, so
links:
cm9 alpha (install script edited)
gapps
original file
note: THIS IS NOT A DAILY DRIVER. i tested it on a 1.2BL tab. i had to turn off the getprop script asserts to get it to install, which is usually bad form. it boots, but we have no hw acceleration, no wifi, no camera, no sound, no usb storage or adb... etc. this is just a taste, proof that work is being done.
irc is freenode #gtab_kerneldev
Click to expand...
Click to collapse
There are good reasons why the devs don't want this posted. Its not to spite anyone or rub it in their faces. 1 they don't want to be liable for someone elses damaged tablet, 2 do you know if the voltage regulators aren't correct it could fry your gtablet permanently, 3 they're a good hard working group who is doing this for zero dollars in their spare personal time and only want to put out a good working product. Have a little respect for their wishes. Be warned that alpha build could permanent damage your gtablet.
iammuze said:
i really don't appreciate this elitist dev crap. "yeah there's a place where you can talk about it, and a build you can get to try it, but i'm not going to tell you where." i completely understand that the devs are doing work that we (I) can't do and that they're entitled to a bit of leeway for that but if they're going to talk about their work in public and post shots, they're just doing it to get a rise out of people. there is no valid reason to restrict people from trying out alpha builds except to keep others out of their club.
of course, if you want to install something against the advice of someone who knows a lot more than you do, that's your perogative but you assume all responsibility. it does absolutely make sense that the devs want ZERO whining or "bug reporting" from alpha builds. ostensibly, the devs and those with technical acumen are trying to protect newbs who might fry their tabs. to my thinking however, nothing would make someone learn faster not to flash random **** than a $300 brick. we're all intelligent humans and not children, however, so
links:
cm9 alpha (install script edited)
gapps
original file
note: THIS IS NOT A DAILY DRIVER. i tested it on a 1.2BL tab. i had to turn off the getprop script asserts to get it to install, which is usually bad form. it boots, but we have no hw acceleration, no wifi, no camera, no sound, no usb storage or adb... etc. this is just a taste, proof that work is being done.
irc is freenode #gtab_kerneldev
Click to expand...
Click to collapse
Well aren't you cool, learning how to use google and ****.
EDIT: Ok now that I'm done fuming about this. The release that was posted is an early build of CM9. It is based off of Android 4.0.3. The kernel that is included with that release is linux 2.6.36. Since then, we have now moved onto 2.6.39. In no way is the "dev" group elitist. At any time anyone could have joined the IRC group and asked for a download link to the latest kernel/rom. The reason this has not been released yet is because of the "power button" script. When the power button is tripped at random times it causes the entire tablet to freeze up. The only way to "reset" the tablet is to open it up and press the internal reset button, thereby voiding any warranty from Viewsonic. Another issue that I have seen with using this kernel is possible damage to the camera. Just a few days ago I learned that while running this kernel the camera heats up and is hot to the touch, almost to the point of burning yourself. I have since then, unplugged the camera from the mainboard, to hopefully stop damage to the camera (I'm guessing that whoever has run this already without unplugging their camera, has potentially fried it). In short, installing this rom does give you some latest and greatest software to play with, but with it comes risks. DO NOT INSTALL THIS ROM/KERNEL IF YOU DO NOT WANT TO RISK DAMAGING YOUR TABLET.
ps. As a dev. team, we will be releasing HC with a .36 kernel that supports hw accel very soon. Keep your heads up for that release. Hopefully this release can hold people over until everything becomes more stable. Thank you all for patiently waiting.
fosser2 said:
Well aren't you cool, learning how to use google and
ps. As a dev. team, we will be releasing HC with a .36 kernel that supports hw accel very soon. Keep your heads up for that release. Hopefully this release can hold people over until everything becomes more stable. Thank you all for patiently waiting.
Click to expand...
Click to collapse
Kids.....they think they know everything! Haha, just kidding but hopefully maybe people understand why now. Im pumped about the HC release! Im tired of froyo and can't wait to play the THD games that required 2.3+. Thank you and the rest of the team so much for your hard work. Im not a programmer but im going to start digging for the technical info you need for the camera.
fosser2 said:
Well aren't you cool, learning how to use google and ****.
EDIT: Ok now that I'm done fuming about this. The release that was posted is an early build of CM9. It is based off of Android 4.0.3. The kernel that is included with that release is linux 2.6.36. Since then, we have now moved onto 2.6.39. In no way is the "dev" group elitist. At any time anyone could have joined the IRC group and asked for a download link to the latest kernel/rom. The reason this has not been released yet is because of the "power button" script. When the power button is tripped at random times it causes the entire tablet to freeze up. The only way to "reset" the tablet is to open it up and press the internal reset button, thereby voiding any warranty from Viewsonic. Another issue that I have seen with using this kernel is possible damage to the camera. Just a few days ago I learned that while running this kernel the camera heats up and is hot to the touch, almost to the point of burning yourself. I have since then, unplugged the camera from the mainboard, to hopefully stop damage to the camera (I'm guessing that whoever has run this already without unplugging their camera, has potentially fried it). In short, installing this rom does give you some latest and greatest software to play with, but with it comes risks. DO NOT INSTALL THIS ROM/KERNEL IF YOU DO NOT WANT TO RISK DAMAGING YOUR TABLET.
ps. As a dev. team, we will be releasing HC with a .36 kernel that supports hw accel very soon. Keep your heads up for that release. Hopefully this release can hold people over until everything becomes more stable. Thank you all for patiently waiting.
Click to expand...
Click to collapse
Thanks to all the Devs working on this stuff for us! That said if you guys need any testing done just shoot me a PM, I rarely use my tablet any more and have cracked it open plenty of times for other hardware testing. I don't have much time to work on software anymore, but am more than willing to test stuff for you if you don't wish to risk your tablets. Again thanks for all your work.
Sent from my Nexus S using XDA App
MOD EDIT:
FORUM RULES:
Encouraging members to participate in forum activities on other phone related sites is prohibited.
Off-site downloads are permitted if the site is non-commercial and does not require registration.
Closing this thread - this is just getting out of hand folks.

[DEV HELP][?]Looking to Build a ROM!

well i thought i'd get this up before source for JB (4.1) drops... I'm looking for a dev willing to let me watch them as they build a ROM and make changes to that ROM... no i don't need to come over your house to do this... I was thinking of a live video stream of your screen as you do the work... if you're willing to allow me to watch and maybe answer a few questions in between, i'm willing to learn!!
i learn really fast if i'm watching someone do it which is why i'm taking this approach rather than trying to read through a bunch of threads on this topic... that stuff basically looks like a foreign language to me... especially when they talk linux stuff lol... i can catch on quickly but i need to SEE IT BEING DONE... not reading and having my brain decode what i just read...
so please pass this thread along... the site i'm looking to use is join.me and it can be viewed by more than one person... so if someone else is willing to jump in on the fun and the dev is cool with it... we all can watch as they work their magic...
preferably someone that's gonna be building on crespo/crespo4g... but i'll take whoever is willing to teach!!
disclaimer: i'm not even looking for a real "expert" on the subject... just someone to do the basic work so i can take notes and then do the stuff myself!!
PM me if you're a dev and willing to help out!! what do you have to lose? nothing really... you're just gonna load the program and let it stream as you do the stuff you normall would do...
sn: it doesn't have to be Jelly Bean... but seeing as source is coming out soon... i figured someone will want to start fresh and build from aosp... that's really where i'd like to start from!!
I'd love to watch too
Sent from my SPH-D710 using Tapatalk
Click here for custom mods for your E4GT
umm. the best way to do it is to just follow the step by step guides online. doesnt get much easier than that. you watching isn't going to help when they already have all the software installed
derekwilkinson said:
umm. the best way to do it is to just follow the step by step guides online. doesnt get much easier than that. you watching isn't going to help when they already have all the software installed
Click to expand...
Click to collapse
thanks but i have everything i need to build a ROM installed and have already built one from CM9 source... i'm talking about all the other edits and things they do... ie: adding in or removing features of a ROM...
and if you re-read my OP... i said reading this stuff is like learning another language... i'm a visual learner... i need to SEE these things then do them... not read them and try to decode whatever i just read...
the1dynasty said:
thanks but i have everything i need to build a ROM installed and have already built one from CM9 source... i'm talking about all the other edits and things they do... ie: adding in or removing features of a ROM...
and if you re-read my OP... i said reading this stuff is like learning another language... i'm a visual learner... i need to SEE these things then do them... not read them and try to decode whatever i just read...
Click to expand...
Click to collapse
I just happen to work for a company the makes tools to help visual learners.
Sent from my SPH-L710 using Tapatalk 2
Yea I'm willing too. I got a few things going here. Along with ubuntu, sdk, java6, android kitchen. I'm more of a visual learner. I've been constantly researching to point where my brain hurts to think android. I need a break. But I'm willing as well. Some devs out there no even respond to help needed. I would love to watch Fergie716 at work tho.
Sent from my Nexus S 4G using Tapatalk 2
My video will be up tomorrow (today) in my MIUI thread. I have everything ready for it. I just had a bit too much to drink tonight (its 450am)
Tomorrow afternoon it'll be up
Sent from my SPH-L710 using Tapatalk 2
I also like to watch.
Sent from my SPH-D710
I agree with the OP, one thing I think is missing (or at least in my experience hard to find) in the Android ROM community is a set of guides on how to properly do things (branch with repo to make a mod, apply patches from other trees, add prebuilt apks, add source provided apps, integrate su, busybox, creating your own vendor, device, adding your kernel, etc)
It's all scattered all over the net, sure you can figure some of it out but if you lower the barrier of entry people will be able to focus their energy on doing better work somewhere else.
gparent said:
I agree with the OP, one thing I think is missing (or at least in my experience hard to find) in the Android ROM community is a set of guides on how to properly do things (branch with repo to make a mod, apply patches from other trees, add prebuilt apks, add source provided apps, integrate su, busybox, creating your own vendor, device, adding your kernel, etc)
It's all scattered all over the net, sure you can figure some of it out but if you lower the barrier of entry people will be able to focus their energy on doing better work somewhere else.
Click to expand...
Click to collapse
i really couldn't have said it any better!!
i know Fergie usually puts out some great tutorials... i used his stuff when i was learning to theme... so hopefully he delivers on this as well... i would still like to do a live "webinar-type" of training tho if any dev is up for that!!
we can get a time going so that everyone can login at the same time and see what's being done...
I'd also like to see how its done, I would love to be able to cook up some things and then release a ROM to the public. I'm sure it's not easy but I'm willing to take a wack at it
Btw are you guys using pretty powerful computers for building ROMS? Or would you say they're average spec?
stellar said:
I'd also like to see how its done, I would love to be able to cook up some things and then release a ROM to the public. I'm sure it's not easy but I'm willing to take a wack at it
Btw are you guys using pretty powerful computers for building ROMS? Or would you say they're average spec?
Click to expand...
Click to collapse
mine isn't that great tbh... but it manages to put out something... once your setup is correct and you do your first build... the second build of that ROM is usually a lot faster...
i think average would be around quad core with 8GB RAM... that's my guess based on a few devs i've heard from...
the1dynasty said:
mine isn't that great tbh... but it manages to put out something... once your setup is correct and you do your first build... the second build of that ROM is usually a lot faster...
i think average would be around quad core with 8GB RAM... that's my guess based on a few devs i've heard from...
Click to expand...
Click to collapse
I like to learn too. But my pc is just dual core 3.0ghz 4gig ram what do you think?
Sent from my Nexus S™
mixtapes08 said:
I like to learn too. But my pc is just dual core 3.0ghz 4gig ram what do you think?
Sent from my Nexus S™
Click to expand...
Click to collapse
it will take longer than some other PC's... but that will still work... i'd guess a few hrs to build a ROM... mine is around those specs and it takes a few hrs on the initial build lol
There should also be a thread for porting, kinda like "chef central" where users could get support on certain issues with their ports.. Over there in chef central the people seem to only help people that are building from source.. there's not too much support for people doing ports which is unfortunate because not everyone is skilled enough to build from source and having ports is what keeps some devices alive... In this thread there would be threads where you could post your logcat if your not getting boot and some of the more experienced porters (like fergie for example) could take a look and point you in the right direction. Also there could be guides and tutorials as how to get certain aspects of the ROM working like HWA, WiMax, MMS/SMS so on and so forth... I think that it would really bring a lot of new life to some devices that don't get the support that they should..
Anyone else agree on that or is just me?
evol4g said:
there's not too much support for people doing ports which is unfortunate because not everyone is skilled enough to build from source and having ports is what keeps some devices alive...
Anyone else agree on that or is just me?
Click to expand...
Click to collapse
I agree with the whole sentiment "more people should build things", but not with "aosp is too hard so we should help people do ports". Unless a port is the only way to get a device working, we definitely should focus on making aosp easier to learn if that's part of a problem the porting people are having.
Anyway, I started my own ROM yesterday and might end up making a wiki to document a bunch of things I'm doing. It's a very stock-ish ROM though, so I won't spend much time writing about adding mods other than a few basic ones.
-IF- I do get around to making the wiki, I will post here about it.
As for the computer, I am using a i7 930 (2.8GHz) with 24GB of RAM.
gparent said:
I agree with the whole sentiment "more people should build things", but not with "aosp is too hard so we should help people do ports". Unless a port is the only way to get a device working, we definitely should focus on making aosp easier to learn if that's part of a problem the porting people are having.
Anyway, I started my own ROM yesterday and might end up making a wiki to document a bunch of things I'm doing. It's a very stock-ish ROM though, so I won't spend much time writing about adding mods other than a few basic ones.
-IF- I do get around to making the wiki, I will post here about it.
As for the computer, I am using a i7 930 (2.8GHz) with 24GB of RAM.
Click to expand...
Click to collapse
id like to ask.. is making a rom really difficult.. how much java language knowledge would a person need to have to build from source...?
ferozfero said:
id like to ask.. is making a rom really difficult.. how much java language knowledge would a person need to have to build from source...?
Click to expand...
Click to collapse
Well, one of the fun things about being a maintainer rather than a developer is that you really don't -need- much knowledge at all.
Everything helps, though. Yesterday I fixed a gcc compilation issue from knowledge of C++ that I acquired over a number of years. It wasn't a hard bug to fix and I could've asked a friend about it instead, but being a programmer lets me get away with fixing mistakes I see in AOSP when it's necessary (it rarely is).
Later, in my kernel compile, I turned on a compilation flag because I knew that a warning (that failed the build due to -Werror) was completely inaccurate. Good luck doing this if you don't know what's a compilation flag, and good luck doing it safely if you're not sure what the warning means and if it is really safe to override it (it often isn't).
If you want to make a ROM and be efficient about it, I think the two most important skills (in order of importance) are the ability to use git and to solve problems. Without a minimum of source control ease, it will be a pain in the ass to add features to your mods or to keep track of changes efficiently (especially when it comes the time to branch off releases and what not). Problem solving is what you do whenever stuff that should work doesn't work. And it's always hard because if it wasn't hard it would be documented already so you wouldn't have the problem.
If you want to build FEATURES for a mod (that is, not repack what others have written), then yes you will need programming knowledge. Java, C and probably C++. Mostly Java for user facing stuff.
great post gparent... that was a wonderful breakdown of how ROM making works... if it's all true (which it sounds like it), then this might be a bit more than i can chew lol... i'm still willing to see someone in action do these things so i have a better understanding of how to put things together and maybe one day i'll take a stab at building my own ROM!!
gparent said:
24GB of RAM.
Click to expand...
Click to collapse
:what: wow, lol
If any other devs come by I'd love to know what setups you guys use for developing too.
Sent from my SPH-D710 using Tapatalk
Click here for custom mods for your E4GT

Categories

Resources