(suggestion) Community SGY - Galaxy Y GT-S5360 General

Please more experienced developers SGY, provide the community with detailed information regarding the modification of "drivers" and porting CM10, I'm not a programming expert, but many of us know something, even a little. I am a student of Mechanical Engineering, numerical control and management, which is somewhat similar to programming.
Please make contributions, to the respective programs to use, if necessary, a specific OS, or Windows 7 or 8 is possible to do so, please contribute.
So it could move forward in correcting errors or bugs present in the ports of CM7, CM10, etc..

Related

[REQ/OFFER] Public Bug tracker to help reduce the activity in threads

With so many roms and software being developed and so many questions being asked over and over again, it occured to me that there is not (correct me if i am wrong) a public bug tracker for XDA.
Ideally integration with the user database and even possibly the threads (more than just a url link) would be great.
If we had a way of tracking and submitting bugs then i think each dev or cook could better manage the bugs in thier software and i think it will help reduce the duplicate requests and bug reports going on in each thread.
The bug tracker could split between software types, platform, then also have device sections with each rom under that, much like XDA is structured at the moment, in fact probably identical to reduce the confusion and help with the linking and integration.
What bug trackers could possibly be used that would integrate with XDA? Bugzilla?
I am more than willing to setup an instance for testing etc, who would be keen to see and help with this? Integration will be the biggest task.
Interesting Idea, I guess that would have to involve developer consent that they want their work to be tracked. Having people discuss in threads isnt bad as that is what the forum is for but a tracker type online utility may be good for huge projects which would cut down on posts saying "Hey whats the status of Bug X and Y?"
Good idea
I used my own tracker for a while, but for xda we would have the issue of how to assign users to what role.
Every time I made a rom, I would need to request a new category and get ten pepper added as project authors ...
Trouble with the tracker that I found was that it just got messed up like the forums. Trust me that nobody searched it.
I reverted to a dedicated subforum, eventually, as it was less work in managing. I had appointed a second bug system admin, yet still got heaps of stuff to do...
A tracker is a great idea, but would be misused, and there stupid "why is camera no work kthxbai" posts would continue by those not checking the tracker.
Integrating a attacker is pretty easy on a username perspective, but harder on a people perspective
Still, I like the idea, but can envisage huge amounts of work for svetius, making new categories every time a new rom appears etc ...
pulser_g2 said:
I used my own tracker for a while, but for xda we would have the issue of how to assign users to what role.
Every time I made a rom, I would need to request a new category and get ten pepper added as project authors ...
Trouble with the tracker that I found was that it just got messed up like the forums. Trust me that nobody searched it.
I reverted to a dedicated subforum, eventually, as it was less work in managing. I had appointed a second bug system admin, yet still got heaps of stuff to do...
A tracker is a great idea, but would be misused, and there stupid "why is camera no work kthxbai" posts would continue by those not checking the tracker.
Integrating a attacker is pretty easy on a username perspective, but harder on a people perspective
Still, I like the idea, but can envisage huge amounts of work for svetius, making new categories every time a new rom appears etc ...
Click to expand...
Click to collapse
yeah i agree with all of your points, i guess i was thinking that if it were somehow integrated into the forums then it'd be used more. as far as roles, a simple request to establish a project that would then be assigned to the dev in question. they could then choose to add extra people.
i just have no idea what tracker could and how fully integrated it would be with the forums.
it seems to me that if some of the noob "why is x not working" could be at least reduced by a bug tracker, hell we could even weed out the noobs by saying that unless you check and submit bugs no questions will be answered in the forum.
anyway, thought it was worth mentioning and getting the ball rolling. We could do some basic pilots of different trackers based on any known integration benefits.

[Q] How can I learn to develop

I would like to learn how to develop Roms like the major bigshots on the Epic forum, can some please give me some advice on where/how to get started with this, along with things I'll need to start developing.
Thanks
Simply AOSP 3.1.1
masaidjet said:
I would like to learn how to develop Roms like the major bigshots on the Epic forum, can some please give me some advice on where/how to get started with this, along with things I'll need to start developing.
Thanks
Simply AOSP 3.1.1
Click to expand...
Click to collapse
I have no idea, but I am glad to hear that you want to learn to build some ROMs for us.
Good luck!
Thanks for the support. I just hope a rom developer would provide me the answers I need soon
Simply AOSP 3.1.1
Read, read, and read some more. Then read again. The info is around just scattered all over the internet. cynagon has a good post about it in the android development section. I would start with going there
First of all, I would recommend buying a book that teaches Java development, there are several available from Amazon (I recommend the Lewis & Loftus 6th edition, it's the one used in my Intro CS classes). Once you have a decent understanding of that, you can go to developer(dot)android(dot)com/sdk/installing(dot)html (sorry, can't post links as a new user) to get set up with the Android SDK and linking it with Eclipse. At the very bottom of that page, they have some guides to starting programming, like a "Hello World" application. Also, I read that Samsung recently came out with a developer's section somewhere on their site, which has some tips for beginning programmers. Finally, take apart some .apks, and try and understand some of what's going on inside them, and look at the sample projects included in the Android SDK.
Best of luck, and welcome to the other side of the community.
If you're old enough, I suggest looking online for nearby classes where they can teach you directly so you can fully understand it all.
Otherwise, feel free to take some of the other's advice, and figure it out by reading =P
Nevertheless, welcome to Development.
There's a thread somewhere specifically for it... brb digging...
Dug: http://forum.xda-developers.com/showthread.php?t=667298
learn about linux.
themes and most ui changes are java - download a rom, unzip it, and check out /system/framework or /system/app
you can open .jar files by changing .jar to .zip and extracting them
Thanks for all the advice you guys, umm I'ma start off by learning how to theme then work my way up trying to understand my phone a lot more than I do now

Android Development Codex: A complete mod guide for every device! (add to XDA Uni?)

> Abstract: I have been consolidating a complete, monolithic, and community editable guide for all mobile devices, to reform how XDA Developers works. Take a look, and edit or give suggestions... (Perhaps merge this with XDA University?)
## Rationale
XDA Developers is one of the largest and most important sites to mobile device development. We know all that; we've been here for years. And after staying here for a long time, it's hard to imagine anything different from the status quo; nor why the "new guy" is so frustrated and confused.
Unfortunately, owing to our messy evolution, the guides for most devices on XDA are, (quite honestly, no offense), outdated and disorganized, divided among tons of threads and maintained by OPs who may or may not be active. The XDA Wiki was built on the premise of consolidating the info from the forum, but the tendency to link to forum posts rather than bring in the full methods has made it utterly redundant, and therefore rarely edited or trafficked.
The reality is, forums are great for development and asking questions, but they are the wrong place for constantly fluctuating guides that demand united community support. The result is the status quo on XDA; a ceberus of information difficult to organize or sift through, resulting in newbies constantly asking supposedly "obvious" questions about methods and issues long since solved.
The question is, is it the noob's fault for not trusting or reading such disorganization, or could it be that we aren't making it clear how to proceed safely?
## Design Specifications
To rectify this situation, I have been compiling the Android Development Codex, a complete, monolithic, and community editable guide to the any device I could get my hands on, taking users all the way from unlocking to customization.
The codex will also give readers a few tips and tricks for troubleshooting common problems (so they don't have to wade through 900 posts to find the answer), and general guides to cool mods that can be made on the phone. Perhaps we could even teach people to create modifications to keep the community going.
The Android Development Codex is based on eight principles:
* Everything must be in the guide. We need customized "beginning to end" guides that give the user everything it takes to mod a device and deal with problems afterwards. As stated above, the XDA Wiki failed because it only linked to the forum, making it no more useful than a forum sticky.
* Mark or fix outdated information ASAP. Outdated information is the biggest issue with the status quo on XDA; at best, it won't work, and the new guy will come crying to the forums. At worst, devices will be bricked, leading to intense mobs of angry noobs. With a monolithic guide, as soon as new developments occur, we can post it in the Codex as a warning to all, and change the method if needed.
* No redundant information. There could be thousands of devices by the time we get to a finished state, and much of that info is exactly the same. This leads to duplication of work, and eventually outdated info. Examples are things like ClockworkMod instructions, Glossaries, and general OS mods. The Codex should consolidate as many mods as possible into general guides, and for things like glossaries and recovery instructions, Mediawiki-style templates should be used to pull them in.
* One customized guide for every device family. Every device is special in some way. The XDA Developers Book is great, but even the most general of rooting guides cannot tackle the thousands of unique circumstances that exist in every device. Rooting, Unlocking, Downgrading, and other unique things are under this umbrella.
* Always provide a manual method. Automatic "one-click" roots are great, but manufacturers are always out to patch the latest method. If we don't know how to do it by hand, we can't really find much of a solution.
* Ensure that all required files are accessible and stay accessible. Eventually, all good things must come to an end, and when people are no longer around to sweep the grounds, link rot sets in. This is very, very bad; one of the archives could contain a vital rooting program, and there would be no way to recover it. Just remember the fall of Megaupload. Always have multiple mirrors for every file, and perhaps archive everything into the Internet Archive when the community is gone.
* Give all sources for methods included. Credit must be given where credit is due, not only in deference to the original authors, but also to give the methods credibility.
* The ultimate goal is to transform a layman into a developer. For most people nowadays, modding mobile phones is their gateway into the workings of the computers that control our lives today, just like home computers were in the 80s. The Codex needs to clearly show how anyone can become an XDA-Developer and participate as enlightened individuals, rather than as mere participants.
## The Monolithic Guide
The Android Development Codex is here.
Currently, only the HTC HD2 and the HTC Droid Incredible have functionally complete guides at the moment.
The entire thing is stored on Github Wiki, so you can edit it if you have a github account. Hopefully, developers will all be able to come together once and for all, and work on one big guide, rather than tons of small, redundant, and outdated ones.
## The Android Development Codex is unfinished! Why are you releasing it now?
Originally, I was going to keep the Android Development Codex as a surprise until all the guides for the devices I owned were complete. However, a new project called "XDA University" is being started with similar goals, so am prematurely releasing my work to the community and awaiting further developments.
If anyone here has a hand in creating the XDA University, please contact me, because I have some great ideas on how to make it work, not to mention tons of data for us to start with.
You have a PM

XDA DevDB FAQ / Feedback / Bug Reports

This is relating to the announcement of DevDB: http://www.xda-developers.com/announcements/introducing-the-xda-devdb/
Please use this thread to report bugs, request features, and offer feedback. :highfive:
==============================================================
The main DevDB Access url is here: http://forum.xda-developers.com/devdb/
This is @bitpushr here, I'm hijacking @svetius's thread to put a bit more information and a quick FAQ on the DevDB for people.
The overall goal of DevDB is to give structure to the development projects on XDA. Most obviously this is for ROMs, but also kernels and other tools and projects that you wonderful people come up with. I've been getting a lot of PMs about DevDB so I thought I'd compile them into a little FAQ:
1. How Do I Add Projects to DevDB?
You can visit the main DevDB url, and if you have access to add a project or import an existing thread, you will see the following links:
Adding a project will allow you to enter a new project from scratch and automatically create a thread for you.
Importing an existing thread will allow you to "enhance" the thread by adding it to the DevDB database and let you add more detailed information about your project.
2. Why should I add my project to DevDB?
For developers, it adds crucial metadata to your project that will allows us to show your project in more locations on the site. Threads that are "DevDB-ized" show up in the device page ROM listings, for example. We also add some cool features like a new large-file download system, reviews, a bug reporter/feature requester, and more.
For end-users, it allows us to present the ROMs and other projects on the site in a friendlier format. Rather than scouring forums and threads for new ROMs, we want to give them a place to see these projects and the unique features each one has.
We have some other cool ideas 'in the pipeline' so we thoroughly encourage devs to add their projects to DevDB.
3. Who can add projects?
Right now Recognized Developers and some other beta users are able to add projects to the system. If you wish to be added to the best-tester list, please pm @bitpushr.
Eventually we'll open this up to all "Senior Members" after we get all of the bugs out.
This is really cool.
Thanks a lot. :good:
That's why this is my favorite forum.
Some characters aren't showing correctly in FF 22.0. They show up fine under Chromium. I'm using Linux.
The characters are located:
Just before the device's name;
Near each of the table's columns' titles;
The stars also seem hidden (didn't check if those were ASCII characters or images, tho);
There's a weird "fi" showing in the search bar. It's in black when using the normal theme, so it may be less visible than on my dark theme.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Also, the bottom bar ("Total Results: X") has white text on a white background using the default theme (on both browsers).
Awesome idea!
GermainZ said:
Some characters aren't showing correctly in FF 22.0. They show up fine under Chromium. I'm using Linux.
The characters are located:
Just before the device's name;
Near each of the table's columns' titles;
The stars also seem hidden (didn't check if those were ASCII characters or images, tho);
There's a weird "fi" showing in the search bar. It's in black when using the normal theme, so it may be less visible than on my dark theme.
Also, the bottom bar ("Total Results: X") has white text on a white background using the default theme (on both browsers).
Click to expand...
Click to collapse
that's a weird binary character. It's actually a hexadecimal representation of a character which is not present in the font you are using.
I have a few issues to address. What about tools which can be used for all devices? The CASUAL project just started a new IDE called CASCADE. It will eventually allow for users to create their own CASUALs easily via guided use of the CASUAL language. Also, there's plenty of CASUAL scripts which will work on all, many, some or one device. Is it possible to link these tools cross-forum?
This is frigging awesome.
Feature requests:
1) Can/will this be enabled for [APP] threads, too? Has anyone SEEN the Nova Launcher thread lately?! But, not just for clutter--the feature request, Q&A, etc. will be very useful, too.
2) Can a FAQ tab be added? Not essential, but may keep 1st post of ROM threads from overflowing with paragraphs and paragraphs of text. Also, related to idea 6, below.
3) In bug reports, can we enter our hardware somewhere so we don't have to re-type it every time? Also, can multiple devices be selected, a la Google Play website app installing?
4) In bug reports, can we have a separate, but REQUIRED TO FILL OUT, text box for steps to reproduce?
5) Can bug reports be edited? Many times we think we know the issue, but then another user discovers the actual regression, and then instead of two bug reports, one can be made?
6) The biggest one is the last, hehe. Can we somehow have user-editable FAQs for threads? I seriously think XDA needs to implement Wiki's IN THREADS. People check threads (nobody, IMO, sees or even knows that XDA has a Wiki) and there are a handful of users who are nearly as knowledgeable as the developer who post. Maybe only OP-approved people can edit. But, seriously, you guys can make XDA legitimately 100x better if you implemented Wiki-style FAQs for these special threads.
Many people know the answer, but don't want to retype it 500 times. Now, let them put their answer in a very EASY TO FIND place in the FAQ. You seriously harness the power of this extremely knowledgeable community. If you don't, then you leave smart people upset at multiple people posting the same question.
Question:
1) Are
My two cents
Hopefully this isn't looked on as the ultimate sin or put me on any list hahaha BUT I have a question for any admin/moderator that's directly involved in this project....
How is this helping the developer?
I see a lot of things that users would love and want because they see this site more of a ROM shop then a development site but I don't see how this helps the developers, the ones doing the actual development.
I mean, judging from threads like the NOVA thread which ikjadoon pointed out above....users don't read or even search before posting which in turn causes developers to take more time away from the development process to answer questions that have been asked and answered about 100000 times if not more.
They also ignore warnings in OPs unless they're in BIG RED letters. They post in the wrong sections time after time even though there are stickies and is written in the XDA rules. The list goes on and on and on, how users repeatedly prove that they can't read 2-3 paragraphs if not less of information that will help them and/or follow simple instructions.
I'm not on any high horse here but if you ask anybody that's willing to be truthful if this is true or not, they will answer HELL YES.
With that said, by encouraging users to be even more lazy and giving them tabs is not only making it more difficult for the developer(s) by having him or her fill out these tabs BUT is not in my opinion going to fix the clutter/searching before posting issue.
This will also (in my opinion) send a wave of users harassing developers if they chose NOT to take part in the whole tabs project.
I don't have all the answers nor do I expect any of the admins/moderators that are directly involved in this project to have them BUT I believe this would be a step in the wrong direction if organizing the forums is the ultimate goal here.
ONCE again, this is my opinion. At the end of the day, is your site and you will do as you want. I'm just a member throwing my two cents in...don't shoot! :good:
svetius said:
This is relating to the announcement of DevDB: http://www.xda-developers.com/announcements/introducing-the-xda-devdb/
Please use this thread to report bugs, request features, and offer feedback. :highfive:
Click to expand...
Click to collapse
How about a field in the DevDB that indicates if the ROM passes Google's CTS (Compatibility Test Suite)? Some people may not want to install something that deviates too far from what Google intended Android to be like (or if something fundamental got broken), if you know what I mean.
Just my humble $0.02
ref: http://source.android.com/faqs.html#compatibility-test-suite
Sent from my Nexus 7 using Tapatalk 4 Beta
@Mazda
Some of your points are EXACTLY the reason I think each of these threads needs a user-editable (aka wiki-style) FAQ.
The developer, here, does NOT need to create and edit the FAQ themselves. Many knowledgeable users can do that and the developer is free to simply curate it.
If the FAQ is readily available in a tab, I think you will see a significant decrease in thread noise.
ikjadoon said:
@Mazda
Some of your points are EXACTLY the reason I think each of these threads needs a user-editable (aka wiki-style) FAQ.
The developer, here, does NOT need to create and edit the FAQ themselves. Many knowledgeable users can do that and the developer is free to simply curate it.
If the FAQ is readily available in a tab, I think you will see a significant decrease in thread noise.
Click to expand...
Click to collapse
I believe they tried that with the WIKI's and it didn't turn out that well....
Some wikis did well and some were ghost towns.........the clutter remained none the less
OH and I would like to say that I'm not here to piss on the idea of this project or just say "none of this will work", I'm simply stating my opinion based on what I've seen as a member since I've joined.
I would LOVE to see XDA live up to it's potential and maybe remove some of the clutter and trolls BUT I just see it going a different direction at this moment in time...
Exactly! They were ghost towns because nobody knew about them and, if you did, why take the time and energy to edit something that like 10 people would see?
Thus, place them as a tab on the OP like the others are now.
Same...XDA has ridiculous potential!
This is a great idea and one I've wanted to see in XDA or any other forum for a long time. Since I own a Note 2 N7100, I contributed my part by using Google docs and forms to provide much of the same information in the DevDB for the Note 2. I would say now much of my work is obsoleted, but I agree it is a good thing for XDA.
However for improved granularity, instead of just 1 ranking rating, can DevDB also include 1 other rating for Screen On Time as an indicator for battery life?
My sig links to the thread where I made the index, you can see what I've done.
Good feedback, guys. Keep it coming :highfive:
Well, more of the same, haha:
Threads are great for a few users having a semi-cohesive discussion. With many users, many important issues are somewhere within hundreds of pages.
A user-editable FAQ would fix that. I'd like to also stress the importance of having the FAQ as a tab and NOT a link, as otherwise we'd have fewer users editing and fewer users reading.
It doesn't have to use the exact wiki format. But, maybe, a community-editable post that is otherwise normal.
Some threads that could've used it:
http://forum.xda-developers.com/showthread.php?t=1727052
Galaxy SIII Annoyances Megathread
http://forum.xda-developers.com/showthread.php?t=1984126
The AT&T Jelly Bean Release Thread (4.1.1 released; Kies and OTA)
http://forum.xda-developers.com/showthread.php?t=1739426
[HOWTO] [ROOT] No Tripping Flash Counter - [ATT / Bell / Telus / Rogers / Sasktel]
Mention @ tags don't work with DevDB.. Rest it ok needs improvement though
Not the s3? wow.
AdamOutler said:
that's a weird binary character. It's actually a hexadecimal representation of a character which is not present in the font you are using.
I have a few issues to address. What about tools which can be used for all devices? The CASUAL project just started a new IDE called CASCADE. It will eventually allow for users to create their own CASUALs easily via guided use of the CASUAL language. Also, there's plenty of CASUAL scripts which will work on all, many, some or one device. Is it possible to link these tools cross-forum?
Click to expand...
Click to collapse
Actually we are considering this as some tools are multi or pan-device. Working on a way to show this correctly across multiple devices without getting confusing. Honestly we wanted to make sure that this system works in the first place, find out where we need to expand it, and then do it. @AdamOutler don't know if you noticed but one of the download options (if you have edit capabilities on a download file) is to set it as a CASUAL file. You can also set a specific board for the download. Our API will allow you to ask XDA to "send me all CASUAL package files for 'mako'" and then allow you to download those directly. More TBA.
Mazda said:
Hopefully this isn't looked on as the ultimate sin or put me on any list hahaha BUT I have a question for any admin/moderator that's directly involved in this project....
How is this helping the developer?
I see a lot of things that users would love and want because they see this site more of a ROM shop then a development site but I don't see how this helps the developers, the ones doing the actual development.
I mean, judging from threads like the NOVA thread which ikjadoon pointed out above....users don't read or even search before posting which in turn causes developers to take more time away from the development process to answer questions that have been asked and answered about 100000 times if not more.
They also ignore warnings in OPs unless they're in BIG RED letters. They post in the wrong sections time after time even though there are stickies and is written in the XDA rules. The list goes on and on and on, how users repeatedly prove that they can't read 2-3 paragraphs if not less of information that will help them and/or follow simple instructions.
I'm not on any high horse here but if you ask anybody that's willing to be truthful if this is true or not, they will answer HELL YES.
With that said, by encouraging users to be even more lazy and giving them tabs is not only making it more difficult for the developer(s) by having him or her fill out these tabs BUT is not in my opinion going to fix the clutter/searching before posting issue.
This will also (in my opinion) send a wave of users harassing developers if they chose NOT to take part in the whole tabs project.
I don't have all the answers nor do I expect any of the admins/moderators that are directly involved in this project to have them BUT I believe this would be a step in the wrong direction if organizing the forums is the ultimate goal here.
ONCE again, this is my opinion. At the end of the day, is your site and you will do as you want. I'm just a member throwing my two cents in...don't shoot! :good:
Click to expand...
Click to collapse
Hey @Mazda, this is ddrager from Twitter.
Well these are all good points. We did a lot of thinking about what XDA does, what we stand for, and what we provide for developers. For a developer, we are oftentimes not only for discussion but also a platform both for distribution and for feedback on ROMs and other applications for mobile devices. In this regard, DevDB is a platform for users to find the right ROMs and applications for their devices, which hopefully keeps them off of the threads with questions about downloads and whatnot. Sure, we can complain all we want that n00bs don't read, don't search etc... but complaining about it doesn't fix the issue. We wanted to present a way that is easier to follow for those looking for new ROMs and how to modify their devices. A sort of 'device central' where you can get all the information on your device for everyone from those new to Android to those who are veterans at flashing ROMs.
For developers, not much has changed. You still have the development forums, and this is totally optional. DevDB adds some features like built-in reviews, bug reports, a torrent tracker/download system etc. This is mainly for those devs who wish to have additional promotion of their projects, and to make it easier for end-users to find and interact with those projects.
Regarding the issue of users not reading, this isn't a problem unique to XDA. You can point people to search as much as you want but there are 10 people behind them asking the same questions. We've all been guilty of this to some extent at one time . What we can do as a site is make the important information as easy to see and find as possible to help reduce the amount of extraneous questions sent to developers, that have already been answered.
XDA is a site full of information overload, and the best thing we can do is make that information categorized and easy to read.
ikjadoon said:
@Mazda
Some of your points are EXACTLY the reason I think each of these threads needs a user-editable (aka wiki-style) FAQ.
The developer, here, does NOT need to create and edit the FAQ themselves. Many knowledgeable users can do that and the developer is free to simply curate it.
If the FAQ is readily available in a tab, I think you will see a significant decrease in thread noise.
Click to expand...
Click to collapse
This has been brought up a few times. I think what it comes down to is that we currently have a wiki, and nobody really uses it for something like that (that I know of). You can create a page on there and link it to the thread as it is right now.
Great feedback all, keep em coming! :highfive:
awesome feature. when can we expect it to be available on other forums
not asking for an eta although
Just wanted to say this is AWESOME!
I browsed around a bit in the "db-test-areas" and I really like it! The benefits are clearly visible:
Better overview
makes it easy finding stuff for your device
no need to browse pages and pages of devices sections when you are searching for something specific
I'd love to find it in the whole forums!! Keep it on!

Recognized Developer Code of Conduct & Minimum Requirements.

Recognized Developer Code of Conduct​As an XDA Developers member with special standing as part of our developer program, we obviously have some expectations of your conduct. We try to be friendly here, and while we understand that not everyone is going to get along, we would ask that you try to avoid getting into big arguments in threads. If you have an issue with another forum member, take it up with them politely in a private message. It’s the mature way to deal with things.
As a titled member on XDA, you are a representative of XDA’s ethos – “by developers, for developers.” As such your activity offsite in other public venues should be in the same vein. Any negative, derogatory, abusive talk or actions may be taken into account as to your status as a titled member. This would include any behavior which violates our site rules. This does not change your responsibility to be subject to the requirements for acceptance into the Recognized Developer program, both in their current and future states.
While all users should follow the site rules, we would ask that you take a quick look at them again, as they are occasionally updated. If you have any questions, please don’t hesitate to get in touch with any moderator.
In addition to the rules, we would highlight the importance of acknowledging the work of others. It’s not nice to see your work get ripped off—whether it’s a ROM, part of a ROM, an app, a theme, images, guide text, etc. If you’re familiar with the regulations in academic institutions, you should know the score. Just seek permission and acknowledge those whose work you use, and generally be reasonable about things.
We would also ask that if you have a dispute, you first try to resolve it in a reasonable and private way, such as through private message. It is in no one’s interest to see your dirty laundry aired in public, and it looks much better for you to avoid conflicts on the site.
Senior Recognized Developers of XDA, in additional to the above, are expected to be active on XDA regularly. While we all go away for vacation, exams, and other everyday life events; we would ask that if a Senior Recognized Developer intends to take a significant break from development, he or she stand down temporarily. You’re more than welcome back if and when you return, and we’d love to have you back, if a space becomes available. The reason for requesting this level of activity is because as a Senior Recognized Developer, you will be able to vote on the appointment of other Senior Recognized Developers in the future. If many Senior Developers disappeared, it would be troublesome gathering a sensible turnout. In addition, from time to time we will invite discussions on matters pertaining to the site, and it’s only fair that we try to ensure that the people most familiar with development and XDA have a chance at helping out.
Recognized Developer Minimum Requirements​To be able to provide some transparency on how the reviews for RD are rated we’ve set up these minimum requirements. Please understand that the RD program is not just a reward for people that try hard on XDA, it is more than that. Accordingly, not just any project meets the standard of development. We will use these minimum requirements with enough room to budge if the circumstances require this, but please use a somewhat critical view of your projects, and only apply if you have at least met these requirements.
Make sure you uphold the RD code of conduct and the regular XDA rules. Should you have infractions on your account, contact the Developer Committee if you want to know if you are eligible to apply. As a general rule of thumb, wait one month per infraction point before applying, and can’t accept members with more than 10 points to their account. Of course, exceptions may be made but contact us if you have a question about this.
All Projects
Members must be actively involved in the community
Team accounts can’t receive the RD title. It’s a program that rewards developers for their individual work and team accounts don’t fit that idea.
A minimum of two full-fledged, markedly different projects are needed to apply for RD, only very special projects are considered otherwise
Any project needs to have at least three months of active development before it will be taken into account for the application
No history of bans and/or serious infractions
Changelogs must be readily available inside the thread, with updated information for each version
Feature lists and changelogs need to be free of blurry expressions like “tweaked ext4 performance” and other meaningless terms. Instead, it should be explained what was done in detail and why it was done
ROM
They started from an official manufacturer or source base (stock ROM or AOSP-like source).
Threads show a clear overview of changes made, in a way that DC can clearly see what has been developed by the user
The ROM isn’t the product of an online kitchen or otherwise derivative development (i.e. themed stock ROM)
ROMs need to identify what kernel they are using
If 100% stock then they must state that
If custom they must provide a link to the kernel on XDA (if available) or a link to the kernel source. To accomplish this there are two options:
Option 1: They provide links to suggested kernels but do not include them in the ROM
Option 2: They include the kernel but must provide a full, buildable source with all GPLv2 requirements met
Apps
Very simple applications may be excluded (very basic UI or functioning)
A free version of the application is available on XDA (no trials)
The developers are either active on XDA or really helpful in their support thread
Kernels
Sources must be posted and downloadable with build comments, toolchain used, and must compile
Sources must be released via forking + commits rather than “lump releases”
Link to the source must include which branch is in use
Guidelines:
In order to make sure the DC is able to find the information we need to make sure your threads hold all the information necessary. Here’s a list of things we like to see.
Threads should include:
Clear introduction
An overview of what the project does (i.e. its purpose) and what is included
2-8 screenshots that are posted alongside each other
A clear changelog in a
Code:
or tag, that shows the non-trivial updates to the project
Installation instructions and links to download and github (or like services) for source code, as applicable
Credits with links to the projects that have been built upon, or have been included, in this project
Provide a checksum if you can (md5, sha1 etc.)
The DC set up a template thread that highlights the important parts of a project. Try to follow this template to have an organized and clean thread. You can find the template thread here.

Categories

Resources