In the past, a couple of LR releases had issues with some third-party software not being able to read its EXIF metadata. LR was writing EXIF metadata in a way that was standards-conforming but not commonly used. But I believe that was fixed many releases ago.
Why don't you upload a sample NEF and its exported JPEG to Dropbox and post the link here, and we might be able to troubleshoot what's going on.
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.
To fix the problem, try checking the "Optimize" box in Exportant's "Miscellaneous" filter (free by me).
It will re-write metadata in a fashion that is more likely to be readable.