[0] NSLs are not magic - https://www.youtube.com/watch?v=YN_qVqgRlx4&t=20m16s
3rd parties can download the signal source and compile it. Not sure if there's enough information available to product a bit identical (and thus verifiable binary).
I guess a NSL might compel OWS to push a binary specifically for a targetted user. If that's in your threat model you definitely need to take additional steps.
To my (admittedly fairly limited) knowledge, that's something the courts have yet to rule on. They can definitely ask to you give them any data they store about their users (and force you to keep quiet about it), but whether they could force you to develop a backdoor (and ship it to someone) remains to be seen. That's basically what the FBI vs. Apple case was about, which the FBI sadly pulled before courts got to rule on it.
https://developer.android.com/studio/publish/app-signing.htm...
If you want to install an update that was signed with a different private key, the app would need to be uninstalled first, which would also delete any sensitive data in private app storage.
This is enforced at the platform framework level, from what I loosely remember of scanning the AOSP source code.
Yes, Google could hijack packages sent to first-time downloaders. That's usually the downside with trust on first use. If the initial download isn't trustworthy, the whole verification scheme falls apart. It would be better off if Android had the APK equivalent of Certificate Transparency. That, and if Google Play made all developer-uploaded APK builds available to users, for awareness.
Android is pretty open about letting you sideload and run binaries, which you can do easily as a non-rooted end user. You can personally GitHub pull & compile the Signal app and you're good to go (w/r/t compromised software download).
