Question: **Background**

I want to programm an android app which can detect if I enter or leave a region. Each region (lets say a building) has a BLE Beacon in advertising mode. I do know the mac adressess of the beacons.
The app shall run in background and shall be energy efficient. It is not important to recognize the region immediately, but a window of 5 minutes would be sufficient.

* On <http://developer.android.com/guide/topics/connectivity/bluetooth-le.html> its said that you should not "scan on a loop" but is there any other way to realize region enter/leave events?
* Also I am bit confused about UUIDs, Services and connections. Is it correct that these issues are **NOT** relevant to my question?
* As far as i understand from the Bluetooth specification a beacon can only handle one connection. So my app should not actually connect to any beacons if I am only interested if the beacon is nearby because connecting will stop the beacon to advertise and so other devices wont see it anymore. Is this correct?

**Related questions**

What i want to know seems to be a common question:

* [Creating background services for Bluetooth low energy on Android](https://stackoverflow.com/questions/19914244/creating-background-services-for-bluetooth-low-energy-on-android?rq=1)
* [How do Android and iOS scan for Bluetooth beacons without battery issues?](https://stackoverflow.com/questions/22535654/how-exactly-does-android-and-ios-scan-the-beacon-without-battery-issue)
* [Bluetooth Low Energy Android - Search in Background](https://stackoverflow.com/questions/19638118/bluetooth-low-energy-android-search-in-background)

but most of the answers are regarding the "Android iBeacon Library", which I don't want to use.

Answer: 
Even if you do not sure want to use the Android iBeacon Library, it is probably a good idea to look at its source code and copy ideas and or code snippets from it so you can get the advantage of the lessons that the contributors and I have learned while building it. That is the advantage of open source. 

Specific lessons related to your questions:

* Yes, you will need some kind of logic that starts and stops Bluetooth LE scans periodically, so you do need as "loop" in the broadest sense. I believe the documentation you reference is just referring to the asynchronous nature of Android's BLE scanning APIs, which have you start a scan once, then get callbacks for each device discovered. For the simplest use case, therefore, a loop is counter-productive.
* Yes, if you connect to a BLE device it will stop advertising. So unless you need to exchange more data than fits in the advertisement, do not do this. Or only connect for as very short time period.
* The term UUID has two main meanings with BLE beacons. It can mean a Service UUID, which is a unique identifier of a GATT service offered by BLE device. It can also mean a ProximityUUID, which is an Apple iBeacon-specific term for the most significant part of the three-part identifier of the beacon that gets sent in the advertisement. The two terms have nothing to do with one another. Unless you make a connectable beacon (see above) the Service UUID and GATT Service are not relevant to your task.

It is not clear from your question whether you plan to detect standard iBeacons or a custom BLE beacon. The answers above are for the more general case, but know that standard iBeacons are connectionless and do not rely on known or even static Bluetooth Mac addresses. While your question is specific to Android, if you build a custom beacon solution that you want to ever work with iOS, know that iOS scrambles Bluetooth Mac addresses in its APIs, so you can never see the real Mac address.

If you are building an Android-only solution you **can** use the Bluetooth Mac as the iBeacon identifier. But if you do so, then realize that your beacons will have identifiers that are static and cannot be easily configured on many BLE platforms. This is one reason Apple's iBeacon uses a separate ProximityUUID/major/minor scheme as a beacon identifier embedded in the advertisement.
iBeacon is merely Apple "highjacking" the Bluetooth Low Energy Advertising mechanism and trying to make money from "iBeacon certification fee" in the near future.
They put in a Manufacturer data block with their own Manufacturer ID (0x004c) which has been allocated for Apple use only.
The advertisement data is made of Length + Type + Data blocks. You should locate the Manufacturing data Type which is 0xff followed by these bytes:
<0x4c> <0x00>