Manifest merger is a wonderful thing in Android app development… usually.
It allows libraries to contribute elements and attributes automatically to
an app’s manifest, saving the app developer from adding those things
manually.
However, sometimes, it will not work in an intuitive fashion.
Such appears to have been the case for a developer, who posted
this Stack Overflow question,
outlining some curious symptoms. Despite having a <uses-permission> element
for WRITE_EXTERNAL_STORAGE, when he would request it at runtime, he would
never get it. In fact, if he did not also ask for READ_EXTERNAL_STORAGE,
Android would not even bother asking the user about the runtime permission.
This symptom – calling requestPermissions() and being rejected outright –
sometimes is caused by the user having clicked “Don’t ask again” for the permission.
However, it can also occur if your manifest lacks the <uses-permission> element…
but that did not appear to be the case here.
Until the developer checked the merged manifest.
Something – I assume a library – was adding android:maxSdkVersion="18"
to WRITE_EXTERNAL_STORAGE. Presumably, the library is writing to getExternalFilesDir()
and needs this permission on older devices, but not newer ones. However, the
app needed the permission for all versions, as the app is writing elsewhere
on external storage. maxSdkVersion causes the <uses-permission>
element to vanish, in effect, on newer devices. That’s why runtime permissions
were not working. Even though the app had the <uses-permission> element,
the library’s contributed maxSdkVersion negated it for newer devices.
The fix for the app developer was to add tools:remove="android:maxSdkVersion" to
that <uses-permission> element, to block the maxSdkVersion attribute and allow
the permission to be requested on all devices.
From the standpoint of the library author, though, this is a case of “being caught
between a rock and a hard place”. If you include maxSdkVersion, you correctly
advertise your library’s needs and you minimize the permissions that your library
contributes to the app. However, for dangerous permissions, it violates
the Principle of Least “WTF?”
for app developers using the library. If you do not include maxSdkVersion,
you cause fewer problems for app developers who need the permission all the time,
but you may wind up requiring the permission in cases where it is not needed.
My guess is that WRITE_EXTERNAL_STORAGE is the #1 permission for use with
maxSdkVersion. If your library requests this permission, think about whether
maxSdkVersion is appropriate for your use case… and then document your requirements.
In particular, if you use maxSdkVersion, make sure that your documentation
mentions this and prompts library users to add deal with this if their apps
require the permission for more API levels.
Developers using libraries should peer at the Merged Manifest tab of Android Studio
from time to time, to see what’s in there and tailor the results via tools:
attributes as needed.
With a bit two tons of luck,
we might get more information when this occurs in LogCat.
—Apr 09, 2018
Subscribers now have
access to an update to Exploring Android,
known as Version 0.2, in PDF, EPUB, and MOBI/Kindle formats. Just log into
your Warescription page and download
away, or set up an account and subscribe!
Exploring Android is a collection of tutorials, to build up an Android
app from scratch. Version 0.2 adds 10 more tutorials, for a total of 30.
These new tutorials:
-
Migrate the app to use a formal GUI architecture pattern, specifically
Model-View-Intent (MVI)
-
Persist the data we collect in the app to a SQLite database, using Room
The next update is tentatively slated for mid-May.
—Apr 02, 2018
Yesterday, Acer officially announced the first Chrome OS tablet,
the Acer Chromebook Tab 10. As with all newer Chrome OS devices, the Chromebook Tab 10
will run Android apps… perhaps including yours.
Many Android developers have been avoiding Chrome OS, arguing that it is a fairly
fringe audience. And it is true that Android-capable Chrome OS devices make up
perhaps 1% of the Android device ecosystem. However, by default, your app ships
to Chrome OS devices, and blocking such distribution is not necessarily
straightforward. Hence, you really need to consider adding Chrome OS to the
lineup of test environments that you exercise your app on, as while Android
on Chrome OS is a remarkable achievement, things are a bit different than what
you may be used to. If Google makes a renewed tablet push
using Chrome OS, the percentage of Chrome OS devices may climb a fair bit.
Some Android developers who embraced Chrome OS may have been thinking that
keyboards were always part of the Chrome OS experience. This tablet indicates
otherwise.
That’s why, on the whole, it is best not to think of particular devices, but rather
particular features:
-
Supporting keyboards is not a Chrome OS thing, as keyboards have been an option
before (Pixel C, various Bluetooth keyboards)
-
Supporting freeform multi-window is not a Chrome OS thing, as we also see them
with Samsung DeX (and perhaps future environments)
-
Assumptions that you might make regarding available hardware, such as GPS or
rear-facing cameras, are not tied to Chrome OS, but could vary on any sort
of device
In these cases, while a Chrome OS device is a great testbed for how your app
handles such things, you are not supporting Chrome OS by handling keyboards and
such — you are supporting Android, and Chrome OS happens to be an environment
for testing that support.
It remains to be seen whether Chrome OS will jump-start the tablet form factor with
respect to Android. However, this is another sign that Chrome OS is here to stay,
and Android developers really need to take it into account, since your app may
be running on Chrome OS devices right now.
—Mar 27, 2018
Subscribers now have
access to the latest release of The Busy Coder’s Guide to Android Development,
known as Version 8.11, in all formats. Just log into
your Warescription page and download
away, or set up an account and subscribe!
Principally, this update adds ~30 pages on Android P, based on Developer Preview 1.
This is a lot less than I was hoping for, because many things in Android P do
not work (e.g., HTTPS requirement, WebView tracing, directory access settings,
FOREGROUND_SERVICE permission) or are still very nascent (e.g., slices). Future
book updates will cover more of this, as these features stabilize.
Beyond Android P, this update:
-
Updates the chapter on Android Things for the DP7 release
-
Updates the chapter on ACRA to cover version 5.1.1
-
Updates many samples to use the Support Library edition of fragments,
in lieu of the native fragment implementation
-
Updates the chapter on the fused location api to cover
the newer API for getting location updates
-
Updates the Maps V2 samples to their newer API
-
Replaced all references to “Android Wear” with “Wear OS”, to reflect the
branding change
-
Removes three elaborate examples, with an eye towards moving them to
Android’s Architecture Components
(after a substantial rewrite):
-
the dynamic tab sample from the chapter on advanced RecyclerView techniques
-
the TinyTextEditor sample from the chapter on consuming documents
-
the document mode sample from the chapter on tasks
-
Removes the chapter on the percent library, which has been deprecated
and supplanted by ConstraintLayout
-
Removes the chapter on implementing a nav drawer, pending some future
rewrite
-
Fixes a variety of errata
If you’re wondering about the naming convention, this book will hit 9.0
sometime later this year, once Exploring Android
covers enough of Android. At that time, I will retire the EmPubLite series of tutorials
and start the 9.x numbering series.
The next update to this book depends a lot on what Google does. If I had to guess,
I will not update this book until shortly after Google I|O 2018. However, if
Google ships a substantial Developer Preview 2 in April, I may push out an update
to this book sooner.
—Mar 26, 2018
Late last year, Google mentioned that:
Future Android versions will also restrict apps that don’t target a recent API level and adversely impact performance or security.
Friday, Android Police pointed out
something that I had missed: apps with a targetSdkVersion below 17
will get a warning dialog when they are first run on an Android P device.
Plus, the documentation for that minimal-accepted targetSdkVersion
mentions:
Applications targeting lower values will fail to install and run.
Let’s assume that the JavaDocs are correct, and so the “restrict” from my first
quote above really means “ban”. So, for the developer previews, we just get
the warning dialog, but that the final version of Android P will block such
apps from being installed or run. This is on top of the Play Store’s already-scheduled
ban on new apps and updated apps that use older targetSdkVersion values.
Let’s talk about the ramifications of this, in the form of winners and losers.
Winner: Active Developers
Clearly, Google is trying to winnow out older apps, and that benefits
developers who are continually investing in their apps. For developers focused
on publicly-distributed apps in the Play Store, the primary driver for this will be the Play
Store ban, more so than the Android P ban. But, there are other ways of distributing
apps, and those channels may be limited more by an Android P ban.
Loser: Small Organizations
Historically, the vast majority of money for software purchases was not
spent on packaged software, but instead were for custom-developed pieces of software, usually in
support of some organization: a business, a government, a non-profit, etc.
Some of that custom development is now devoted to mobile, and those apps
are privately distributed by one means or another.
While many organizations are used to software obsolescence, they expect that to be
on fairly large time frames. I distinctly remember helping a firm in the early
2000’s keep a 16-year-old MS-DOS program running on Windows XP, for example.
The idea that a piece of software developed five years ago might stop running
because Google decided that it should stop running is not going to go over very well.
Larger organizations frequently are better equipped to try to do periodic maintenance on
apps to avoid such bans. Smaller organizations may lack the budget to
keep tinkering with an app just to make Google happy.
Winner: Web Developers
The solution is a fairly simple formula:
-
If you are willing to invest annually in an app, feel free to make Android apps
-
Otherwise, write a Web app
Web apps have their issues, to be certain. However, you are less dependent upon
Google infrastructure and Google decisions. For example, even if Google decides that Chrome
will no longer display Web pages written over five years ago, there are other
Web browsers.
Loser: Users
Probably I have fewer apps on my personal Android device than you do.
But some of the apps that I use might not run on Android P, such as the app
that I can use to track my blood pressure and the app that I use for its NYC subway
map. Are there alternatives? Sure. But I happen to be aware of this impending
change and might be able to migrate to some other app.
What happens to users if they get an upgrade to Android P, which then refuses
to run some of their installed apps?
If the ban is only imposed on newly-installed apps… what does that say about
the stated rationale for the ban (“adversely affect performance or security”)?
Do existing installed apps somehow not adversely affect performance or security,
where a fresh install of the same app would?
Winner: App Repackagers
I expect a cottage industry to arise where people will skills in decompiling
and recompiling Android apps start distributing versions of apps that have
their targetSdkVersion raised to a level that avoids these bans. Whether those
repackaged apps will work — and whether they contain malware —
remains to be seen. But, some people will want some of these older apps and will
be willing to turn to unconventional sources to get them.
Winner: Regulators
For anyone worried about Google’s power, these bans become yet another lever
to pull to try to convince regulatory bodies that Google’s behavior should
be curtailed. There will be a variety of aggrieved parties who can point out
how their organizations were harmed by these bans.
Loser: Google
These bans play right into the issues that
Steve Yegge outlined last week.
Google deciding to drop support for certain Android apps adds a risk factor to developing
Android apps in the first place. Avoiding these or future bans requires either abandoning
native development or ensuring that continuous native app maintenance is super cheap.
“Super cheap” is unlikely to be traditional Java-based development, or even
Kotlin-based development.
That, plus the regulation concerns, means that it is unclear how Google comes
out ahead from this. Yes, they will be able to retire some amount of legacy logic. Is
it worth it?
Alternative Scenarios
Perhaps all Android will do, at least for Android P, is show the “this app is
damn old” dialog, but will still allow the app to run — the behavior that we
see today in the developer preview. There is still risk
to Android app development that Google is introducing, but it will have less immediate impact,
since everything will still run as it had before.
Perhaps Android P will show that dialog, then treat the app as having a targetSdkVersion
of 17, even if the manifest declares something lower. This would allow the app
to try to run while stopping it from “adversely affect[ing] performance or security”.
Some apps might fare just fine. Others might fail spectacularly. But even if less
than 100% of the apps work, that is better than 0% of the apps working because Android P
refuses to run them.
Perhaps this is a “trial balloon” and Google will revert all of this before Android P
ships in final form.
This fall, we will know for certain what the shipping Android P will do and how
it compares to what we see today.
And if you’re reading this blog, probably you are an active developer, and
probably you are keeping your targetSdkVersion close to current, and so
probably neither of these bans will affect you directly. Unless you use Android
apps, in which case, you may have problems.
Which reminds me… perhaps I should hold off checking my blood pressure for a bit…
—Mar 20, 2018
