The LGPL requires that anybody who receives the software with a LGPL library in it to be able to change the LGPL library and link it with the application.
1. Mr. Somebody downloads and uses a fictional LocosFoo.apk extension app (not open-sourced)
2. LocusFoo.apk includes Locus data library (LGPL licensed)
3. Mr. Somebody changes the Locus data library (he has access to the sources) - lets say he changes it to swap latitude and longitude before passing it to Locus
4. Mr. Somebody MUST be able to link LocosFoo.apk against the modified library so that LocusFoo.apk runs with the modified version and swaps latitude and longitude when passing data to Locus
In C++ world, this is usually done by shared library linking, the shared library could easily be exchanged. Alternatively one can ship
the non-linked object files and the user can link it against the executable.
In pure Java world, one could unpack the .jar file and exchange the .class files. (when the .jar is not signed)
In Android world is starts to get complicated. You have to open the .apk and the .dex to get the .class files again. Then you have to pack it all together and sign it with your own private key. Before reinstalling the modified version, you have to delete the original .apk as the public key / certificate changed and all stored data of the .apk is lost. I am not sure if that is still ok with LGPL.
Adding an exception like in GNU Classpath http://http://www.gnu.org/software/classpath/license.html
might work - or even a more liberal license like the 2 clause BSD license.
Modifing the library itself might be no problem as long as the interface to Locus does not change.But you are correct - most changes do not make sense without changing Locus too. But if the developer does that in an incompatible way, he is simply asking for trouble - and he can do that anyway even with pure GPL