If you’ve spent any amount of time on XDA, you’ve heard of XDA Recognized Developer Cyanogen or the nearly ubiquitous CyanogenMod. In fact, chances are that at you’ve either run CyanogenMod on one of your devices at some point in the past, or you’re running it (or a kanged version) now. In many ways, CyanogenMod represented all that was good about Android Open Source Project (AOSP) and proceeded to go where the carriers and manufacturers were unwilling to take their devices. Along the way, Cyanogen inspired developers everywhere to reach for what was previously lacking in the Android community.
Cyanogen also saw an emerging trend which he wasn’t too happy about – the term “chef” being applied to the Android custom development scene, along with the emergence of the so-called “WinZip ROM.” So he created a thread back in 2010 to speak to this emerging trend and offer up some advice. The overriding theme was that contributing quality was far more important than contributing quantity on XDA.
He had this advice to offer for those looking to make their own Android ROMs:
Stop. Write an app or two first, learn how the system works from a developer standpoint. Learn some Java. Read the developer documentation. Learn how to use Git. Then learn how to build AOSP from source. Read the porting guides, and learn how the build system works….. Now try to put your new found skills to work on enhancing the platform by writing code or making theme overlays. And share! And put that s**t on your resume. There is a *ton* of information out there but any kind of “step-by-step rom cooking guide” is going to be a complete fail- it’s too broad of a subject.
As XDA has grown right along with the meteoric rise of Android, so has a desire of users to create their own ROMs, kernels, themes, and so on. Much of this work classifies as “original development,” but there’s been a growing trend to what many are calling “derivative development.” This category covers most of ROMs based on stock releases from the manufacturers, applying patches and scripts aimed at optimization, theming and/or removing stock applications, and using “kitchens” that run a stock release through a list of scripts and then repackage as a recovery-flashable update.zip. This is what Cyanogen was expressing frustration about—shortcuts being taken to achieve a product that differs only slightly from stock (derived) and pushed out instead of building from source and delving into the core of Android and making something truly original.
XDA-Developers exists first and foremost for developers. It’s at the core of who we are; it’s in our blood; and it’s in the air we breathe. There is a place for derivative works—they provide an entry to the scene which can help to introduce people to the wonders of Android. But let’s not stop there. Don’t be satisfied with just creating yet another derivative of someone else’s work. Instead, follow Cyanogen’s sage advice and learn about Android from the ground up, and create something truly original and innovative.
Here are some locations to help you on the path to learning about Android and contributing to the community as a whole:
Android Developer Guides
Working with Android Source
Downloading the Android Source
Git Tips and Tricks
Building CyanogenMod
Pro GIT Book
source : http://www.xda-developers.com/android/sage-advice-from-cyanogen-still-valid-today/
original source : http://forum.xda-developers.com/showthread.php?t=667298
Well put and a great reminder for all.
Side note - What is with all the "reserved" posts? This has to stop, its just spam. I will delete all posts on sight and repeat offenders will have their ability to post removed.
Sorry to divert the topic.
andyharney said:
Well put and a great reminder for all.
Side note - What is with all the "reserved" posts? This has to stop, its just spam. I will delete all posts on sight and repeat offenders will have their ability to post removed.
Sorry to divert the topic.
Click to expand...
Click to collapse
moved and cleaned...nice..
i was also curious of the so many reservations
anyway, the message is clear..
Dev = Creator(File Pusher)
Chef = Indirect Piracy? LOL
For the chef thing is my opinion since its just improvising, not really creating
Related
First I would like to thank the whole forum (with few exceptions that I'd like to not mention here) for the past 2,5 years, which have been very educating for me regarding Windows Mobile as a system. During that whole time I have searched for the perfect simple-to-use, lightweight app for storing and retrieving a grocery list, yet unfortunately I have had to come to the conclusion that it does not exist to this date. There are some existing apps but these are either not simple to use or do not accomplish the simple task at all, or they are too heavy (requiring additionally the .NET framework to be installed for example, etc.).
The idea for the simple software is that one has a changeable groups and items of groceries, from which they can select the already saved ones needed at that shopping day (e.g. during a discussion with girlfriend), and later when in shop they can just check the ones they have already put into basket. I would like to see the person who will argue that it does not easily beat archaic mode of storing information, a.k.a. paper and pen.
I have found an app which, with some relatively small amount of effort can be rewritten to accomplish that task, this software is iContact AE. As far as I understand, there is judicially no problem using the source code from iContact AE as long as following the license restrictions (correct me please if I am wrong). Why AE? Just a selection based on the fact that AE has the most appealing interface and most settings. Of course, this could be a point of discussion, but so far it seems like the best choice.
CAB - http://icontactae.codeplex.com/releases/view/28951
Source - http://icontactae.codeplex.com/SourceControl/list/changesets
I created a possible, chronological tasklist in order to get from iContact AE to the shopping app, whatever it will be called (name suggestions also welcome in due time). Also, I already have a pretty clear vision about
Discuss the usability and feasibility of the selected software / it's source code and it's alternatives (as far as I remember there was the original iContact and some other derivate version).
[*]Create, discuss and review static prototypes of the interface (basically screenshots of each view).
[*]List the requirements to be implemented (or removed).
[*]Code in / remove code according the list from previous task.
[*]Create skin and graphics.
[*]Clean up rest of code, remove unnecessary parts of it (to make it more light).
[*]Test and review changes.
I can either take lead, perform or participate actively in the tasks that are listed green. I only need a competent C++ coder who can help and thinks this is a great idea.
The changes needed to the existing source code do not seem to be much at first glance, but of course as I cannot code in C++, I could be wrong. I just looked at the parts of code where to change the tabs and queries to storage files.
So there, got it off my chest. Any C++ gurus missing a simple, convenient grocery app?
OK, I will put this in another way. I will personally contribute $50 (via PayPal or if EU country, via transfer) to the coder - provided that the end result is according to the requirements, which we will agree forehand. If anyone wants to join in with contribution, You are more than welcome.
aiiro said:
OK, I will put this in another way. I will personally contribute $50 (via PayPal or if EU country, via transfer) to the coder - provided that the end result is according to the requirements, which we will agree forehand. If anyone wants to join in with contribution, You are more than welcome.
Click to expand...
Click to collapse
If I had money I to would offer some.
It's no wunder WinMo is falling behind no one wants to create apps even when offered a straight cash deal.
Amen to that. I was actually reading this and took a good hour of researching to see just how hard it might be and how time-consuming it might be. I would have loved to take this on...but alas, It would split me way too much. I am already working on my FFP_LS Pro 2.5 Improvements (Major Major improvements...I am practically re-writing the app), I am starting work on a game I plan to release (Its a rather popular game I have yet to find for WIndows Mobile), and I already volunteered to work on the Boggle Clone for WinMo ... so I am already pretty split as it is. heh...if I find free time, and nobody has taken this on, I will probably come back and make this my next project
Sorry though...I do hope some developer comes around to assist!
Thanks for Your support. I thought that I don't need to subscribe to my own threads in order to get a notification if a new post is made, but I was wrong. I certainly didn't get one for Your post. So, sorry for the late reply. I will subscribe to my own thread now
I wish XDA provided some form of centralized bug reporting/fixing control system, where bugs could be reported and resolution tracked. I think it would help both developer and end user: Developer could quickly evaluate which bugs cause the most pain. End users could judge stability of the custom rom by its load and severity of active bugs.
For this to work, developer, developers' trusted aid or third party should have a power to merge or delete duplicates to keep the noise out the system
What do you guys think?
That would be an awesome idea!
Browsing through 50 replies, or even 1000s of replies in order to see if a particular bug is solved is rather annoying... I can't even imagine how it is for the developers!
The biggest problem here would be users just needlessly filing things that are not issues.
Then devs would complain their ROM shows with more bugs, due to some idiot not being able to flash correctly...
It's a nice idea, but google spreadsheets can be used by a dev if desired etc...
Might work in small scale, but on big scale it would be a nightmare.
pulser_g2 said:
The biggest problem here would be users just needlessly filing things that are not issues.
Then devs would complain their ROM shows with more bugs, due to some idiot not being able to flash correctly...
Click to expand...
Click to collapse
I totally agree, if such system is left to its own devices it will quickly become overwhelmed and useless. That is why I said this:
"For this to work, developer, developers' trusted aid or third party should have a power to merge or delete duplicates to keep the noise out the system"
pulser_g2 said:
Might work in small scale, but on big scale it would be a nightmare.
Click to expand...
Click to collapse
Actually, opposite is true. Small projects can be handled ok without centralized system. Any larger project requires it. That is why all for profit development companies and most open source projects have it. Some of the custom ROM development is more like the good sized open source project. Many ROM development threads have thousands of replys
This is a short summary of some important general points for posting new ROM's.
It should be considered as an optional "add-on" to the general thread:
"Galaxy S I9000 Android Development **STICKY THREAD** Read here first!"
The number of man hours spent working and developing new custom ROMs are astronomical! So why then, is it that so few new ROMs are successful? Basically because of lack of information and poor public visibility/involvement of the developers themselves. It's just like in any other successful business, you have to make your product or service stand out from the rest. Either by making an amazing product or by being a great inspiration for others to follow. Here I will try to explain and list some fundamental ideas, in order to make your ROM better and more popular.
When a would be ROM flasher is looking around for a new ROM, he searches the web and the XDA-forums for threads, usually beginning with the text "[ROM]". Next he/she look at the FIRST page where the developer (and his/her team) is presenting the various features of their new design. What is presented there will often be a decision maker for whether or not someone wants to try it out.
There are a few things that consistently differs between "good" ROMs and "bad/poor" ROM's. These things are often and naturally related to the amount of information available around the ROM in question. Someone who have put down enough mind, sweat and hart into the production (cooking) of a ROM, would also like to share his/her effort in the best possible way, not minding writing a detailed and useful description about their product. The items found below are part of some of these things that do MAKE A DIFFERENCE.
- Primary Purpose:
Essentially a description why you want to provide this ROM and why you think it is needed. What are the main features and driving forces for providing this ROM?
- Ultimate Gaming Experience
- Super stability
- Super Compatibility
- Great Battery Duration
- Minimalistic User Interface (UI)
- Simple to use functionality
- Latest and coolest never seen before interface behavior
- Fully loaded with ultimate editions of absolutely everything
- Mobile Penetration Testing Platform
- or perhaps just for educational or experimental purposes etc...
- Up-to-date Maintenance:
That means an active developer (or group of) who are readily available to answer questions from users of all levels, new or advanced! Often that they should be inhumanly available at all times of the day & night!
- Up-to-date Firmware Release:
That means the the source of your ROM is preferably based on the latest, but publicly available code/firmware. Not on some hidden leaks or old hacked code. When I say "hidden leaks" here, I mean the kind where the origin of the code (compiled or not) cannot be verified or downloaded. (BMW doesn't make car/sales advertisements using 2 year old engines from unknown/secret sources!)
- Detailed CHANGE-LOG:
People want to know that what they flash on their phones, is as close as possible to what they would like to see and use. Also from a paranoia perspective most of us would like to know that it doesn't contain 3rd party or other strange applications that we will never use, or which will give us trouble when we want to add/update applications, at a later time. A description of the various applications is also very useful. Most people would wonder what the "DarkBotSendHelper.apk" is doing on a phone.
A change-log would ideally consist of a list with:
- Title: Change Date and the custom ROM Version the changes apply to
- Full application name
- Full application version
- Short application description
- Link to application source-code, if available
- Link to application on "Android Market"
- Reference to what hacks has been made, if any
- Reason for why the hack is needed
- Unresolved BUG-LOG:
A brief log of bugs and unresolved issues that affects the current release. It is hard to explain without cussing how annoying it is to flash a new ROM, just to find out that some WiFi issue has not yet been resolved, which was posted on page 456/1200! If people post bugs/issues, that cannot be immediately resolved, please add those issues to the BUG-LOG, on the front page.
- Screen Shots! Updated Screen Shots!
The importance of good screen shots can never be enough emphasized! Many ROMs are updated continuously and if the screen-shots doesn't match what the user installs, he's gonna go WTF!, and will start to peppering your support threads with questions about how to install this and that, and how to get the same themes you are using in those screenshots, or from another different ROM altogether! You wouldn't be able to sell a new BMW with a picture of an old Volvo, would you? So why do you think a ROM would be any different? Also include a brief caption about the essential feature(s) shown, for each picture.
- Detailed Installation Instructions
This hardly need more explanation apart for making sure you also say something about:
- WIPE/No-WIPE
- Bootloader Requirements
- Recommended Procedure
- Detailed Device Compatibility List
Yes, the same gross model name/number of a particular device, may very well have some minor variations that can render the device completely incompatible with software from it's apparent twin-brother. Or even certain Firmwares may not be compatible to slight manufacturing variation. See for example the "Samsung Galaxy S" with their sub-models GT-I9000(B/M/T), and to complicate things further, even within the same model there may be slight differences, like in the PCB of the USB-port of the SGS2 GT-I9100.
- Detailed Language Compatibility
What do people use their phones for? Communication! Sure, some use them as a game pad, but after all it is primarily a browsing and communication device. So if you can't use your primary languages with your device, it is useless! Although some network operators are only beginning to understand that most of the connected world is at least bi-lingual and often much more. Thus it is of essence that your phone's keyboard, screen-reader and web-browser can read, display and understand most characters and alphabets around. (I.e. I still fail to understand why it is virtually impossible to find a phone with Russian, English, Spanish and Norwegian keyboard layouts/character sets or at least let me select these my self!) In addition it is very confusing for a first-time ROM flasher to understand the need for all the various PDA/PHONE and CSC region settings, which are often modified and re-packaged for a well cooked ROM, and thus no longer adhere to the original regional code.
So when you cook your ROM, please provide as much information as possible regarding how the user can adapt their phone to his/her own languages. This information includes at least:
- What languages are available for basic operation (the operating system)
- What languages are available for the keyboard mappings
- What keyboard applications can use these languages (Swype, Samsung Keyboard etc.)
- Simple instructions how to include, use and set the phone languages
- List of Technical Terms and Definitions that describe the ROM
The world of mobile device development is packed by technical jargon and abbreviated terms. Many times they are also abbreviated and used in the wrong context, although some the community know what it means. Simplify your vocabulary and clearly define your terms and stay with community standard ones!
- General Presentation
Like any other business presentation, please skip the HUGE fonts in a zillion colors. Most of us are neither blind nor illiterate, but you may risk to come across as being both, with those type of fonts. Remember "KISS"? - Keep It Simple Stupid.
- SPELL CHECK!!
It's embarrassing and very annoying to read descriptions of how great, professional and how well maintained a particular ROM is, when the text is riddled with misspellings, wrong words and childish grammatical errors. Although most of us are very understanding that we are living in a multicultural and multilingual society, sometimes all I think about is, how a person who doesn't know how to spell check, could ever be able to cook a mobile phone ROM. Most text editors feature at least some basic spell checking, bloody hell, USE IT!
- CREDITS
Most of the Android development community is completely driven by voluntary and open source work. Make sure to include the correct credits to those persons who have contributed to the various info/hacks/software that you include in your ROM. Use a separate list for the credits, that include the name (handle) and how/what he/she did to contribute.
2 Good Examples:
http://forum.xda-developers.com/showthread.php?t=1350763
http://forum.xda-developers.com/showthread.php?t=1155776
Final Words:
It is very likely I have missed something here, or that you (as a developer or moderator) disagree on something I have written here, if so, please provide your constructive comments how I can improve this list and post.
In Great Expectations and Hope for Many New Amazing ROMs!
- E:V:A -
PS. This was posted in the "Developer Section" as it applies only to new ROM development threads, and I wouldn't consider this neither as "Q/A" nor "General". But if OP/MOD know of a better suited place, please just move it there...
Also I am not aware of a similar post to this one, even after searching XDA quite a lot. So if it already exists, it is not easy to find and should be reposted or stickied!
<Reserved>
@E:V:A
The only thing that I missed so far is a thread like yours.
Agree on all requirements of released software.
Sometimes I wonder how some "devs" priorities are stacked regarding quality control vs. early delivery on pay-per-download sites.
Not sure what is best place for this thread. Counting # of posts in General asking Q already answered in stickies, it's kind of accepted to skip reading what's there. :-\
Perhaps keep it alive as hottest thread here?
Tapatalked - There's a Thanks button somewhere
I like this
One thing you must add while promoting your ROM.. That is CREDITS.
Rahulrulez said:
I like this
One thing you must add while promoting your ROM.. That is CREDITS.
Click to expand...
Click to collapse
YES! Not giving credit where due is horrible, basically just forgetting all the hard work another individual has put in to the "feature" of your ROM. Also, this should probably be in general.
So, I have a T989D and I'm a budding Android developer (almost finished my first major release). Once my first app is released to the masses, I will have plenty of time to develop ROMs while I'm updating my app.
This being said, I know absolutely nothing about ROM development, but quite a bit about the Android framework, java, etc. etc. I assume most ROM development is cracking open the source and tweaking to your hearts content, however, there must be some very specific things which I'm not sure my skills will translate into effectively?
So, what I really want to know from other Developers turned ROM makers is, how much of my skills are transferrable and what are the quirks/pitfalls I'm going to have to learn?
I'm quite excited to get involved and develop some ROMs for this phone, a nice kickstart would be appreciated.
Thanks!
Hello,
I would like to hire a consultant to help me with my communications needs.
Specifically, I would like to hire someone who can step me through unlocking, rooting, and loading custom OS software on android phones.
I would also like help building my own development environments and setting up my own tools so I can do this myself with your instructions.
In addition to rooting/unlocking I am also interested in security and deeper UNIX internals of the phones, so if you are applying for this consulting job, you should have a very, very good understanding of UNIX/Linux and how the OS controls the phone (and how to control the phone from the command line).
DO NOT contact me about this consulting job unless you have worked as a consultant before and know how to write good documentation and how to create real deliverables ... this is a REAL JOB.
Please PM me here at xda-dev if you'd like to chat.
Thanks.