You should read RFC 5245, which describes ICE-lite in very readable terms.
ICE-lite is expected to be a stepping stone to a full ICE implementation only. If an endpoint has a full implementation, that endpoint probably will not support ICE-lite operation.
In order for ICE to be used in a call, both agents need to support
it. However, certain agents will always be connected to the public
Internet and have a public IP address at which it can receive packets
from any correspondent. To make it easier for these devices to
support ICE, ICE defines a special type of implementation called LITE
(in contrast to the normal FULL implementation). A lite
implementation doesn't gather candidates; it includes only host
candidates for any media stream. Lite agents do not generate
connectivity checks or run the state machines, though they need to be
able to respond to connectivity checks. When a lite implementation
connects with a full implementation, the full agent takes the role of
the controlling agent, and the lite agent takes on the controlled
role. When two lite implementations connect, no checks are sent.
For guidance on when a lite implementation is appropriate, see the
discussion in Appendix A.
It is important to note that the lite implementation was added to
this specification to provide a stepping stone to full
implementation. Even for devices that are always connected to the
public Internet, a full implementation is preferable if achievable.
ICE-lite is something you would run on a server. You can get away without STUN if your server uses ICE-lite and you can configure the server to send a reachable address.
I don't think Android has an ICE-lite implementation. Android devices are expected to have changing addresses, and Android already has full ICE, so there would seem little point in having ICE-lite for Android.
