Support for Android O

[fennifith]

Currently, Android O doesn't allow overlays to display on top of the status bar, regardless of the target SDK. It doesn't seem like the Android devs are planning on changing this anytime soon. If I can find a workaround, I will implement it. Otherwise, it would be more productive to work on a rooted version of Status for users on Android O. The only problem here is efficiency - Status as a concept only makes sense if you consider that it is meant to work without root access :P

[fennifith]

Currently I've set the maxSdkLevel to 25 to prevent users on Android O from installing it (since it won't work) :P

[fennifith]

Posting links to some more detailed explanations of the issue for documentation purposes:

• Google Issue Tracker
• G+ Post
• XDA
• Reddit
• Android Police

[0x7067]

Hi, did you have any luck finding a method that works on Oreo? I also work on an app that needs to draw over the status bar and couldn't find a solution yet. Thanks.

[fennifith]

@0x7067 as stated in the AP article and other posts, it is not likely that there will be a solution to this issue as it is the intended behavior of Android O and there is not meant to be a workaround.

[tnyeanderson]

It is a huge stretch, but is there a way to draw over the top of the screen if immersive mode is set to hide the status bar? I have SystemUI Tuner and I can set it to hide the status bar, and if Status could find a way to draw at the top of the screen without the status bar itself being there, it could make a thinner status bar at the top of the screen, maybe with flatter icons. I'm just spitballing here, I hate the icons on my LG V30 and anything would be better that that!

[fennifith]

@tnyeanderson you could do that, but the top of all your apps would be cut off by it, since there would be no way to change the window insets to accommodate status afterwards.

Another way would be: Since Status can still display things underneath the original status bar (underneath the icons, but above the "color layer"), you might have a bit of luck disabling all the icons you can through SystemUI Tuner and disabling the ones you can't in Status, then changing the side margins / alignment until they don't overlap each other. I believe you could also make Status's background transparent (there's a toggle I added near the bottom of the settings menu a while ago to do this), since you would no longer need any of the color detecting functionality.

[tnyeanderson]

@TheAndroidMaster Wow, that's an awesome idea! I'm going to give it a shot and I'll post here after some research. Hopefully that can be a viable workaround!

[fennifith]

@tnyeanderson heads up, if you're planning to compile from source to remove the maxSdkLevel, you'll want to do so from commit a3e3ad8, as everything after that is somewhat broken due to #111

[tnyeanderson]

@TheAndroidMaster I tried hiding all of the icons from the status bar, but Verizon puts a butt-ugly 4G LTE icon in the status bar that can't be detected or hidden by SystemUI Tuner. This makes "hiding all the icons" a little bit harder. Also, in the short amount of time that I was testing this, it was a little buggy (I think it crashed once and the notifications section had to be hidden on Status and use the system status bar otherwise both would show). Is 3.7 stable to test this on? I still think an option could be a thinner, more simple status bar that could be drawn at the top of apps while immersive mode hides the system status bar. Is there a way to determine, when in immersive mode, if an app is trying to display or hide the status bar? If so, Status could hide its flat status bar when a fullscreen app is in use. It is truly a shame that Android decided to intentionally deprecate this functionality when so many apps use it. Is there any place to give feedback and suggestions to Android to bring this back?

[fennifith]

@tnyeanderson the only real place for "Android feedback" is their issue tracker (I think there's a link in one of the linked articles), in which an issue has already been created (marked as intentional, and nothing had changed since), so I don't think there's much anyone can do.

As for the stability issues, much of them are a result of the app being somewhat disorganized and mostly undocumented, as a result methods are occasionally called without null checks in place, not accounting for all possible values, etc. I am partway through fixing this, which is why the latest source is unusable (hence my previous comment).

As for detecting whether an application wants to be full screen or not, it's pretty much impossible, since Status's current method is to create a second invisible overlay using a different flag that causes it to be bound by the application window (the entire screen, minus the navigation and status bars), then listen for changes in its bounds. If the view's height is changed by a value equivalent to the status bar height or a combination of the status and navigation bar heights, it shows or hides Status's status bar accordingly. It will also sometimes change those values directly from the Accessibility Service if it thinks the volume or notifications panels have been opened.