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