Jumping straight to the point of this post, this is our road map to Android O.
I haven’t seen a whole lot of ROM traditionally do this but some users have asked me on Telegram for ETA’s on our first official Android O based builds, what devices we’re going to support and asking about what features will be available. This has been more than normal since the announcement of the final Android N builds yesterday. While we can’t exactly answer some of those questions because we don’t even know when exactly we’ll be able to release our first official Android O based builds or what devices will meet our standard come Android O, we can though explain what we’re going to do and give you an idea of what is going to take.
So let’s get right into it.
– Wrap things up with Android N
We’ve started this yesterday but there are still some things that need to be done both internally and in public. For one we’ve gone ahead and closed out JIRA. This was important for us because if we continue to get bug reports and features and work on them then we can’t move forward. No reports or feature requests can be made as of right now. Some previously made feature requests were kept open to allow our maintainers/developers to work on them come Android O but we’re done with JIRA for now.
While we won’t close gerrit in the same way we did JIRA, it’ll pretty much be closed for business as in nothing will get merged or reviewed. Contributors are free to push but just keep in mind that at this point is a storage/placeholder type of thing. Again, no commits will be merged into our n7x and n7x-caf branches.
Devs base threads will be closed by the end of the weekend as well. New threads will be created come Android O. Discussion threads can be made by users if they wish to discuss features or quirks if any within the ROM but all official threads will be closed. Our G+ community will remain open of course but no RC, official builds or weeklies will be posted.
– Set up a staging organization and AOSP manifest
As with all Android work, we don’t push to the main organization unless is stable and can be built. Since Android O will require a few months of work before we’re ready to kick start things again, it needs to be done in a semi-private but not really private environment if that makes sense. We just want it away from our main organization. While we won’t prevent github stalkers to contribute, we do ask that you respect our release cycle and don’t push out any builds based off what’s in the staging organization.
– Bring up the build repo and vendor
These two repos are essential in what we do and so they need to get our attention first. In the build repo we need to add all necessary commits to compile a decent zip. This means leaving out all the jazz and funk, just add in the necessary commits ONLY. Vendor will be rebased for Android O but shouldn’t need much work. The goal for this stage is to get all currently supported Nexus/Pixel devices compiling and booting.
– Fix any and all issues found on Nexus/Pixel devices
Once all currently supported Nexus/Pixel devices are compiling and booting, our maintainers will run these near stock AOSP builds for some time. While running these builds, maintainers will take notice of any issues that they may come across and will be required to fix them. The goal for this stage is to fix any device specific bugs we come across and making our devices on stock AOSP as stable as possible. No features or be included, no matter how ‘Awesome’ someone thinks it is.
– Push Nexus/Pixel manifest to main organization/gerrit
Once all Nexus and Pixel devices are deem stable, the manifest along with any necessary repos that were modified will be pushed to the main organization (github.com/dirtyunicorns) and gerrit (gerrit.dirtyunicorns.com). This will allow maintainers to continue to further improve on performance and/or stability.
– Nexus/Pixel will break off from the team
At this point the Nexus/Pixel maintainers will break off from the team thus helping us to speed things up some. They will test AOSP further on their now stable devices and figure out what bugs are present in AOSP, what needs to be improved and push these fixes/improvements to gerrit to be reviewed and possibly merged. No features will be merged at this point. How ever little or big, features will stay out. We understand that once we go down this hole of adding features, is hard to pull back. People usually tend to justify adding more features by saying ‘well you added this feature why not this other one’ and it gets out of hand quickly. The goal for this stage is to fix any AOSP specific bugs we come across.
Setup a manifest for CAF devices
While the Nexus/Pixel team is attempting to eliminate any bugs they come across, the rest of the team (CAF maintainers/contributors) will setup their own manifest. CAF will use the AOSP manifest put together and start to work on adding in the CAF pieces we need for CAF. We will not attempt the ‘pure CAF’ thing instead we will continue to work with what has work for us in the past, our two hybrid system. I will not attempt to sugarcoat this, is not going to be easy. We anticipate a lot of issues but we’re up for a challenge. Our maintainers don’t quit, they fight. This stage is probably going to be hardest for us because we need to not only wait on CAF to push certain branches necessary for older CAF devices but we also need to make it work with what we have. This is easier said than done and will be a challenge. Patience is key for this stage. The goal for this stage is to get CAF devices compiling and booting.
Once CAF devices are booting, we need to fix any CAF device specific issues
Easier said than done but this is the game plan. We need to fix any CAF device specific issues. Meaning that things like the camera, sound, sensors, data, wifi, etc need to be working in stable condition. We don’t move forward until this stage is completed. This stage is also going to be a pain but again, our maintainers don’t quit. We will not give in to things around us or pressure from users. If it takes us longer than expected then it takes us longer than expected.
– Push CAF manifest to main organization/gerrit
Once all CAF devices are deem stable, the CAF manifest along with any necessary repos that were modified will be pushed to the main organization and gerrit. This will allow maintainers to continue to further improve on performance and/or stability
All maintainers will be encouraged to release 1 RC build per device
At this point we want to make sure that we’ve caught everything. They say 2 sets of eyes is better than 1 and so we want to let the users have a go at it. Although we do not take part in the ‘blind build’ way of doing things and all our maintainers are more than capable of testing their own devices, we do realize that sometimes things get by us. Certain combinations of apps and situations can expose bugs at times. We need users to help us here with that.
JIRA will be opened up at this point and we will accept bug reports ONLY.
If users come up with anything, we attempt to fix it. The goal for this stage is to gather up bug reports and fix them. Again, we will not take feature requests at all, no matter how stable you think it is or how many other ROMs have added it at this point. We won’t even entertain the idea of it.
Our team will discuss where we’re at and decide our direction
Once we’ve gathered up bug reports from our users and hopefully get them fixed, we will discuss where we’re at. We will ask ourselves if we’re happy where we’re at or do we need to repeat a few of the steps above. If the answer is yes then we will repeat the necessary steps until we’re satisfied.
If and when we do decide we’re ready to move forward, we will very carefully start to add in features. This process does not mean that is a free for all and anything goes. In fact, is the opposite. We’ve gone ahead and outlined a list of features that were in Android N that we feel that are no longer necessary or wanted. We will also not fall for the misconception that because something was working in Android N, is going to work in Android O. API’s change, code changes, patterns, classes get moved around and so what was working in Android N may not work in Android O. We will not assume that it does until we see for sure that it does.
Our review process will also be different at this point. Things will take a little longer to get merged. We want to make sure we’re extra careful and that we’re not being influenced by things around us. We won’t participate in the annual ‘lets see how many features we can pack into 1 ROM’ race. We did that a LONG LONG LONG LONG LONG time ago and it ended horribly. While users were happy with how many features they had, the experience was horrible for us. We try to learn from our mistakes and that was one of those.
This does not mean that contributors can’t contribute to gerrit. Both contributions from internal and external will be reviewed the same. Just because something was pushed by say Edwin or Josh or myself does not mean that it will get treated any different than if it was pushed by Randall, Ezio or Caleb.
That’s it folks! Like I said in the very beginning, we can’t tell you exactly when our first official build will be released or what devices will be supported. We don’t even know ourselves at this point. I can probably put a list together but reality is that a lot can happen between now and then. Maintainers have real life responsibilities. Our team is made up of a lot of different types of people. Some have high demanding jobs, some are students and some have both. Some live half way across the world and some live very close to each other. So at any given moment life can strike and your device may get dropped from support. This is why we’re also open sourced, so that if someone does drop your device then someone else can pick it up.