The CommonsBlog
Random Musings on the Android 15 Developer Preview 1
Wow, it’s February again already?
When Google releases a new developer preview, I rummage through
the API differences report
the high-level overviews,
and even the release blog post,
to see if there are things that warrant more attention from
developers. I try to emphasize mainstream features that any developer
might reasonably use, along with things that may not
get quite as much attention, because they are buried in the JavaDocs.
Last year, a common complaint was how small Android 14 felt. This year, Android 14
seems huge by comparison. Android 15 DP1 is so small, Google did not bother writing
a high-level overview of the changes, or at least it has not been published in an obvious
location. Google usually does a bit of “sandbagging” in early developer previews,
preferring to talk about changes one release later than when they are introduced.
Still, this total lack of docs is rather stunning.
What Gives Me Security Concerns
AccessibilityService
has long been used for things other than accessibility. Google
tried for a while to enforce this at the Play Store level, but if I recall correctly
they backed off.
AccessibilityService
now offers the ability to attach overlays to displays
(and to windows).
These are designed for UI that controls the accessibility itself, apparently.
I worry a bit that users will enable accessibility for an app for other reasons (e.g.,
help with playing some game), then get bitten by tapjacking attacks initiated by these
overlays. Hopefully, these overlays have system-supplied “chrome” that helps prevent
this.
See also getOverlaySupport()
on Display
.
What Claims to Have Integrity
FileIntegrityManager
has been
around for a few years, but without a lot of functionality. Now we can call
setupFsVerity()
for a File
,
enabling some amount of tampering detection.
However, the documentation for applying it (in setupFsVerity()
) is seriously confusing.
What We Also Got In Android 14, Sorta
Android 14’s QPR2 added support for partial screen sharing,
powered by MediaProjection
. This change is also folded into Android 15 DP1.
What Else Is Interesting
PackageManager
offers parseAndroidManifest()
.
This is designed for APKs that perhaps have not yet been installed. You get an XmlResourceParser
back, letting you traverse the manifest akin to using XmlPullParser
.
SystemClock
now offers uptimeNanos()
, the time since last boot, measured in nanoseconds.
JobManager
, via JobInfo
, now offers debug tags
and trace tags
for help with logging and traces.
MediaRoute2Info
now supports a bunch of additional remote media routes: to cars, computers,
game consoles, other phones, watches, tablets, or docked tablets.
We can now create notifications that have TV extensions,
presumably for cases where a phone is tied to an Android TV device.
The parade of screen densities continues, as there is now support for a 390-dpi density.
—Feb 17, 2024
Security and Third-Party Transports
A couple of weeks ago, news broke that
governments might be spying on push messages
delivered through Apple’s push notification system or Google’s Firebase Cloud Messaging.
(hat tip to Prof. Matthew Green for raising awareness)
IMHO, governments are only part of the problem. Apple and Google can read your push messages.
While both firms claim that messages are encrypted, that is only for “data in motion”, as they
are sent over the Internet. Messages in their servers are unencrypted. Not only can they access
the data, but they can hand it to whoever they want to, not just governments.
While the current focus is on “Big Tech” push message systems, the problem is more general
than that. Any third-party data transport system has the same sort of problem. Services
like PubNub, Amazon SNS, Stream, and others that offer “publish/subscribe”
and similar sorts of message-based APIs are very useful, but generally their data is encrypted
in motion and not at rest. Those firms can see your messages, as can anyone that those
firms allow.
Roughly speaking, I see two main ways of addressing this.
The best is to not send anything of significance in the message itself. Use it as
a trigger mechanism only. So, the message might contain some sort of verb identifying
what it wants the app to do, but nothing else. The app would then use other communications
options (e.g., Web service calls) to do whatever it is the trigger is requesting. This
allows you to focus on securing those other communications options, and you care less
about spying on your messages.
The other is to encrypt your message payloads so that only the recipient can read them.
This can work, but key management is a pain as always. IMHO, use this approach only if
the messages do not require any other communications to be useful — if you are going
to have to make a Web service call anyway, there is little value in packing data into
the message itself.
Neither of these approaches help much with metadata. The message system providers (e.g., Google)
and their favored partners (e.g., governments) can still examine which apps are getting messages,
at what times and for what accounts (e.g., Google accounts). The
only way to avoid that is to avoid using a message system provider, such as hosting your
own messaging server. That has its own problems (e.g., background process limits in Android).
Using a push message system provider often is unavoidable. Letting them have your data is avoidable,
by encrypting that data or not having any meaningful data in the messages themselves.
—Dec 16, 2023
TV: Now What?
News broke recently that
Amazon might move Fire TV away from Android
and to their own in-house fork of Linux. TV app development would be done in React Native.
This really leaves TV Compose in the lurch. It will be used primarily for Android TV
(a small fraction of the streaming device space) and for an ever-shrinking number of
older Fire TV devices.
However, it further opens up an opportunity for some entrepreneur who wants to go after it.
App development for first-class TV devices will be highly fragmented now:
- Roku uses a proprietary language and UI toolkit
- Future Fire TV devices will use React Native
- Legacy Fire TV devices and Android TV use Android frameworks like TV Compose
- Apple TV uses macOS-style frameworks
- Samsung, LG, and some other TV manufacturers offer their own stores and platforms
Here, “first-class TV devices” means devices where the app is installed on the device.
Platforms like Chromecast, where the app is installed elsewhere, work substantially differently.
To me, this level of fragmentation, coupled with the nature of content-centric TV apps, suggests that
a server-defined UI approach might work well. The TV apps would be largely white-labeled
containers pointing to dedicated endpoints that serve the UI and the content viewed by
that UI. Part of that server-defined UI would be a “stylesheet” for branding elements
(color scheme, logos, etc.). The browsing and playback UI would be driven by a mix of
the available content and some general presentation patterns, with customization as desired
by the customer.
I am uncertain if Roku’s system will support this approach, as it is very proprietary
and reminds me of 1990’s Visual Basic as much as anything.
It used to be that Roku plus Android would be 80+% of the North American TV streaming
market. Eventually, that will become Roku plus React Native, as Amazon migrates to the
new OS. Perhaps some enterprising developers will come up with something interesting
to help bridge this gap and pick up the other smaller platforms as well.
—Nov 18, 2023
Testing the Limits of Anti-Competition
The latest Play Console restriction
is a testing gate:
developers with newly created personal Play Console accounts will soon be required to test their apps with at least 20 people for a minimum of two weeks before applying for access to production
This seems trivial to bypass — 20 sockpuppet accounts and
a test monkey
might suffice. One imagines that somebody will create an underground service for this.
But Google can enact policies like this without much concern, as there
is nowhere else for developers to go, by and large.
That’s why it will be interesting to see if Epic v. Google
will touch upon a key anti-competitive tactic: banning app distributors from the Play Store.
If your app’s principal job is to help people install apps, you are out of luck. Either
you need to be a device manufacturer (e.g., Samsung) who can pre-install a store, or
your potential users will need to sideload your store.
If this ban could be removed — by lawsuit or by legislation — there could be a
more concerted effort to offer the Play Store meaningful competition. Even if Google were to continue
with its policies, the competition would mean that there would be other useful avenues for
affected developers to use.
—Nov 11, 2023
The Omega and the Alpha
This is the seventh and final post in a series where I am revisiting CommonsWare, my long-time
business and current “hobby with a logo”. I thought it might be useful to some to
see how all that came about, the decisions I made, and so on.
The series:
As noted in the previous post,
I had a lot of success in the early years. Things might have peaked for me in 2014-15, when
I had the opportunity to train hundreds of developers at a device manufacturer that was
moving into Android… and then subsequently moved out of Android. 🤷
Perhaps that was foreshadowing, because by 2018, it was fairly obvious to me that CommonsWare
was “circling the drain”, and there wasn’t a thing I could do about it.
So, what happened?
As I noted earlier, I am not a marketer. CommonsWare’s marketing pretty much boiled down
to: be useful to a large audience and hope that you get enough
“true fans” to
keep the business afloat. This is not a bad approach when you can be “a big fish in a small pond”.
It does not work as well once the pond grows a lot, and in the case of Android, the pond grew
to be the size of the Pacific Ocean. Either you:
-
Find some shallow eddy in which you can still be a “big fish”, by focusing on some niche
while sticking with the same word-of-mouth marketing
-
Adopt other forms of marketing, or relationships with larger brands, that allow you to
deal better with a larger set of competitors
-
Drown
I drowned. I did not plan ahead for finding some smaller niche, and I did not have any clue
how to do anything else to keep CommonsWare at the forefront of developers’ minds.
By 2018, I started doing contract development work. I knew that the time I was working on contracts
was time that I was not investing in CommonsWare’s future. I did, though, elect to
declare “tech debt” on The Busy Coder’s Guide to Android Development and started in
on the second-generation books, such as
Elements of Android Jetpack
and
Exploring Android.
But I knew, even as I was writing those, that I didn’t have much of a prayer with the Warescription
model. I had too few subscribers and no clear plan for how to get more.
So, I did what a lot of people would do in that situation: I succumbed to depression.
Or, in the words of Britain’s greatest secret agent:
I lost my mojo.
In August 2019, through the efforts of Touchlab, I wound up
doing contract work with a company called MIRROR. They made a fitness mirror, one where
you can see the instructor and yourself while doing yoga, strength training, pilates, cardio work,
stretching, etc. At the outset, that was just another contract.
In early 2020, I cut that contract to part-time status. I had one last shot
at salvaging CommonsWare: dive into the niche of Jetpack Compose. I started
a Jetpack Compose newsletter and had plans for books and a lot of the things
you see others doing, such as an online catalog of composables and how to use them. My plan
was to keep MIRROR going on a part-time basis as long as practical, while using the time to build
up Compose expertise and content, in hopes of re-establishing myself.
But in June, MIRROR asked me to come back as a full-time contractor. I knew that if I did that,
I had no shot at saving CommonsWare. But, I was tired and depressed, and I felt like CommonsWare had
run its course. Plus, I really liked MIRROR, even after it was acquired by lululemon. So,
I returned to full-time contractor status. And, in late 2021, I joined up as a regular employee,
published the final edition of my books, and shut down CommonsWare.
2022 was a rough year for me emotionally. While I enjoyed the work with MIRROR, I was still
depressed over my “failure” with CommonsWare… ignoring the fact that having the business
survive that long and do as well as I did was a massive achievement. Few startups survive five
years, and fewer still make it past their first decade. I beat both of those. Few developers
will ever get the name recognition that I once had, and to a lesser extent perhaps still do.
Yet, I could only focus on the fact that I couldn’t sustain the business over the long haul.
Plus, being in my early 50s, I felt like being an entrepreneur was something I might never do again.
Which brings us to 2023.
Early this year, I was inspired, not once, but twice, to turn my life around.
I came to grips with my emotional state and got into therapy. I lost 25 pounds (hey,
those MIRROR workouts really do work!). I saw what I was missing
professionally due to my depression, and I finally got past the end of CommonsWare.
I once again saw the joy in what I could do, and I started feeling like the Mark
Murphy of old, for the first time in years. I started doing some “extracurricular” things to
try to help MIRROR (née lululemon Studio), and while those may not ever have an impact, I
felt good for trying to “move the needle” and make a substantial impact.
And now? I have plans for some more books. I am making no promises, but watch this space
for further developments.
I learned a lot during the CommonsWare years, about myself perhaps more than about
Android. For example, at times I was not very nice, and I will be forever chagrined
at aspects of my behavior. While it is a cliché to say that “I have become a better person”,
in my case I think it is true.
I am forever grateful to the Android developer community, from the experts to the newcomers,
for helping to grow Android to what it is today and to give me the opportunity to be useful.
I am thankful for my colleagues at MIRROR lululemon Studio
lululemon, for putting up with my foibles and letting me help along the way. And I will
be forever in debt to the person who inspired me twice this year to turn things around.
If I may be so bold to provide some advice, based on all of this:
-
Don’t be afraid to chase your entrepreneurial dreams. The likelihood of cataclysmic
failure is very low. The most likely form of “failure” is just to fizzle, and while it
will seem painful in the moment, you will be fine. The possibilities of success, and
the joy you will get from that success, are far more than worth the fizzle.
-
That said, if you start a business, do not only have a plan at the outset. Have a meta-plan
for how you will adapt your plan to changes in the marketplace, in your situation, etc.
Be in position to “take a step back” and look at your efforts with a clear and unbiased
eye. And don’t be afraid to change that plan… so long as you are not doing so on a whim
and without clarity for how those changes will help.
-
Introverts can be entrepreneurs. Ask me how I know.
-
Be kind, and find ways to be kinder tomorrow than you are today.
—Sep 09, 2023
Older Posts