And all this article is "just" about the building of the Java/Kotlin application :)
Native NDK is another can of worms, with updates linked to SDK or sometimes not, unclear documentation about device and API compatibilities, compiler behavior changes and other requirements (like the 16K one) that impact so many 3rd party native libraries.
But, of course, the rules on the uploading and the changes of the Console, that changes so often is what makes it painful.
The absolute nightmare is about giving Google the root signing key of your application, the unfinished business about app bundles (which should reduce the size of the downloaded app, and more often than not, make it bigger), the changes in compliance, letters to sign for different countries, the compatibility for Google form factors (XR, TV, Auto, Automotive), Inline installs and other Teacher Progams, Play for family and so on.
All of this changes non-stop and is very poorly documented :)
At least, the Play Store is still GPLv2 compatible, so for now, we're saved (VLC)
> The absolute nightmare is about giving Google the root signing key of your application
I wish more people talked about this. At Amazon, I helped with the early threat modeling around adoption of "App Signing by Google Play", which requires sending your app's root signing key to Google (and is now required, with no publicly-available opt-out for new apps.) It would have added some nice things for Android devs: app bundles, smaller downloads, instant apps, etc.
That said, we imagined the following scenario, and were unable to find a reasonable mitigation at the time:
It seems plausible the US government could send a NSL (or similar) to Google and force them to distribute modified APKs for apps like Signal (ex: to exfiltrate keys). This would be nearly impossible to detect, especially if the modified APK were distributed to only an individual user, or a small group. A few people raised concerns [1], but I don't recall Google ever giving a reasonable response.
Well, this is one of those HN comments that I will never forget. Someone wrote (and then removed after a buyer purchased it and required it's take down) a stylometry analyzer once for HN comments. A supposedly senior-y Google-r lambasted some Snowden slides commenting things were impossibly unimaginable inside Google (this was before it has done become widely accepted that internal services at such companies such of course be using some transport security). I got in some silly fight with someone ... 13+ years ago? These are specific things I remember. And now probably your comment.
I didn't trust stock Android before, and I felt the sinking-gut feeling as soon as I realized where "upload root signing key" was going, but spelling it out here puts a ... fine point on things.
> > The absolute nightmare is about giving Google the root signing key of your application
> It seems plausible the US government could send a NSL (or similar) to Google and force them to distribute modified APKs for apps like Signal
Since when do you have to hand over your signing keys to Google? I seem to remember the Signal devs saying that they preferred publishing their app on Google Play as opposed to F-Droid because in the former case they control the signing keys. Has this changed?
Valid reason for them is they would have to spend money on supporting and maintaining cross signing. I can image it is much much cheaper to just store priv key.
So if they can get away with it they just do it, no one is there to stop them.
> Depends of your paranoia level: either because laziness or because of evil intentions...
They disposed of the "Don't be evil" promise in a very active and energetic manner, seems like we have rational grounds for deciding, without paranoia :)
Thanks for sharing this.
I agree with your sentiment as one of my Android apps use vox SDK.
However, my experience is very limited compared to you to write about it.
> The absolute nightmare is about giving Google the root signing key of your application,
I haven't and I don't think it is required.
> the unfinished business about app bundles
Can you elaborate what's unfinished here?
> the compatibility for Google form factors (XR, TV, Auto, Automotive),
My app is disabled for Android Auto in production.
If I re-enable, then it gets rejected during the review.
I have never been able to precise fix the issue they are raising to let me re-enable Android Auto.
For Chromecast (TV), I have to run a web server inside the app to serve the media.
NDK is bad, feels like a 20% project, and I think if it wasn't for game devs, the userspace would be Java/Kotlin only, just like ChromeOS is V8 only, for all practical purposes.
However a good way to minimise headaches with NDK is to stay by the Google rules, it is a complement to Java/Kotlin, with a specific set of APIs, and not a way to pretend Android is GNU/Linux.
Also, things like debugging suddenly stopping to work after upgrading NDK/SDK versions without a peep by adb about what might be the problem. But who needs debugging right? ;)
So far, VideoLabs is hiring most of the VLC core developers and those people are the main force of development of VLC. It's setup this way so that if the Videolabs company does not live forever, VLC stays forever free, and the non-profit lives.
This is quite classic of open source projects, and in the case of VideoLAN, there are 3 or 4 companies doing consulting.
Very cool, that definitely makes sense! I've edited my comment, apologies for that. Hopefully bringing attention to the fact that you guys are easily available for hire ends up doing more good than harm.
The harm I imagine would be the reputation damage from people believing that "they are intentionally trying to mislead people into thinking that they are the developers of VLC." NoahKAndrews, having been informed that these really are the devs of VLC, is hoping his earlier, uninformed statement did not cause too many people to think poorly of VideoLabs.
I'd actually appreciate that if it's not too much trouble. I hope this feedback from an interested potential user is useful for however the design winds up :-)
In case you're curious, a few more details about this application:
- We're taking videos outdoors, so depth is longer range than usual (0m-80m). Ideally we'd love to store depth maps as single channel fp16 alongside the RGB stream. It's common in other application to store depth as int16 (e.g. as 16-bit greyscale PNGs), but if units are mm, you get overflow at 65 meters.
- In addition to depth maps, it would be interesting if we could store segmentation maps (single-channel int16), stereo footage (maybe MV-HEVC could be useful for this if it lands in ffmpeg one day), and various camera metadata (e.g. per-video epipolar matrices)
- I've briefly looked into single-channel 12-bit h264 for this application, but if the standard provides for something less hacky, that's even better! :)
I could find some discussion references on the mailing list, but nothing on the main website/wiki. Would be great if this could get documented on the website. (I'm filing a PR for endoflife.date/ffmpeg)
Isn't Nvenc (and its equivalents) based on using a specific ASIC on the GPU, rather than Vulkan which (as I understand it?) is just "regular" GPU compute?
Most GPU encoders are part ASIC, part regular GPGPU compute. That's what allowed AMD to increase the quality of their encoders via a driver update, but also why you can't add easily add entirely new codecs.
That said, outside of GPUs there are both FPGA-based and pure-ASIC hardware encoders that beat not just NVENC but even software encoding in terms of quality AND performance, such as AMD's Alveo lineup. https://www.amd.com/en/products/accelerators/alveo/ma35d.htm...
No, Vulkan has released a standard API for video encoding/decoding[1]. So you can use that to access the hardware rather than the proprietary APIs like nvenc.
The Vulkan APi calls out to the same hardware. The benefit of using it via Vulkan is that you (in theory) don’t need to have multiple APIs for different GPU vendors.
It's also meant to make it (somewhat) easier to apply various GPGPU filters and scalers before encode or after decode, like HDR tonemapping. The OS usually has some method to do this while keeping the data in the GPU VRAM by passing a handle from one API subsystem to another but if it never leaves Vulkan you don't have to worry about getting that right.
Native NDK is another can of worms, with updates linked to SDK or sometimes not, unclear documentation about device and API compatibilities, compiler behavior changes and other requirements (like the 16K one) that impact so many 3rd party native libraries.
But, of course, the rules on the uploading and the changes of the Console, that changes so often is what makes it painful.
The absolute nightmare is about giving Google the root signing key of your application, the unfinished business about app bundles (which should reduce the size of the downloaded app, and more often than not, make it bigger), the changes in compliance, letters to sign for different countries, the compatibility for Google form factors (XR, TV, Auto, Automotive), Inline installs and other Teacher Progams, Play for family and so on.
All of this changes non-stop and is very poorly documented :)
At least, the Play Store is still GPLv2 compatible, so for now, we're saved (VLC)