As someone who’s built my company’s mobile crash reporting solution, I have a guess why they might do this.<p>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.<p>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.<p>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.<p>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.<p>Instead, we crowd source as much as we can from our employee phones.<p>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.
If the actual files are uploaded(?), doesn't this constitute reverse software piracy? Under what license are the uploaded files covered by? Can facebook require the end users to supply the source code for GPL-licensed library binaries uploaded through this system? What about proprietary oem blobs that are often covered by a no-redistribution license or EULA? What if I am an AOSP or vendor developer working on unreleased R&D next-version Android?
Okay what is the purpose of this even?<p>Sure, everyone is going to talk about fingerprinting, but let's face it, there are way easier and more reliable methods of doing that than system libraries that mostly match between same devices.<p>Must be for some sort of debugging? Still seems insane...
Apps should be statically linked and the kernel should not allow any access to the hdd or fs. Where you have to opt in to what folders the app is able to read or write to. Same for network access and any other hardware, camera, mic, etc.
How is this not utterly illegal in the EU, per GDPR? (Which was drafted to stop indiscriminate data acquisition on human subjects: I'm assuming that metadata about the core libraries on your phone, in conjunction with FB's user metadata, are trivially de-anonymizable.)