Google sunsets the APK format for new Android apps

https://www.androidauthority.com/android-apks-sunset-1636829/

142 108 5 years ago

askonomm• 5 years ago

So what's this mean, effectively, to other app stores on Android? I'm pretty sure most developers won't bother making APK's for third party app stores with very small user bases. And what's this mean to Microsoft who is bringing APK's to Windows? Existing APK apps sure, but can Microsoft use the new format as well or no?

notatoad• 5 years ago

From my reading of the windows 11 coverage, they're relying on APK sideloading or the Amazon app store for distribution. So no, Microsoft will likely not be able to use the new AAB format (although I'm sure there's some ongoing negotiations around this. Never say never...)

tadfisher4• 5 years ago

AABs are built, and APKs extracted, with bundletool, part of the open-source Android SDK. There is nothing technical preventing Amazon or F-Droid from accepting AABs and providing APKs on-demand.

sxp• 5 years ago

If the dev wants to release their app on another app store, they would just export the apk. Pirate app stores that share apks without the dev's permission would probably need to write their own aab to apk converter and sign the apks with a key owned by the pirate app store. So this probably isn't a big deal for regular devs, but will reduce the security of apks downloaded from pirate app stores since it would be harder to verify the code integrity of the derived apps.

jayd163• 5 years ago

Seems like devices still deal with apks. Apks remain a core part of development. The biggest hurdle to 3rd party app stores is the API, not making an apk.

pjmlp4• 5 years ago

https://android-developers.googleblog.com/2021/06/the-future...

If I use app bundles, can I still publish through multiple distribution channels/app stores?
Yes, there are multiple ways to achieve this. You can either use the same app signing key everywhere or use unique app signing keys for different channels, including a unique app signing key for Google Play. You can either build and sign artifacts for all distribution channels locally or you can download distribution APKs from Google Play for use on other channels. Distribution APKs downloaded from Google Play, either via the app bundle explorer in Play Console or via the Play Developer API, are signed with the same key used by Play App Signing.

chrisweekly• 5 years ago

"The other issue is that developers will need to give Google their app signing key to export an AAB app as an APK. This gives Google quite a bit of power."

I can't even.

laweijfmvo• 5 years ago

I'm confused; why do developers need Google to export an APK for them? Can they no longer generate APKs (locally) themselves and distribute them however they like?

zucker42• 5 years ago

Based on the blog post's FAQ my impression is you can still do that. My impression is it's only for apps in the play store (and the corresponding export play store AAB to APK feature) that you are required to giving your keys to Google.

https://android-developers.googleblog.com/2021/06/the-future...

meesterdude• 5 years ago

when i saw the headline, I knew google would use it as a pretext to do something disgusting. Everything they do has some dark pattern to it somewhere. AMP is a great example.

You should never, ever give your signing key to anyone. Especially not google. you might think of google "they wouldn't" but in fact they can, they have, and they will again.

tadfisher4• 5 years ago

Note that new apps don't provide the Play Store with the key, they just verify against the first certificate they receive.

whoknowswhat112• 5 years ago

No one cares about your signing key.

Google can create a key on their own servers if you want (you can't export this key so can't use it to sign apps for multiple stores) but u can keep your own keys secret

pavon2• 5 years ago

This is insane. What is the point of even having a developer signing key if people other than the developer have access to it? Why don't they just sign the APKs with Google's own keys from here on out?

Can't wait to hear Moxie's response on this. One of his (many) reasons for refusing to support FDroid was because it didn't allow developers to sign their own apps, and thus users had to trust that FDroid did not modify the app. Now FDroid has addressed that, but Google has not only removed that feature, but is demanding that developers allow Google to impersonate them.

birksherty• 5 years ago

Now FDroid has addressed that

Out of loop, what changed?

resoluteteeth• 5 years ago

Iirc they're switching to that model (google uses it's own key) but they need the developers' keys for older apps because android won't allow changing the key when an already installed app is upgraded.

noisy_boy2• 5 years ago

Will we be able to do offline installation of the .aab files like we can for .apk? Sucks if the answer is no.

userbinator• 5 years ago

I suspect making that harder was one of the main motivations, since I highly doubt Google would actually care so much about app sizes in an ecosystem that was already insanely bloated from the beginning. (https://news.ycombinator.com/item?id=15442743)

Weakening adblocking in browsers and churning the web "standards" to the advantage of its browser, the increasingly "ignore the user's request" attitude of its search engine, and dumbing-down and hiding information in its products --- it has a technical argument for every single thing it does, but don't let that convince you to think that's the real reason it did that. Google is extremely good at rationalising otherwise anti-user decisions with a technical and positive spin --- it's an ad company, after all, and persuasion/reinterpretation of the truth is what marketing is all about.

Android is still comparatively open as far as mobile devices go, but with each change it makes I can see the walls are slowly rising around its garden.

noisy_boy2• 5 years ago

I have to agree. I don't like it either but Android's flexibility still is miles ahead of iOS so it is more of a case of choosing the worse between two bad choices. E.g. I heavily use Syncthing to keep data/media across various devices in sync (mostly Linux and Android); recently we purchased an iPhone so I thought of doing the same setup for managing photos/videos etc and basically, other than some hacky options, there is no clean and seamless solution. Google's walls are rising but I can still pretty easily hop over them compared to Apple's fortress.

sofixa• 5 years ago

since I highly doubt Google would actually care so much about app sizes in an ecosystem that was already insanely bloated from the beginning. (https://news.ycombinator.com/item?id=15442743)

Isn't that logic backwards? Precisely because the ecosystem is bloated they're doing something about it in a place they can?

smackeyacky• 5 years ago

Google warned last year they were deprecating APKs on the play store. I didn't think much of it at the time as I had a much bigger problem when they insisted everything shift to 64 bit, a painful process if you have native libraries.

AAB files aren't suited to local installation like an APK though, they are more like everything google needs to build APKs themselves for installation on different devices. I think we will still build APKs for direct distribution.

ergot_vacation• 5 years ago

As others have asked though, how does this effect side-loading? What does the user end up downloading: an apk, or an aab? If it's an aab, can they archive it for later, like you can with apks? APK archive sites have saved my ass on numerous occasions when the developer decided to "improve" their app, forcing me to downgrade to get it back to a preferable state. And then of course there are apps that don't have the holy blessing of our Lord and Savior Google. Is it going to become impossible to load those at all without installing some weird homebrew OS? For now APKs still work on the phones themselves, but I imagine that will be stolen from us as well at some point.

iggldiggl2• 5 years ago

What does the user end up downloading: an apk, or an aab?

Your phone still downloads APKs from the Play Store, but it's no longer a single monolithic APK that covers all languages/screen sizes/CPU architectures [1] supported by that app. Instead you'll get a collection of APKs covering your specfic device configuration only.

If it's an aab, can they archive it for later, like you can with apks?

You can archive the individual APKs, although installing them again is a bit more complicated, as you either need a third-party app like https://f-droid.org/packages/com.aefyr.sai.fdroid/, or else install them via the correct incantation on the command line.

As for APK archive sites, presumably coverage of languages/screen sizes/CPU architectures with few users might get worse, as one user uploading an individual APK version will no longer be enough to automatically cover all languages/screen dimensions/etc. and instead you need to grab separate APKs for each possible language/screen size etc.

Getting the APK with the correct CPU architecture (where applicable) will of course be critical, although in practice almost everybody is probably using ARM these days, so there's not much to go wrong here (although if you still have a 32-bit device then you can only run the 32-bit APK, whereas the other way round a 64-bit device can run both 32- and 64-bit native code).

As for language and screen density, my guess would be that Android can fall back to whatever language and screen density APK actually has been installed (since this should be the same situation as when a monolithic APK doesn't contain the correct resources for your preferred language/screen density), so you might get a degraded experience (wrong language, either blurry or unnecessarily-high-resolution graphics), but the app at least still runs.

[1] Although given the potentially large size of native libraries, separate APK versions for differing CPU architectures already aren't that uncommon.

techrat2• 5 years ago

As others have asked though, how does this effect side-loading?

It doesn't.

APKs are still the end format.

ridaj4• 5 years ago

The good: .aab can be optimized by the Play store for the device that is requesting them (for example stripping resources that don't apply to a particular device)

The bad: it will be more difficult for non-Google app distribution storefronts to jump-start their catalog by grabbing APKs from the Play Store, because they won't be able to get one neat APK per listing via some APK downloader. (For apps that do want to get listed on those storefronts, life won't be very different.)

The ugly: APK distribution is a "zero-trust" model which allows the developer and the user to not have to trust the store not to make any changes to the application. In fact that's what prevents the kinds of "good" optimizations mentioned above: Google can't reach into an APK to strip resources that are irrelevant to a particular device, because doing so would invalidate the APK's signature. By forcing apps to be deployed with keys under Google's control, this trust model is broken. The Play Store no longer guarantees through cryptography that APKs haven't been tampered with between the developer's build system and the recipient device.

tadfisher4• 5 years ago

At least they give you the signing certificate so you can verify the end user is using a Play Store build and not something potentially malicious. Testing release builds requires a round-trip through the Play Store, though, and apparently AOT-compiling is only triggered when the Play Store installs its blessed version of the app.

whoknowswhat112• 5 years ago

Users trust Google more than they do random app devs in many / most cases

square_usual• 5 years ago

This isn't about trusting the app dev at all, this is about trusting that Google didn't tamper anything. Whether or not trust a dev, you can't trust that you are getting what the dev intended. If you download a version of Signal Google silently changed to include a backdoor, it doesn't matter whether you trust Signal or not: Google will get all of your data.

ridaj4• 5 years ago

Totally agreed. However for the few cases where it matters, IMO it's a regression

Iv• 5 years ago

About the last point, I am not familiar about the key distribution there...

Say Google wanted to create an eavesdropping Facebook Messenger, couldn't it hide the real one and replace it with an app of the same name, signed by an entity named "Facebook Inc [random invisible unicode character]" and essentially do the same thing?

I always assumed that the APK security model did not protect against a compromised Google Store?

SuperNinKenDo• 5 years ago

If my understanding is correct, it wouldnt protect new installations of the app in your hypothetical, however any attempt to update existing users would fail.

thu2111• 5 years ago

It sort of does. The new app in your case would be signed by a different key and so wouldn't have access to the existing app's data. It would boil down to a phishing attack - the new app would have to impersonate the UI of the old one and get users to log in again.

Hence my concern with this part of the article:

"While it’s unlikely Google would ever do so, it is possible that it could sign apps on behalf of a developer"

Actually given the trend the company has been on over the past 6 years I'd say it's very likely Google would do this ...

the-rc2• 5 years ago

I don't think the "ugly" point is completely true, there's another optional level of signing that uses keys under control of the developer alone, approximating the APK model: https://developer.android.com/guide/app-bundle/code-transpar...

TheMatten• 5 years ago

From the linked documentation:

The code transparency file does not verify resources, assets, the Android Manifest, or any other files that are not DEX files or native libraries contained in the lib/ folder.
Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs.

Do I understand it right that it basically means user's device doesn't care about this signature at all? Wouldn't that make it pretty easy to supply modified versions of app to specific devices without them noticing, unless users decide to check signatures by themselves?

pjmlp4• 5 years ago

As side note, this is how Windows Store (the old one) used to work, a cloud compiler generated native code specific for the device.

The whole JIT/AOT infrastructure from Android 5 onwards, Microsoft did it on the cloud instead.

Hence why Windows Phone always tended to be snappier than similar Android devices.

https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-an...

https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native

Also how iOS and watchOS apps, since app thinning and bitcode were introduced as packaging format.

ridaj4• 5 years ago

Idk about Windows but yes the App Store has been doing it this way from the start. I suspect this is a case of Apple envy.

Eridrus• 5 years ago

I do not find "The ugly" very compelling since most developers are not very good at keeping their signing keys secure.

zodiakzz• 5 years ago

An Android App Bundle is a publishing format that includes all your app’s compiled code and resources, and defers APK generation and signing to Google Play.
Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app.[1]

So a unique .apk is generated for each device configuration on demand? Goodbye to the days when a single (or a couple) .apk worked on all devices, which was easy to rehost, redistribute etc.

Is the toolchain needed for compiling AAB -> APKs open source atleast? And will Google Play let end-users download the source .aab file?

1: https://developer.android.com/guide/app-bundle

Nullabillity• 5 years ago

IIRC, an AAB is basically a set of APK "dimensions" (base, screen size, screen density, ISA, and so on), so you end up downloading one APK per dimension and install them as one transaction.

This is also possible to do through both the CLI (adb shell) and Java APIs. However, it does indeed make sideloading more troublesome (the regular graphical installer has no idea about how to do multi-APK transactions). However, you can still distribute monolithic APKs for that purpose...

tdeck• 5 years ago

This is basically correct. An app can be loaded as one APK or as a set of multiple APKs - these are sometimes called "split APKs". For a while the Play Store has supported sending apps as a base APK plus a bunch of "config split" APKs. The base APK contains things like DEX code (Java bytecode).

The config split APKs are grouped by various device targeting dimensions (basically language, DPI, and architecture). As you can imagine, apps often have a different set of strings for each language, multiple versions of native libraries for different ARM / x86 ABIs, and assets for different DPIs.

When you create a bundle, Play will build split APKs for each possible value in each group (e.g. a low-dpi APK, a high-dpi APK, an English-language APK, a Korean-language APK, etc...).

When a device downloads the app, Play will send that device the base split APK and one config split APK from each group. So I will get the base DEX code, the arm64v8a native code APK, the XXHDPI APK, and the English strings APK. That means devices don't have to download or store potentially large amounts of app assets and native code that will never be used on that device.

EDIT: Older devices (IIRC L and below) don't support this. So Play will build standalone APKs for their configuration. I am not sure how many possible standalone APKs it will build.

UncleMeat• 5 years ago

App Bundles have been available and widely used for years. People are lamenting days that went away years ago but are just now complaining, which makes me think that the concerns are overblown.

iggldiggl2• 5 years ago

Curiously enough, Google itself only recently introduced local app sharing ("Nearby Share" via Bluetooth/Wifi etc. – of course only for free apps) as an official built-in Play Store feature, while at the same time an increasing prevalence of app bundles will mean a suboptimal experience when sharing between devices with differing screen density, language, etc.

Russelfuture• 5 years ago

I had six apps on Google Playstore several years back. They were free, no adverts or in-app tricks... Google removed them, since I didnt keep creating new versions. Oh well. But the API churn has become explicit neo-monoploy strategy. Google and Apple should be broken up. Two companies control all mobile software distribution - and restrict and block independent developers using all the classic tricks of monopolists. It's just nuts. No other industry is this concentrated. There is no innovation happening here. 15% smaller size? So what. This whole exercise is to maintain and extend control. Regardless of where one sits on the political spectrum, this is just "company store" monopolist tricksterism, and the solution is to dust off the old Anti-Trust laws and break this abusive entity into three or four seperate companies. "Trust Busting" is something both the Right and the Left can agree on. Break Google up. If - as a developer - you want to distribute your code as an .APK, then you and your customers should be able to make that choice. This current economic model is not only bogus - it is actually contrary to black-letter US law.

dontblink• 5 years ago

Genuine question: why not distribute them yourself (e.g. on GitHub)? If more and more developers do this, it will be like pc software. We don't have to accept a storefront (on Android at least).

PradeetPatel2• 5 years ago

It has been established that distributing APK anywhere else (Github, etc.) other than the Play store would have a drastic impact on the exposure and discoverability of the app, which will lessen user engagement and revenue stream.

Disclaimer: I'm not an app developer, but works in PR and marketing.

WhyNotHugo• 5 years ago

It doesn't reach users.

On iOS, that's not even an option. On Android, that's hidden behind some scary checkboxes that state they're only for developers.

Side-loading apps like this is advertised as "insecure" and "dangerous" so as to discourage people form doing so.

Andrew_nenakhov• 5 years ago

You also wouldn't be able to use push notifications, and modern Androids heavily restricts background app running.

jaimex22• 5 years ago

Same. I just left them as downloadables on XDA forums and personal site.

Apple and Google can eat a d#%$

xvector• 5 years ago

Why not F-Droid?

Camillo• 5 years ago

Is there really that much API churn on Android? I have a cruddy old app originally written for API 16 and it still works. It's not on the play store, though.

Avamander4• 5 years ago

Tremendous amount if you want your app to work well and properly on newer Android versions.

ppf2• 5 years ago

So it turns out the original "disruptors", using scorched-earth business techniques, and despite adhering to the mantras of open-source software, have become uncontrollable monsters?

It should make you think a little about how things are done in Silicon Valley.

vcavallo• 5 years ago

We just need new disruptors.

A little tougher now that the current companies have the government on their side.

Abishek_Muthian• 5 years ago

After nearly a decade of mobile development I have stopped developing for Android & iOS as well.

Apple had(has?) two years policy for app removal if not updated, I feel that's fair considering quality & security.

But Apple did me real good when overnight it moved my arcade type game from Arcade category to some other generic category because it named its game store as 'Arcade'.

That was the beginning of the series of events ending with semi-mandatory vaccine apps being available only these platforms (no web) to put bad taste in my mouth. Now I've gone back to web development for my products.

The only reason an average app publisher want their app to not be on web is because it cannot steal as much private data(or users can easily protect themselves) .

herbst2• 5 years ago

Same here. I've build web things 10 years ago that still have happy visitors to this day. Every app I built (only 3) was removed within a year.

I don't feel crazy enough to waste time in things that can't exist without me permanently touching it for no reason

Helmut10001• 5 years ago

There are so many arguments for Progressive Web Apps (PWAs). Independence from FAANG is only one of them.

actuator• 5 years ago

Yes, there are but in iOS even PWAs are at the mercy of Apple as they anti competitively don't allow any competing browser engines.

devetec• 5 years ago

The walled garden's walls heighten. However, sideloading will still function with other avenues. But still, this barely adds anything, and even though it can be more optimized for devices, that's not much compared to the large ramifications.

sschueller• 5 years ago

Just wait, Google will probably remove that in an upcoming Android version soon.

justshowpost• 5 years ago

I absolutely do not believe in caring about flash space, all of the APKs from Google LLC are quite bloated. Google is likely targets users who are side-loading their apps, grabbing even more DRM power for themselves.

yjftsjthsd-h• 5 years ago

Wait, why can't other stores use AABs?

jayd163• 5 years ago

Pretty sure there's no technical reason they couldn't.

rock_artist• 5 years ago

I've started deploying a new app under testing (public testing) a few days ago (it's still under review).

I've also made similar flow for iOS (test flight).

I already had few apps on Play for years now but didn't need to update them within the past 2 years.

The AppStore and Play Store feels now much similar than before:

- bundles / bitcode - The AppStore get modules they can repackage on "your behalf"

- review - for a year or more it takes a few days for your app to be reviewed. Even just for testing (public beta)

- signed by store, that's the major difference now (which as stated required for bundles)

Iiuc, that was always the case with Amazon AppStore (noted by commonsware https://news.ycombinator.com/item?id=27651983)

Personally I'm more concerned when/if a private certificate won't be allowed at all (eg iDevices).

CameronNemo• 5 years ago

Is anyone using Aurora Store and worried about how it will affect them? For reference, Aurora anonymously retrieves APKs from the play store so you can use common apps like Zoom, Slack, et cetera.

ajkdhcb22• 5 years ago

Yes I am seeing mixed messages about this

kuesji• 5 years ago

aurora store currently supports aab file format. go to an app's "more about app" section and scroll to files section. you can see bunch of apk if app is using aab.

( for example spotify )

securitypunk• 5 years ago

APK is an antiquated format that originates from Java Jar over two decades ago. It's basically a zip file with some internal structure for signing a manifest of hashes. Google already had to bastardize the APK format to move the signature to ZIP metadata, but there were still tons of problems around key rotation and distribution of large APKs.

This is a natural evolution of the format. It's good for the ecosystem. Whatever guarantees were supposedly provided by having developer (poorly) store their own signing keys are better handled by Google's own infrastructure.

js4ever• 5 years ago

I believe this is maybe the last step before a total removal of sideloading apps on Android. Sideloading is the main reason why I left iOS for Android 10 years ago. If it's off the table ... I might switch to a Linux phone... Or go back to iOS

techrat2• 5 years ago

People have been crying wolf about "ZOMG! GOOGS GON REMOVE SIDELOADS" for years now.

It's still present.

AOSP still exists and is still updated.

Pixel devices still have unlockable bootloaders.

Your fear is still unfounded.

unethical_ban• 5 years ago

AOSP is neigh unusable in its own form without heavy modifications on a phone.

Going from "all phones" to "one brand and modified" is a significant barrier to sideloading.

Being concerned is valid given Google's history. It may not happen. It may happen. It may happen a long way now. But when has Google opened a service or product in a purely consumer friendly, community friendly way?

Avamander4• 5 years ago

After SafetyNet, unlockable bootloaders are quite useless, you instantly lose access to a bunch of apps. It's a no-go for many.

dataflow3• 5 years ago

Any reason to believe APKs will be supported in Android in a few years?

jayd163• 5 years ago

Bundles are essentially intermediate compilation units and apks aren't going away.

dartharva• 5 years ago

This won't hinder app sideloading, right? RIGHT?

ppf2• 5 years ago

I am so glad I got out of the whole game, and stopped using a smartphone. I'm also glad I live in a country where it is somewhat viable, although in our post-Covid world, everywhere seems to need a crappy app to get anything done.

bhawks2• 5 years ago

Very disappointing. Normalizing sharing private keys? I expect better from Google.

None of the user facing benefits of the new format apps are predicated on throwing away the trust model of the app ecosystem. It is easier to implement and optimize the publish flow sure. Google is one of the few companies with the skills and resources to do it the right way.

Say it ain't so!

ajkdhcb22• 5 years ago

"The other issue is that developers will need to give Google their app signing key to export an AAB app as an APK. This gives Google quite a bit of power."

Does iOS have the same situation? This sounds so bad that I would switch. Although iOS being closed source I suppose it is just as bad or worse

pjmlp4• 5 years ago

Yes, for quite some time.

Bitcode is signed by Apple Store for watchOS and tvOS applications.

Additionaly Google is now copying Application thinning that has existed for years on iOS.

By the way, UWP Apps on Windows Store work in a similar way.

Jyaif• 5 years ago

As an app developer that does the release build and the uploading myself, having Apple and now (finally!) Google do the app thinning themselves saves me a ton of work. I'm also way more confident it's done the right way.

If you are worried about Google tampering the apps now that they sign the apps themselves, well I've got news for you: guess who owns the *OS* on which the apps run.

westurner• 5 years ago

I was just trying to explain this the other day. Not sure whether to be disappointed in is this a regression? No, bros, you may not just `repack it` and re-sign the package for me. That's not how it should work unless I trust their build server to sign for me; and I don't and we shouldn't. I'll just CC this here from https://westurner.github.io/hnlog/#comment-27410978 :

```

Unfortunately all packages aren't necessarily signed either; "Which package managers require packages to be cryptographically signed?" is similar to "Which DNS clients can operate DNS resolvers that require DNSSEC signatures on DNS records to validate against the distributed trust anchors?".
FWIW, `delv pkg.mirror.server.org` is how you can check DNSSEC:

  man systemd-resolved # nmcli
  man delv
  man dnssec-trust-anchors.d

  delv pkg.mirror.server.org

> Sigstore is a free and open Linux Foundation service for asset signatures: https://sigstore.dev/what_is_sigstore/

The TUF Overview explains some of the risks of asset signature systems; key compromise, there's one key for everything that we all share and can't log the revocation of in a CT (Certificate Transparency) log distributed like a DLT, https://theupdateframework.io/overview/
Certificate Transparency: https://en.wikipedia.org/wiki/Certificate_Transparency
Yeah, there's a channel to secure there at that layer of the software supply chain as well.
"PEP 480 -- Surviving a Compromise of PyPI: End-to-end signing of packages" (2014-) https://www.python.org/dev/peps/pep-0480/
> Proposed is an extension to PEP 458 that adds support for end-to-end signing and the maximum security model. End-to-end signing allows both PyPI and developers to sign for the distributions that are downloaded by clients. The minimum security model proposed by PEP 458 supports continuous delivery of distributions (because they are signed by online keys), but that model does not protect distributions in the event that PyPI is compromised. In the minimum security model, attackers who have compromised the signing keys stored on PyPI Infrastructure may sign for malicious distributions. The maximum security model, described in this PEP, retains the benefits of PEP 458 (e.g., immediate availability of distributions that are uploaded to PyPI), but additionally ensures that end-users are not at risk of installing forged software if PyPI is compromised.
One W3C Linked Data way to handle https://schema.org/SoftwareApplication ( https://codemeta.github.io/user-guide/ ) cryptographic signatures of a JSON-LD manifest with per-file and whole package hashes would be with e.g. W3C ld-signatures/ld-proofs and W3C DID (Decentralized Identifiers) or x.509 certs in a CT log.

```

FWIU, the Fuschia team is building package signing on top of TUF.

Google sunsets the APK format for new Android apps

Related Stories