The best practice depends on the exact usage.
What I gather from your question is that you have an app which sends you GPS data and time, like a "footprint" application. You want to ensure that you are not being fed false data, and so you want to ensure that the data is coming from your real client and not a fake.
Well, unfortunately as other answers have stated, that is impossible. Given the APK file for your app, someone can quite feasibly decompile it into Java source code, possibly not as elegant as your own source, but definitely workable. They can then use your code to build their own app, that communicates with yours in exactly the way you expect, and use it to feed you false data.
Therefore, whatever scheme you use for data transport should never trust the client. It should instead trust the user.
Consider this solution; your app server is signed with a trusted public-key certificate (it could, in this circumstance, be trusted for the sole reason that your application knows the exact certificate it should be given; this is called "certificate pinning" and it works whether you got the certificate signed by a global CA or not). Upon request, it presents this certificate to whomever asks for it; it's public information, you could plaster this thing on every hacker forum on the Internet and it would be no less secure. Your client uses this certificate to negotiate a secure communications tunnel; this is pretty standard stuff.
Now, you have confidentiality. You need authenticity; it doesn't matter that nobody else can listen to the conversation between the two of you if you don't know for sure who's on the other end. So, once the channel is open, the next thing you expect is an authentication request containing user credentials. You should reject any request to send GPS data if the session has not been authenticated. The credentials the user supplies in such a request could be their username and password, their phone's IMEI or MAC address, the 10-digit code from a crypto key fob, whatever you think is necessary to properly ensure that only a particular user could be able to provide those credentials.
Once you have those credentials and have verified that they match expectations, however you want to do that, you send them back an "authentication token". This is as simple as a random number distinct from that used for any other open session. A V4 GUID's a pretty good choice as well. This identifier will be required as part of any request to send or receive data on this channel during this session, it will only be accepted on this particular channel, and only as long as this unique session is open.
Once all this is set up, any service call that was made over that session's secure channel that includes the correct authentication token can generally be trusted. You should probably include one more thing, which is a measure to guard against replay attacks. An attacker doesn't have to know exactly what's being sent back and forth to mess you up by simply repeating what has already been said. So, to ensure that your system only deals with a unique message one time no matter how many times it's sent, each message should include a nonce, a unique value used one time. A simple sequence counter value, forming part of the request structure and encrypted by the secure channel, should suffice for this; then, all you have to do is ignore any message whose sequence number isn't the next one you expect to receive from the client (there can be some fault tolerance inherent in this, but never accept the same type of service request from the same client with the same sequence number twice).