It’s a common occurrence: users apply Substratum themes to their phones then later update Slack, WhatsApp, Instagram, or any number of other apps from the Play Store. Suddenly they can’t even open those apps until their theme overlays are disabled. Plenty of newer Substratum users have voiced their experiences with this issue ever since the release of rootless Substratum theming for Android Oreo.
Sometimes rebuilding the overlays in Substratum fixes the problem, but sometimes it won’t work until the theme developer updates the theme again. In the latter case, users are stuck having to use the affected apps in their unthemed, stock states. Needless to say, this can be a frustrating experience for many.
The problem is usually the result of a combination of factors: a poorly-coded third-party app, frequent updates to said apps that actually cause more problems than they fix, and limitations in the Overlay Manager Service (OMS) framework. I spoke with a couple of well-known themers who provided some valuable insights into the issue: Jeremy Beck, who makes the Spectrum Substratum theme, and David Wilson of Domination fame.
According to these Substratum stalwarts, some of the worst offenders in the realm of poorly-coded apps are among the most popular. WhatsApp, Instagram, Slack, Facebook and Telegram are examples that these Substratum themers cited to us when recounting this problem. In fact, David said they’re examples of “horribly, disgustingly, despicably coded” apps, which colorfully illustrates the frustration Substratum theme developers face when keeping their users happy as they try to unify their Android experiences around a common theme.
For example, a “despicably coded” app might tie the text color to the background color in its colors.xml file. If a themer changes the background color to no longer be white in this example, the text will also be changed and could be made harder (or even impossible) to read. Consequently, the themer will have to add their own layout xml files to their theme overlays to specify separate colors for text and background.
The caveat is that the new xml files have to also include every single character of code from the original app’s files of the same name so no functionality is lost. This is because OMS reads from the substitute, themer’s file while the app itself tries to do everything the original file allowed for. When the app is updated and even the slightest unrelated change is made to the original xml files, the overlays will fail to work.
Here’s how David explains it:
What these ridiculous “developers” (I use that term loosely when describing these clowns) do is they use items in layout xmls which make it hard for us to theme the app properly without adding those layout xmls into our overlay.
To give you an example, let’s take WhatsApp and look at an item in their /res/values/colors.xml which is <color name=”white”>#ffffffff</color>
They use @color/white for both text colours and background colours all throughout their app. This means that if a themer wants to change the colour of “white” to something dark to make their backgrounds dark, then it will make lots of text dark too which is very bad.
To work around that shortcoming, themers will add the layout xmls into their overlay and change either the text colour or the background colour or both from being something like android:background=”@color/white” to something like android:background=”@*android:color/background_dark” to make the background dark.
Now this is great and makes the background dark, but the layout xml needs to include everything in it that the original layout xml has which can vary from a few lines to over 100 lines. Within those lines of the layout xml can be lots of different resources which reside inside the app’s original code that get called on such as ids, dimens, strings, styles, etc etc.
Now herein lies the problem…. if a themer makes an overlay to suit WhatsApp 2.17.323 and WhatsApp updates to 2.17.351 (for example) then if WhatsApp in their infinite wisdom decide to change the name of say a string which was in the overlay made for 2.17.323 and that string doesn’t exist anymore in 2.17.351 then the overlay will not successfully build.
The same goes for anything within the overlay that is in any code that is calling on a resource that is within the app, if that particular resource was in the app that the overlay was designed for and then the app updates and the resource is no longer in the app’s code then the overlay will not compile.
This is just one example of the cat-and-mouse game of alternating app and theme updates that Substratum themers are faced with. When themers support a large number of third-party apps, they have to multiply this game several times over with each theme update. It’s a never-ending cycle of keeping up with multiple supported apps and hoping that frustrated users don’t rate their themes poorly between updates because Slack (for another example) pushed three updates to their app in the two weeks since the last update of their favorite Slack-supporting theme.
What can you do about it?
Personally, I usually wait for an update to my favorite themes before I update any apps I use that are themed. That said, not every themer has the time to constantly push updates to keep up with these app updates, so your mileage may vary. If you really can’t stand using an app in its unthemed state, then maybe waiting a few hours or days isn’t that big of a deal for you. If this is a deal breaker though, then perhaps you might wish to only theme system applications that are unlikely to change anytime soon (such as SystemUI or the Android Framework).
Just recognize that the problem isn’t because of Substratum itself or Substratum themes, and please don’t blame the theme developer when something goes wrong. This is the why theme engines on OEM flavors of Android such as EMUI, Samsung Experience, or LG UX don’t allow you to theme more than system apps and the system UI itself. To enjoy the level of customization that Substratum offers, the trade-off is that you might have to wait a short while to enjoy that latest app update.
from HIGH BROADCAST Tech http://tech.highbroadcast.com/2017/10/why-app-updates-sometimes-break.html
0 comments:
Objavi komentar