ODK Collect dropping support for Android <5 in 1.26 and process for future deprecations

ODK Collect currently supports Android versions down to 4.1. The 4.x Android versions are very different from modern ones so this has caused a significant developer and QA burden.

Android 5 was released in 2014 and only about 6% of current Collect users use versions of Android <5. The biggest change coming to the next Collect version v1.26 is the start of the scoped storage migration (Collect will need to stop using /sdcard/odk for files). This is not relevant to users on Android 4.x so we have proposed simultaneously dropping support for Android 4.x which @TAB agreed on during today's call.

This means that Android 4.x users will continue to see Collect in the Play Store but that the latest version they will be able to update to is v1.25.1.

On the call, @ggalmazor asked about also dropping support for Android 5 and 6. That will be the next big milestone because once the lowest Android version supported is 7, a lot more Java 8 features will be available. @tomsmyth also asked about writing out a policy for dropping Android version support so that we don't have to revisit this question periodically.

Each of Android 5 (mostly 5.1) and 6 represent about 11% of Collect users. That's 22% of users combined who would no longer get Collect updates. That feels like a lot and I am not in favor of dropping updates for them now.

Only dropping Android 5 support has very little benefit so I think the next decision to make will be when to drop both Android 5 and 6. After that it will be much easier to develop a standard policy because the nature of Android and Android devices has changed. Before Android 7, it was generally impossible to get Android updates so if you got an Android 5.1 device, it would be an Android 5.1 device forever. More and more, it is possible to get Android release updates.

I propose we consider the transition to Android 7+ carefully based on number of Collect users affected and upcoming large features so that we can bring as much of the user base forward as possible. After that, we can develop a policy based on when new Android releases come out.

9 Likes

Sounds great Helene. Very thoughtful response. Thank you!

1 Like

Thanks for the info, @ln!

I agree with you. A combined 22% is too much, more so taking into account that our user base could be more biased towards lower Android versions.

I got excited about the opportunity to ditch Joda Time in JavaRosa :stuck_out_tongue:

1 Like

Exicitng! This will let us clean up a bunch of code. I agree about avoiding a standard policy for now as we see how Android deals with backwards compatibility moving forward.

As an example here we are using more or less 20 Crosscall phones. 25-30% run Android 4.4.2 and the others run on 6.0.1.
6.0.1 phones where bought a year ago, we will not change it quickly... In the future we will have to find strong phones with big autonomy and to be more attentive about OS updates.
I don't want to fork the discussion (I can create a new topic on the forum about that) but as an alternative I would like to try lineageos on my personal (galaxy s5 phone android 6.0.1).
Is there any feedback about how collect runs on lineageos ?

1 Like

Thanks for chiming in with your setup, @mathieubossaert!

It is a bit tricky to know what to do with a fleet of devices that has mixed Android versions. You could choose to turn off updates for all devices and stay at Collect v1.25.1 for consistency.

Yes, I think that's pretty common. I personally would like to continue shipping updates for Android 6 for at least another year or two. I'll make sure you're looped in to any discussions we may have around that next step.

The only thing that would definitely not work is Google Play Services integration. However, it shouldn't be required and there should always be a fallback for functionality that does use it. You should be able to install the Play Store and get normal Play Store app updates. If you do try it, please report back!

1 Like

Hi Helen,

I am not affraid about that and I understand how it could be tricky to maintain an app over a lot of different OS versions.
Anyway a lot of our phones don't have a google account so I do not have problem with unwanted updates (we manually install and update odk).
And I think that older phones will be still useful for forms that do not need most recent odk's features.

Yes I will try LineageOS for my personal use. I will let you know how it goes with collect.

1 Like

@LN This is extremely valuable information and I appreciate you sharing it now, even if the implementation is a ways off. This will almost certainly impact my decisions about hardware purchases. I still have several units deployed that are running Android 4 and some more recent that are on 6. I think your proposed path forward makes sense and is well thought out.

@mathieubossaert The LineageOS is intriguing. (I had to search it, as I had never heard of it.) It doesn't look like it supports what I currently have deployed (Kyocera Duraforce Pro), but maybe there's another ruggedized device in their list of devices. In any case, I'll be looking forward to your report on how this works with Collect.

2 Likes

@Greg1 after few years using "ruggedized" devices for odk, I think that a lot of more common phone, with a wter/shock proof case are doing the job as well. I just need to focus on battery duration. So it will give us more choice for cheaper phones with durable/uptodate OS

1 Like

@LN what if Android Version start to be collected as metadata or as audit parameter in order to measure impact?

That's very interesting, @mathieubossaert. If you find a device and case combination you really like, please share so others can benefit!

We get general analytics through the Play Store and that's how I can say that 6% of the user base is using Android 4.x. Of course, that doesn't tell us anything about whether those users are working on the most mission critical projects, or anything at all about what projects they're affiliated with. That's why we've typically been very conservative with dropping updates.

Do you mean that having this information would be helpful for you as a project administrator? I do agree that in cases where project admins don't control the device fleet, it would be really great for them to be able to tell at a glance whether these kinds of changes will affect their users. In general, knowing more about the devices that filled out certain forms would also help a lot with troubleshooting. It's something that has been on my mind and hopefully that we can add soon.

If I misunderstood your suggestion, @Alexander_Torrado, do let me know!

@LN about the protection case, otterbox make good ones. We used it te, years ago for a Asus pda. And my colleague @Remy_CLEMENT use it for different Samsung phones or tab.

1 Like

@LN Thanks. You understand well: It is information for project administrators.

3 Likes