3 ms·
The whole point of TFA, if you read it, is that they SAID they would do that, but there has since been ZERO evidence that they actually will. This feature is no
by bityard 8mo ago
The whole point of TFA, if you read it, is that they SAID they would do that, but there has since been ZERO evidence that they actually will. This feature is not present in anything they have released since that statement.
- lern_too_spel 8mo agoOn the other hand, blocking installation of non-notarized apps is not present in anything they released since that statement either, as far as I know.
- m4rtink 8mo agoIt would be foolish to depend on that & far harder to get ridd of it if they put it in place. There needs to be clear statement and verification method to make sure they really are backtracking. Anything else won't do.
- tadfisher 8mo agoIt's already implemented in 36.1: https://developer.android.com/sdk/api_diff/36.1/changes/android.content.pm.PackageInstaller#android.content.pm.PackageInstaller.getDeveloperVerificationServiceProvider_added https://developer.android.com/sdk/api_diff/36.1/changes/andr...()
- lern_too_spel 8mo agoThe API is implemented in 36.1, but the previously proposed notarization requirement is not enforced in any production build, so this error is never thrown. Even if they implement the scare text, this API will still be needed. If they implement what they said they would implement after the uproar, users will be better off. Previously, if a company wanted to distribute their app on their website, any user who installed it would have to dismiss scare text. Now, they have a way to distribute apps on their website without the scare text, and people who want to distribute apps without any tracking can still do that with the scare text.