Road map to Oreo

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 ( and gerrit ( 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.


Android O planning

Android O will be here before we know it! The hype train has been put in high gear and it seems like that’s all everyone is talking about these days! Part of this is because there’s not a whole lot to really do Android wise. This time of year is always like this. People go into maintenance mode and just fix bugs, tweak little things here and there and that’s pretty much what you’ve seen out of ROMs lately. The other part is the unknown. Most people just don’t know what to expect with a new release. This may be because they’re new to the Android custom ROM scene or they just don’t want to go on assumptions.

The unknown has caused a lot of users to contact us via Twitter, Google+ and via email (YES, people still use email lol). We’re here to answer some of the questions that have been asked of us in the last couple of days.

What devices are you going to support in Android O?

Until we have the source sync’d up and we attempt to bring these devices up, we can’t answer that. I mean, we could answer it and give you guys false hope but that’s not our style. Giving you false hope will just piss you off if say months from now we release DU12 and your device is not on the list. You would feel like you got cheated or lied to and we just rather wait to see what we really have to play with.

That said, I will go into detail on what we look for in a device to carry it forward in the next cycle.

– Someone on the team has to own the device and willing to maintain it.
Sometimes the device is fully functional but the maintainer just wants to get something newer. After all, we’re just like you guys. We like new things and we want to see how the ROM works on higher end hardware. If a maintainer is not available, it doesn’t matter how popular the device is or how many other projects support said device.

– All core features on the device MUST work.
We’re not going to make exceptions on this. Quality over quantity! We want to make sure that when you run DU, you’re not getting a bad impression of the good work we do.

– The device must not break another device in order for core features to work.
This mainly applies to CAF devices but not limited to them. In the past we’ve seen maintainers attempt to force a device to work with DU but then break 2-3 devices in the process because they added this repo and these commits and we’re not going to do that. It makes no sense for us to maintain 1 device and break 2-3.

What features will make it into Android O?

Is easier for us to tell you what features won’t make it in because the list is a lot shorter. Before I start, know that this is always subject to change. We may add more features to this list but we also may change our mind about a feature and carry it forward. That said, here it is….

– Media scanner on boot
The ‘Media scanner on boot’ feature has become obsolete. Is no longer needed in today’s Android. Pictures, ringtones and other files get scan accordingly into apps so there’s no need for it.

– Scrolling cache
The ‘scrolling cache’ feature just never made sense but up until now, nobody questioned it unfortunately. I’ll leave that at that.

– Wifi/data indicators
The ‘Wifi/data indicators’ while they work great, it was either them or the traffic indicators we have because we can’t have both. We took a small vote internally and the traffic indicators were just loved a bit more.

– Doze notifications QS tile
– Heads up QS tile
– NFC QS tile
QS tiles moving forward will have to pass our test of whether or not said QS tile is used more than once. For example, you have QS tiles like WiFi, BT, Flashlight, etc that are constantly being used by the user. We believe now that all QS tiles should be like this. They should be used and not just added because we can. QS tiles like the heads up one are used once because you either love heads up or you don’t. That said, the tiles above fall under the category of tiles that you toggle once and never use again. No need to collect tiles for the sake of saying we have more features than everyone else.

– Keyguard statusbar clock
The ‘keyguard statusbar clock’ is something that while it was some what neat, just doesn’t make sense considering the lockscreen clock widget.

– Statusbar date options
The ‘statusbar date options’ while they some what function, just doesn’t work to our standards. This feature has bugs. We’ve attempted to savage it but it would probably end up like the ‘Quick unlock pin’ feature that everyone continues to carry forward, a feature that’s popular but is now limited/doesn’t work in full.

I know I know, we’re horrible people but remember we could of just lied to you and then pulled the rug underneath you. At least we’re honest!

What are things you’re considering come Android O?

I won’t go into what we want to do with existing features that we’ve seen in the developer previews because that’s all subject to change. Google might just pull the rug underneath us and keep everything exclusive for the Pixels. Here are a few things we do know we can do.

– Improve the appearance of Dirty Tweaks.
Back in kitkat, we introduced Dirty Tweaks v1.0 which had the tabs with the layout in which the icon is to the left of the title/summary similar to how you saw in Settings. Our train of thought was that since Dirty Tweaks is an extension of Settings, it should look some what like Settings but not entirely. We also wanted it to stand out. At the time it did the job. Dirty Tweaks stood out and that style became known with DU. The ‘problem’ now is that this is open source and if another project likes something of yours, they can easily adapt it as well. Today you can count on one hand the projects that don’t have this style. That said, is time to introduce another style and hopefully it can stay unique to us for a while longer before we have to move on to another style 🙂

– Content guard (Anti-piracy)
This is something that we’ve considered for a while but are finally moving forward with it. I won’t go into the reasoning for this, is pretty obvious. I will say that unless you steal apps via going around license checks or decompiling themes, you shouldn’t have a problem with this. It won’t affect you if you purchase all your apps, themes, etc. We have app developers on the team (Bret, James and Mat) and we support them as well as our friends (Davey, Bryan, Train, De Jan, etc) in the theme world!

– Less QS tiles
As stated above, we want to only include QS tiles that are used. Just because we can, doesn’t mean we should. There are a lot of tiles that while neat, just don’t make sense. For us a quick settings tile tied to the system should do more than just open up an activity. It should perform a useful task that the user will use more than once during their day. Quick settings tiles that open up activities are now reserved to those introduced by apps via Google’s QS API.

Better device/features integration in Settings
We support a lot of devices. A lot of our devices on their stock ROM support ‘screen off’ gestures and so we do as well. We want to centralize these gestures into one section instead of it being a guessing game depending on the device or whether it being unofficial or official. Features are no exception here. Although we have Dirty Tweaks, it doesn’t mean that everything has to be included in Dirty Tweaks. If a feature can be included in one of the menus that Google has included in AOSP then we should include it there.

That’s it!! Just remember that this is all subject to change but we will keep you guys in the loop as always!

To stay in the loop, follow us on Twitter, Telegram and Google+


Tell me how you really feel

So about a month ago we (Josh Chasky and I) wanted to do something for April fools day! We started to think and we came up with a decent plan.

Given that Shreesha Murthy is a popular maintainer with a huge following for his work on devices like the OnePlus 2 and Oneplus 3/3T, we decided to use him as the target for our prank. We figured more people falling for this, the better!

Our plan was simple. We started to find little things that supposedly bothered us and got on to him about it the week of the prank. This started on 27th of April. We were telling him to check JIRA for bug reports, to fix commits in gerrit and just minor things. One after another, we were riding his ass. He was losing his shit but we were doing this to build things up so when we did pretend to kick him out, it wouldn’t seem to sudden and he would sell it. About 2 days in we started to feel bad for the guy. Shreesha is a young guy (probably the youngest in DU) and we didn’t this to cause him any issues in real life.

Anyways, we brought in on the prank. We told him all about it, he laughed and we told him not to say anything. He was now in on it. We kept on ‘riding’ him and even team members were like ‘OH SHIT’. Anyways, 2 days ago we “kicked him out”. We booted him from our chats (slack, telegram, etc). We removed his repos BUT not before forking them first. THEN we made an announcement saying that we did just that. We said that we wouldn’t go into detail but that we parted ways with Shreesha. It was epic! We (Shreesha, Josh, Bret, Edwin, Nick and I were all laughing).

It wasn’t enough tho. Some people were still calling bullshit and that it was part of a early April fools prank. We denied it of course but they still said ‘eh, we’ll wait til April 2nd before we believe anything’.

That’s when we knew we had to step shit up!

I got on Google and found a broken picture of a OnePlus 3T, quickly edited it and said ‘Oh noooo I broke my phone’. This was the dummy and ever so obvious April fools prank. This was done to distract from the Shreesha prank. A lot of people laughed but said ‘Good one but not as good as last year’s prank’. Once that was said, I knew it. They assumed that was the prank BUT we still had the Shreesha prank in play. We didn’t want to just leave it there and so Shreesha and I hopped on Telegram.

We went into the most public chat we could think of. A public chat filled with over 700 members from around the Android community. Developers, themers and a shit ton of n00bs populate this chat. We jumped on there and we started to argue. I acted like I was mad about Shreesha’s tweet he made after he supposedly got kicked out. Oh YEAH…….I had him make that tweet to possibly draw some people to the prank but it failed, only a few people saw it. None the less, I was supposedly ‘mad’ and ‘butt hurt’ about this in the Telegram group hahaha

We went at it! He said things, I said things and we had people convinced that this was a legit thing. That Shreesha and I were mad at each other and that I was some what butt hurt about this tweet. We made it so big that even some of the moderators got involved and told us to take it to PM and even the n00bs came out to take part in the drama.

BUT that wasn’t enough. We needed to convince some folks on G+ who had said that this was obviously a April fool’s prank. So we said OK, lets do the same thing! Shreesha was set to make a post and sell this! He was suppose to come off upset about me supposedly deleting repos. He sold it! People were buying it. I jumped on there and again, I acted like I was mad! I acted like I was stomping my feet and I was supposedly legit mad hahahaa couldn’t be further from the truth. I actually had to stop once just to catch my breath again. I was laughing so hard!

Anyways, I was supposedly upset and butt hurt and everything hahaha people were buying it! Aside from some people taking it WAY TOO FAR and pretty much embarrassing themselves with foolish comments, we sold it! People no longer believed this was a April fool’s joke! They started to take sides and saw this as a real life beef! hahahaha we were all laughing HARD!

Telegram blew up as well and people were like ‘Yo Alex, you should take this private’ and nobody was questioning it anymore! So yeah……APRIL FOOLS!!!! hahahaha

Shreesha is very much loved in DU. He’s a good maintainer and part of the team and will continue to be a part for a long time! Early on there were issues with this and that but he’s adapted very well with our style of doing things and has fit well with the other maintainers and the team in general!

Remember guys, don’t take things so seriously and especially not around April 1st. You guys really embarrassed yourself. I saw a lot of REAL comments from people that I had assumed were cool with us. Really disappointing to see that but it was fun for the most part 🙂

Thank you for playing and til next year folks!


Android O and some plans

Android O was announced not long ago and it’ll be here before we know it. They already got a developer preview and is scheduled for late August or early September. We’re ready and have a lot of neat ideas to expand certain features and create a few new ones. We won’t jump the gun on our plans for features just yet because until we get a change to evaluate the source, is just hot air. Google is Google and what that means these days is that Google might throw a curve ball at us and plans might change.

Our first impression of Android O has been positive. Very little things annoy us with Android O. Our developers like it and think we can do wonderful things with it. We’re excited.

For more information on Android O we suggest you take a look at these two articles

Android O announced, developer previews available today

Hands-on with Android O

BUT hold on!! Android N is no chopped liver. Android N has been great to us and has enabled us to learn a lot and in turn we’ve been able to create and include a lot of different modifications to our project. We also didn’t bring in a whole lot from Marshmallow so things even out. Some of our users would of wanted us to do so but we didn’t and life goes on. We did so because we felt like it was necessary, let us explain.

While newcomers to the Android scene may think that the point of our project or any Android based project for that matter is to add in as many features as possible, we disagree. That’s not to say we haven’t put on that hat before. We probably had the most modifications in a custom ROM in kitkat. It was fun, not going to lie but it also came at the expense of stability.

We want stability, great battery life similar to the stock ROM (what you see on Nexus/Pixel devices) and useful additions that we the developers and users of the project would use on a daily basics. I think in Marshmallow we had a perfect blend of all 3. In Android N we continued that perfect blend and maybe a bit naive to think but we feel like we can reproduce that in Android O as well. So to our critics, we’re doing it because we want a better experience than what Google or any OEM provide not compete in a ‘who can add as many mods in a ROM before it blows up’ race.

Moving on, I recently put out a call to all our users to show us their screenshots. We wanted to see what users were using on their devices as far as features and how they configured things within the ROM. We focused on things like the navbar, quick settings and even the actual settings layout. What we learned from our #MyDirtyUnicorns experiment over at Google plus is that while a lot of users love the eye candy features when introduced, they don’t actually use them in their daily setups. I know is disappointing but is true.

For example in Marshmallow we had a feature called ‘Gestures anywhere’ that was originally created by Clark Scheff in kitkat and a lot of users found it to be awesome. They requested it and we delivered. The feature works by going into the feature menu, adding in all your gestures and mapping them to an application or action and from there on you could perform the gesture on any screen and your app would launch or whatever action you picked previously would take off. When it was showcased it was a mad house! Users went crazy over it! They loved that it was something they’ve never seen before but when it came down to it, they didn’t use it.

Not once did anyone showcase it in their screenshots or talked about it on any threads or even our G+ community. I recall seeing a bug with it on the Nexus 7 (flo) and asking Josh if anyone had reported this bug and he replied that he didn’t see any reports. That tells you how much the feature was being used. I still asked around to close friends and people from around the community and they didn’t use it either. Some said it was neat but too much of a gimmick for them to use. This mod alone was close to 1000 lines after it was set and done with fixes and this and that. To us it was a waste of time to bring that over to Android N because it could of potentially caused issues merging in security updates and even major updates. There were many mods like this in Marshmallow and even more in Android N that will not be ported over to Android O.

We don’t want to collect features. We’re not in that race. We want to expand on Android in an effort to create the perfect OS (in our opinion) for us. I think every project should have this goal but as they say, different strokes for different folks. So in Android O expect for us to change things up. We’ll most likely remove some current modifications but that is not to say that new ones won’t be created or ported over. Right now only thing that is certain is that a few modifications will not be catching the bus to Android O-ville.

What mods? We’re still evaluating and having discussions about what the final list will look like. We’ll keep folks posted over in our G+ community.


On the other side of Android N we learned a lot! We’re moving up the ladder, gaining more experience and learning from our mistakes. The last part is the most important one for us because we’re going to make mistakes. We’re not perfect but we do need to learn from our mistakes. If you don’t learn from your mistakes then you’re doomed to repeat them. That saying doesn’t just make for a nice office poster but is true. Our team continues to learn, evolve, share knowledge with one another and we’re excited for what the future brings.

One of the highlights of Android N has been (at least for me) when the folks over at 221 Pixels redesigned our app icons. They gave them a fresh professional look and it created consistently across the project. It made everything around it just that much better. The icons actually look like they belong. They’re not too flashy but not too dull and that’s exactly what we wanted. We’re an extension of Android not a replacement. We love the stock look and feel.


Going forward with the professional look, we want our boot animation and default wallpaper to correspond to the icons above. We also want to get the community involved so we’re going to set this off in the form of a contest.

Contest details for what we’re looking for, prizes and all are not set in stone. Stay tuned for that as they’ll be made in a another post.

In Android N we made a lot of moves. One of those was with Substratum. We ventured off in the unknown of Substratum and it worked out great for us. A widely criticized move to leave the CMTE for Substratum, turned out to be the best thing for us in both usability and perfect alignment with our goals. We wanted to decrease our work load when it came to mergers and with Substratum we can do just that. Substratum requires very little commits on the ROM side and does the same job (and more) that the CMTE was doing for us in Marshmallow.

OMS introduced by Sony has a strong possibility of being merged into AOSP and if that’s true then there’s no denying that this was the best move and that is here to stay. Expect Substratum to be our theme option in Android O.


In Android N we saw some new devices get added and some old ones dropped. Expect this to be true in Android O. As devices get older, our maintainers lose motivation to keep them due to performance issues and the fact that they want new toys to play with. No list has been generated as of now but a list will come. Stay tuned to our G+ community for more information on that as it gets closer and closer to shut the book on Android N.

Our way of doing things (AOSP branch and CAF branch) will not change. This is something that has continued to work great for us and we’re strong believers in not fixing what’s not broken!

We want to thank all our contributors (past and present) and themers for everything! We wouldn’t be where we’re at without you guys. We know a lot of critics make silly jokes about themers but Android wouldn’t be what it is today without these fine folks! They’re a large part of the DU community and we appreciate them!

We want to also thank all our supporters for everything they do in our community. Answering questions, encouraging other members and spreading the news about our project! Right now we’re under 30K active members in our community and that’s all been word of mouth, so thank you! You guys have been awesome and is really encouraging to see!

Again, stay tuned for a contest announcement with details and all!


Options are good

About 4 months ago we talked about SuperSU and the conspiracy that had taken a life of its own in the community. While we still believe that there’s NOTHING to worry about with SuperSU, we have gone ahead and changed our mind about one thing. We will no longer ship with root. We can’t stress enough how this change has nothing to do with SuperSU. There’s been no evidence of wrong doing when it comes to Chainfire and SuperSU, this is a fact.

The majority of the team still loves what Chainfire is doing for the community and we will continue to show our support as SuperSU users. This is not a anti-Chainfire/SuperSU post nor is a pro-phh’s superuser one. Both options in general are good, is like picking red or blue as your favorite color. We believe that removing root creates options for the user. If the user wishes to stay unrooted then they can still enjoy all of what makes DU the ROM it is today. If the user decides to root, they can enjoy even more stuff out there.

To add on to this, removing root is not making DU any less of a ROM. Currently there’s nothing in DU that requires root. All of our in-house modifications have been coded properly and any modifications that were not, have been reviewed by our developers and if needed were rewritten to follow our level of quality. With that said, it made no sense to force SuperSU on the user or even replace it with another root management app.

We will go ahead and make this change with DU 11.1 which we anticipate to ship either on February 3rd or that Monday, the 6th. Please be aware that we will only support what we ship with. If you decide to root DU once this change is made and install something like magisk or xposed, you’re on your own.

There seems to be some confusion with the last paragraph of this post so please allow us to clear this up. We will not provide support for ‘mods’ like Xposed, Magisk, Viper4Android and anything of that nature. Rooting alone will not disqualify you from support. If you root and have an issue with say SmartBar or a Quick settings tile, we will not hold it against you. We apologize for any confusion. We assumed it was clear but obviously it wasn’t haha

Thank you and #StayDirty

Theme decision 2016


It was almost a month ago that we made a post telling you that we were still undecided on which theme engine/outlet we would include in DU and that we would wait and see. A lot of people said what they had to say but we wanted to discuss it as a team, take it slow and just look at the code because really that’s what makes it go round. We wanted to really just think about which one would be a better fit for us not just for this version of Android but for future versions. A project of this size can’t just think 1-2 steps ahead, we need to think 5-10 steps ahead and not really jump but be ready to jump.

The team discussed it. Many of our developers took a look at the code and really liked what they saw. Sony has done an amazing job with OMS (Overlay Manager Service) and Nicholas Chum has done an equally amazing job with his Substratum app. So it was a easy decision. We picked Substratum because is the smarter play for us right now and likely future cycles as well.

We still have a soft spot for the CMTE but we don’t make decisions like this based on emotion. We make decisions that are good for the project and its future. Add in the controversy surrounding CM lately and you can see what we see.

Substratum has a growing theme support. If you haven’t paid attention then you might of missed what I like to call, the themer migration of 2016. What I’m talking about is seeing themers like Travis Hall, Manuel Möllmann, Jacek Malinowski, and Andre Zimmermann bring their talents over to the Substratum side. Is exciting to see and we hope the migration continues.

Substratum like the CMTE is fully open sourced. Is very welcoming of improvements, bug fixes and just overall contributions. The DU team is excited for this and we look forward to it! We really can’t say enough nice things about it. Below are some links for you developer types

Now that we’ve told you about our decision, please allow us to tell you about our path to merging.

OMS/Substratum won’t be merged today or even tomorrow. No we’re not crazy but right now we’re in limbo. What this means for us is that we’re waiting on Google to release not only the security updates for December but the 7.1.1 source along with nexus kernel source and blobs.

If all goes as planned then you will see us merge in 7.1 on December 5th onto a different branch. Once that’s merged we will go ahead and begin work on merging in 7.1.1. We’re anticipating everything to go as smooth as butter but if they don’t then that’s why we prepare for the worst and hope for the best. Once 7.1.1 is merged and fully tested with the new kernel source and blobs, we will begin the merge of OMS/Substratum.

Once all of this is set and done, there’s a strong possibility that you will see a DU11 official release.


SuperSU, the fear and the plan


Let me start off by saying that we are grateful for everything that Chainfire has done for the community. From Mobile ODIN to SuperSU to FlashFire, the guy is a beast and has help the Android community more than anyone. That’s a fact. Thank you for everything you’ve done for us Chainfire!

We started using SuperSU at the beginning of 2014 and it still performs great! Chainfire has even work together with our very own Josh Chasky in getting our Pixel C (dragon) working with SuperSU. We love SuperSU! Back in September of 2015 the news broke out that Chainfire was selling SuperSU to a company named CCMT. We like everyone else had questions. Part of it was that was the unknown. We’re humans and is in our nature to get curious about the unknown. Back then we didn’t know much but that Chainfire had sold it to a company own by an individual or group of individuals that supposedly own other root apps and that it was a new company. A lot of rumors started to circulate. Everything from Chinese hackers to the owner of XDA to even Google. It got crazy and stayed crazy for a while but like all things, it died down. The community went back to using SuperSU and that was the end of it, at least until now.

A week or so ago, this conspiracy surfaced up again. Same demands, same arguments, just different usernames and more people shouting at the computer screen. We won’t take part in the mudslinging but we have to address this issue because Dirty Unicorns is a large AOSP project with many users and we do ship SuperSU with our builds as of right now. So allow me to put out the facts first.

1. We trust Chainfire. He’s a great contributor and developer and the community would not be the same without him.

2. CCMT has been pushing out updates for over a year now so if they were going to steal our soul here, they would of done it already.

3. Chainfire has taken a look at their work and says that SuperSU is not collecting data even with the latest update, 2.78

4. There’s been ZERO reports of anyone falling victim to identity theft that points back to SuperSU.


Here’s our plan!

We will continue to use SuperSU until there is something to talk about other than rumors and conspiracies. If SuperSU does stop working or there’s an issue that can’t be address by Chainfire or by us, we will move forward and use Koush’s open source alternative, Superuser.


Superuser is what we were using back in 2014 when we switched to SuperSU. We’ve gone ahead and tested Superuser with our N builds (no ETA’s) and it performs good. We haven’t noticed any hiccups with any known root apps. I’ve had a few testers take it and try to make it crash or find issues and nothing.

So to wrap this up, please just know that we are prepared. If something does go wrong we will put this plan into motion but as of right now, we rather not jump to conclusions. Chainfire is a trustworthy developer and this company has been pushing updates for a year now so again, until there’s solid evidence of any wrong doing is business as usual!

Thank you again for your support!


What you got on my Nougat?


So many of you know that Android N is being rolled out today. I was a bit surprised to see this considering the new Nexus devices have yet to be announced. History told us that this would never happen but it did (where’s that crow at). Google seems to have lost their mind but we’re ready for the cluster ahead.

The point of this post is to give our users some insight on where we’re at and where we plan to be in the coming months. I’ll start off by saying that is been great working on Android M. We’ve all learned a lot and really enjoyed ourselves along the way. For us we gained new talent and saw “old talent” step up and really it was great seeing people come together on a common goal. We had a lot of pieces, some didn’t work but in the end I think we’re happy where things ended up at. We made some mistakes but we’ve learned from them and hopefully don’t make the same ones twice.

Right now we’re waiting on security updates to roll out on Monday September 5th (2 weeks from now). Security updates will be merge as soon as we can into our source and we will release v10.6 on Friday September 9th. Version 10.6 will be our final M release. Weeklies will come to a stop Friday September 2nd. DU builds based off Android N will be label DU11.

While waiting for security updates to drop, we will go ahead and get a manifest for Android N going as soon Google pushes the source to AOSP. Don’t get too excited yet because we won’t be adding anything or releasing anything just yet. We will evaluate the source for about a week and see exactly what we have. We expect the worst out of Google and so we want to see what’s broken first before adding in a ton of things on top of it.

After we evaluate the source, we will try our best to fix any issues that we may find and really get a solid base. We have a cabinet full of unique features and want to make sure you enjoy them without any hiccups.

This cycle will catch those that like the kitchen sink ROMs by surprise. We will be focusing on less. People say less is more and that’s becoming more true than you guys can imagine. We’ve started to really see that a lot of mods were just there and that really nobody used them. We came to this conclusion by looking at our community. This doesn’t mean that we’re going for a vanilla look and we’re going to hype up a battery icon and a new wallpaper, that’s not that we mean. What we do mean is that you won’t see a lot of things in DU that are not used by us. Things like ‘gesture anywhere’, ‘app circlebar’ and a few other mods will be a thing of the past. You want to use those mods, don’t bother using DU because you won’t see it in future builds. We will focus on expanding even more on what we have and in turn provide more original work.

Do you plan on sticking with the CMTE?
Yes, we will go forward with the CMTE minus the CMSDK and everything we’ve done to it so far. Since the start of M, we’ve made significant changes to the CMTE and we’re curious where things lead. The CMTE for us provides a lot of flexibility for not just the user but for developers. Proof of this flexibility can be seen with the work we’ve done so far. Things like our themes tile, headers integration and the ability to continue to make use of features such as instant patching in apps like Arcus without the use of the CMSDK.

16 - 1

Are you guys still going to support the same devices?
I would love to tell you that we are and that your 3 year old device will keep going strong but that’s very unlikely. I’ve heard whispers from maintainers that they will drop devices because either is becoming too much of a pain to deal with hacks or they just really want to use something newer. As of right now, we can’t say for sure and provide you all with a list. You will for sure see a few devices swap out maintainers. Some maintainers are planning on getting newer devices and other maintainers are picking up those devices left behind. If your device does get drop from official support, don’t be surprised. Maintainers lose interest all the time or the device just gets too old or sometimes life hits and life is really unexpected.

So when can we expect DU11?
Like last year we don’t plan taking part in the annual ‘I’m first’ race. We’re not hungry for donations and we don’t have anything to prove. We’ll evaluate our source and very carefully move forward. We’re learning from past mistakes and rather just take our time. We’re constantly innovating and pushing out unique features. Really just pushing the bar, setting the standard and making the community better! Up until now, google has had a rough 8 month window between the time they release the source for the next Android version and the time they announce the next Nexus. For us that’s a long time to make sure we get things right so you won’t see builds from us for a while.

If anything changes, we will update via our G+ community so please keep an eye on there for teasers and updates!


Wallpaper you say?


So as many of you now know, we have a new logo via a community contest! The winning logo selected by a team vote was made by Rajath Ranganath. This logo was legitimate and many users loved it, but we needed something that spoke to our brand and so we changed our mind. We went with John Xionidis‘ logo who btw got the second most votes in this contest and have not looked back. The community has taken it and run with it!

Known designers like JayRod, Paul Clark, Simon Schürrle and many more (I could of listed more folks) have shown their love for the DU community once more by creating absolutely amazing wallpapers! There’s even been talk of DU edition themes by both JayRod and Jacek Malinowski! We could not be happier!



OK so are you gloating or WTF?

A little bit because as founder of this project, known trouble maker, and on a rare occasion — the voice of reason, it’s always good for me to look back and see where we started. It helps me see where we’re at and paint a picture in my head for where we’re going. I do this with the help of good friends on the team so don’t be fooled either, this is not a one man show. 🙂

Just keep in mind that when I started this project, it was just me, a can of red bull, and a used EVO 3D. I didn’t really see this becoming as big as it is right now. Especially not with the gerrit, website, crowdin, tons of features, etc. I really didn’t see any of this happening. I honestly figured it would just be something to pass the time, which maybe would have resulted in getting the attention of AOKP and potentially maintaining the EVO 3D for them.

With all that said, I started to look at other areas that need a makeover, a touch up in terms of design. The default wallpaper stands out as something requiring an update. It stands out because it doesn’t stand out, if that makes sense. The default wallpaper created by Jesus Partida (who also created our boot animation in both LP and M), was designed to do just that. It was supposed to blend in and not take away from anything. Times have changed. We now want something that can be used and enjoyed by users and not end up as something they quickly replace on first boot.

Below are some of the requirements we’re looking for:

Clean and original
I can’t stress this enough. It has to be 100 percent original for the exception of using John Xionidis‘ logo if you wish to add that into the wallpaper

In case you do decide to add the ROM logo, here’s a PSD, Ai and SVG for designers to use

Must fit all supported resolutions
This one is a bit difficult to explain but some wallpapers look great on say the Nexus 6P but you put that same wallpaper on say the Nexus 7, it looks like a hot mess. The wallpaper begins to lose quality and/or might be stretched out or cut down. Remember that we support multiple devices with different resolutions so if you have to, make multiple versions

Must use the team colors
Designers you know what to do with these
#980800 #FFFFFF #161616


Oh and yeah, there’s a prize too!!!
When John Xionidis‘ logo was selected, we offered him the prize just like we did the original winner, but he refused. I was like WTF, but he refused. He said that for us to make another contest and just put it towards that so thank him for this. That was incredibly classy on his part.

The winner will receive a $25 USD prize via PayPal. Be immortalized by many DU users, and get to see their wallpaper on thousands (if not more) of devices around the world!

We would of gone with a Google Play gift card, but we underestimated things, and didn’t know that we have users in countries where Google does not play ball. With that said, a gift card might not be a fitting reward for them due to country restrictions and/or they might just want a pizza instead.

The contest ends in exactly one month from today on Tuesday August 23rd. We will announce the winner that Friday inline with that weeks weekly build!

If you enter the contest, make sure that you can use PayPal. If you cannot use Paypal, please do not enter the contest. I can’t stress this enough. If you don’t know whether there’s restrictions for your country, Google it. DO NOT ENTER if you can’t redeem the prize.

How do I enter?
Simply use the hashtag #NewDUwallpaper and post to Google+. It does not have to be in the DU G+ community, just anywhere on G+. When we get ready to select the winner, we will use that hashtag to find the entries. If you don’t use the hashtag then you’re SOL.

Thank you for all the support and all contributions!


winner winner chicken dinner


Last month we aimed at rallying up the community to help us find a new logo. We created a blog post explaining why we wanted a new logo, the requirements and even pony up a price of a 25 dollars gift card to the playstore and it was reshared a few 100 times on Google+. We even got our friends over at iTechTriad to help us spread the word, thanks Jeff and it was a success!

Many of you answered the call and submitted your artwork for us to judge. We saw a lot of good artwork via #NewDUlogo and made us wish we could pick more than one but unfortunately we can only pick one.

Our requirements for the new logo was simple. We were looking for something clean, original and that still said DU when someone took a look at it. Again, this was a very hard competition to judge and it came real close with people even changing their votes every 5 minutes and lots of talk.

Anyways, we would like to congratulate the winner Rajath Ranganath! His entry was the one that came out on top and we will go ahead and use it in everything from our gerrit to our apps within DU 🙂


Rajath please contact Alex Cruz via hangouts or in the G+ community as soon as possible so we can coordinate the exchange of your prize and PSD/Ai/vector of the winning logo.

Honorable mention goes to John Xionidis who received the second most votes

Thank you to all who submitted their artwork! It was really fun seeing the community come together and show each other support for this 🙂

We have decided to go in a direction thus selecting John Xionidis has the logo to be used from here on out. You can read more about it in the link below