Related
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice 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 (the links below have almost everything you could possibly want to know). 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 **** 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.
Android Developer Guides: http://d.android.com
Working with AOSP source: http://source.android.com
Platform Developer Guide: http://pdk.android.com
Android Gitweb: http://android.git.kernel.org
Git Ready (Git tips and tricks): http://www.gitready.com/
Building CyanogenMod: http://wiki.cyanogenmod.com/index.php/Building_from_source
How Dexopt works and what are those odex files: http://android.git.kernel.org/?p=pl...bcd225e47b2cc7abb2a366112d3aeb45936;hb=master
The PDK site is absolutely vital if you are going to work on custom ROMs. Read every single page. Twice. Some of the info isn't up to date, but you'll get a really good idea about what goes into actually configuring Android to work on a real device.
I cannot agree more. Learning the in's and out's of the Android framework will benefit newcomers SIGNIFICANTLY.
Building ROMs is easy, fixing bugs and adding new functionality is the fun stuff, and having a solid understanding of the Android framework helps with this. The best way to learn is to pick up the Android SDK and whip up some apps, there are great tutorials out there.
Awesome information! It is good to see I have been reading the right literature... There are also a few that I missed... Thanks again for the links!
cyanogen said:
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice 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 (the links below have almost everything you could possibly want to know). 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 **** 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.
Android Developer Guides: http://d.android.com
Working with AOSP source: http://source.android.com
Platform Developer Guide: http://pdk.android.com
Android Gitweb: http://android.git.kernel.org
Git Ready (Git tips and tricks): http://www.gitready.com/
Building CyanogenMod: http://wiki.cyanogenmod.com/index.php/Building_from_source
How Dexopt works and what are those odex files: http://android.git.kernel.org/?p=pl...bcd225e47b2cc7abb2a366112d3aeb45936;hb=master
The PDK site is absolutely vital if you are going to work on custom ROMs. Read every single page. Twice. Some of the info isn't up to date, but you'll get a really good idea about what goes into actually configuring Android to work on a real device.
Click to expand...
Click to collapse
I completely agree. But it's cyan saying it, who wouldn't
I am ok with "chef" terms because they were born on XDA, which makes them kinda cool, but I agree that the file-pusher mentality/stereotype is quite derogatory.
I hope this section goes places.
P.S. Hearing a diehard android dev like you (cyanogen) say that you are biased against sense really made me think about how good plain old android really is... so clean and functional. Good stuff bro.
very nice thanks for the info was looking into this...now to fill the brain.
Weird how this is exactly what i was looking for. Time to read. Thank you cyanogen.
I'm with Cyanogen on the bias against pre-built, proprietary code blobs. Even the non-free, basic parts to get AOSP to build for dream give me the hivie-jivies, mostly because the reason we're in such a pit now with further versions of Android is because we have no source to maintain working basic functionality (yeah, video in a device capable of recording/playback is basic).
I'll try to work a couple basic tutorials based on my rom-building exploits covering things from getting android built from source, to actual troubleshooting possible problems, to having a hand at modifying the source so you can make the built your own. I really want to see somebody come up with a real custom rom on the android part of the OS and leave the linux part rest for a while.
Oh man! PDK! Never seen it! Thanks a lot
Great job
As always, my hat is off to you Cyanogen. This is exactly what i was looking for. Once again thanks for your hard work and dedication to the project.
This is awesome. I am going to be learning this stuff over summer. But there seems to be a gap of information between learning the android stuff, and learning the linux stuff.
Hi do you know some guides online to build Overclocked Kernels ???
PDK website
Odd that the PDK website does not function. Anyone know who owns it?
mistere372002 said:
Odd that the PDK website does not function. Anyone know who owns it?
Click to expand...
Click to collapse
Works fine for me. What issues are you having?
I guess I'll be the first in the thread to ask the extreme newbie questions.
Are the links in the OP in a particular reading order, or is there a recommended order?
Since the entirety of my programming experience is some simple VB type stuff, will I be able to learn from the ground up via those links, or will it be more like trying to figure out the words in a Chinese book with no knowledge of the language?
At one point I had managed to cobble together a web front end on my Droid for wowhead.com (all it did was bring up a screen with a search box, which would then pop open the browser with the results of whatever you searched for), but to say I had a firm grasp of what I was doing in my tinkering would be a gross overstatement.
cyanogen said:
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice 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 (the links below have almost everything you could possibly want to know). 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 **** 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.
Click to expand...
Click to collapse
So, firstly thanks for the websites. Personally, I already knew about most of those. But that is beside the point right now.
Why would someone want to learn how to program anything when they are just building a rom? I just don't understand what is wrong with someone only tweaking and slimming a rom down. What point would it be for a website like this to make everybody just go out and learn on their own EVERYTHING, and then what would this site be for? Posting only in the development forums? This is a support website. Plain and simple. Who cares if someone asks a question? If they searched and couldn't find something, let it go.
In your same thought process, very FEW WM chefs could call themselves chefs. And before you ask yes, I could call myself a chef because I have written quite a few apps to assist in building a rom or actual tool for WM. Maybe not the best chef, but one nonetheless.
I just think this is basically discouragement of any new developers/chefs from posting something in fear of being chastised. I am absolutely still learning android. If it wasn't for the people of SDX, particularily joeykrim, I wouldn't be so close to a final product of my Android kitchen.
This being said, maybe I am just full of crap and the only one that will go against your POV. Mainly because I am not afraid to state my opinion. And this POV is wide across the forum and this is why I don't contribute much here anymore
cyanogen said:
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice 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 (the links below have almost everything you could possibly want to know). 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 **** 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.
Android Developer Guides: http://d.android.com
Working with AOSP source: http://source.android.com
Platform Developer Guide: http://pdk.android.com
Android Gitweb: http://android.git.kernel.org
Git Ready (Git tips and tricks): http://www.gitready.com/
Building CyanogenMod: http://wiki.cyanogenmod.com/index.php/Building_from_source
How Dexopt works and what are those odex files: http://android.git.kernel.org/?p=pl...bcd225e47b2cc7abb2a366112d3aeb45936;hb=master
The PDK site is absolutely vital if you are going to work on custom ROMs. Read every single page. Twice. Some of the info isn't up to date, but you'll get a really good idea about what goes into actually configuring Android to work on a real device.
Click to expand...
Click to collapse
Thank you.
cyanogen said:
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice 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 (the links below have almost everything you could possibly want to know). 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 **** 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.
Android Developer Guides: http://d.android.com
Working with AOSP source: http://source.android.com
Platform Developer Guide: http://pdk.android.com
Android Gitweb: http://android.git.kernel.org
Git Ready (Git tips and tricks): http://www.gitready.com/
Building CyanogenMod: http://wiki.cyanogenmod.com/index.php/Building_from_source
How Dexopt works and what are those odex files: http://android.git.kernel.org/?p=pl...bcd225e47b2cc7abb2a366112d3aeb45936;hb=master
The PDK site is absolutely vital if you are going to work on custom ROMs. Read every single page. Twice. Some of the info isn't up to date, but you'll get a really good idea about what goes into actually configuring Android to work on a real device.
Click to expand...
Click to collapse
Thanks for your support/advice,
I'm trying to understand all the stuff in order to create a new ROM for Tattoo from 0, and I will take your info in order to. Crate this ROM and make a step by step manual to help people to understand how to modify their Tattoo's. I will like to see this cooperative knoledge share for this phone. As more peoople understands all this stuff, and all this work done by the comunity, more people will join and share to have better phones every day.
Tanks
java version
hi all,
Working 100%. Thanks for this great work. Now runing this 2.6.34 kernel on tattoo. Just now ajusting the kernel configuration.
Cheers
great advice
Cyanogen
Thanks for your support & advice
Time to start reading....
trying to understand all that is needed ==
TO BE A DEVELOPER..
IF ANY BODY HAS MORE INFO OR VIDEOS ..
PLEASE POST
----------------------------------
Currently own a Sprint EVO 4g > and plan on making great things for it..
Cyanogen you are so damned right. Building a Rom should implicitly mean that you know git, Android, dev and... read api and docs
I'm thinking about dsixda Rom kitchen.
I use its scripts to unpack kernel and zip everything, but largely customized the scripts and added some. In fact I love shell scripts.
I just wish you could also post a link to a toolchain tutorial for those willing to compile binaries from sources on x86 for an ARM architecture. And also to add shared libraries.
Have a nice day.
Hello XDA,
I just recently got into compiling from source, and wanted to share what I've learned to XDA of course.
I've noticed a lot of tutorials on ROM Development with kitchens, but in my opinion you're not getting anywhere near as much control of your ROM then if you were to compile from source yourself. I'm not bashing kitchens at all, because they're great for fundamentals of ROM Development. Learning the basics with kitchens is how I started, but I wanted more control. So I've been doing a lot of research and figured I'd give back to the community.
This is a series of tutorials, with this one being the "Basics/Introduction". I've also been getting into Kernel Development, so if anyone wants me to make another series for that as well please let me know! I would love to hear some feedback on this letting me know if I'm wrong on anything (because I'm definitely NOT an expert on this) or any constructive criticism for the next video(s).
If I get good feedback I'll continue making videos for this, and like I said, maybe for Kernel Development as well. :highfive:
tl;dr
Code:
I'm fairly new to ROM Development, I tried my best to help people out who are attempting to learn compiling from source to have more control over their ROMs. [B]Please be gentle![/B] ;)
Thank you for this, dude! It's easy for a beginner to get overwhelmed by the mountain of information out there about ROM development, as I've recently found out. This is a great little tutorial, consisely showing the stuff you really need to do whilst explaining the reasoning behind it.
Can't wait for episode 2!
+1
Go for the video tutorials:good:
I really liked it, waiting for new videos :good:
Hi Nick Mast,
Can you give me your text file named As_I_Go.txt in this video.
Thanks so much.
Thank You
Please continue making more. This was very helpful.
Sent from my Nexus 4 using Tapatalk 4 Beta
Need help on custom build
Hi @d0wngrade,
We are still waiting for the other videos in the series.
Thanks in advance.
I've just reinstalled Linux in a Virtual Machine and I'm syncing the Android 5.1.1 (latest) branch now. I'm going to watch part 1 and record a video where I left off. I don't know how long it will be, but it will be coming soon-ish. After the sync and some initial setup I'll be ready to record, so watch for it!
Hi,
I'd like to get some very important info from Remix OS dev team.
Users unrelated to the dev team or with no android-x86 OS dev experience, please DO NOT attempt to answer these questions.
Could you please make a thorough guide on how to report bugs, suggestions, feature requests and hardware incompatibilites?
Which tools should we use to report bugs or hardware problems - be precise please. Current feedback form seems very modest and inefficient.
Except for bug description and device info should we provide a full logcat, dmesg, per-app logcat - please point out the most effective way to report this stuff.
Where should we post feature requests or suggestions?
I personally think, that e-mails or forum threads are really inefficient for this. I'd recommend using Uservoice service (https://uservoice.com) or something familiar . Example of uservoice usage in practice: https://touchpal.uservoice.com/ There are plenty of web services like these and they are very powerful and efficient.
Perhaps there is a web service that would help making an official list of supported hardware?
Remix OS, Android-x86 and Phoenix OS all base pretty much on the same ground here, so they could share same list, but none of these actually has a nice, neat tool to report supported hardware. Except for a list of officially supported devices, it's a total mess.
I know that ChromeOS with android apps support and upcoming Android releases may be groundbreaking for whole Android-x86 related projects, but if we mobilize ourselfs and use all resources efficiently, I'm pretty sure Remix OS can become very popular and liked. Devs - help us, users, help you achieve that.
Right now it seems like you don't really care about other devices compatibility or about what people may report. If you did, you would provide better tools for that in order to do your work more efficiently. Don't take it as offense, it's just cirtical point of view.
Please optimize that - this will help speed up the development process and community contact a ton.
Please reply Remix OS, Jide, @RemixOS_Cameron , @RemixOS_Guannan , @RemixOS_Jason , @RemixOS_Josh , @RemixOS_Joshua , @RemixOS_Valentina , @AmoraRei
Hey Ventricle,
Thanks for the message and the suggestions!
Currently:
We have the help center setup for general inquires as well as leaving technical feedback here: http://support.jide.com/hc/en-us/requests/new
We also have a google form specifically set up for Remix OS for PC users: https://docs.google.com/forms/d/1WMRbcwDqcoZ1vyUq68AJKCYvXBGvUIEvbgHhuySrUUc/viewform
On products like Remix Mini, clicking on the power options will allow you to "Report a problem" and then "Submit feedback". This will also send a user log along with the report.
We also actually read through almost every one of these threads for bug reports and feature requests. As for hardware incompatibilities, we accumulate a list based on the comments here as well as in our google group (https://groups.google.com/forum/#!forum/remix-os-for-pc). However, these incompatibilities are much trickier to tackle as the hardware configurations are so varied and diverse.
However, I will admit that the user feedback process can be better. We'll work on a more streamlined process, write up an easy to follow guide and then we'll post it here in XDA as well as other channels.
Thanks again for your comments. We clearly need the support of our user community as we grow. Sometimes, in the process of growing as a young company, processes need to keep getting better or else we fall behind. Appreciate the reminder and I'll drop you a note after we've created the guide.
Best,
Jason
@RemixOS_Jason that's great, thanks. I'm looking forward to your actions.
A little overhaul in this part of Remix development can have a powerful impact and spare so much time both for the devs and the users.
Wysłane z mojego Nexus 4 przy użyciu Tapatalka
@RemixOS_Jason I've just checked how feedback for Phoenix OS looks like and they're ahead of you! Anyway, this is what I think is better than just e-mails, forms and forums - http://www.phoenixos.com/feedback/page/1
Unfortunetly they don't have everything translated to English yet, but I hope this will change.
Just a suggestion from my side.
UPDATE:
Phoenix is definitely not ahead, so I take my words back. The feedback page is still a mess and all bushy (Chinese).
Ventricle said:
@RemixOS_Jason I've just checked how feedback for Phoenix OS looks like and they're ahead of you! Anyway, this is what I think is far better than just e-mails and forums - http://www.phoenixos.com/feedback/page/1
Unfortunetly they don't have everything translated to English yet, but I hope this will change.
Just a suggestion from my side.
Click to expand...
Click to collapse
I fail to see how that is any better that Jide's feedback forms form1/form2 or the submit a request
That page from PhoenixOS looks just like a nonsensical mess that there team would need a crystal ball to decipher what the posters 'issues' are.
HypoTurtle said:
I fail to see how that is any better that Jide's feedback forms form1/form2 or the submit a request
That page from PhoenixOS looks just like a nonsensical mess that there team would need a crystal ball to decipher what the posters 'issues' are.
Click to expand...
Click to collapse
It's true that the page looks a bit chaotic and as if people don't suggest anything useful (technical) to devs - but THATS BECAUSE THERE ARE NO GUIDELINES. And of course it looks like alpha state feedback page which isn't even translated to English yet. The description text area in Remix feedback form is like those suggestions on Phoenix feedback page - it's simply bad, because it doesn't hint people how they should describe things and what should be mentioned.
I didn't say Phoenix feedback is perfect, I'm only suggesting what direction is good in my opinion. TouchPal uservoice page looks awesome and you can see that devs read these reports and they let you know wheter they will add something or fix it. Also it lets community decide which things should be dealth with first - by upvoting them.
The forms you mentioned seem quite inefficient to me (except the booting problems one - it's great) - you can only describe a bug or a problem, you can't attach any error files and the forms don't ask what camera, audio, bluetooth devices you have. What's important - after you send it, you will never get a notification about anything coming to life - you can only hope that the next OS release will include fixes you need.
I've spoken to few devs and they usually need logcats dmesg files and as much HW info as possible. This form is just too poor to provide nice information and a gazzilion of people can report the same thing.
Instead, I'd rather visit f.e remixos.uservoice.com search if someone has the same problem as me and then if I find it, I'd upvote it and maybe add a comment. In other case, I'd post a new "ticket" following specially written guidelines on how to report/suggest stuff.
To sum up, feedback needs:
1. Guidelines on how to report (error files, which apps to reproduce etc.)
2. Anti-redundancy filter - upvoting existing feedback reports
3. More direct contact with devs - by them replying to feedback when it's a major or very popular issue (then it's not a waste of dev team's time, because it's like replying to hundreds or thousands of people) and ITS PUBLIC.
4. After a new version of system is released, the devs should also point volunteer testers to what they should focus on in testing.
Trust me, this may seem like devs will have to focus on community instead of real work, but actually if this is better designed and more efficient, they will eventually spend way less time on it then they might now.
Also using Google Groups to get to the community is a mediocre measure in my opinion. I get that it's free, has google class stability and requires almost no time to maintain or set up, but it's hugely inefficient, chaotic and inconvenient.
Remember, I only want to help improve Remix, so I suggest what may be better. I'm on Jide's side, specially now when they have Android-x86 founder working with them.
Ventricle said:
Hi,
I'd like to get some very important info from Remix OS dev team.
Users unrelated to the dev team or with no android-x86 OS dev experience, please DO NOT attempt to answer these questions.
Could you please make a thorough guide on how to report bugs, suggestions, feature requests and hardware incompatibilites?
Which tools should we use to report bugs or hardware problems - be precise please. Current feedback form seems very modest and inefficient.
Except for bug description and device info should we provide a full logcat, dmesg, per-app logcat - please point out the most effective way to report this stuff.
Where should we post feature requests or suggestions?
I personally think, that e-mails or forum threads are really inefficient for this. I'd recommend using Uservoice service (https://uservoice.com) or something familiar . Example of uservoice usage in practice: https://touchpal.uservoice.com/ There are plenty of web services like these and they are very powerful and efficient.
Perhaps there is a web service that would help making an official list of supported hardware?
Remix OS, Android-x86 and Phoenix OS all base pretty much on the same ground here, so they could share same list, but none of these actually has a nice, neat tool to report supported hardware. Except for a list of officially supported devices, it's a total mess.
I know that ChromeOS with android apps support and upcoming Android releases may be groundbreaking for whole Android-x86 related projects, but if we mobilize ourselfs and use all resources efficiently, I'm pretty sure Remix OS can become very popular and liked. Devs - help us, users, help you achieve that.
Right now it seems like you don't really care about other devices compatibility or about what people may report. If you did, you would provide better tools for that in order to do your work more efficiently. Don't take it as offense, it's just cirtical point of view.
Please optimize that - this will help speed up the development process and community contact a ton.
Please reply Remix OS, Jide, @RemixOS_Cameron , @RemixOS_Guannan , @RemixOS_Jason , @RemixOS_Josh , @RemixOS_Joshua , @RemixOS_Valentina , @AmoraRei
Click to expand...
Click to collapse
Hey Ventricle,
Again, thanks for your comments on our communication channels. I've consolidated our feedback channels into their core functions and how one can access them. In short, we're constantly trying to improve so we'll take a step back and evaluate how this can be done better. As of now, here is the short guide on how to communicate with us most effectively:
Feedback/bugs channels
Remix OS for PC: Google form: https://docs.google.com/forms/d/e/1FAIpQLSeqaTBTPzHgjwUKtn08zUDusKTYXQtG8mLczmo7D6bDgd_17A/viewform
Remix Mini: Go to power options, select â??Report a problemâ?
Remix Ultratablet: Go to power options, select â??Report a problemâ?
Feature requests/suggestions
Help Center: http://support.jide.com/hc/en-us/requests/new
Official list of supported hardware
Remix OS for PC
Google group: https://groups.google.com/forum/#!forum/remix-os-for-pc
Thanks and I hope this helps,
Jason
Could we have a development road map somewhere please? I would like to know what the devs are working on and where we are heading. I would like to know what to expect in a future release. At least what's the plan in general terms. I feel it's a bit too quiet when we talk about future releases/versions/patches.
Still no improvement?
@RemixOS_Cameron , @RemixOS_Guannan , @RemixOS_Jason , @RemixOS_Josh , @RemixOS_Joshua , @RemixOS_Valentina , @AmoraRei
Still no improvement in how you gather feedback and still no guidelines for reporting issues and giving the feedback. Why is that? This is as important as education is for a country - no education means slow or no development.
If you invest just a little more effort and time into what I suggest, I guarantee you huge improvement in feedback value and that will result in faster development. Also this will truly involve users in the development and make them want to support the idea even more.
If you don't like the Uservoice methods then I suggest you making a seprate repository on GitHub called f.e Remix OS feature requests, Remix OS problem reports, Remix OS hardware incompatibilities etc.
In these repositories, people could make Issues that your actual devs could assign to future builds or at least they would acknowledge them - people would actually feel like devs really read their feedback!
This way, people would also be able to sign under existing issues instead of duplicating them. Just like here:
https://github.com/FortAwesome/Font-Awesome/issues/878
Look just how awesome this can be:
https://github.com/FortAwesome/Font-Awesome/issues
I honestly can't understand why you neglect this part of Remix OS.
It's beyond my imagination how a company like this uses such inefficient feedback tools.
I know you use Zendesk for feature requests, but doesn't it have an option to make requests public? It'd avoid duplication of requests. Maybe it's possible to view all reports; both feature requests and problem reports? But users just don't know about it?
It could be so much better with the tools I mentioned. Come on... use them!
Please reply and let me know what you think of my suggestions.
dag u done tagged everybody ?. I see u and I forward ur message.
Ventricle said:
@RemixOS_Cameron , @RemixOS_Guannan , @RemixOS_Jason , @RemixOS_Josh , @RemixOS_Joshua , @RemixOS_Valentina , @AmoraRei
Still no improvement in how you gather feedback and still no guidelines for reporting issues and giving the feedback. Why is that? This is as important as education is for a country - no education means slow or no development.
If you invest just a little more effort and time into what I suggest, I guarantee you huge improvement in feedback value and that will result in faster development. Also this will truly involve users in the development and make them want to support the idea even more.
If you don't like the Uservoice methods then I suggest you making a seprate repository on GitHub called f.e Remix OS feature requests, Remix OS problem reports, Remix OS hardware incompatibilities etc.
In these repositories, people could make Issues that your actual devs could assign to future builds or at least they would acknowledge them - people would actually feel like devs really read their feedback!
This way, people would also be able to sign under existing issues instead of duplicating them. Just like here:
https://github.com/FortAwesome/Font-Awesome/issues/878
Look just how awesome this can be:
https://github.com/FortAwesome/Font-Awesome/issues
I honestly can't understand why you neglect this part of Remix OS.
It's beyond my imagination how a company like this uses such inefficient feedback tools.
I know you use Zendesk for feature requests, but doesn't it have an option to make requests public? It'd avoid duplication of requests. Maybe it's possible to view all reports; both feature requests and problem reports? But users just don't know about it?
It could be so much better with the tools I mentioned. Come on... use them!
Please reply and let me know what you think of my suggestions.
Click to expand...
Click to collapse
@Ventricle - After receiving your message, I shared your suggestions with our PMs, engineering team and customer support. Long story short is, they are trying to work out the feasibility, the timing and the execution of your suggestions. Although I cannot confirm at this time if and when these changes will be made, I can tell you that it's not something they haven't thought of. It does come down to the internal planning, human resource allocation and execution. Thus, please give me a few days to reply to you about your suggestions. Thanks again for pushing us to improve!
Jason
Sure thing @RemixOS_Jason ,I understand it completely. Just you saying that gives the community the sense that improvements are coming.
I'm looking forward to your follow up on this issue.
Some high hopes there!
Cheers,
Karol
UPDATE:
Got a very informative and valuable quote from @RemixOS_Jason here:
RemixOS_Jason said:
@alz_uk - Wow! It's pretty clear you have it in your mind that we are quite an evil, greedy company! Not sure if I can make a dent in your opinion, but I thought it prudent to give you a transparent answer:
As @Vioner and other users have pointed out to us, they'd like to see a different user feedback system. However, we designed it because we in the International (meaning outside of China) PR, marketing and customer support team is two full time staff and 2 part time interns. This means that our resources are limited.
Thus, the way the system is currently designed is for us to:
1) gather feedback - this is what this form is for: https://docs.google.com/forms/d/1cZNesOmnmO2esilFpvMzFZ874rvwsiKgWIX2fo9QsDk/viewform
2) organize the feedback regularly - once a week, my colleague organizes all the feedback into topics and sections and prioritizes them based on volume of reported bugs, issues, and compatibility with specific devices. This includes issues like the audio over HDMI, black screen, Wi-Fi, Bluetooth, gaming, app specific, etc. Device specific is numerous, but consider this: currently we support roughly 65% of the PCs out in the wild. This means that there will be 35% of the PCs that just don't work for one reason or another yet. That also means that for every person with a PC that doesn't work, there are around 2 people whose PC does work. With a small dedicated engineering staff as well, we try to tackle these issues from a platform point of view. Thus, you've seen in some updates the fact that we worked on GPUs that were vendor or brand specific, rather than only tackle one specific set of hardware components in a reported device. This is where the feedback form helps us to gather data so that we focus on fixing the issues that affect the widest range of users first.
3) send the feedback to the engineers - when it reaches the devs, they tweak our prioritization order based on what's feasible and what's not in the short and long term. Thus, you can be certain that we know about outstanding audio issues (we all dogfood our prodcuts and so, there are colleagues who's Remix OS for PC machines also don't have audio coming out). However, if we haven't update with this fix, you can be certain that whatever we've tried haven't passed testing, or is in the process of testing. Thus, there are two layers of what we do with feedback: count them, and then see which ones we can actually fix.
4) The fixes we do come up with must pass internal and external testing.
5) If they do pass, they are put into updates.
The installer issue was pretty simple. Most 3rd party installer do work, but as we gathered feedback from back in Remix OS for PC based Lollipop, our product manager noticed a trend where some of the OTA issues were due to 3rd Party installers. Thus, we put out the message that we couldn't promise that 3rd party installers would work 100% to support future OTAs.
Releasing fixes take time because they need to be tested. If a fix worked for some, but might cause issues for others, we don't release that fix for a stable release. Let's take the black screen issue during installation as a case example. We gathered around 65 users' emails who had this issue during installation. When we had a fix, we sent out emails and a testing ROM just for these folks with the potential fix. After around a week, most reported that their issue was fixed and that they didn't experience any other significant issues after being able to boot Remix OS (outside of some minor app compatibility issues). Thus, after a few more days of testing internally in parallel with this tester group, we rolled into that update. If you didn't see the fix applied in an update yet, it's probably because it didn't pass testing internally, or with their related testers, meaning though some folks' issues got fixed, many did not, or it caused other significant issues.
With limited resources, we do tackle issues from a platform (CPU, GPU, broadcom wireless chip, etc.) and not focus on your device, or his device or her device specific. We also work with the patches that are given out by the Android-x86 team (of which their founder, Chih-Wei Huang actually is our tech lead on Remix OS for PC) as can be evident by the update that integrated their latest release (rc2). In fact, we are small enough as a startup that we welcome our user developers assistance. So much so that I'm trying to work on making GitHub a place where interested developers can work on projects with us (where applicable since most of Remix OS is closed source). This is how much we actually need your development help!
In the end, I beg you to consider that people in general post 4-7 times more likely if they have outstanding issues, and not because we fixed any of their issues. Thus (and I know this all too well as the manager of our forums here) it can seem like everything is terrible, that Remix OS for PC just doesn't work for anyone and that no improvement has ever been made, ever. However, I just need to remember that for every 1 person with an issue that we're still trying to resolve, there are many more where the fixes we've implemented have made a difference.
As a startup, having the amount of users we have is a blessing. As a startup, having the amount of users we have with the limited resources, I mean engineers and folks like myself who communicate with the community, has been challenging. But, I ask that instead of giving up on us or spiting us for being a "mind game" playing, evil, greedy company, that you work with us to make a difference.
It wasn't that long ago that we had users who called us out on forums and tell we needed to improve our feedback system, and they're right. I'm working on improving it to offer more transparency into the process without increasing our workload to the point where it's not sustainable. Those same users who called us out are now working with us to improve through our Ambassador program. So, the challenge is, can you help us rather than just spite us? Running a startup in the industry we're in isn't easy, but it's something we're passionate about. Clearly we can still get better. Please help us.
Thanks,
Jason Zheng
Head of International PR, and Community Management at Jide Technology
I'm also frequently on our Facebook page and Twitter page
Click to expand...
Click to collapse
Wear 24 DevelopmentContributors: @JaredTamana, @davwheat
Current Status: ActiveCurrent Kernel Status: Building, NFC driver working but still potentially WIPSystem ROM Status: Still WIP. Current task: collecting/compiling files, modifying .jarsTHIS ROM IS NOT YET AVAILABLE TO DOWNLOAD AS AN END-USER ROM
This project has a few goals:
- Bringing NFC/Google Pay support to Wear24 [Feasible, main goal]
- Bringing system updates to the Wear24, ie System H [Probably doable, second goal]
- Adding/fixing functionality in the Wear24 (such as new radio bands, no cloud icon, etc) [Maybe possible but needs more research, low on the list)
- Other projects are being considered for the Wear24, but no news on them at this time.
Links
Social
Wear24Dev Blog, periodic updates on this project: http://wear24dev.blogspot.com
Wear24 NFC Discord, open chat so users can see us develop in real-time! Also, tech support. https://discord.gg/8XyTeUC
Development
Wear24-NFC-Kernel GitHub, this is our source for building the kernel. Instructions for building it yourself are in the README. https://github.com/davwheat/Wear24-NFC-Kernel
Travis-CI Build Logs for Kernel: https://travis-ci.org/davwheat/Wear24-NFC-Kernel
Wear24-NFC-ROM GitHub, will soon contain the files needed to make an image/zip, depending on how we decide to distribute. https://github.com/davwheat/Wear24-NFC-ROM
JaredTamana's GDrive dorado folder, may contain files you need: https://drive.google.com/drive/folders/1h6gz-oLMPZ90nwt7BLhWVgHii1DRCW5c
davwheat's GDrive dorado folder, may contain files you need: https://drive.google.com/drive/fold...droid-msm-dorado-3.18-nougat-mr1-wear-release
tetra release for enabling NFC: https://forum.xda-developers.com/sm...ony-smartwatch-3-nfc-support-package-t3219713
NXP Setup Guidelines: https://github.com/NXPNFCProject/NF...r/AN11762-Android_NXP_NFC_Setup_Guideline.pdf
Special Thanks
janjan: Dev guidance
@bensdeals: Donor, help
@yochanmarquos, u/lerxi: Development help.
-- RESERVED -- Because you never know
Someone should have a TWRP backup handy with the images you are looking for. Correct me if I'm wrong, but all the images you require are inside a TWRP backup image.
Anyone remember that Sony SW3 port thread? I'm not sure what happened to the project, but dev seems quiet and the device tree repos are gone. Was hoping to use those as a resource and it wasn't crawled by archive.org. Wonder if external forces got involved, which makes me a bit worried. If anyone has a clone of that repo, it might be really useful.
Please. I beg you to make this happen. Thanks for even trying
I'm definitely interested in this. If I knew I could get Google Pay working on this device, I would definitely buy one. I'll happily throw a few dollars your way too, if you can release something that works.
Hoping I found it
JaredTamana said:
Anyone remember that Sony SW3 port thread? I'm not sure what happened to the project, but dev seems quiet and the device tree repos are gone. Was hoping to use those as a resource and it wasn't crawled by archive.org. Wonder if external forces got involved, which makes me a bit worried. If anyone has a clone of that repo, it might be really useful.
Click to expand...
Click to collapse
Is this what you're looking for? (Sorry, I'm not allowed to post url yet so just remove space before .com)
github .com/FlorentRevest/android_device_sony_tetra
My Wear24 just came in from eBay . It's a really good looking device. I might be able to help you test at some stage. Also willing to donate ducats if you get far enough. Good Luck :good:
I got my wear24 a few months ago, and was slightly disappointed to find out about the lack of root, customization, etc. I'm still not a huge fan of opening it up, but I'm up for helping any other way I can!
YTSec said:
I got my wear24 a few months ago, and was slightly disappointed to find out about the lack of root, customization, etc. I'm still not a huge fan of opening it up, but I'm up for helping any other way I can!
Click to expand...
Click to collapse
I appreciate the thought, but doing anything in the vein of system modification will require opening the watch. Luckily, the pinout is right under the back cover, so chances of damaging the watch are minimal. If you change your mind, let me know.
** NEWS **
Semi-daily updates will be going on this Blogger Page so I don't clog up the thread
http://wear24dev.blogspot.com
Hi, can i flash this rom to zte quartz 2017?
Hi, can i flash this rom to zte quartz 2017?
Eshal said:
Hi, can i flash this rom to zte quartz 2017?
Click to expand...
Click to collapse
Eshal, this ROM hasn't even been built yet. I cannot guarantee compatibility with your device because I'm not building for your device. You can try flashing whatever you like, but I'm not liable for your device.
This ROM is still in its first steps and I quite literally have nothing to release yet. I've just finished bringing backups over to my PC.
JaredTamana said:
I appreciate the thought, but doing anything in the vein of system modification will require opening the watch. Luckily, the pinout is right under the back cover, so chances of damaging the watch are minimal. If you change your mind, let me know.
Click to expand...
Click to collapse
I took a look, it's not as bad as I thought. Its probably worth unlocking the bootloader anyway! I'll let you know tomorrow if I do.
YTSec said:
I took a look, it's not as bad as I thought. Its probably worth unlocking the bootloader anyway! I'll let you know tomorrow if I do.
Click to expand...
Click to collapse
Glad to hear it! Make sure to read the main thread as to tips on how to do it. Use lots of heat, and don't forget the Y000 (0.6) screwdriver.
Kernel builds are now passing, and I've begun debugging the boot process. More info on the Blogspot
Sorry for the late reply, I'm just waiting on a toolkit that works on it, then I'll start ripping it apart to help out! Also, I got that new UI which is great.
How goes the testing? I've noticed that there haven't been any new posts on the blog or on this thread. Hope everything is well
@JaredTamana Have you seen this? BLOCKS announces Project OpenWatch: an Android Oreo-based OS for smartwatches in collaboration with CarbonROM and LineageOS
Here's their GitHub.
VlitalityX said:
How goes the testing? I've noticed that there haven't been any new posts on the blog or on this thread. Hope everything is well
Click to expand...
Click to collapse
Hiya! Sorry for the lack of updates. I've hit a wall with that Binder error. All documentation online seems to be about x86 machines and ranges from IO errors to SELinux errors. I've already tried compiling without SELinux in a few different ways to no avail. I've tried contacting development channels on IRC, but no one seems to have the answers I need (most times I don't even get a reply...)
I'm still brainstorming. I took a look at the kmsg from the stock build and there's a LOT being sent to logs there that isn't from my kernel. I'm not sure where to go next, and I don't want to go knocking on the door of every single developer that might know the answer. The problem is the Binder errors are so vague about what's causing the failed transaction that I can't even start to understand what's wrong.
yochananmarqos said:
@JaredTamana Have you seen this? BLOCKS announces Project OpenWatch: an Android Oreo-based OS for smartwatches in collaboration with CarbonROM and LineageOS
Here's their GitHub.
Click to expand...
Click to collapse
Thanks! I do remember seeing this. Problem is, if I can't even build a stock kernel, nothing else can be done. I need the device booting first before I can move to system changes.
First of all, thanks to all custom ROM builders who have made the Android ecosystem diverse and rich. Even when the companies whom we pay for the device stop providing us with updates, your tireless works keep our cellphones alive and running.
Now, I would like to understand what goes into building a custom ROM. Here are my questions:
-> What kind of knowledge is prerequisite for starting such a project? For example, proficiency in C++, Java and an understanding of Linux kernel seems to be the basis of it. What else would you suggest?
-> Which tutorials, books or documentations would you suggest to learn the stuff? There are a few videos on Youtube, a few threads here, but sadly they seem to be out of date, and I guess Google has changed the Android system architecture drastically in recent years. Also, there seems to be a misunderstanding between building from source code, and modifying the source code before build. There are many which focus on the former, which is not that difficult of a project.
-> What kind of tools would make the whole process easier? There are a lot of tools like SuperR Kitchen, but are they used by actual devs? Or do the devs make their own tools for development?
-> What hardware specs would you suggest for Android system development? Is 16GB RAM enough, or is 32GB optimal? What about CPU: speed vs threads, which is more preferable?
-> How do you implement a new feature that doesn't exist in any current ROM? How do you, let's say, add a customizable lockscreen, or scrollable QS tiles?
-> When you start a ROM development, there is always an ethical question of stealing someone else's code. However, you have to start somewhere. Some ROMs say they are based on AOSP, or Lineage. How does the choice of base ROM impact the final product? How much do you copy code from a different custom ROM's source code?
-> Any other advice, suggestion or warning. Feel free to enlighten us.
Consider this thread to be a Q&A, where, if the devs are kind enough to participate in, we will get to pick their brains and learn from the process.