I examined your sample .jpg with Exiftool, the most authoritative metadata tool available, and I also used the following tools to examine the metadata:
OS X 10.9.5: Finder, Preview, Photoshop CC 2014, LR 5.6, exiv2
Windows 8.1: File Explorer, Irfanview 4.38
All of these were able to display the EXIF metadata, including exposure information, without problems, and Exiftool didn’t flag any nonconformities. So it seems that it’s the Android apps that aren’t conforming to the standards.
Looking at the internal structure of the LR-produced .jpg, I suspect that it is producing a layout of the IFD0, IFD1, and ExifIDF sections that the Android apps aren’t expecting (because the developers didn’t follow the standards). LR produces the following ordering: unused bytes, ExifIFD, IFD1, IFD0. A more typical ordering would be: (no unused bytes), IFD0, ExfIFD, IFD1. Both orderings conform with the standards.
You could test out this hypothesis by obtaining a copy of the free Exiftool and then in a Terminal window (Mac) or command prompt (Windows) do the following command:
exiftool –exif:usercomment=”Hello world!” sample.jpg
This will cause Exiftool to rewrite the Exif metadata in the more-common ordering. If the Android apps can now see the EXIF exposure metadata in the modified sample.jpg, then that confirms the apps are non-standards-conforming and should be fixed.