Compat libraries are great. They allow us to work with the newest Android APIs, without thinking (much) about your minimum API level. Instead of thousands of devices, you can reach billions. With nearly no changes in your code. But sometimes, they’re not so great…

What is Android Things? Android Things is an alternative Android version, announced at Google I/O 2015, and released as a first developer preview in December 2016. Its purpose is to develop embedded IoT devices, with a known and widely documented Android ecosystem basis. It’s currently running on three different boards: the Intel Edison, the NXP Pico i.MX6UL, and the Raspberry Pi 3. Some higher-end boards are coming soon. On the SDK side, Android Things comes with a specific support library to ease low-level hardware usage. It consists in two parts: the Peripheral I/O API, which supports GPIO, PWM, I2C, SPI and UART, and the User Driver API, which allows a developer to write a hardware-specific, high-level driver, to ease hardware reusability by injecting events into the Android framework. Other applications can in turn use those events without having to interact with the hardware directly. There’s a downside: the bundled Android is not as complete as the one you can find on a phone. Most of the standard applications aren’t installed (Calendar, Phone…), and standard content providers are absent too (MediaProvider, Dictionary…). Android Things supports displays, with the default Android UI toolkit. However, the display is a bit different from what you’re used to seeing on an Android device: there’s no notification bar, navigation bar or anything, the running application will use the full display. That is, if it uses it at all: displays are purely optional.

With the Android M SDK (API 23), Google removed the Apache HTTP Client library. It was deprecated since API 22, and Google recommanded to use HttpURLConnection instead since API 9. While the classes are still bundled in Android 6 ROMs, it won’t be long until we see them completely go away. Some applications are still relying on this library, and need to be updated to use the SDK 23, without having time/budget/whatever required to switch from HTTP Client. While I strongly recommend you to still take time to move to something else (there are many high-level libraries, like OkHttp or Ion, or you can use HttpURLConnection to keep a low-level access), there is a way to use the Apache library while using the SDK 23.

When writing an application, you probably want it to run on most platforms possible. Having a game on Android is great, but what about this weird friend with his iPhone? It would be nice to be able to play with him. Of course there are cross-platforms technologies like Cordova or Titanium. But sadly, you can’t achieve both a perfect user experience and great performances with this kind of tools. And even if you could: what about reusing code on the back-end? We need to share some code.

Introduction to RecyclerView RecyclerView has been introduced with Android 5, in the support-v7 package. It allows to display a collection of items in an arbitrary disposition (think of a ListView, but much more flexible). As the name of the support package indicates, it’s available from the API level 7 (Android 2.1). Its name comes from the way it works: when an item is hidden, instead of being destroyed and a new one being created for each newly displayed item, hidden ones are recycled: they are reused, with new data bound on them.