I'm inclined to assign this task to the server for security and integrity reasons, but i'm not sure on the way i can accomplish that.
Yes, definitely; never trust clients. Clients sometimes "predict" what is likely to happen to help isolate the user's graphical experience from their network conditions, but any actions that could affect the outcome of the game should be validated by the server, which has final authority. That does not mean that the server has to manually "OK" each action. If the server detects cheating, the client is disconnected. If the server disagrees with the client's prediction, the client is killed. So, the fact that they have not been killed or disconnected by the server automatically tells clients they're good.
How can I communicate this timer information between my client (Android app) my server and my database? Should I communicate to the server every second in which state my timer is? Should I even do this on the server (i.e., should the timer run on the client)?
For one, again, never trust clients to do anything critical. The clients can maintain their own "timers" but they are, again, purely for graphical fidelity.
I think you may be confused about the client and server roles. The server is "the timer". Clients can make educated guesses about what has probably happened, but nothing has actually happened on any client until it's already happened on the server. So, aside from the graphical reasons, there is no reason for clients to "timer" anything; the only "timer" actually required is the Update() loop on the server.
In that loop, the server will accumulate real time into discrete chunks of "what just happened", referred to as "ticks", and then dispatch those ticks to the clients for consumption. In many games, the client-side frame-rate, and the server-side tick-rate, are independent. Clients with higher frame-rates move through time in smaller chunks, but will still progress from tick to tick at the same rate as all other clients. Since the game occurs during the server-side ticks and not during the client-side frames, we can use the (constant) tick-rate to measure spans of time in ticks.
For example:
-30Hz tick-rate (each tick is 33.3mS)
-Player confirms build in tick 300
-Building takes 10 seconds to build
10 seconds / 0.03333333 seconds = 300 ticks
Since the server controls the creation and processing of ticks, and all clients move through ticks at the same rate, the "current tick" on any machine is a measurement from tick 0 (the beginning of the game) and can be used as an absolute timestamp to represent any past, present, or future event.
Absolute:
Rather than ask a timer: "Is it done yet?", "How bout now?", "Now?", etc., etc. The server can just calculate (once) that it will be finished in tick 600 (300 + 300). The server does not need any more information from the client; during tick 600, the client is notified of completion.
Counting:
Alternatively, you can tell the server (during tick 300) that a new building has 300 ticks worth of construction left to do. You can decrement that number down to 0 or start at 0 and increment up to 300. While construction is proceeding, the server either increments or decrements the building's counter. Depending on the method, the building is done when the counter is either (<= 0) or (>= 300).
Building progress may be paused by the player (client sends pause command) and by the server (player has insufficient resources for server to consume during this tick). While construction is paused, the server simply skips the increment/decrement. With multiple builders helping build the same building, the server adds/subtracts more than 1, each tick.
You may wish for the server to provide occasional progress reports to the client, just to help the clients maintain their own "timers" (for graphical purposes), but this does not have to be done every anything (frame/tick/second). This is just the client and server "re-synchronizing their watches" every now and again; maybe give updates at every 10% (which also automatically provides an update at 100%). When the server processes tick 600, the client is notified that the building is actually complete.
The client may predict the building becoming active and preemptively allow the player to issue commands to it. Even though the server hasn't confirmed the building yet, the timestamp on the commands issued by the client will be after building completion. So, by the time the server evaluates them, they are, indeed, valid.
