Hacker News new | past | comments | ask | show | jobs | submit login

One example that is easy to explain is the runtime permission system.

IIRC this change was introduced in API 23 (marshmallow), now a while ago.

Before that Android version, permissions (such as accessing your contacts or your calendar, using the camera sensor, etc) where requested and given at installation time.

23 introduced runtime permission : now you don't get the permissions at install time but at runtime : while the app run it incrementally asks to access your contacts, camera, or whatever else it needs.

But there is an issue : how to handle all the existing apps ?

What happens is that apps declare which sdk version they are targetting when they are compiled. If that version is 23 or higher, they get the new behavior.

For apps targeting 22 or less though, the system fallbacks to the previous behavior.

This way apps don't suddenly break when you update your phone and apps already published on the play store don't have to handle this change right away.

Most apps, especially popular ones have been pretty quick to follow these new targets.

However, some apps (cough like snapchat cough) have seen a loophole there and have been keeping their target sdk very low so they don't have to follow new behaviors.

So a couple of years ago Google decided to address that : now if you want to publish a new app, you have to target an android version that is at most one year old. App updates have the same rule, although IIRC the period is a little bit longer.

So it is no longer possible to game a system that is only there to gracefully handle old apps.

I have mentioned runtime permission because it is one change that is easy to explain, but each Android version has several behavior/security changes like this one, so enforcing this rule is definitely for the best.




Thanks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: