The CommonsBlog

Android Studio 3.5 Upgrade XML Reformatting Problems

If you upgrade Android Studio 3.4 to 3.5, you may run into a problem where reformatting an XML file (e.g., via Ctrl-Alt-L) reorders the XML elements in each level of the hierarchy. So, for example, you might have a <uses-permission> before <application> in your <manifest> element; reformatting would flip the order of those elements. It seems to be alphabetizing them.

For the manifest, this might almost be survivable. However, lots of things in Android are dependent upon XML element order, such as the children of a LinearLayout, the children of <menu>, the children of <layer-list>, and so on.

The original issue for this appears to be this one. It is marked as “fixed”, though that appears to be overly optimistic. A number of developers are running into the problem, filing other issues and asking Stack Overflow questions. I ran into it myself in my “daily driver” Android Studio setup.

Based on some experiments, the problem seems to be limited to upgraders. I cannot reproduce the effect with a fresh Android Studio 3.5 installation.

The simple fix is outlined in the aforementioned Stack Overflow question:

  • Go into the Settings screen (File > Settings, or Apple > Settings, depending on your OS)

  • Navigate into Editor > Code Style > XML

  • In the upper-right of that dialog, choose Set From > Predefined Style > Android

The real problem lies in the “Arrangement” tab in that XML code style screen. After an upgrade from 3.4 to 3.5, you wind up with arrangement rules like these:

Broken Android Studio 3.5 XML Arrangement Rules

There may be a more surgical fix that can be applied to those rules, editing each of them to limit them to attributes, but I have not tried this. Applying the Android predefined style replaces the buggy post-upgrade rules with valid rules:

Repaired Android Studio 3.5 XML Arrangement Rules

Because the problem lies with an upgrade, it might be tricky for Google to fix it with yet another upgrade to some future 3.5.1 version. With luck, they’ll find a solution.

Regardless, when you upgrade to Android Studio 3.5 from 3.4, double-check these arrangement rules and fix them if they appear broken.

Many thanks to Birju Vachhani for his writeup of the steps to fix the problem!

Aug 21, 2019

"Elements of Kotlin Coroutines Version 0.1 Released

Subscribers now have access to Version 0.1 of Elements of Kotlin Coroutines, in PDF, EPUB, and MOBI/Kindle formats. Just log into your Warescription page to download it, or set up an account and subscribe!

Originally, I thought that I would just have a chapter on basic coroutines in Elements of Kotlin. However, I quickly realized that to cover enough for Android app developers, I would need a lot more than just one chapter. Elements of Kotlin Coroutines is the result.

As with all my 0.x editions, this one is partially complete, with a number of placeholders for future chapters. However, it covers the basics of coroutines, including suspend functions and Flow. It also includes a “hands-on” appendix that walks you through converting a small RxJava-based app to use coroutines. And most of the samples are in the Klassbook, so you can run and modify them from the comfort of your favorite Web browser.

This book will get updated every month or two for a while, as I flesh out the remaining material.

Aug 19, 2019

Enabling Type Hints in Android Studio

Android Studio offers type hints for Kotlin code. Basically, the IDE adds “fake” type declarations where your code does not have them, for places where the compiler is inferring the type:

Type Hints in Android Studio

The types with the gray backgrounds (e.g., PackageInstaller) are added by the IDE. Other types (e.g., Uri) are really there in the typed-in code.

This can be handy for helping to ensure that your types are being inferred the way that you expect. They are also good for educational scenarios, such as conference presentations, to help make the implicit more explicit for people spending a limited amount of time in the code.

I got these by default with IntelliJ IDEA, and I wanted to enable them on Android Studio, particularly for tomorrow’s Android Summit workshop. This is possible, but you have to dig a bit in Settings to find them. Or, you can stumble across a helpful Stack Overflow answer.

In Settings > Editor > General > Appearance, you need to check “Show parameter name hints”:

Type Hints Setting in Android Studio

Then, click the adjacent “Configure…” button and choose Kotlin from the “Language” drop-down in the resulting dialog:

Kotlin Type Hints Configuration in Android Studio

The “Options” set of checkboxes are where you indicate the scenarios in which you want the type hints to show up. The large text field above those checkboxes are a blacklist, indicating situations where the IDE will skip the type hints, even if they otherwise would qualify based on your “Options” choices.

Aug 13, 2019

Harmony and Compatibility

Huawei’s rumored operating system is now less of a rumor and more of a reality. At the Huawei Developer Conference, they announced Harmony OS, to be used on the Honor Vision TV and perhaps the Honor Smart Screen. They indicated that they would continue to use Android on phones and tablets… but that is contingent on the current trade ban. As XDA Developers’ Mishaal Rahman noted:

Yet, this new OS is still “plan B” for the Chinese technology giant, since Huawei will need to solve the biggest hole in the adoption of Harmony OS: the app ecosystem. Huawei is building up its AppGallery platform as an alternative to the Google Play Store, and this week the company unveiled Huawei Mobile Services as an alternative to Google Play Services. Huawei is in the process of building its own ecosystem, and if the trade ban doesn’t lift by the end of this year or early next year, then Huawei will be forced to switch to Harmony OS for its new devices, including the upcoming Huawei Mate 30 series. In fact, Richard Yu confirmed that the Mate 30 did not receive certification to use Google Play Services before the trade ban was enacted, so Huawei is considering using Harmony OS on the device if the ban isn’t lifted in time.

Little of this shocks me. Even if the trade ban gets relaxed enough that Huawei can continue with Android internationally, I would expect them to start shipping Harmony OS devices within China as soon as they decide that it is practical.

However, there were some particularly interesting nuggets in XDA’s coverage of the announcement, with similarly-interesting follow-on effects.

Open Source?

From the XDA post:

Finally, Huawei announced its plans to open-source Harmony OS, establish an open-source foundation, and create an open-source community for collaboration.

Simply making an operating system open source is insufficient on its own to guarantee success. If it were, Ubuntu Phone and Firefox OS would be significant players. Unfortunately, neither “crossed the chasm”, in part due to lack of manufacturer and carrier support.

Huawei is a manufacturer, and their moves are likely to result in at least some measure of carrier support, at least within China. Hence, Harmony OS has a significant advantage over other attempts to compete with the Android/iOS duopoly.

If Harmony OS actually does wind up in a truly independent foundation, that would make it easier for other manufacturers to adopt it. On the other hand, it could be that the foundation is a pleasant fiction, much along the lines of how the Open Handset Alliance turned out. And, if you do not recognize the name “the Open Handset Alliance”… well, that’s not surprising. It is the closest thing that Android has had to a foundation for overseeing it. Needless to say, Android is very firmly in Google’s control, and it remains to be seen how Huawei handles Harmony OS in this regard.

App Compatibility?

From the XDA post:

Developers will be able to use Huawei’s ARK Compiler to compile code from multiple languages like C/C++, Java, and Kotlin for Harmony OS. Huawei will be providing an IDE to support app development across multiple device types, including televisions, car kits, smart speakers, smartphones, smartwatches, and more… Harmony OS is not compatible with Android apps out-of-the-box, confirms Richard Yu, CEO of Huawei Consumer Business Group. That means you won’t be able to merely side-load any Android app of your choosing. In a press conference, Mr. Yu says that app developers will have to make “small changes” to their apps in order to compile them to run on Harmony OS. He states that it is “very easy” to transfer Android apps to Harmony OS.

All of this information comes from media events, so we have to assume there is some amount of “spin” here. Certainly, if Harmony OS supports Java and Kotlin, it would be easier to migrate an Android app to Harmony OS than, say, iOS. However, “easy” is quite a high hurdle to reach in terms of the level of effort of app migration.

One way that it could be “easy” is if they take the approach that BlackBerry did with their early Android efforts. Before BlackBerry retired BlackBerry OS and moved to Android, they had an Android runtime for BlackBerry OS. Developers could use some tools to convert an Android APK into a different file (BAR), and a BAR could be distributed to a BlackBerry OS device. This approach failed for BlackBerry for several reasons, none of which would preclude Huawei from trying and perhaps succeeding. It might still require a fair amount of work to port an Android app to be a native Harmony OS app, though, if this is Huawei’s approach.

Another possibility for this being “easy” is if Huawei basically adopts the Android SDK. Basically, they would have their own SDK with the same class structure, perhaps with some cosmetic changes (e.g., you have to convert android. to harmony. in packages). I would be somewhat surprised if they went this route, as it ties them to Google and Android more than they might like. It also raises interesting parallels to the Oracle v. Google series of lawsuits, with Huawei in the role of Google.

Yet another possibility is some sort of a converter, that can take code that makes Android SDK calls and convert it to making Harmony OS SDK calls instead. That would be difficult to pull off, since it has to convert both app code and libraries. But the Jetifier (sorta) accomplished it for converting Android Support Library references to AndroidX ones, so I certainly cannot rule it out.

Regardless, we would need more details to be able to judge whether moving an app to Harmony OS will really be “easy”.

Ratcheting Interest?

However, Huawei does not need getting an app over to Harmony OS to be easy. It simply needs such a move to be compelling. Huawei sells more devices than does Apple. If Apple can convince developers to write apps for iOS, Huawei should be able to convince developers to write apps for Harmony OS.

The catch is that Apple already has a large installed base of iOS users. Huawei has zero users of Harmony OS today. And unless Huawei has better success than a lot of manufacturers have had with smart TVs and smart displays, they will still have relatively few users by the time that they start shipping Harmony OS phones. Huawei will only have success selling Harmony OS phones if there is a critical mass of apps for those devices.

However, once again, Huawei has an advantage: initially, they might not need the world’s apps. They might only need China’s apps. One imagines that they can broker deals with major Chinese app brands, and a good developer outreach program can help pull in apps from “the long tail” of the app distribution curve. If they can get a reasonable Chinese app catalog at the outset, success can breed success, with Harmony OS device sales convincing more Chinese developers to port their apps to Harmony OS, helping to improve sales of those devices, etc.

If Huawei is able to convert their existing domestic smartphone sales over to Harmony OS, non-Chinese developers already distributing to China would need to take notice and consider Harmony OS ports of their own. This could accelerate if Huawei is open enough with Harmony OS to convince some other manufacturers to adopt it. And it would accelerate if Huawei starts selling Harmony OS devices outside of China.

You will know when Huawei thinks that they have succeeded: when they start offering support for converting Harmony OS apps to Android, believing that there is enough “Harmony first” development going on to warrant that kind of support.

What Now?

If you write apps for Android TV, you might peek at the Honor Vision TV and Harmony OS, to see if there are any “first-mover” sorts of advantages that you can leverage.

For Chinese developers, pay very close attention to what Huawei does. Even if you do not plan on shipping an app for TVs, you might experiment with Harmony OS on a TV, just to get a better sense for what Harmony OS development is like. That will help you decide how to react if and when Huawei starts selling Harmony OS phones.

And, if you are a “bleeding edge” sort of developer anyway, Harmony OS represents an interesting opportunity, comparable to those poking at Google’s Fuchsia right now. Fuchsia advocates might scoff at that notion, and right now, Fuchsia is ahead simply by being publicly available, if not on shipping production hardware. However, I think that Huawei has an easier path to 250 million Harmony OS devices than Google does for getting to 250 million Fuchsia devices. Huawei already sells more devices than that, whereas Google would need to convince other manufacturers to distribute Fuchsia-powered devices. Huawei still has to execute, and there are any number of ways that Harmony OS could wind up being “a whole lot of nothing”. After all, Samsung’s Tizen was in a similar position and has not had much success with developers or mobile devices.

For everyone else… check back in 2020, and let’s see where Huawei and Harmony OS are.

Aug 10, 2019

Room and Flow!

At next week’s Android Summit, I will be leading a workshop, “From RxJava to Coroutines”. The idea is that we would take a small Retrofit-and-Room app and rewrite it to use coroutines rather than RxJava.

When writing the app, though, I realized that Room did not yet support channels or flows. The app relied upon Room’s invalidation tracking to deliver fresh results when the database changed. The only way that I could get a Flow was to have the DAO use Flowable, then use coroutines’ Reactive Streams support to convert the Flowable to a Flow. This worked, but it meant that I had leave RxJava in the app, to get the Flowable.

And so I prayed to Saint Yiğit that Room would get Flow support in time for the Summit.

Yesterday, my prayers were answered! Room 2.2.0-alpha02 advertised Flow support, and in light testing, it works as expected! So now your DAO can have stuff like:

@Query("SELECT * FROM observations ORDER BY timestamp DESC")
abstract fun loadFlow(): Flow<List<ObservationEntity>>

…and you can consume that Flow from within your favorite coroutine builder (e.g., launch()) or a suspend function.

Of course, not only is this Room version an alpha, but Flow itself is still in a release candidate state right now. Experimenting with this stuff is fine, but be careful about shipping production code using this. At least wait until the beta.

But, if you are “coroutines-curious” and are attending the Android Summit, come to my workshop, and I’ll show you how to nuke RxJava from orbit.

UPDATE: Many thanks to Dany Aguacate, who implemented the Flow support in Room!

Aug 08, 2019

Older Posts