I have an APK file that contains my application running on a minimum of API 21 so that I can best support material design functions. Since Android Lollipop (API 21) only runs on 12.4% of devices, I naturally want to also support lower APIs. What is the best way for me to create my application with different layouts for both API v21 and less than v21? Should I create two different apps, one optimized for v21 and one for less than v21, or is there an easier way to go about it?
Thanks!
You should not build multiple APKs, as this becomes a maintenance nightmare.
Use the Android Support Library and the Android Design Library to take advantage of latest platform features while also backporting to earlier API levels.
Look, you can create multiple apps & you can use Androids support library.(The Android Support Library is one of the best resources for accomplishing this by taking care of the little things for you).It's always your choice to choose.
This is a common problem for many apps that have design or other optimizations that target newer platform versions (not just API 21+ ... but what about when API 25 comes along?)
There are several factors to consider before making this decision - some programming and some organizational. Android has many features to support backward compatibility within the same app. Resource folders, static methods to check the platform API, compatibility libraries. Some organizations balk at the idea of supporting multiple apps.
Here is a list that you may need to prioritize for your own environment:
Can you limit the resource folders needed to support multiple API's to an acceptable level of complexity? Managing a few additional layouts and/or image folders is pretty easy. But a tight dependency on many layouts for a single Activity or Fragment, and then supporting many screen densities along with device sizes... you may be better separating them into different apps to reduce complexity.
Do you have several nested object dependencies that require determining the device API? If you have layer upon layer of objects that all have different API requirements (Object A is for API 21+, Object B is for API 19 only, etc. and then Object AA is for API 17+ and also depends on either Object A or Object B, depending on the API) - you may be forced into single app development. Or you may be forced into creating libraries and separate APK's so you can properly test your code.
Will the business understand that "single APK" does not mean "cheaper than multiple APK's"? Sometimes dividing the development into separate APKs will reduce complexity and increase development output while decreasing the cost of QA. At other times, they will go through separate release approvals and other "red tape" activities that make separation inefficient. Also, sometimes developers will favor work in "the latest and greatest" API target and quality will suffer in the lagging target API's.
Can you support library or submodule development so that you can reuse code efficiently with multiple APK's? Once you separate the APK's, there may be a tendency to not be familiar enough with each codebase to effectively reuse components. A problem that exists in one APK may get solved without the recognition that is also solves a similar (but not exactly the same) problem in another.
Generally speaking, keeping the same codebase adds complexity with the benefit of maintaining focus on one set of code and keeping management happy. However, specific cases (such as having a notification app - where the very nature of notifications changed in Lollipop) may result in the need to create a new APK at the risk of significantly reduced support for older versions, which may be best as adoption of newer versions reaches saturation.
Google allows you to upload multiple APK's that target different API's (and even devices) for a single app. This is additional flexibility - and additional app store maintenance.
Good luck.
