I suspect phone's time is not really correct.

What do you guys suggest?

The best way to figure out the actual time is to send a packet, and then check how long it takes you to get the response to that packet. That way you are using the same clock for both the send and the receive part of your check.

In reference to the time aspect rather than the networking aspect...

Computers change their clocks ALL THE TIME.

Computer clock time does not necessarily match wall clock time.

Computer clocks can move faster than the wall clock time.

Computer clocks can move slower than the wall clock time.

Computer clocks can move backward in time.

Computer clocks can run backwards multiple times in a row.

A day may have more than 24 hours.

A day may have less than 24 hours.

You can experience the same time more than once.

You can skip over blocks of time.

An hour may not contain 60 minutes.

Clocks still drift, my clock can go at a slightly different speed than the server's clock for many reasons.

This is one reason the header mentioned by hplus above is such a good practice. Every message that is received includes both a step-counter and an elapsed-time-counter. The drift between machines is constantly being corrected and accounted for in the simulation.

System.currentTimeMillis() uses wall-clock time. Specifically, it returns the number of milliseconds elapsed since midnight, January 1, 1970 UTC. This means that times are subject to NTP correction, interference from users changing their system clocks, and other issues. You will get better luck with System.nanoTime() (divide by 1,000,000 to get milliseconds). Although documentation suggests that implementations will be imperfect, it at least is required to be a monotonic clock. On modern Windows, Linux, and OS X, iOS, and Android; it should work suitably for your purposes.

The important thing is that the clients have to synchronize to the server's time. The first packet the server sends should contain a base timestamp, which the clients use as a reference to what the current time is on the server. Depending on your needs, you may need to send a timestamp with every packet for correction, or you might only need to send a time synchronization packet every few frames. This will be to adjust for communication latency and packet misordering, not for any inaccuracy in how the server is measuring its time.

It is important that the client also uses System.nanoTime() for prediction and correction. It's not the precision you need, millisecond precision is enough for game logic, but the regularity of the results.

This is like what frob mentioned in one of his previous posts:

To help combat some of these real life difficulties with time, most operating systems provide a way to get elapsed time from an arbitrary event, such as elapsed time from the start of your program or since the last restart.