VideoLAN unable to update VLC on Android | Hacker News Reader

VideoLAN unable to update VLC on Android

twitter.com

The Tweet:

> If you wonder why we can’t update the VLC on Android version, it’s because Google refuses to let us update:

> - either we give them our private signing keys,

> - or we drop support for Android TV before API-30, and all our users on TV API<30 can’t get fixes.

I don't understand why that is an "or"? How does dropping support for older Android TV versions fix the problem for updating on regular Android?

Google doesn't allow apps on the Play Store that support deprecated API versions.

But they do if you give them your signing keys?

I still don't understand the "or".

When Google signs your app, they build the .apk bundle. JVM bytecode can be optimized without needing the source (Java or Kotlin). They actually build & sign several different bundles for different devices, optimizing each for the particular target (API level), and then serve the correct one when it's installed via the Play store. When they do this, they optimize out any calls to legacy API functions, and don't build bundles for those API versions.

A perfect opportunity for advertising F-Droid as an open-source app store and software repository for Android which has an always uptodate version of VLC.

Was thinking the same thing. For better or worse, F-Droid lists it's latest VLC version 3.5.4 from Feb 23, 2023. I don't suppose there's a custom repo with newer versions?

F-Droid allows to install development versions but it seems there aren't any for VLC.

But there are nightlies on VLC's site itself: https://nightlies.videolan.org/

Seems more like they are unwilling to update VLC on Android, as they don't want to use the Play App Signing feature.

> they don't want to use the Play App Signing feature

It's not a feature that you enable with a button and it's good to go. It's basically giving up control of your own app, even for people getting this app from non-Google app stores.

You need to give your signing key to Google and accept that Google employees (or any government asking Google nicely) can release updates to your own apps without going through you, and the user phones will accept those updates as being from the original developer because the signatures match.

With an update installed with matching signatures, the system doesn't wipe existing data from the storage and the fake update can read all of it. As a user of VLC I would not want them to use app signing keys that Google has access to.

I believe it's the only way that Google can make the App Archive feature works within the current architecture: the replace the existing app by a small shim with the same AppId to save space, and that allows the system to retain the local user-data since it's not actually uninstalled.

And when you load the shim, it redownload the app to be used again. The only way to achieve that currently is to "upgrade" or replace the app by a shim with the same digital signature, on the system will block it.

It seems another design could have been used, that would likely have been more work but wouldn't rely on getting private signing keys.

For instance, the OS could have a carve out for these shims that allows a Google-signed app to overwrite an app, but without access to its local data. Then that overriding app could delete itself when the original is re-downloaded.

It's the only design they could do that was backward-compatible though.

That does not sound reasonable, why would the shim ever need to be signed with the same key? why can't a system supporting App Archive make an exception for the shim? if it can't for hardware reason, why can't they ask key owner to sign the shim app? That would degrade security but is not as bad as requiring to give away the private key.

If they implemented this properly there wouldn't be any need for shim. So talk about ignoring signing requirements is meaningless. Adding single flag in the installed application table not to erase the application settings+icon cache would have been enough.

Using a shim application is a giant hack, allowing to implement this feature by updating only the Google Playstore without modifying the base OS and how it handles application installation and managing process. This is only relevant only because most android phone manufacturers are bad at providing Android updates. Some Google engineer probably felt very clever, that he came up a with a trick which in theory allows adding this feature to older phones that probably won't receive any Android system updates.

Google could have also allowed application developer to sign the shim. That way getting the benefits of archiving feature on older phones, without forcing app developer to give up the key.

You can but a 1TB microsd card for $21 on amazon.com. Maybe app archiving feature should be eol'd.

Seems like many phones these days come kneecapped with no SD card reader.

It is fairly uncommon for phones to come with SD card slots. It is hard to blame them, as cheap unreliable cards must lead to a lot of support issues.

I believe it's more to do with the people making the phones wanting to sell you cloud storage.

I dont think those ~$20 listings are for legit cards :) Real 1TB cards are ~$100

So not only do they have the theoretical ability to publish their own code with your private key that has full access to your apps private data, they even do it in practice?

They don't need to do any of this to keep your local data without keeping the entire app. Android phones have had the ability to uninstall apps without removing their data for some time. Any time you can install the application again and if the keys match, it has access to its data.

But that wouldn't create a good excuse for Google to ask for private keys from developers.

Reply on news.ycombinator.com