Soooo.. it’s been a while and although a lot of work was put into this new release, from an end-user point of view, this is merely just another “maintenance release”.
What happened?
You may know it is not easy to build apps that display stuff on top of everything, even if it is for a good reason. I tried to fix it, work around it, but I officially give up. Google is not bringing back the overlay permission. Nevertheless, using developer tools it is still possible, albeit totally user unfriendly. In theory, there is still another loop hole left, using accessibility features, but it’s only a matter of time before your app gets delisted.
Which segued nicely to the next cause of delay: the app got delisted because google does not like me linking to a donation page from the app. You would think removing this link is a small change. Android development is a moving target, so no, nothing is “simple”. 😉 Releasing a new version often requires updating other parts of the app because of google increasing the minimum android version constraint. In this case, there were so many changes (also in ads, support libs, etc), even for a little app, it was a nightmare. Anyway, after a few beta releases, it got sorted out.
In the meanwhile, I was trying to fix the overlay permission problem: my strategy ranged from asking nice to google, to implementing workarounds, to creating a companion app, to decompiling other apps.. Today, I decided I have to accept there is no acceptable solution and just provide technical documentation on how to give the permission using a developer tool which, by definition, is user unfriendly. It is a sad solution, but better than nothing! Apologies for taking 3 years to come to this conclusion. 🙂
The documentation link will show up as a QR code when you encounter the permission problem. You can also open it from within the app. Later on I hope to have an instruction video. Lastly, for rooted devices, you can simply press the button and it solves the problem magically. 😉
What’s next?
Over the years, I collected quite some feature request. More recently, it seems TCL has released some TV sets which do not properly redraw the clock. It seems to be a bug but I will see what I can do there. I provided a tweak flag in the settings to try out certain workarounds. Let the experimenting begin! 😉
v0.7.0 2021-01-29
=================
+ overlay permission: QR code to guide on how to grant the permission
+ overlay permission: on rooted devices you can now grant the permission with the simple press of a button
* preview color before accepting
* fix crash opening website on TV device that does not advertise itself as TV
* fix crash on some devices when moving/resizing the clock
* changing 12/24 hour format, notify state change no longer requires clockview recreation
* cleanup pref change code and prevent clockview NPE
* workaround pref: TCL devices
* admob upgrade
+ firebase analytics (can be disabled)
* bumped min SDK level to 17 (Jelly Bean 4.2.x)
* target android sdk 30
technology is there to help you, and in theory it can do lots of cool stuff to make your life more comfortable, yet it only seems to cause more frustation.
Yesterday I felt exactly in this spot 🙂 Let me paint some context.
A few years ago I moved into a new place and didn’t immediately find a spot for my radio. I bought this radio when I was 14 years old with just about all my savings. You have to imagine: a cool radio in that era had to be bulky and excessive wrt tweaking nobs and bass sounds etc. Problem with this is that it consumes quite some valuable living room space. Even more, in the last few years I didn’t often listen anymore to air-broadcasted radio. Nowadays it’s all about on-demand internet streaming, right? 😉 But I also listened less and less to radio channels in general. There is one exception though: I turned into a loyal Klara listener. (Tastes can change!) You can hardly call it a “classical” radio station though 😉 There’s no screaming at you or ads interrupting every 10 mins.. Very peaceful indeed. Anyway..
Without a physical radio in my living room, the ideal workflow to start listening is as follows:
Open radio app on my tablet
Cast to TV
However, the real-world workflow is more like this:
Turn on my android tablet. Wait up until 1 minute until it has “warmed up”. This has everything to do with Android becoming so bloated Google had to introduce the Doze feature which basically makes your device useless unless under active use (read that again 😉 ). This guy summarizes the Doze matter quite nicely.
Open my radio app (good app unless you use Android Pie)
Wait for the ad to materialize, otherwise playback stops. Same goes for syncing of mail accounts which kicks off due to awesome Doze feature.
Open the desired radio channel and press play button
Wait for the stream to start playing.
Google cast the stream to my Android TV (Nexus Player connected to “regular” smart tv)
Wait for my tv to automatically turn on using HDMI CEC.
Check whether the android TV responds to the cast call. Several possibilities here:
the TV fails to turn on -> turn on manually
the TV turned on but forgot why (cast does not start)
Realize it is broken again, and cast again from the tablet.
You see it’s working now and starting doing other stuff, only to realize a few minutes that the stream stopped! This can be anything: from the tablet sync somehow interfering in the playback on the TV to internet connection problems to the TV restarting services (but not resuming) because it deems it needs more memory.
Although my television has sub par sound quality, it highly exceeds the fidelity of my tablet or phone. 😉 It does however consume quite some power: ~120W (off the top of my head). Luckily I can fix this with a few extra button presses. So the final steps in the workflow are:
use TV remote to open menu (where you can configure brightness etc)
go into first menu “Picture”
navigate to bottom of list (luckily you can go up to end up at the bottom)
select “Picture off” and press OK
Only consumes about 20W then, which seems acceptable to me.
Conclusion: while listening to the radio should be only a few clicks/touches away, it literally takes minutes to set up.
Mind you, this is only turning on, not turning off! You might think: is that even a thing? You just “turn it off”? That would be to easy in today’s technologically advanced world!
Option 1: turn off the TV. Simple right? Problem is that does not stop the audio stream. Since I still live in a country where bandwidth is not unlimited, this is not an option.
Option 2: use android tv remote to exit cast (press home button a few times), then turn off TV. Problem is: sometimes the tablet will think the TV temporarily went missing and will start the cast again. (without you knowing, because you turned off the TV 😉 )
Option 3: the solution is to disconnect the cast on the tablet (sometimes it lost connection to the TV by itself) and then proceed with option 2. To be fair: successfully disconnecting the cast should stop the cast on the receiver (TV) too, so it saves time in option 2. However, disconnecting is cumbersome, it is not the same as simply pressing the stop icon in the notification (which merely pauses the cast on the receiving device)!
Anyway, this is a (quite elaborate) rant on why casting sucks. I feel sorry for ranting so much but after all, it is the tag line of this blog! 😛 So now, let’s cut to the chase!
Yesterday morning (when you don’t have much time), I was exactly in that spot again and decided to do something about it. First I checked my app updates (android TV updates when it feels like updating). Lo and behold: there was a google cast update! For a minute there, I had hope. I installed the update and checked: nah, although the changelog told me “bugs were fixed”, of course, not this bug. 😉
Reducing the number of dependencies seems the obvious solution: the less components are involved, the less can go wrong! In this case a native Android TV radio app could ease the pain but neither general radio apps nor specific Klara apps are available. In a peak moment of frustration I thought to myself: I will create an app this evening myself! Of course I’ve had this thought before, but anyone who has created an app knows that the effort can highly exceed the enjoyment, especially when you decide to share your app with the rest of the world because you feel any good compassionate person would do that.
But this app seemed so simple I thought: it can’t go wrong. 😉 In any case, I’ll keep it to myself until I feel it can more or less defend itself against the judgemental tsunami the internet can be.
Though, without further ado, here is a small demo.
It’s so basic I almost feel embarressed about it. 😉
The plan is to make a fast minimalistic app:
Only live stream (+ continuo maybe later)
Only foreground. You can stop playback by exiting the app.
Temporary pause (for a few seconds): answer a phone call and resume the radio where you left off
Several users have brought to my attention that the clock app no longer works after a device factory reset due to a permission problem. The dreaded message appears:
Unfortunately, your device’s rom does not support a user interface for granting the overlay permission :/
These are my findings so far:
Not brand or model specific problem When I received the first report, I uninstalled the app on my Nexus Player (Oreo) and reinstalled it and guess what: same problem. In the meantime I received reports on Sony TV and Nvidia Shield TV.
Android TV Marshmallow and higher
Yes, all trouble started with Marshmallow. 😉 I received reports on Nougat and Oreo and tested the app also on a Nexus 7 tablet (KitKat) and Pie phone. Unsurprisingly on KitKat no problem since no permissions exist yet, on Pie my phone showed a permission dialog to grant the permission (which is good, but still abnormal).
Unfortunately, I have not encountered an Android TV rom yet which provides a user interface for granting the overlay permission (it’s not in stock android TV and none of the vendors seem to care).
Fresh installs All reports were due to device resets, but as I already pointed out: simply uninstalling and reinstalling the clock app will exhibit the problem. Updating the app is no problem since it will preserve the previously granted permission. By taking advantage of this, I can test out a fix without impacting existing users.
I did a quick search on the interwebs but no luck so far, it’s kind of a niche topic after all. 😉 I suspect a google Play Services or Play store update is the culprit but didn’t find any news yet. If it’s part of a security fix, information will be sparse anyhow.
I see several options:
google did a small fuckup in the play services or store (as they did with the remote not responding, deep sleeping) and might fix it (can take several months)
google intentionally changed the way the overlay permission is granted (and no longer wants to grant it automagically)
the permission not being granted anymore might be a side effect of some other policy change
Overlay permissions have always been tricky on android (tv), so let’s hope there is a solution possible.. (or a hack at least)
Yes, you read this well! The most requested feature is finally there, although I wouldn’t call it finished just yet. As of 0.5.0 you can configure the clock and outline color by selecting a color from a predefined palette. You might have noticed I’m not that savvy with colors (a lot complained about the default green color, or was it yellow? I blame the color blindness) so I wasn’t sure which colors to include in the preconfigured palette. I found some nice material design style colors but figured people probably don’t care about material design and would want to tweak the colors anyway. 🙂 So I simply configured the colors from a standard 12-color color wheel and added black and white. The idea is that in a future version, you will be able to select a color from the palette and then tweak it to your liking. At first I didn’t want to release without the tweaking functionality but since this feature has been delayed for so long, I realized it’s better to release, put already quite some people out of their eyestrain misery and bear the negative reviews bitching about the fixed palette. 😉
The reason it took so long is because I wasn’t sure how to provide a user-friendly user interface for selecting a color on a tv (using a D-pad). I now settled on the fixed palette and found peace with it since I will be offering a fine-tune option later on.
So with the big fancy feature out of the way, what else is new?
Better gamepad support
As a Nexus Player user, I was harassed by this nasty bug Google rolled out a few weeks ago which causes the remote to go to sleep at the worst possible moments, i.e. when you’re using it. 😉 It’s really frustrating when you’re trying to watch tv, but it’s even more frustrating when you’re developing an app. 😉 I tried using an emulator but my pc hardware is officially unsupported now by google’s emulator (missing some instructions). It’s time to replace this 8 year old rig, it served me well.. Anyway, I’m digressing.
As a replacement for the bluetooth LE remote, I started using a Logitech gamepad. Unfortunately, it turned out to not emit DPAD_CENTER events required for adjusting size and position. From now on, gamepads should work just as well (use the “A” button to press “enter”).
Positioning the clock
While I was at it, I added a notice about keeping the button pressed to reposition the clock faster. It seems some people have trouble moving the clock around and complain having to move it a pixel at a time. The input dialogs for repositioning and scaling the clock were originally stubs for a nicer UI but as a lot of things, it just stayed.. Might improve in some future version.
Android 4.0.3+ required
The original plan was to have the clock run on as many devices as possible (also smart phones). So for a long time, the min api level was 10 (Gingerbread or 2.3.3+). I remember having a gingerbread device and often being annoyed by developers bumping the android version too early, effectively abandoning me from a functioning app (due to backend changes). I looked at the app stats and it turns out there are only 3 users below 4.0.3. I apologize, but no new version anymore for them. The bump is due to support lib requirements.
Changelog
+ customize clock and outline color
* fix pressing buttons with gamepad
* size and position pref: hint about keeping the button pressed to go faster
* min api level bumped from 10 to 15 (4.0.3) due to support lib requirement
* renamed main activity title because Oreo shows it in the launcher
I recently upgraded my Nexus Player to Marshmallow and guess what, the OnScreenClock app crashed. No big deal, I thought, let’s “just” fix this by properly requesting the overlay permission using the new permission system. Reading up on the topic, I learned there are 2 types of permissions: normal and dangerous permissions. Dangerous permissions need explicit permission from the user while normal permissions are automatically granted by the system. However, a small info panel (like for tidbits) in the documentation grabbed my attention, stating (parafrased): “oh, and btw, you also have some special permissions”. So actually there are 3 kinds of permissions! Why not say that up-front 😉
Anyway, you might have guessed, the OSD clock app uses a special permission called SYSTEM_ALERT_WINDOW which allows it to create windows that draw on top of anything else. You might think (as I did at first): no problem, let’s just ask the user for this OVERLAY permission. This is a nice idea in theory, and it actually works on your average Marshmallow phone. Android TV would not be Android TV if they did not add something extra to the challenge. Indeed, all Marshmallow Android TV roms that I have encountered (to be honest, so far only Nexus Player and Nvidia Shield, there are not much more at the moment), do NOT provide a GUI for allowing the user to allow the app this permission. They do have a gui for dangerous permissions but not for “special” permissions! I guess we finally know now what makes them special. 😉 A bug has been reported (originally for Android Wear which suffers the same problem) but no response from google.
So yeah, in case of my OSD clock app: no permission = no app. But wait, no problem, let’s just revert back to Lollipop target sdk and everything’s fine like Marshmallow never happened, right? Well, except if you already published a version of your app targeted for Marshmallow. In that case, you are not allowed by Google’s Play store to downgrade your target SDK. That’s really too bad.
That’s why I had no other choice than to create a new app with a similar name and update the current app to show a deprecation notice, inform the users of the new app and hope they understand what to do. So, goodbye nice reviews and stars, goodbye established user-base… Congratulations Google, you win.
Disclaimer: please don’t take this post too serious as I wrote it on a ranting spree, failing to keep consistence or structural coherence, using hyperboles to keep you entertained. You’ve been warned 😛 As with many funny things, there’s some truth in there though 😉
About a year ago, I bought an Android TV device: Nexus Player. That fact alone I could talk about for an hour, but let’s stay on-topic. 😉 Being introduced to Netflix and the concept of binge-watching, I had to protect myself from wasting all my time. Although I never used a clock on my tv before, its existence and use now became blatantly obvious to me. Unfortunately, neither my tv set nor the nexus player/android tv provide this! Android TV apps were (and still are) scarce so I took on the burden of the app dev and decided to try it myself, can’t be too difficult, riiight? 😉
After having taken the standard android and android tv specific hurdles, I quite quickly had something running that worked sufficiently for me. But what about “all” these other android Tv users? Being the empatic man I am, I put it on the app store, hoping to help others. As most often is the case, it turns out every user has different needs 😉 People want to use it on tablets, phones,.. So it had to become the super OSD clock app! Of course.
The requirements were boldly defined:
Show a clock
Be available on all android devices, from api level 10 (gingerbread) and up
Provide easy positioning with predefined anchors for each corner
Configurable font size
Optional background to make the clock readable on all surfaces
Configurable color (everybody likes colors, no?)
Android TV specific UI’s (leanback interfaces). The Nexus Player comes with a D-pad remote. All user interfaces should be as intuitive as possible using the D-pad.
Choose between digital or analog clock.
One year later, I can safely say that any of these features turned out to be much more complicated than anticipated. 🙂
1. Show a clock
Sounds simple, right? The problem is, it’s not just a clock. It should be an on-screen clock, meaning: on top of EVERYTHING at ANY TIME. I wasn’t sure if it was possible on Android. When I found out how to do it, I wasn’t sure it would work on Android TV (didn’t at first). But with some perseverance, the hurdle was taken. After that first achievement, I celebrated for a few months (ie I was lazy, development stalled and I preferred to binge-watch instead ;)). Picking it up again, I realized the journey had just begun.
2. Be available on all android devices, from api level 10 (gingerbread) and up
If you ever tried making an app that works well on every device from api level 10 to 23, you know this is no mean feat. I learned compatibility layers the hard way, thinking it would be easy. 😉 Tip: use compatibility lib from the start.
3. Provide easy positioning with predefined anchors for each corner
So it turns out there are tons of ways to define the available screen estate in android, what’s next… I want my clock in the upper right corner. Can’t everybody else offset from that one corner? On tablets you want to be able to drag the clock to position it? Of course, anything is possible. But I had to narrow the scope down to be able to release. Instead of providing touch on tablets and and a DPAD nav on android TV, I just put 4 simple buttons. It’s ugly but it does the job, for now. At least I made the button press repeatable so the user doesn’t have to click it like a crazy monkey (also, I felt like the standard NP remote wouldn’t survive it ;)).
4. Configurable font size
Here too, I had some nice ideas. Preview text of different size, seeing the right size instantly without having to increase/decrease until desired. But then I realized: if you can get a live preview of the clock position (no3), why not keep it consistent and provide a live preview of the size. Done. Wait.. configurable fonts? Naaaah
5. Optional background to make the clock readable on all surfaces
I thought I would make the clock more readable on light surfaces by putting it on a semi-transparent background. One day I implemented an outline instead and never looked back. It gives nice contrast and is nicely anti-aliased. It’s perfect, right? Of course not, read next.
6. Configurable color
If your app has colors, people want to customize that. I can’t really blame them for not liking my green on black clock. I’m color blind after all. 😉 The problem is, if I want to provide nice TV interfaces for my app, how does one choose a color using a TV remote? I’m still not entirely sure about that but I have a few ideas. Stay tuned.
7. Android TV specific UI’s (leanback interfaces)
I actually just explained the challenge in no6, I know bad article structure. But hey, I’m actually on a rant and just brain dumping 😛
If you want a TV app to be user friendly, you have to redefine its interface. There are several reasons why my attempts failed to this date.
a) Android TV dev was (is) in its infancy, so standard components are barely available and the compat lib only recently saw a release containing reusable preference items.
b) I had already so many hurdles to tackle, I thought: **** it, I’ll make a phone interface until the app is more functional and the UI is used only once anyway: just one time to configure the app! Nevertheless, it remains high on my todolist as a TV app should have a TV user interface, period.
8. Choose between digital or analog clock.
Aha, I kept the easiest one for last 🙂 Thinking about all the configuration options, I thought, the user should be able to choose the clock’s appearance, of course! Be it digital, analog, binary, what-have-you… I implemented an analog clock, and while I’ll admit it was fun, I doubt anyone uses it. 🙂 Development of the analog clock stalled (missing outline for example) in favor of more pressing features. Although, in the upcoming release, it kinda works..
This is only the high level overview of why it kept me so long from releasing this app. I stumbled upon all kinds of trouble from the service that was killed because android OS deemed it unactive to trying to obfuscate my publisher’s key.
On top of that, I complicated things by wanting to develop 2 apps in tandem AND reuse common code. Software development is all about reusable components, riiiiight? 😉 Unfortunately, up until recently I had absolutely no experience with either a) modular androids app or b) modularising code in git.
a) If you have never used gradle and maven before, you’re in for a treat. Try to keep it simple and you’ll get there 😉
b) I went from submodules to subtrees to strees. Enjoy this read, thank me later 😉
So yeah, this post is rather tongue-in-cheek and while touching some pain points, fails to offer clear solutions or solutions at all. That’s because this post is already long enough and I’m too tired to pump up the quality. Sorry if I lured anyone into reading this, hoping to learn something. You had been warned though 😛
So without further ado (queue drum roll), the one and only (literally!), on-screen display (OSD) clock, without ads (but with ads if you care about the developer), for Android TV ! (*cymbal*)
OnScreenClock OSD clock on Google Play store
Note: “Box art may deviate from actual in-app visuals.” 😉 The slick font is actually a residu of a dropped feature “configurable clock font”.
Main feature in this release is the widget! It reflects current login state and clicking on it opens the activity.. I also switched to using the AndroidHttpClient explicitly to allow proper resource cleanup although I’m not sure that won’t give any problems for pre-Froyo platform users..
Changelog
+ widget: shows login state, click on widget to open activity
+ activity: show last login time and ip
* service: correctly parse json response to allow proper logout
* service: moved logout action into service
* service: use AndroidHttpClient instead of HttpClient to avoid IllegalStateExceptions
* service: don’t attempt login on portal error
+ activity: initial localisation support
Changelog
– fc bugfix on portal connection failure
– fc bugfix: intent may be null on service restart
– log ip on successful logon (trying to find connection refused problem)
