"Free memory" in a garbage-collected managed language is difficult to measure. If you don't have to GC, the performance-minded choice would to not GC. Every computation costs battery life, so I would suppose Android's GC is tuned to not run if it doesn't have to.

If you look at the specifications of system.gc(), it can be implemented as a placebo, like the "push to walk" button at the street corner. So even explicitly GC'ing isn't guaranteed to do anything.

Android also has a strategy for "swapping" components within a process, and whole processes. This is, effectively, Android's GC strategy across processes. An Android system's memory, especially on small-memory devices, should always look full-ish, but you can almost always launch a new task, since GC and components and process "swapping" (the "destroy" phase of component lifecycle) and GC can almost always make room for more.