In Android Run Time (ART) environment, Garbage Collection activity could be triggered due to one of these reasons:
A concurrent GC that does not suspend app threads. This GC runs in a background thread and does not prevent allocations.
The GC was initiated because your app attempted to allocate memory when your heap was already full. In this case, the garbage collection occurred in the allocating thread.
The garbage collection was explicitly requested by an app, for example, by calling gc() or gc(). Like Dalvik, in ART, the best practice is that you trust the GC and avoid requesting explicit GCs, if possible. Explicit GCs are discouraged because they block the allocating thread and unnecessarily waste CPU cycles. Explicit GCs could also cause jank (stuttering, juddering, or halting in the app) if they cause other threads to get preempted.
The collection was caused by native memory pressure from native allocations such as Bitmaps or RenderScript allocation objects.
The collection was caused by a heap transition; this is caused by switching the GC at run time. Collector transitions consist of copying all the objects from a free-list backed space to a bump pointer space (or vice versa). Currently, collector transitions only occur when an app changes process states from a pause perceptible state to a nonpause perceptible state (or vice versa) on low RAM devices.
Homogeneous space compaction is free-list space to free-list space compaction which usually occurs when an app is moved to a pause imperceptible process state. The main reasons for doing this are reducing RAM usage and defragmenting the heap.
This is not a real GC reason, but a note that collection was blocked due to use of GetPrimitiveArrayCritical. while concurrent heap compaction is occurring. In general, the use of GetPrimitiveArrayCritical is strongly discouraged due to its restrictions on moving collectors.
This is not a GC reason, but a note that collection was blocked until a heap trim finished.
Acknowledgement: Android Developer Guide