Support (handle gracefully) older Android APIs

[pwittchen]

Support (handle gracefully) older Android APIs

[pwittchen]

Sure. We can set lower min SDK. I've set this version, because BLE beacons became popular in the last years and most of recent Android apps support min SDK from about 18 (or maybe 15). I'm also not sure how device with older API will behave when library Manifest has information about BLE usage and I currently don't have older devices to test it.

Which min API version you think we should use? What should be the most proper way or place to handle potential errors caused by decreasing min SDK? Do you know what errors could occur and when? As I mentioned earlier, I don't have older devices to test it myself and I'm afraid Bluetooth apps cannot be reliably tested on emulators.

When we clarify this issue, we can update library. Moreover, Pull Requests are welcome.

[pwittchen]

I'm wondering what could be the best way to solve this problem. According to Android 4.3 APIs - Wireless section, Bluetooth Low Energy (Smart Ready) was added in API 18 (Android 4.3), which is min SDK for ReactiveBeacons and we need to declare

<uses-feature android:name="android.hardware.bluetooth_le" />

tag in the Manifest. I'm not sure if we can use such declarations in lower API levels.

[Wrywulf]

The uses-feature tag is not used by the OS itself when installing an app or running it - it is purely informational and allows eg. Google Play to filter out devices not supporting this feature (essentially hiding your app from users of those devices).

Imho the library shouldn't force this constraint on the app; if it can run (perhaps in fallback mode) without BLE it should be visible to non-BLE devices.

Regarding the minSdkVersion, I think it should be lowered to cover more devices in the wild. Personally, I'm thinking API 15 or 16. But perhaps even down to GingerBread? https://developer.android.com/about/dashboards/index.html gives an idea on how many users are left out. RxAndroid uses minSdkVersion = 9.

In any case, lowering it below API 18 requires the library to handle lower APIs runtime. I'm thinking something like throwing an exception if being initialized on devices running API < 18. This essentially forces the the app using the library to guard against using it on older APIs - which is ok imo.That could perhaps be achieved by a convenience method like isBleSupported()..

I don't know what you prefer.. but I can look at making a PR if you like?

TLDR;
As it stands, I - as an app developer using the library - both have to override the library's minSdkVersion and do runtime guards against using it. Settling with the latter would be preferable imo.

[Wrywulf]

btw, kudos for creating the lib :)

[pwittchen]

Thanks for the clear and complete explanation as well as proposed solutions. I'll figure something out and we can lower API even to 9 (same as RxAndroid), so I could be available in the next release. :-)

[pwittchen]

I've decreased min SDK to 9 and added additional method isBleSupported(). You can take a look at the updated documentation in the README.md file and view code of updated sample app to check how to use it. Decreased SDK and checking BLE support will be available in the next release.

[Wrywulf]

Cool, thx!

Do you have any plans or roadmap for the (next) releases?

[pwittchen]

Currently I don't have plans for next releases. Maybe I will take a closer look at GATT (Generic Attribute Profile) and try to use it in the library. Besides that, I'll probably and some Static Code Analysis, add sample code with Android Service and sample app in Kotlin.

If you have any ideas for the further improvements, feel free to share them through the GitHub issues.