When we first started Dirty Unicorns nearly 4 years ago, we didn’t have to worry about translations. Our users back then were mainly English speaking and we had no complaints, life was simple.
A lot has changed since and today we have all types of users. From French to German to Polish, we have them all. The DU team has also changed and nearly 30 percent of the team speaks English as a second language.
That said, we have brought back Crowdin and is ready for all translators that are willing to help out 🙂
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…
We’ve enjoyed it and in DU fashion learned a thing or two from it. It has truly been fun reading all the comments on XDA, Google+, Telegram and even made it’s way to Twitter and the famous Reddit. We even managed to get an article about us leaving to work for some Russian company in the middle of no where.
Sorry Jeff, hope we didn’t get you in trouble but you know, we had to get our laughs hahaha
Several close friends also got reeled in and we enjoyed every second of it hahaha Whether they like to admit it or not, they did 🙂
People like Nate Benis of Pure Nexus, Brian Koluch (who the fuck is bdogg) of Resurrection Remix, our friends over at Evervolv and even the great Andrew Dodd of Omni ROM were quick to dismiss our prank because it really had some holes in it but after talking to them in hangouts, they too were a believer. Truly fun times! haha
What we did learn from our prank was that a lot of people had our back! Many users, themers and developers from around the community were quick to get in touch with us and offer help whether with hosting, maintaining devices or just give us advice as some had gone through similar situations. Some people we knew of and some were new faces but all were ready to do what they had to do to get us back on track! While it was fun to play this prank, it was also heart warming to know that people genuinely cared and wanted to help. To those people we would like to say THANK YOU and we are very honor to call you our friends!
Other side of the prank, we had some folks that saw this as a chance to kick us while we were supposedly down. They were too caught up in the moment to see that it was a joke and were gloating on social media, saying things that were clearly BS and claiming that it was “karma” that did this. We just laughed at that because it really takes some real bitchassness (Josh Chasky’s word) to say things when someone is down and not do it when we’re in the position to do something.
To those people we say FUCKKKKKKKKKKKKKK YOOOOOOOOUUUUUUU!!
When I started this project nearly 4 years ago it was not my intention to ever make any money off it. This is why from day 1 I had a policy to never accept nor ask for donations. This has work well and all members, former and active have always respected this policy.
That said, bills have to be paid. Student loans have to be paid and money does not grow on trees.
So it kills me to say that today we are losing several vital members of the team.
Randall Rushing, Anders Nielsen, Andrzej Ressel, Susan McCombs and James Taylor have all accepted offers to work on a new project for Russian based smartphone manufacturer Highscreen.
We all are very happy for them and wish them the absolute best in their new opportunities.
So what does this mean for us?
You will see things start to slow down as far as bug fixes until we can get some new talent added to the team. Some devices will be dropped as of right now to include the Angler and M8. Gerrit, JIRA, this website and many things that we’ve taken for some what granted will soon be shut down and we will have to regroup and find alternatives.
For right now, we are looking into using Android File Host or maybe Google Drive.
Last week we released our first builds based off Marshmallow and it felt pretty damn good! Not so much the hype or the onslaught of n00bs that followed but the fact that we can now focus on bigger things. Yes, this is not a one and done.
Those that have been here before the wagon got full, know that after every major release we kick off weeklies. Weeklies in the past were released every Monday unless otherwise posted. This time around, things will change a bit and they will be released on Friday’s.
Because it makes sense. End of the work week, you have more time to throw a few back, flash some builds and test features while providing feedback to us.
Be adviced that weeklies are not to be considered stable. Although 9/10 times they’re as stable as the official build, they may include code from time to time that does not make it into the next release. This is all part of the development process.
– Only devices with OFFICIAL XDA threads will receive weeklies
– DO NOT ask for us to include unofficial devices to the weeklies
You can download weeklies one of two ways, via our updater that all OFFICIAL builds include or via our download site.
If coming from the v10.0 release, you can dirty flash it on top of it by just wiping cache afterwards. Be advice that if you do experience any bugs, is recommended that you do a FULL WIPE to rule out any issues that may come from dirty flashing. Please provide logcats and useful information when reporting issues.
If coming from anything else, is recommended that you do a FULL WIPE. This means wiping everything but internal storage. If you’re coming from a ROM that includes Layers, is also recommended that you delete the ‘overlays’ folder. Please refer to the FAQ in our G+ community of any official XDA thread.
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.
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!
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:
– HTC Droid DNA (dlx)
– Nexus 6P (angler)
– Nexus 5X (bullhead)
– Moto X Pure (clark)
– Nvidia Shield K1 (shield tablet)
– Oppo R7 Plus
– 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
When Android M was released, many users fear that we would stop work on Lollipop and leave Lollipop AS IS.
To an extent that was true. We saw it fit to jump on the latest release as quickly as possible not because we wanted to be the first to release a build on XDA-developers (which we haven’t yet) but because it gave us a chance to evaluate things early. Given Google’s history with releases, we knew things were going to change and we wanted to get a jump on that. We were right and it was a cluster. We’ve learned a lot and we’re better for it now.
Many users reached out to us and asked if we would release a security update and we said yes. Fast forward a few weeks and here it is!
Keep in mind that this is the FINAL lollipop build from us. We will try our best to keep the Lollipop branch on github as updated as possible as far as security updates for those compiling personal builds but this is it. This means we’re not adding PIE or Halo or this or that….is done!! We’re moving on to M
XDA threads will be updated when the maintainer gets time.
The Manta thread probably won’t be updated til the maintainer gets back to us, whenever that is. He’s in the military so that definitely comes before some XDA thread, try to understand!
I would say that we will miss the AOSP browser but we would be lying to you.
When I first got into developing and compiling Android, the AOSP browser I think was at it’s prime. It was getting updates from Google and many hobbyists around the community were still contributing to it. Those days are long gone with no light at the end of the tunnel.
Those that keep up with AOSP know that Google has slowly started to abandon AOSP apps in favor of their closed source alteratives. These apps include Browser, Music, Gallery2 and Calendar. While we would love to continue in putting lipstick on a pig and “materialize” these apps for future versions of Android, it’s taken a lot of out of us. In the end, these apps look nice but they still lack functionality.
Many developers have simply removed these apps from their ROMs and that’s a choice that we considered and for a while, was a very likely option.
We’re happy to say that for the browser app within DU, that’s no longer an option.
Thanks to the efforts of Team EOS developer Anders Nielsen, we can rest easy in knowing that we’re not only replacing the AOSP browser but replacing it with an open source alterative. One that’s being actively developed and in turn, get better with time.
If you have not put the pieces together, we’re talking about Google’s Chromium!
In a lot of ways, that is correct. Google pulls a lot of their own code from Chromium to create Chrome.
Below is a small list of differences for those wondering
– Colorful logo
– User metrics are reported
– Video and Audio codecs (AAC, H.264, MP3, Opus, Theora, Vorbis, VP8, VP9, and WAV)
– Sandboxed PPAPI (non-free) Flash plugin included in release
– Code is tested by Chrome developers
– Sandbox is always on
– Single deb/rpm package
– Profile is kept in ~/.config/google-chrome
– Cache is kept in ~/.cache/google-chrome
– New releases are tested before being sent to users
– Google API keys are added by Google
– Sucks all the ram out of anything……is a black hole
– Blue logo
– User metrics are never reported
– Video and Audio codecs (Opus, Theora, Vorbis, VP8, VP9, and WAV by default)
– Supports NPAPI (unsandboxed) Flash plugins, including the one from Adobe in Chrome 34 and below
– Sandbox depends on the distribution
– Packaging depends on the distribution
– Profile is kept in ~/.config/chromium
– Cache is kept in ~/.cache/chromium
– Doesn’t suck as much….
You said it was open sourced, so why is it a prebuilt apk?
Those that have ever attempted the task of compiling Chromium from source know that is not something that you could compile inline with a ROM.
Syncing close to 14GB worth of source is a bit intimidating when you consider, this is just a freaking browser. Those that want to compile it from source are more then welcome but we chose not to and take the welcomed help from Team EOS.
In the coming weeks, don’t be surprised if we replace more of these abandon apps.
Again, thank you for your continued support and patience!
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!