Author: Matthias

OnScreenClock v0.7.0

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

Klara Live for Android TV

Do you recognize this feeling:

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
  • Maybe: show current song metadata

K.I.S.S ftw!

OnscreenClock v0.5.0k and ADBoverEthernet v0.8.6

a few weeks ago, ADBoverEthernet was removed from the Google Play store due to a payments policy violation. As you may know, only Google is allowed to make profit off your app, so you may not provide alternative ways of payment within the app. Since my app only provides Google’s In-App payment and still got removed, apparently it’s also not allowed to even mention other possibilities. I removed the mention of my paypal and link to my donation page on this blog. So everything should be good now. 🙂 I also updated the OnScreenClock app as it shares the donation code with ADBoverEthernet.

It took me a few iterations to get the new apps released as Google forces you to upgrade the target sdk to at least 26 (= Oreo) these days. With this upgrade comes extra limitations on background processes. ADBoverEthernet used a service to launch shell commands. I changed that to use the new WorkManager api.

Changelog

ADB over ethernet v0.8.6 2019-04-24

  • show app version
  • make output window scrollable (in case of exceptions)
  • fix NPE crash when back button is pressed before webview is fully loaded
  • fix crash opening website on TV device that does not advertise itself as TV
  • store compliance
  • fix NPE’s when user revokes overlay permission while configuring the clock

OnScreenClock v0.5.0k 2019-04-18

  • trying to fix overlay permission trouble
  • bumped min sdk version from 15 -> 16
  • bumped target sdk version from 23 -> 26
  • fix crash on Android Oreo and higher when launching clock service at boot time
  • fix NPE’s when user revokes overlay permission while configuring the clock
  • fix admob crash

OnScreenClock: permission problem

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)

Quick KDE KWin hack: Ignore global shortcuts except alt-tab

From time to time a pet peeve can reach a critical level of annoyance at which it starts to irritate. You google it, hoping to find a solution or at least some allies, but if none turns up and you’re out of time, you simply give up and hope a solution will magically manifest itself one other day. But what if that day never comes? Luckily for us, open source enthousiasts, we can do something about it ourselves 🙂

Context

I’m quite an avid shortcut user. Linux/KDE is an environment where this type of user feels right at home. Not only do most actions in a software have a shortcut, you can also define lots of system-wide or global shortcuts. Kwin, KDE’s window manager defines quite a few out of the box.

Problem

This is all fine and dandy until you want to use this cross-platform software which you got used to in a different environment (i.e. windows at work) and you want to start using it at home. When the application is not (KDE) shortcut friendly or you are so used to the windows keymap that it’s a pain to learn a new scheme, you start to feel frustrated. Learning a new shortcut scheme seems the best solution but this doesn’t work well when you have to maintain 2 shortcut schemes in your head, depending on your environment (home vs work, your computer at work versus a colleague’s computer).

A typical example here would be some IDE, for example Intellij IDEA. Although the IDE does provide a KDE keymap by now, I started using it ages ago when there simply was no alternative keymap (nor a community edition or even official linux version, I guess). Also, I used linux only occasionally back then. These shortcuts are hard-wired by now and it is already hard enough to keep in mind whether I’m using Intellij or Visual Studio.

Another possibility is that the application really needs that much shortcuts that it just can’t bother with the shortcuts which may or may not be defined by the environment or workspace. One example of such complex application is Blender. Try it out and you’ll see what I mean. 😉

KDE, being the configurable desktop environment, does offer some configuration settings. For each window, Kwin allows you to define rules which match certain windows / applications which creates a config. Using this config, you can configure special window attributes. One setting is to block all global shortcuts.

This allows you to use your favorite application with its favorite native shortcuts. Of course, most people use more than 1 application at the same time. However, since all global shortcuts are blocked, the alt+tab shortcut to switch windows is blocked too. Alt+tab is not a special shortcut to KDE, it simply is a shortcut that happens to be assigned globally to the “Walk through windows” action exposed by the KWin component to the System Settings. Lacking any window switching shortcut, you adapt and start using the mouse to switch applications. There are times you cope just fine. But there are other times it is just one thing too much that annoys you. 🙂

Solution

So how to fix this? Just like any other problem you have with an open source application: fetch the source, fix and build! 😉

Since I just wanted a quick fix (I thought, let’s check this out for 30 mins, which turned out to be a lot longer of course), I chose to patch the behavior of the “Ignore global shortcuts” setting to exclude the Alt+Tab shortcut (more precisely, the shortcut currently assigned to the “Walk through windows” action). I briefly investigated KWin’s scripting abilities but it turns out the required functionality is not exposed.

I will now document the process, which took place on opensuse leap 42.3. You may want to tune out now if you don’t care about the gritty tech details. 😉

Where is the source?

I thought it had to be kwin, right? So I checked out the source from github and started searching for “Ignore global shortcuts”. It turned out to just call something in kglobalaccel which is not part of kwin.

Getting my hands dirty, I first fired up a VM I had lying around in order not to f*ck up my currently running system. Next I installed Qt Creator to easily navigate the code. Also, never forget you have to checkout the tag for the version you are currently running! (can be a treasure hunt by itself)

Browsing the source, I finally find a possible tweaking point in the src/runtime/component.cpp -> deactivateShortcuts method. It disables all shortcuts when a window is entered which has a “Ignore global shortcuts” rule. So I simply added an exclusion for the “switch windows” action.

Building a patched rpm

Time to try it out! In order to build it, you will need to install its dependencies. On an rpm based system, the easiest way to go forward is to do a “sourceinstall” of the rpm in case. For that, we first have to know which rpm contains the affected shared object (.so file).

You can take different routes to pin point the rpm. I checked the CMakeLists.txt to see what the output targets were. When you build, you can also see the class pass by and check into which library it gets linked into. Using that .so file, you can find the rpm using “rpm -qf <.so>”

An alternative way would be to find a kde related rpm matching “global” and then checking its contents (using “rpm -q –filesbypkg <rpm>”) for the .so file.

Once you know the rpm, you can easily install all required build dependencies by issueing a zypper sourceinstall command: “zypper si <rpm>”

The hard part: logging

I wanted to add some debug output to see if I was looking at the right place in the source base and how frequently the code got called. Now things got messy. You’d think patching the code was the hard part, guess what.. 😉

I had played with logging before in KDE, but of course things have changed with KDE 5. Nowadays, KDE uses Qt’s default logging mechanism. It meant figuring out the logging category used by kglobalaccel and finding a way to activate it. The logging category was nicely tucked away in logging_p.h: “kglobalaccel-runtime”. Activating it seemed to be trickier. According to the Qt documentation, you can alter the log level through an env var QT_LOGGING_RULES. Since I was adapting a core component, I needed to set the env var before logging in. On opensuse you can create a file /etc/profile.local which gets sourced by /etc/profile.

I added the env var and it seemed to work (=showed up), unfortunately still no logging. More precisely, nothing showed up in ~/.xsession-errors-:0. I started adding log statements all over the place, analysing the .so file to check whether my modified method was actually included in it (readelf -Ws libKF5GlobalAccelPrivate.so.5.32.0  | grep deactivate), etc.. Until I realised I didn’t check the journal (journalctl -b -0) yet, there it was. 🙂 Bonus points: the code change had its intended effect!

End result

So there I had it, a working patch WITH logging ⇒ pure SATISFACTION 🙂

Feel free to share this satisfaction by downloading the .so and installing it in /usr/lib64 (use at own risk). I’ve been using it for 2 months now without problems. It’s a good hack until a more fundamental solution is in place. First steps have been taken! 😉

OnScreenClock v0.5.0

Customizable colors

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

OnScreenClock v0.4.1

This is a small update before the big changes come in 😉

I noticed sometimes the clock disappears due to high system load. Normally, the android system automatically relaunches the service afterwards, but sometimes this does not seem to happen. I’m not sure what’s the cause, but I added a trigger: when the service is destroyed by the system, it sends out a broadcast event just before dying to restart the service. Not sure if it will help..

v0.4.1 2017-11-30
=================
* try restarting service when it is killed by the system to free resources
* fix NPE crash when back button is pressed before webview is fully loaded

Get it on Google Play

ADB over Ethernet v0.8.3

So I finally managed to release a new version of the ADBoverEthernet app. I noticed the ip detection stopped working on Marshmallow and higher. Rather than using command-line script-fu, I now use the official android api’s to query network interfaces and stuff. 🙂 I don’t recall why I didn’t use those in the first place, but in its current state, it definitely seems to work on all tested devices.

A nice-to-have is the new “autostart” feature. Check the box to enable the ethernet adb at boot time. This also explains the new permission RECEIVE_BOOT_COMPLETED.

v0.8.3  2017-04-28 
================== 
+ autostart at boot option (requires NEW permission RECEIVE_BOOT_COMPLETED) 
* use better ip detection logic (fixes ip detection on marshmallow and higher) 
* fix NPE when root access is denied

OnScreenClock: back to 1 app

When google released Android Marshmallow, they introduced a new permission model. I jumped on the band wagon too eagerly and as a result, the OnScreenClock app had become unusable on Marshmallow and up due to an unimplemented feature on Android TV. Complaining to google did not help.

So I did the only thing I could do: release a new app targeting an older api. This app is known as “OnScreenClock Marshmallow” (a bit of a paradox, i know 😉 ). Recently, however, just when I was about to migrate all users of the old app to the new one, I discovered Google has relaxed their policy, so now the “old” app is good to go again! I guess it was causing too much trouble for users everywhere.. This is undocumented so I guess Google wants to keep that change low profile. 😉 This also means the future is uncertain, but that’s life, right?

To all users using the “OnScreenClock Marshmallow” app, please migrate to the “OnScreenClock” app as I will not be further developing the “OnScreenClock Marshmallow” app anymore.

Apologies for the inconvience.