Describe the issue
This might be better in the android repo but I figure it requires cht-core work too.
We have a lot of flavours of android app now. It would be good if we could provide details around the version of the android app, which flavor(crosswalk or webiew) and the build number in the webapp. This would help to identify if there are problems with a specific version or flavor etc...
Describe the improvement you'd like
Add details to the about page to get more info about the android eco system.
Describe alternatives you've considered
None.
Right now we have some user telemetry, including userAgent, however we do not appear to capture the flavor (crosswalk or webiew) or build number. Ideally these could be captured in discrete fields instead of concatenated into a super userAgent, but that's a detail left to the implementer. See @garethbowen's notes below too.
The current code just returns the versionName from the PackageInfo (docs). We should include more information, particularly the packageName and versionCode which is a little cryptic but will uniquely identify exactly which apk is running.
This should also be included in telemetry and feedback docs.
I've added this to 3.12 to align with our other planned telemetry improvements
@garethbowen and @newtewt - I'm warming this up in prep for it to be actionable in 3.12 and had some questions (so no real rush, but when you get a sec ;)
Is this meant to be visible on the mobile device from with in the android app? So it'd be something any end user could see, yeah?
There is already a field in the About page which shows the version of the medic-android app but it's light on detail (that's what my comment was trying to get it). My proposed fix is to modify the medic-android app slightly to include more information in the string that's currently returned and then it'll magically work with existing cht-core webapps.
Additionally, are we looking to add to existing metadata we already aggregate, yeah? This would then be ferried back to couch and ultimately to couch2pg, right?
Right! That metadata is for Telemetry docs and adding this will allow us to do analysis on what apks are installed. I also proposed it be included in the Feedback docs so if we're debugging issues reported from users we can easily see if it's related to a specific apk (eg: crosswalk apk keeps crashing).
The downside of my proposed solution is by concatenating the info together in medic-android it makes it harder to do any analysis of the Feedback and Telemetry docs, for example, it would be easier to write a sql query if all the version data was stored in separate fields.
One improved solution would be to make the change as suggested above which keeps backwards compatibility, but then also provide 3 (or more) other methods to provide each piece separately. Then we can make a change to cht-core to call the three fields separately, which means we can easily query the data once cht-core has been upgraded.
OK - awesome thanks @garethbowen - all makes sense.
@marialma and @helizabetholsen - if your ears weren't burning already, they should be now ;) Again, no rush, but we're getting close to moving on these.
I suspect as we get closer 3.12, we should have a holistic look at all the telemetry tickets to ensure they all line up, compliment each other (as opposed to being in a disarray and conflicting ; )
Please allocate any time spent on this to Project | 214 Research in Clicktime.
It would be useful for us to be able to aggregate these data on cht-core across projects to ensure we understand which version of the app each partner is running currently [currently have version of cht-core included], as well as the original version [@yrimal notes that this is technically possible and he will link the ticket here], and how many times a given project has updated their version of cht-core [@mrjones-plip this would be the additional ask, I believe]
Does this make sense?
@helizabetholsen - thanks for the input! this ticket will be scoped to just showing the version and related information in the app itself per Nick's original comment.
If R&L would like to gather/aggregate this information, or other related info, we should open another with a specific feature request along with the user story as what is the intent for gathering the info.
I think having the info in telemetry data goes beyond the needs of R&L, as this is going to be extremely useful when we are debugging live incidents, eg to know if the issue is limited to particular variants. From that perspective, having this info in telemetry should be part of this issue, and not prioritized as a separate feature/issue.
@abbyad - awesome! Thanks for the input and for reaching out for the ad hoc call just now. Per our chat, I can see the value of adding the data to telemetry, especially given we may not work on this any time too soon after this ticket and the sooner we get it deployed, the sooner we can run reports that R&L mentioned above.
I'll update the title of this ticket and extend the body (but not overwrite so the conversation above stays relevant)!