Develop Reference

Is there a way to make my app constantly look for connection in the background?

I'm trying to figure out if it is plusible to make an app constantly look for any kind of internet connection so once it finds any it makes a comparison of its local database with the one in the cloud and upload anything that is not in the cloud.
I was thinking about a code that triggers every time the phone connects to the internet but my research turned to be inconclusive and I'm running out of time.

You wouldn't do it that way. There's methods of being notified when an internet connection is made in Android, but you really wouldn't even do that. Instead you'd use WorkManager to schedule a job that requires internet, and let it launch the job at an appropriate time for you. See https://developer.android.com/topic/libraries/architecture/workmanager

Firebase - Is it possible to have a "Cloud Listener" for app connection status?

I'm building an Android game which requires the user to be online while playing. I'd like to detect if a game was interrupted while playing ( the internet connection was lost \ the device was turned off, etc...),and if it was - this should be considered as a loss for the user, and be written in the database. The only thing I have in mind for now is to save this loss offline, and update it when the user goes back online.
I know I can detect app connection status like this, but it doesn't help be because I can only execute offline operations after this. I also know I can listen to writing events in the database like this, but it doesn't help me, because no child in being updated after the game is interrupted.
My question is: Is there a way to write a Cloud Function which can listen to specific app connection status? If there is no such a way, what are the other options I have?

You can use a onDisconnect() handler. This is a piece of code you run while the app is connected, that sets an operation for the server to run when it detects that the app has disconnected.
A simple example of this from the documentation:
DatabaseRef presenceRef = FirebaseDatabase.getInstance().getReference("disconnectmessage");
// Write a string when this client loses connection
presenceRef.onDisconnect().setValue("I disconnected!");
But I recommend that you read the full documentation on managing presence for more examples.
With this you can have a Cloud Function trigger on the operation of the onDisconnect handler and then update the game status.
Note that it may take a few minutes before the server detects the lost connection in case of a non-clean disconnect.

Handling keepSynced() while on background on Android and with FCM

I'm considering the use of keepSynced() for some data from Firebase Realtime Database. I understand that it will automatically sync those paths. But how does that relate to Android lifecycle? If the user leaves all activities (and all normal listeners disconnect), will it stop syncing? I don't want the app to become data or battery hog.
On the other hand, I would like to update cached data when FCM notification arrives. I can launch some service which will connect to Firebase. I would like to sync all paths which are in keepSynced() and stop it when it's synced. I'm not sure how to achieve that. Create a listener to one of the paths and keep the service running for some time? After the service is finished, will it stop syncing?

firebaser here
Great question!
When there is no active activity, the operating system may close the connection to the Firebase database at any time. Our SDKs don't try to prevent that, but will reconnect when the app becomes active again.
What you're describing in your second paragraph is what we call "push to sync", where you send a push notification (typically a silent FCM data message) to trigger synchronizing of the data.
We did something like that in last year's I/O app and, while it was a bit more complex than we wanted it to be, it worked great. We explicitly managed the connection in that case, calling goOnline() and goOffline() (after 5 minutes iirc). The main sync code can be found in the IOSched github repo.

Message queuing from android considering unreliable network

My architecture will use ActiveMQ on the server and have Android clients send and receive messages.The network situation will be very unreliable; possibly hours of missing connection. Is there a framework that will allow me to queue up the messages on the android client and deliver them reliably once the connection is back?

You can efficiently implement one yourself, I don't think anyone will provide you this service, and if they do they will certainly charge, Here is what I can suggest for an optimal solution.
Design a db using SQLITE to hold you message, once a message is ready for deliver from android client, you can perform the following
a. If network is avaibale, then you can directly deliver message to your web clinet
b. If network in not present, then cache it directly to you local android db
Design a Sync logic, you can achieve it by network listener, so when user device comes back into network,
you can write a logic to query from databse and posting to your webclient, deleting local data subsequently
upon successful posting into server
You can strengthen you logic, by caching message everytime into local db first, then a Sync logic which will commit your local changes to web server in bulk, thus improving upon processing time.
Hope this answer your problem.

What is the good practice on android app development integrated with web services?

I have developed android apps, and have a web server application which serves REST style JSON, to the apps.
My apps are strongly dependent on that web services but as traffic gets higher, users' complaint started, as force close problems. I am not sure but maybe my server (AWS small instance) may not answer all requests correctly or in time.
I am planning to retry the web request when a problem on getting json response arise instead giving the error/net-connection alert.
I guess there are many developers who integrates apps with web services, so what is the good practice on handling network problems?
Or is the frequency of such network problems acceptable?
I take about 10-20 problem per day.
I have about 200.000+ web requests per day, for a AWS small instance (1.7 RAM), dedicated to server Tomcat. I analyze the logs there is no clue, no error log. Also the errors are spreaded.

You need to start with analyzing the problem, and determine the root cause or root causes of your issues. You always need to take into account that
a network connection might drop
a users switches from 3G / WiFi
the android devices "thinks" it's connected while in fact it's not
Also, be very sceptical when using the Android ConnectivityManager / NetworkInfo. Only trust it when it states that it is not connected. If it is connected, check it yourself (as sometimes, user is on a hotspot and the only connectivity he has is with a login page).
The application needs to handle all these scenarios properly. The way it's presented to the user depends on the use-case (do you want the user to be informed of the error, do you silently ignore it and just retry, ....)
In terms of retrying webservice connections, there are several ways to implement this :
exponential backoff
periodic rescheduling
event-driven triggering
retry-after moratorium intervals
You need to start by putting sufficient logging both on the client (Android) and on the server (AWS) so that you can analyze the issues and draw the proper conclusions.

I think the answer to your problem lies in the design of your android app.
You need to take into consideration the worst case scenario and redesign your application to take that into account and recover. Dealing with the chaos monkey - jeff atwood.
Personally I never allow an android app to be in a state where it needs to force close. For any or all network connection I assume that the connection is down, lossy, not all data can be retreived and (finally) up and working correctly.
That way my app will degenerate gracefully. If it needs web access it'll make an attempt in a background thread allowing the user to continue using the app, it will cache previous requests and will retry until it gets a connection or gives a nice toast to the end user.