Again that depends on how far back you are thinking to be backwards compatible.
Every year the number of users on older apis reduces, and these older users then either jump forward almost to the front (new phones, many low cost versions available today) or at least somewhat to the front (buy newer used or refurbished devices).
As Google has done quite a bit of work to try to solve some of the issues with core OS updates on third party decices (Project Treble for instance), over time the fracturing is getting better (for instance the latest API releases are bringing with them changes to how 3rd party OEMs can bundle their own Linux kernel modules so that the process is simpler and so could extend the possible software update cycles).
But there will always be some fracturing in some respects.
With that out of the way, I have not made apps with lower API requirements than 21 in the last 4 years and starting on one now I set the limit to 23.
This does not bring with it as many headaches as say when I was supporting API 15 onwards.
Google has put a lot of effort into creating tools that take care of much of the biggest headaches (for instance WorkerManager for background task execution and scheduling).
It also really depends on what parts of the platform you are going to use. If you do netwark calls, local data caching and display only then you wont have any problems that need handling.
There is sadly still this lingering sense in the dev community that Android developers need to deal with massive amounts of fragmentation. I would say it is no way as bad as it used to be, and only ever becomes apparent at the edges.
Just follow the guides that Google supplies. They are excellent and take care of explaining each possible pitfall and nuance you might need to take care of.
Every year the number of users on older apis reduces, and these older users then either jump forward almost to the front (new phones, many low cost versions available today) or at least somewhat to the front (buy newer used or refurbished devices).
As Google has done quite a bit of work to try to solve some of the issues with core OS updates on third party decices (Project Treble for instance), over time the fracturing is getting better (for instance the latest API releases are bringing with them changes to how 3rd party OEMs can bundle their own Linux kernel modules so that the process is simpler and so could extend the possible software update cycles).
But there will always be some fracturing in some respects.
With that out of the way, I have not made apps with lower API requirements than 21 in the last 4 years and starting on one now I set the limit to 23.
This does not bring with it as many headaches as say when I was supporting API 15 onwards.
Google has put a lot of effort into creating tools that take care of much of the biggest headaches (for instance WorkerManager for background task execution and scheduling).
It also really depends on what parts of the platform you are going to use. If you do netwark calls, local data caching and display only then you wont have any problems that need handling.
There is sadly still this lingering sense in the dev community that Android developers need to deal with massive amounts of fragmentation. I would say it is no way as bad as it used to be, and only ever becomes apparent at the edges.
Just follow the guides that Google supplies. They are excellent and take care of explaining each possible pitfall and nuance you might need to take care of.