Facebook scans system libraries on Android and uploads them to their server

Yes it does. At the very least, people running custom libraries that nobody else does would never upload data.

It appears, that FB app indeed uploads copies of specific system files: https://twitter.com/wongmjane/status/1167463077748436993

At first glance, the amount of damage being done is close to nil — even if they reverse engineer received files to steal trade secrets therein (lol), it is hard to pinpoint specific amount of harm, dealt to the copyright owners.

But actually... why are Facebook people doing that? If I were to wager a guess, Facebook needs those files to create exact copies of user systems to debug. In other words, they are trying to save up on buying real devices for their test lab! Using "pirated" copies of libraries to spin up testing VMs is most likely cheaper than owning lots of real smartphones with all available firmware versions. And also illegal.

I wonder if they gauged possibility of being sued for this along with possible legal expenses and found that it is still cheaper than buying those devices themselves.

That’s one misconception (or misnomer) about Facebook and Google. They don’t “sell or give away your data”. They sell access to you based on your data. The distinction is important if we want to pass laws limiting what they can do with your data. If there was a law passed saying they couldn’t “share your data” they would just shrug.

As someone who’s built my company’s mobile crash reporting solution, I have a guess why they might do this.

It’s is extremely difficult to diagnose Android native code crashes. Unlike iOS where it is both straightforward to unwind on the phone, and where Apple makes the iOS system symbols available for symbolizing system frames in a stack trace, neither of these things are true on Android.

My first approach for my company’s Android crash manager SDK was to use Google Breakpad. This works by capturing a snapshot of stack memory at the time of the crash. Unwinding then occurs on a backend server. But to unwind successfully, absent a frame pointer register, you need unwind info to provide to the unwinder. This simply isn’t available except for Nexus devices for which you can download the system images from Google. And even on devices where the code was compiled with a frame pointer, you still need symbols so you know what each frame’s function was.

Another approach is to unwind on the device. In my experience, using libunwind, this is successful about 50% of the time. It also risks hanging the app, which looks even worse to the user than just crashing.

Years ago, I briefly considered having our crash SDK, optionally and with user consent, extract the symbols and unwind data from the libraries on the device and upload them to our backend. I dismissed it as too expensive to do on a user’s phone.

Instead, we crowd source as much as we can from our employee phones.

Android native code crashes remain a bear to diagnose. Especially annoying since Android itself collects a ton of diagnostic data about your app when it crashes - it just doesn’t make it easily, or in some cases at all, accessible to the app itself.

Except it's not the data that's protected by copyright laws. ...and that it's not the original file is what makes it ethically palatable that Facebook is doing this without explicitly notifying the users that it's happening, although they damn well should have because it represents a profound change in the relationship.