The 'service' approach is fine but consumes considerable battery due to the constant polling,which I want to avoid.
Nope, the service approach does not. Infact you need to have your listeners in a service to do all this in the backend.
Connectivity listeners for wifi and data are the only way to do it. If you dont use wifi, testing will be a nightmare (imagine testing on a 2g network). Data listener you need to test when on highway's and bad network scenarios. Listeners behave badly, sending multiple events sometimes, and sometimes no event at all. So test this really well with wifi before you test with data. Since with data you need to get out of the office and test on real roads and undergrounds, in lift and in special modes like AIRPLANE mode. Think about this feature carefully is it worth the effort ? There are too many scenarios (real world) that can fail. The impact is huge, if it misbehaves battery, functionality and your connection server can get too many connect requests sending it into a DOS attack :).
Think about automatic connection carefully.
When I had this case, I changed the UX / UI a bit to connect when needed, adding 2 seconds to the performance of the app instead.
Edit : Testing nightmare
Yeah, coding is one part of the problem, testing can be a nightmare. Imagine getting 10 bugs a week only on this connectivity problem. Imagine a DOS attack on the server, and u wont know until you reproduce it. Servers DONT log socket connections (with time stamps). Imagine a whole 3 day effort on fixing a DOS attack caused by your own app from one customer, who was in the lift. :) I faced this shit recently. Samsung has made it impossible to do somethings in Android due to their poor customization of the framework.