Mark L. Murphy's Blog, page 8

Waiting for a Chasm-Crosser

This is the first of several posts where I am revisiting CommonsWare, my long-timebusiness and current ���hobby with a logo���. I thought it might be useful to some tosee how all that came about, the decisions I made, and so on.

Often times, when I explain my adventures as a self-styled independent developeradvocate for Android, I���m told ���you were really lucky to get in on Android so early!���And, that is true: I did benefit from some luck, and I will point one prominentinstance of that a few posts from now.

However, in entrepreneurship and many other facets of life, you make your own luck.

By 2007, I already had started and buried two businesses, one pathetic enough that itdoesn���t even make my LinkedIn profile. I was focused on identifyinga business model and an area to apply that to. I will get into the business model morein the next couple of posts. It turned out that I had been thinking about the area to applyit to for far longer than I had expected.

In 1995, I co-founded a firm named, at various times, The Sapphire Group and Firewater.We attempted to sell a Web application engine and IDE called PageBlazer.

(branding is hard)

In 1996, I stumbled upon a firm named Unwired Planet. They were partnering with AT&T Wirelesson cellphones that could connect to the Internet. While nowadays that is ridiculously common,back then the Internet itself was fairly new to most people, and we were happy if our cellphonescould reliably place voice calls. Unwired Planet createdthe Handheld Device Markup Language (HDML),which described stacks of cards, each designed around a few lines of text, and each supportingsoft buttons for navigation between cards. AT&T Wireless created a cellphone that could get tothe Internet via a gateway, hit a Web server that served HDML, and render the results. Effectively,Unwired Planet created a ���Web��� browser, just based around HDML instead of HTML, and designed aroundsimple text interfaces that supported the screen technology used by phones of that era.

I adapted PageBlazer to support HTML and HDML from a single set of source code, in hopesthat we could ride a mobile Internet wave. My business partner and I knew that one year, mobileInternet would become huge. 1996 was not that year. The phones��� battery life was best measuredin minutes and IIRC never hit the market.Unwired Planet���s HDML eventually formed the foundation of the Wireless Markup Languagethat in turn was part ofthe Wireless Application Protocol (WAP),which enjoyed modest success.

After that, I kept tabs on mobile communications technology, waitingfor something to show up that I felt would capture mainstream interest ������crossing the chasm��� in Geoffrey Moore���s terms.Many candidates popped up but never reached that sort of attention:

Two-way paging from Motorola and Research in Motion (a.k.a., BlackBerry) The Palm VII Handheld PCs many of which ran Windows CE Windows Mobile

Then, in January 2007, Steve Jobs debuted the iPhone.It was obvious to me at the time that the iPhone was going to be big��� but you couldn���treally write apps for it. They had some Web technology that could be used, but it never reallytook off.

Later in 2007, though, two announcements rocked my world:

In October, Steve Jobs announced that they would release a real honest-to-goodness SDK fordeveloping iPhone apps in early 2008

A month later, Google announced the formation ofthe Open Handset Alliance and shippedthe first preview release of Android

At this point, I knew, without a doubt, that one or both of those would ���cross the chasm���and become mainstream, and that I could build a business supporting one. But, which one?

I���ll get to that decision a few posts from now. But before that decision would be meaningful,I needed a business model. And before that would be meaningful, I needed to address a fundamentalproblem: I absolutely suck at marketing. How I planned to get past that will be the topic of the next post.

Text Will Not Always Scale

I have long been a fan of Android���s nudges towards using sp as units for text.This unit takes into account the font scale setting, so the visually impaired canhave your app display its text larger. However, it is 2023, and support for font scalingis far from universal. Developer nudges remain fine, but it is important to recognizethat text will not always scale based on font scale.

Pointy-Haired Bosses

It has been a decade since Android was predominantly a hobbyist OS. Nowadays, havingan Android app is typical, especially for major brands. Those apps are not just tossed togetherby some developers ��� rather, they are professionally designed and have scope/featuresapproved by executives.

In other words, developers are no longer ���calling the shots��� on whether or not font scalingwill be honored.

Instead, developers need to follow the designers��� directives and executive mandates. If thosedirectives and mandates include support for font scaling, great! If they do not,developers can advocate for font scaling. But, in the end, the directives and mandates needto be followed, or the developers will be replaced by other developers, ones who followinstructions.

Today, if advocates want font scaling, badgering developers about it is counter-productive.Advocates need to:

Convince designers to take font scaling into account

Convince executives to take font scaling into account and to adequate fund the designdepartment so they have the time to devote to having designs that can adapt to fontscale values

Google (and other app distribution channels) could try to enforce font scaling. Googleis doing that in 2023 for Wear OS.If they enforce it, some Wear OS apps will no longer be published, because the designerssimply are not in position to support it.

And Google is partly to blame for that.

Consistently Inconsistent

One thing that Google could have done to reduce the burden on designers would have beento enforce consistent font scaling across Google Play ecosystem devices:

How small can the font scale?

How large can the font scale?

What is the granularity in font scale change?

Google elected not to enforce this. As a result, it is up to device manufacturers,and they have varied significantly. AFAICT, Google has never published information aboutwhat the overall ecosystem limits are ��� and my guess is that Google has never compiledthis information. As a result, AFAICT nobody knows what the overall maximum font scale mightbe. Even on Wear OS there are font scaling differences between models, and there are a handful of watchmodels, compared to tens of thousands of phone models.

No designer is going to sign up to support arbitrary font scaling. At best, designersmight be willing to support font scaling using a couple of reference devices and hopefor the best for manufacturers who go beyond what those reference devices do. Otherdesigners will use the lack of guidance as a rationale for just ignoring font scalingentirely.

And, in some cases, designers aren���t wrong.

Dewey Defeats Truman!

For a very long time, Google���s belief was that this newspaper headlinewould need to scale based upon the device font scale. While the article text ideallywould scale, the headline does not need to scale, because the headline is alreadyhuge.

The reality is that not all text needs to scale, because the text may already bebig enough, even for visually impaired readers.

Google did eventually catch on to this��� a few months ago. Android 14 supportsnon-linear font scaling,so larger text will not scale the same as smaller text. Google even claims nowto cap scaling to 200%, though it remains to be seen if they will enforce thatlimit or let manufacturers do whatever they want.

However, it will be 2028 before Android 14 dominates. In the meantime, we need todeal with devices that lack this non-linear font scaling support.

How Google Could Help

Google could create a new Jetpack library (e.g., androidx.text) with utility codeto assist in dealing with font scaling. Or, perhaps that goes in some existinglibrary (e.g., androidx.compose.ui:ui-unit).

Partly, this would provide a backwards-compatible way to get the non-linearfont scaling support. For example, in Compose UI, perhaps we could have a .nlsp extensionproperty for Int and Float that matches the .sp extension property but appliesthe non-linear font scaling algorithm.

Ideally, Google���s utility code would also offer constrained scaling support. Manydesigns for text UI elements can support some amount of font scaling, just not���to infinity and beyond���. Google���s attitude to date has been that apps need to preciselysupport the system font scale, rather than using that font scale as guidance for whatthe user wants. If we had easy-to-apply options to say that a particular bit of textcan scale from X to Y, but not all the way to 200%, developers will have an easier time���sneaking in��� font scaling support. Similarly, designers can focus on providing instructionsfor how far the font could scale in spots, rather than having to redo designs to accommodatearbitrary font scales (200% or higher).

For example, in addition to a .nlsp extension property, there could be a .nlsp()extension function for Int and Float that takes minScale and maxScale parameters.In addition to applying the non-linear font scaling support, .nlsp() would clamp thescale based on those supplied parameters.

In the end, pretty much everybody wants to be adaptive to the needs of the visuallyimpaired. However, that is one objective out of many, and not all objectives haveequal weight. If Google wants font scaling support to be more widespread, it needs to:

Work on convincing executives and designers to increase the weight of that objective, and

Provide more and better options for designers and developers to support font scalingon an incremental or progressive basis

The latter seems like a more realistic approach ��� it just recognizes that one sizedoes not fit all, both in terms of text and how we scale that text.

Random Musings on the Android 14 Developer Beta 2

When Google releases a new beta, I rummage throughthe API differences reportthe 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 developermight reasonably use, along with things that may notget quite as much attention, because they are buried in the JavaDocs.

Not surprisingly, the pace of change is down now that Beta 2 is out. My focus ison the developer side; see Mishaal Rahman���s Twitter thread for a broader look at Beta 2.

Of note:

A fair number of APIs were removed. That is not surprising at this stage and probablyrepresents ideas that were not going to be ���fully baked��� in time for the Android 14release. One example is the PersistableBundle-based extras on PendingIntentthat I covered in the Beta 1 preview��� those are now removed.

Similarly, a few things that had been deprecated are now undeprecated. Whetherthat is because they found new use cases or their replacements were not yetready is unclear. Examples include the getApplicationRestrictions() methodson UserManager and RestrictionsManager.

WindowManager gained a series of PROPERTY_COMPAT constants, such asPROPERTY_COMPAT_ALLOW_DISPLAY_ORIENTATION_OVERRIDE. These let you opt out ofcertain behaviors, such as forcing activities to landscape. You specify thesevia child elements of in the manifest.

MotionEvent has getEventTimeNanos() and getHistoricalEventTimeNanos(),to get finer-grained resolution than the millisecond-based methods like getEventTime().

Google continues baking the notion of financed devices into the OSDeviceManager, as I mentioned back in musings on Developer Preview 1.DevicePolicyManager lets you determine if the device is financed andfind out about changes in the financing state.

TextView now explicitly has setLineHeight(),rather than only being able to specify line spacing.

There is a new PROVIDE_OWN_AUTOFILL_SUGGESTIONS permission, but it is only availableto ���the Browser application���, however Google is defining that.

Similarly, there are new permissions related to credentials, such asPROVIDE_REMOTE_CREDENTIALS.

It is likely that this is the last set of random musings for Android 14, unless somethingunexpected happens with the next release.

Random Musings on the Android 14 Developer Beta 1

When Google releases a new developer preview, I rummage throughthe API differences reportthe 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 developermight reasonably use, along with things that may notget quite as much attention, because they are buried in the JavaDocs.

We���ve moved out of developer previews and into beta releases. That slows downthe pace of change, but still there some things worth mentioning. My focus ison the developer side; see Mishaal Rahman���s Twitter thread for a broader look at Beta 1.

What Got Top-Line Attention?

One trend with these musings is that I cover something before Google does, forone reason or another. Some stuff from my DP2 musingsthat were announced this time were:

The share sheet improvements

Device screenshot detection

Also, Path is no longer a largely write-only API,which has been a large pain point for developers over the years.

Something I noticed in DP2 but didn���t understand enough to write about is thenew limitation on accessibility services. Apps can indicate certain UI elementsthat are only available to ���true��� accessibility services, those that actuallyhelp people with accessibility. Mishaal Rahman wrote more about that.You can use ACCESSIBILITY_DATA_SENSITIVE_YESor android:accessibilityDataSensitiveto enable this.

What Else At Least Was Announced

The concept of ���non-dismissable notifications��� was always a bit scary, insofaras apps can really annoy users with those. They have been slowly becoming moredismissable, and Android 14 makes them mostly dismissable.

While dynamic code loading via PathClassLoader and kin might get you banned fromthe Play Store, it���s still a technique used by many an app. Android 14requires that code to be marked as read-only,once you are targeting Android 14.

Eight years ago, I published some safe unZIP codeto avoid path traversal attacks.Android 14 now enforces that at the system level,for apps targeting Android 14. I really hope safe unZIP code becomes available in a Jetpacklibrary, so it can be used by all apps on more OS versions.Bonus points if they also stop ZIP bombs.

One hole in the background activity start limitation was IPC. Other apps could arrangeto start activities by convincing some other app to start them, such as via a PendingIntent. Android 14 makes that opt-in,for apps targeting Android 14.

What���s Outta Here

overridePendingTransition() on Activityis deprecated, replaced by overrideActivityTransition().

Google removed the ���data transfer��� type of JobInfo.

What Could Be Kinda Wild

The IntentFilter class appears to now allow filtering by extras.Since the parameter is a PersistableBundle, this is not merely filtering based on theexistence of extras by name, but presumably they also must match on value. Prior tothis, extras were purely ���payload��� of an Intent and were not something that you couldfilter upon. It will be interesting to see where Google puts this to use.

What Else Caught My Eye

View continues to get handwriting recognition APIs.

Google���s ill-documented HttpEngine now supports a bi-directional streamAPI, backed by a BidirectionalStream class.

The NetworkCapabilities API now explicitly supports Thread,of particular interest to those working with Matter.

I had not realized this, but apparently getType() on a ContentProvider wasnot defended by read permissions. Since that could leak information (the MIME typefor a particular Uri), they added getTypeAnonymous().getType() will be protected by read permissions for providers that also implementgetTypeAnonymous().

In DP1, Google stated that context-registered receivers might not receive broadcastsin real time.They have now added some APIs for the reverse direction: a broadcast itself,via BroadcastOptions, can have a deferral policy. The description ofDEFERRAL_POLICY_UNTIL_ACTIVEsounds a lot like their DP1 announcement��� except this would be opt-in by thesender. ����

Broadcasts now have some form of ���delivery group��� semantics,though the documentation on this is confusing.

And, there is now a dedicated exceptionif you try to startForeground() a service that is not actually started.

Random Musings on the Android 14 Developer Preview 2

When Google releases a new developer preview, I rummage throughthe API differences reportthe 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 developermight reasonably use, along with things that may notget quite as much attention, because they are buried in the JavaDocs.

So��� what does DP2 have in store for us?

What Got Top-Line Coverage

You can no longer kill app processes other than your own.I am stunned it took them this long to address this. Mishaal Rahmannhas more on this.

You will not be able to install apps with a targetSdkVersion below 23.My hope is that Google, or somebody, uses hypervisor techniques (or something similar)to allow running older apps in a sandbox.

MediaStore tracks who owns what, but.

What Changed with Screen Captures

There is a new DETECT_SCREEN_CAPTURE permission.This ties into registerScreenCaptureCallback() on Activity.As you might guess, this lets you find out when this activity is subject to a screencapture. It is unclear what sorts of screen captures are covered:

Screenshots only, or also screencasts? Only from MediaProjection, or also from built-in OS mechanisms? Does it include screen captures from development tools, like Android Studio?

Also note that the callback does not allow you to block the screen capture, justfind out that it happened. You can block screen captures using FLAG_SECURE, atleast to some extent.

There is also ACTION_LAUNCH_CAPTURE_CONTENT_ACTIVITY_FOR_NOTE.This captures a screenshot, allows the user to edit it, and gives you thescreenshot back via the Uri delivered to onActivityResult(). However, you will need tohold the LAUNCH_CAPTURE_CONTENT_ACTIVITY_FOR_NOTE permission,which is only available for apps in the ROLE_NOTES role.

What Is Choosy

For the ���share sheet��� (ACTION_CHOOSER), there are two new extras:

EXTRA_CHOOSER_CUSTOM_ACTIONS,for you to supply an array of ChooserAction objects representing additional entriesthat you want in the sheet

EXTRA_CHOOSER_MODIFY_SHARE_ACTION,which lets you know if the user wants to modify the content that they are sharing

What Got Highlighted

TextView got highlighted. Specifically, there is a new setSearchResultHighlights()method to allow you to specify ranges for highlighting text. And, asThomas K��nneth notedthere are new Highlights and Highlights.Builder classes for more sophisticatedhighlighting, with setHighlights() on TextView to apply them.

What Permissions Changed

There is a whole suite of new MANAGE_DEVICE_POLICY_* permissions, suchasMANAGE_DEVICE_POLICY_CAMERA andMANAGE_DEVICE_POLICY_DEVICE_IDENTIFIERS.Presumably, this ties into DevicePolicyManager.

There is a new EXECUTE_APP_ACTION permission,limited to assistants.

What Is Not Long For This World

The ���long jobs��� stuff in JobScheduler is now ���user-initiated jobs���. So,for example, the RUN_LONG_JOBS permission is now RUN_USER_INITIATED_JOBS.

What Changed with Broadcasts

A BroadcastReceiver can call getSentFromUid()and getSentFromPackage()to find out where the broadcast came from.

In related news, sendBroadcast() and sendOrderedBroadcast() now have variantsthat take a Bundle that you can build using BroadcastOptions.Right now, the only such option is whether or not the identity-sharing mentionedin the previous paragraph is enabled.

What Else Caught My Eye

There is a new overrideActivityTransition() method on Activity.The JavaDocsmay make your head spin, as it ties into the older overridePendingTransition()method and ���predictive back��� navigation.

Health Connect got its own family of packages.

WindowManager has an addProposedRotationListener() method.Your callback gets a rotation value (e.g., Surface.ROTATION_180).���This listener gives application an opportunity to selectively react to device orientation changes���.

The USE_FULL_SCREEN_INTENT permission was added a few years ago, to controlwhether you can raise a full-screen notification.Now, there is ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT,which you can use to launch an activity to allow the user to grant your apppermission to use ���full screen intents���. And there iscanSendFullScreenIntent() on NotificationManagerto find out the status of that permission.

PowerManager now offers isAllowedInLowPowerStandby(),which will tell you if low power standby is disabled for one reason or another.You can also react to these changes, it appears, by registering a receiverfor ACTION_LOW_POWER_STANDBY_POLICY_CHANGED.

JobScheduler now has .

While by default you can no longer create mutable PendingIntent objects wrappingan implicit Intent, FLAG_ALLOW_UNSAFE_IMPLICIT_INTENT.might let you bypass that restriction.

Random Musings on the Android 14 Developer Preview 1

It���s that time again!

When Google releases a new developer preview, I rummage throughthe API differences reportthe 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 developermight reasonably use, along with things that may notget quite as much attention, because they are buried in the JavaDocs.

What Might Make You Want to Wait

Apparently, you can only run your app once on Android 14 DP1 from Android Studio, and you then have to uninstall it.And the fix is going to be in a canary release of Studio, rather than a patch releaseon the current production version.

What Might Be Less ���Orphan Black��� and More ���She-Hulk���

Mishaal Rahmann reports that Android 14 might support app cloning.Here, ���app cloning��� appears to mean that the user can set up an app to havemultiple distinct sets of internal storage (e.g., getFilesDir() on Context).This can allow them to, say, use multiple logins for the same app, simply by switchingwhich clone they run.

This may cause some compatibility problems, because some developers refuse to usemethods like getFilesDir() and instead hardcode filesystem paths. That has not beenreliable in many years. However, many app developers can get away with it, becausethe scenarios where the hardcoded path might not work are uncommon (e.g., multiple deviceprofiles, work profiles). App cloning may add yet another scenario where those hardcodedpaths are a problem, and some apps will wind up getting smashed.

FWIW, launchers might need to play along with this ���see ACTION_PROFILE_ADDED.

What Might Get Photo Access In a Bigger Pickle

Mishaal also reports that Google may be unhappy with the rate of Photo Picker adoption, and thatGoogle might shoehorn the Photo Picker into the permissions flow.I agree with the premise that this can improve privacy and security. However, thischange does not appear to be documented, and it will be interesting what the impactsare from a compatibility standpoint.

What Else Screams ���Compatibility Concerns���

There is quite the list of things that are documented that might break appsfrom unwary developers. Some of these will affect many current apps, such as:

Broadcasts sometimes no longer being deliveredwhen your app is running but is not in the foreground

SCHEDULE_EXACT_ALARM no longer being granted by default

Others will crop up later in 2023, when you raise your targetSdkVersion to whateverthe magic number will be for Android U:

Mandatory foreground service types,complete with exceptions,and a veiled threat of the ban-hammer swinging freely on the Play Store for apps that fail to comply

Blocking implicit Intent use even further

Requiring registerReceiver() to specify if the receiver should be exported

Usually, there are some undocumented (or late-documented) compatibility challengestoo.

What Would Matter If Device Manufacturers Were, Y���Know, Reasonable

There are new foreground service types, such as for health.It would be even nicer if these actually mattered, as device manufacturers routinelynerf your foreground service anyway.

There is a new data transfer type of Job.Maybe device manufacturers will pay attention to these and let them actually run.

What Makes Me Consider Using Jedi Mind Tricks

Android 14 has CredentialManagerand CredentialProviderServiceand a bunch of other code tied to ���credentials���. This appears to be in supportof a Jetpack libraryfor integrating traditional logins, passkeys, single-sign-on services, etc.

Ideally, this would be awesome. Google���s track recordmakes me less than interested,at least until this code gets seriously vetted. At least it is part of the AOSP ���I would have expected this to be part of the closed-source Play Services SDK.

But, seriously: an OS that has an entire class hierarchy for ads doesn���t exactly strikeme as the sort of OS where I want to be trusting the OS itself very much.

Note that View now has isCredential() and setIsCredential(), to flag UI elementstied to credentials. It is unclear what impact this has, though it would be niceif they were automatically redacted in screenshots.

What Might Be Signs of Competition

An app using PackageInstaller can now request enforcement of update ownership.In other words, if Store A installs an app and requests this, other stores willneed permission from the user to update the app, even of those other storeshold INSTALL_PACKAGES and can otherwise freely install apps. This also canbe requested in the manifest,apparently.

My guess is that the Play Store will apply this to everything it installs��� butthis implies that Google sees a future with more stores.

What Else Is Rich

setStyleShortcutsEnabled() on EditTextapparently lets common hotkeys like Ctrl+B apply formatting. This is the first tinystep towards getting first-class rich-text editing in Android, which would be welcome,if the current support is limited to people using keyboards.

In somewhat related news, support for handwriting recognition seems improved,with several new methods on Viewand ViewConfiguration.

What We Might Be Allowed To Do

There are many new permissions.Of note:

Each foreground service type now has its own associated permission, suchas for access location data

We might need a permission to turn the screen on

They appear to be adding hooks to allow apps to find out when screenshots are taken,which would be a nice addition

It is unclear how they define Wifi display,but it would be sweet if we somehow got Miracast support back

Google Glass might be making a comeback

What Features Might We Require

There are a few new elements we can add, including:

Support for the aforementioned CredentialsManager, which implies that this willnot be available on all devices

Support for ultra wideband

Support for seamless refresh rate switching

What Means We Can���t Have Nice Things

Another new element is for ���device lock��� support. This probablyties to DeviceLockManager.The primary cited use case: a ���financed device, where the financing entity has the capability to lock the device in case of a missed payment���.

The concept of having financed devices is fine. The concept that financers andand complicit device manufacturers can lock the device for non-payment is unsurprising.Having this ���feature��� baked into the OS is disturbing.

What I���m Surprised Took This Long

As a native English speaker, I am frequently unaware of all of the different nuancesof other languages. But I am a bit surprised we made it this far withoutsupport for grammatical genders.

What Is Going��� Going���

Criteria-basedAPIs on LocationManager are now deprecated.

What Else Intrigues Me

We can now, finally, figure outwhat other app started our app.

There is a VirtualDeviceManager.It is undocumented what this pertains to, other than probably not the Android SDK emulator.However, it also ties to the notion of creating a ���device Context���.And, given this listener,this appears to be for moving an app to a different device, such as from your phoneto the rumored tablet/hub thingy that Google is building.

More of Health Connect is baked into the OS now, with the addition ofHealthConnectManager.

TextView can now have highlights.It is unclear how this related to the rendering of Spanned objects, whichwas our traditional way of highlighting certain portions of the text.

You can get the shape of a Display.It is unclear if this is designed for Wear OS or for other scenarios.

There are new types of KeyEvent,including for stylus buttons.

StrictMode can now complain if you manually request garbage collection.

As part of adding a few hundred OpenJDK 17 classes, we got StackWalker.I can see this being useful for diagnostic tools like LeakCanary.

The media projection APIs now supportscreenshots for a specific or user-selected Display.

Our existing runtime resource overlay (RRO) supportis getting expanded withfabricated runtime resource overlay (FRRO) support.

There is an AltitudeConverter,hopefully not for Android-powered airplanes.

Android now supports Dvorak keyboards,though really the international keyboard types are more important.

We can now find out how much memory the user was told their device has,which might not resemble how much memory their device really has.

Apps on Chromebooks can now request to move to full-screen mode.

And, finally, we can now ask to create a note,even on the lock screen.

Applying distributionSha256Sum to Gradle and Android Studio

Since I wrote about a Gradle Wrapper supply chain attacka few days ago, I decided to check back in Android Studio���s support fordistributionSha256Sum. And the good news is that with Android Studio ElectricEel, it seems to work well��� if you know the limitations.

Basic Setup

In your gradle/wrapper/gradle-wrapper.properties file, there is adistributionUrl property that indicates what build of Gradle should be downloadedand used for building your project:

distributionUrl=https\://services.gradle.org/distributions/gra...

You can add distributionSha256Sum to gradle/wrapper/gradle-wrapper.properties aswell. You get the value for your target version of Gradle from the Gradle Web site.So, for example, for the Gradle 7.5 binary-only ZIP, you will find that the checksumis cb87f222c5585bd46838ad4db78463a5c5f3d336e5e2b98dc7c0c586527351c2. So the matchingdistributionSha256Sum line for the above distributionUrl line is:

distributionSha256Sum=cb87f222c5585bd46838ad4db78463a5c5f3d336e5e2b98dc7c0c586527351c2

This helps prevent a Martian in the middle (MITM) attack that replaces the GradleZIP file with one that has been modified. If Android Studio or the Gradle WrapperJAR file tries downloading the ZIP from distributionUrl, and the resultingZIP file does not have a SHA-256 checksum matching distributionSha256Sum,Android Studio and Gradle will refuse to use it. Android Studio Electric Eelwill give you output akin to this in the Build tool:

Verification of Gradle distribution failed!Your Gradle distribution may have been tampered with.Confirm that the 'distributionSha256Sum' property in your gradle-wrapper.properties file is correct and you are downloading the wrapper from a trusted source. Distribution Url: https://services.gradle.org/distribut... Location: /home/mmurphy/.gradle/wrapper/dists/gradle-7.5-bin/f1w0cc9nuo0eivz97x2xlu9sv/gradle-7.5-bin.zipExpected checksum: '6b47b85e791fa422b9b78bdfab7672dd934ff973d6e781ba98d972e844d91754' Actual checksum: 'cb87f222c5585bd46838ad4db78463a5c5f3d336e5e2b98dc7c0c586527351c2'

That same message, minus the first line, will also be output by the Gradle WrapperJAR.

The Limitations

The big wrinkle with distributionSha256Sum is that it is checked at the pointof downloading the Gradle version specified in the distributionUrl. If youalready successfully downloaded that version of Gradle before ��� such as viaa project that lacks distributionSha256Sum ��� no further checks are made.So, it is very easy to think that distributionSha256Sum is not working, becauseyou add it to a project, put in an invalid checksum value to test��� and the projectstill builds. You need to clear out the already-downloaded Gradle distributionfirst, forcing a fresh download. Those are stored in ~/.gradle/wrapper/distson Linux and macOS (and presumably in an equivalent location on Windows).This may be less of a problem for CI systems that use fresh containers on eachbuild.

Also:

Android Studio templates do not supply distributionSha256Sum, which meansyou are screwed right out of the box. If you have a new Android Studio versioncreate a new project which uses a new Gradle version, since there is nodistributionSha256Sum in the generated gradle-wrapper.properties file,there is no checksum check. And, even if you adddistributionSha256Sum yourself manually later,you also have to manually clear out the already-downloadedGradle to force a checksum check. Since the SHA-256 hash is a known value for theassociated distributionUrl, it would be very useful if Android Studio���s templatesincluded it.

If you have Android Studio update your gradle-wrapper.properties file topoint to a new Gradle version, it does not add distributionSha256Sum if you do not have it already. Similarly, if you have distributionSha256Sum in thegradle-wrapper.properties file already, when Android Studio changesdistributionUrl, it doesnot change the associated distributionSha256Sum. You will get the error shownabove and will need to change distributionSha256Sum manually.

Those limitations will hamper adoption of distributionSha256Sum. However,it still feels like a useful defense, for those who are willing to work around thoselimitations.

Gradle Wrapper Supply Chain Attack

Gradle, Inc. has reported thatMinecraftOnline had malicious Gradle Wrapper JARsin some of their repositories.

I warned about this sort of possibility six years agoand off and on thereafter.

I���ll re-up the same sorts of points that I have made before:

Do not use the Gradle Wrapper from an arbitrary project that you grab offof GitHub or elsewhere on the Internet. Delete it or replace it with a locally-generatedwrapper (gradle wrapper command).

Consider not publishing the Gradle Wrapper in your projects. Historically, I wouldpublish gradle-wrapper.properties, but not the actual Gradle Wrapper JAR andscripts.

ActivityPub and Android

Android Dev Social is not merely a Mastodon instance,but it also has an associated blog. I wrotea guest post there, ActivityPub and Android,describing what ActivityPub is and outlining where I think some opportunities liefor interested Android app developers.

When It Comes to Twitter, Have a Plan

TL;DR: You can find me on Mastodon at @commonsguy@androiddev.social.

You might be a fan of Elon Musk, or you might not. However, it is hard to lookat the past two weeks and conclude that Twitter is now in a more stable positionthan it was previously. Even Mr. Musk himself has hinted at bankruptcy as beinga potential outcome in the coming months.

Plenty of social networks have fizzled out: Orkut, Friendster, MySpace, and so on.Some are able to survive the transition and simply become smaller editions oftheir former selves. Others die out ���gradually, then suddenly���, in the words of Ernest Hemingway.In the case of Twitter, to me, the latter course feels more likely. From failing tobe able to pay off their loans, to FTC action for violations of a consent decree,there are cataclysmic ends that we on the outside can see, let alone ones we cannot.

The question then becomes: what happens to you?

Maybe you just use Twitter for cat pictures, memes, and the occasional bit ofAndroid developer knowledge. If so, Twitter���s possible demise may not impact youall that much.

However, plenty of people rely on Twitter for more than that:

For reaching out to others for help, personally or professionally, such as forAndroid development concerns

For keeping tabs on announcements, such as Ian Lake���s tweets about Jetpackreleases

For keeping in contact with friends and family

For promoting themselves or their services

For alerting others of risks and dangers

And so on

If you use Twitter for these sorts of things, what will you do if the whale fails permanently?

If you are already part of other social networks that can fill the gap, great!If not, you may want to find an alternative.

Right now, the alternative that seems to be getting the most attention is Mastodon,in part because it offers a fairly Twitter-like experience:

Short posts, optionally with attached media

Follows and followers

Hashtags, such as #JetpackReleaseNotes for Ian���s Jetpack release announcements

Equivalents for some Twitter behaviors (e.g., retweets -> boosts)

Mastodon is not Twitter, and so some behaviors are skipped intentionally (e.g.,there is no equivalent of the Twitter quote-tweet).

Because Mastodon is federated, it also lends itself to having layers of networks.In particular, a common pattern is to join a Mastodon ���instance��� that is tiedto some subject of interest to you, as you can then monitor the ���instance feed���for that instance. This gives you access to posts from peers in your instance,without manually following them.

We in the Android developer community owe a world of thanks to Mike Nakhimovich.Mike set up the androiddev.social Mastodon instance,aimed at Android developers. While you can still follow people from all over the���fediverse���, you have more immediate access to fellow Android developers. Signups on that instance are limited, and you are strongly encouraged to donatea few dollars to help with upkeep, but it is still a leading option for Androiddevelopers.

However, as with many Mastodon instances, androiddev.social is not a business.In essence, Mike is inviting you to a party and is asking you to contributea bit towards the cost of food and drinks. While Mike is friendly, Mike is underno obligation to invite everyone, and Mike can kick anyone out. There arethousands of Mastodon instances out there, and many people (including some Androiddevelopers) have simply set up their own personal ones. I am very grateful toMike for letting me come to the party,but there are lots of parties, and you should choose one that best fits youand where you best fit.

Mastodon may or may not be right for you. But, one way or another, you shouldbe starting to chart your post-Twitter future, should Twitter collapse.