Category: Announcements

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

#StayDirty

Options are good

no-root-du
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.

–UPDATE–
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

cmte-sub

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

https://github.com/nicholaschum/substratum
http://review.projektsubstratum.com/

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.

#StayDirty

winner winner chicken dinner

maxresdefault-1

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 🙂

du-logo-presentation-slide1

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
//plus.google.com/u/0/+JohnXionidis/posts/eRZr9ZiNCob

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

[UPDATE]
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
//plus.google.com/+JoshChasky/posts/A4fst2wBuoA

#StayDirty

Weeklies and Officials now signed with private keys

Just a PSA. We are now signing all weeklies and officials with our own private keys and not using the AOSP ones.

What that means for end users is that dirty flashing will fail if you are on a Weekly or Official prior to March 25. If you clean flash any Weekly or Official after that point you can continue to dirty flash going forward. But bear in mind this will be the first question we ask you if you have issues.

If you want additional reading on why not signing with the AOSP keys is important here is some reading for you below…

Security Alert: Malware Found Targeting Custom ROMs (jSMSHider)

Release The Kraken!! Unicorns!!

Android M was released back in October; and we’ve been busy hacking away at things; writing new features; and trying to fix what El Google has screwed up. It has truly been an exciting couple of months and we’re finally ready to release our first Marshmallow build to the public.

Although it seems like every ROM under the sun has released 100 builds before us; we wanted to make sure we got it right. We didn’t want the “ME FIRST” award. With the help of many testers in the G+ community; I think we can say that we’ve done a great job!

With this release, we’ve also started to flex our muscles a bit and show the community what we really have. We’ve adopted an approach of not just adding features just to add it, but also moving things forward. We look at feature XYZ and see what we can do with it; and if we are able to make it better. This has been the best thing to happen to DU!

We’ve also written some very unique features and we want to talk about them while we have your attention.

“Fling”, who doesn’t love “Fling”?

“Fling” is a gesture based navigation feature; like nothing else you’ve seen in Android. You are able to assign gestures to everything. From an application (chrome, youtube, angry birds, etc); to an app’s activity; to contacts; a settings shortcut; or to many custom actions that we have provided.

These custom actions include ‘back, bluetooth, expanded desktop, force close an app (aka kill-all), Google Now on Tap, home, last app, menu, notification panel, overview (aka recents), power menu, screen record, screenshot, setting panel, turn off screen, voice search, wifi or no action at all.

BUT WAIT, there’s more!! The fun doesn’t stop there as you can assign short swipes, long swipes, single tap, double tap and longpress in either left or right direction.

You don’t like the “Fling” logo? You can get rid of the “Fling” logo and still have the same functionality!

If you decide to leave the “Fling” logo in place, by default the animation is a circlular motion. If you decide this is not for you; the logo can be turned off. You are also able to use the color changer to pick the default color.

The trail that you see when you start to use “Fling” can also be customized. You can turn the trail off and still keep it’s functionality. Even the color of the trail can be changed to match your favorite themes.

“SmartBar”, in case “Fling” didn’t already win you over!

“SmartBar” is a one of kind navigation feature. You can assign up to 7 targets on phones and up to 10 on tablets. By default, “SmartBar” looks and feels the same as the AOSP navigation bar. If you don’t add targets or change any of the settings, you won’t notice any difference.

With “SmartBar”, you can assign targets in the same way as “Fling”. Whether that’s with a application, or a preset custom action. You can also use your favorite icon packs to change the default icon on any target. This is all done without touching the CM theme engine; for those that want to keep the stock look.

Like “Fling”, you can also assign single tap, double tap, and longpress actions to your targets. This allows for true customization. Where your home button may take you back to your homescreen, but double tapping it takes you to Google+, or turns on the flashlight. Long pressing could take you to the last app, or turn off your screen; without the need to use the power button. The possibilities are endless!

BUT WAIT, there’s more!! You can change the touch animation on your targets. You can set them to have a spring-like action, or if that’s not your cup of tea; you can go back to the stock animation. Changing the layout of context buttons and keyboard arrows is also included in “SmartBar”!

With both “SmartBar” and “Fling” the bar size can be adjusted and still use “Pulse”!

“Pulse”, YEAH….we didn’t just bring sexy back, we made it sexier!

While playing music with “Pulse” enabled; you get a one of a kind; brilliant; bar-style equalizer. You are able to toggle “Pulse” on and off; as it’s not everyone’s cup of tea. “Pulse” can be used with the default setting where it looks like a lava lamp. The “Pulse” color is even customiziable.

“Pulse” will not render visualizations under certain circumstances. This is a limitation of the Android API / media stack. It is not a bug. I will explain a bit further.

Android uses an output “sink” called remote submix. In submix; audio may pass through for operations like downsampling (a2dp compliance etc), pre and post processing (fx) and other things including passing track data through the visualizer library. Most output destinations like bluetooth, headphones, music, and Chromecast; Android intercepts the audio track automatically and routes it through remote submix. The visualizer library gets the track data and we have “Pulse”. Device speaker output does not require remote submix operations. Often in cases where the track is streamed with DRM protection; remote submix is bypassed; and “Pulse” will not work. I’m exploring options to force remote submix on speaker output. Such a task will be rather difficult and complicated.

“Themes Tile”

Besides these three landmark features; we have also added in an awesome “Themes Tile”. The “Themes Tile” does not work as just a shortcut to the themes engine; it allows the user to change themes on the fly.

“Long Pressing” the “Themes Tile” changes the theme on a per-app basics. Some of you have seen this similar feature on Cyanogen OS, but previously you had to use the prebuilt apk taken from that ROM. While this proved to be an OK workaround; it took away the default theme engine, and at times, was hit or miss.

Our “Themes Tile” is functional and is open sourced. It will continue to get better via the help of the community!

http://i.imgur.com/7pnaeNa.png http://i.imgur.com/hWHtAGG.png http://i.imgur.com/UMPKJ0Y.png

We could be here all day explaining every feature we’ve written, or implemented from other ROMs, but I’ll end with a short list of the features we think are important to you 🙂

– CAF Task Manager
– Double tap to sleep (statusbar/lockscreen)
– Selinux Switch
– LCD Density Changer
– Mid screen shortcuts
– Bottom L/R shortcuts
– Lockscreen wallpaper changer
– Lockscreen notifications customization
– Weather options (lockscreen/extended statusbar)
– Lockscreen colors/fonts customization
– Statusbar customization (battery, clock, traffic indicator, etc)
– Quick settings customization
– App circle bar
– Geature Anywhere
– OmniSwitch (standalone app / use for recents)
– Slim Recents and AOSP recents customization
– Heads up customization
– Animations (system/list and toast)
– Expanded Desktop customization
– Power Menu options
– Built-in system app remover
– Wakelock blocker
– Built-in ad blocker
– CM Theme Engine
– Dashboard customization (columns, dividers, title view)

On top of this; we’ve added support for some new devices and dropped a few:

Added support
– HTC Droid DNA (dlx)
– Nexus 6P (angler)
– Nexus 5X (bullhead)
– Moto X Pure (clark)
– Nvidia Shield K1 (shield tablet)
– Oppo R7 Plus

Dropped support
– HTC EVO LTE (jewel)
– Samsung Galaxy Note 3 (HLTE)
– Sony Xperia Z (yuga)

 

Official builds will start to roll shortly. Please have patience and try to keep from asking for ETA’s.

ROM developers, source for SmartBar/Fling/Pulse will be fully release within 30 days 🙂
Keep an eye at our github for updates https://github.com/DirtyUnicorns for the #Kangbang

#StayDirty

Let’s talk marshmallows

So is been almost two weeks since Google spread the heavens and came riding down on their unicorn and threw a bag filled of Marshmallows at us.

Many of us were not looking forward to Android M. Simply because we knew what was coming. We didn’t know exactly what would be “Googlify” but we’ve been around the block a few times and know how things go down. Unfortunately, we were right on many fronts. Once we all got a chance to sync the source, add the binaries and compile for our primary device (Nexus 6), we saw that this version of Android seem rushed.

We don’t exactly know why it was rushed out but we normally see AOSP source being released around Halloween so we know it was definitely different compared to past years.

What was wrong?

A few things but compared to past years and considering these issues were on a Nexus device, it was that more annoying to see. Not providing the toolchain to compile their kernel source on one of their most recent devices (Nexus 6) and incomplete blobs which caused a lot of confusion around the Android community. Many knowledgeable developers found themselves with a deer in the headlight look because they have done what they’ve done for years and this year, they had no data/signal on last year’s Nexus. This left many of us questioning ourselves if we missed something. After regrouping, we found that these issues were effecting everyone.

Things have since looked up and we now have a somewhat functional build for most Nexus devices. YAY Google!!

Moving forward, we will start evaluating our CAF based devices and put in the work to get those booting. Hopefully we have enough coffee and liquor haha

With every Android version, things change. Source code changes, maintainers come and go and the ROM itself matures. With this also comes newer devices that we add support for and older devices being dropped. This year is no different on that front.

We have decided to drop a few devices. This decision was made not because of Android M as much as it was made because life happens and the maintainer can no longer maintain them.

Those devices include the Samsung Galaxy Note 3 (HLTE) and Sony Xperia Z (yuga). More devices maybe dropped but as of right now, those two are certain to not make it to M with us. As with all things, it is subject to change. We might gain another maintainer who does have the time to maintain those devices so don’t be surprised if they get DU flavored M in the near future.

So what about Lollipop?

Nothing much to say on that except that we’ve experienced a lot of different things and learned from that, both good and bad experiences.

Many of you have expressed the need for us to release one last build for Lollipop with Google’s security patches and we have listened and will make that happen. As of right now, we don’t know when exactly that will be but that it will happen before we release our Android M based builds.

As always, we ask for your patience and thank you for your continued support!

Kickstart Weeklies AGAIN!!

Yup, weeklies are starting up again! Huge thanks to DU developer and friend, James Taylor for taking charge on all fronts and making sure things were ready for everything to run smooth.

In the past, I was running the weeklies off my buildbox using a simple script and it got the job done but things were slow. Then there were weeks where life got in the way and I couldn’t sit behind a computer and make sure things got done. Maintainers tried their best to help and sometimes compiled their own builds and uploaded them to the DU server but again, there was life.

We don’t run a business or a sweat shop for lack of a better word. Maintainers have lives, responsibilities and sometimes shit happens. Some users sometimes don’t understand things like that and it makes for an ugly conversation.

Anyways, that should no longer be an issue. Things will be handle via Jenkins and users will start to see weeklies get pushed out on Mondays.

Weeklies can be found for each device here http://download.dirtyunicorns.com/files

If for any reason you run into any issues with a weekly, make sure you’re not using Xposed or using any 3rd party kernel and have done a full wipe prior to flashing the weekly. If you continue to see the issue, head over to our G+ community and create a post describing the issue as best as possible. Include what device, kernel, any mods and how we can duplicate the issue for troubleshooting purposes.

Thank you again for your continued support!

DU Team

Welcome!

We have been around a long time compare to most ROMs these days. Started by me, Alex Cruz aka Mazda on the HTC EVO 3D, this ROM has grown beyond just me and my laptop. With over 20 maintainers and many more contributors, we can honestly say we had no idea it would grow to what it is today.

Having been around for nearly 3 years, we have gain a lot of knowledge and have enjoy seeing things grow. Sites like XDA-developers have allow us to grow as quickly as we have and for that, we are thankful. Another great site that has allow us to not only share our work on but also communicate with our users unlike XDA is Google Plus. The interaction there is a bit more personal and allows users and developers to get to know each other, to see beyond the username.

With over 13K members in our Google Plus community and many more over at XDA-developers, we have a lot of users asking us different things from “can we get a change log” to “what do you guys think about….” and we try our best to answer those questions via the Google Plus community and the XDA forums but sometimes things get lost. Users start posting memes, bug reports and things start to go off topic and that important announcement or answer to something important may get lost and there’s little we can do to change that on those sites. We try our best to inform users with pinning posts and repeating ourselves time and time again but that sometimes isn’t enough.
Fortunately for you, we’re problem solvers and a bit hard headed and so refuse to just give up 🙂
Our website has now transformed itself into a blog and will now serve as a central location for all those things mentioned above. Change logs, download links, announcements and anything we feel that would be of use to you will be posted here.

As time goes by, we will take suggestions and add more elements to the website so if you don’t see something now, just let us know either via the comments here or via social media or XDA and we will go from there.

Thank you all for your continued support,

DU Team

(credit to http://stagmaworld.com/ for featured image)