mlcommons
Create a GitHub/APK release to correspond with Play Store version
Now that we have a version of the app on the Play Store, shouldn't we release the same thing via GitHub?
Probably ought to be a normal part of our operating procedures going forward, right?
I think we should only release the Play Store version by default. If there are users who can’t access the Play Store, we can provide a separate APK as an exception. The two versions should be as similar as possible, but since they’re not exactly the same, reducing the number of versions will make maintenance, support and debugging much easier.
@anhappdev I don't know about mlperf users, but as someone who personally doesn't use google play services, I generally appreciate github or F-droid builds when available. If we automate the building process, I don't know if the build differences would be big enough to impact the benchmarks. What do you think?
@mohitmundhragithub: users in the whole China market mostly don't have access to the Google Play.
It seems that putting a release APK on GitHub is a "must".
Agreement to release on Github and PlayStore simultaneously, we may need to do Extended Testing on CI / browserstack before release/
Here is an updated hardware support list: https://docs.google.com/document/d/1lsnxbfncRZLqlWu5OiwHRLCbDGWOKj_029oE8A-T3Xg/edit?usp=sharing
How should we plan the release on both the Play Store and GitHub? Apart from the new benchmark, we've also made bug fixes and added new features. Considering these changes, what should be the release cycle?
The release process itself is through github workflow right? We are already generating both an APK along with the AAB we're using for play store, all we need to do really is edit the play store release flow to also create a tag, use it for a release, and upload the APK to that release.
As far as differences between the 2 versions, the only difference I'm aware of is that typically an AAB generated APK (basically the ones we download from the play store) only include native libraries for the specific ABI being used, whereas an APK includes all native libraries defined in build.gradle. Which should translate to no difference other than download size. The actual code being loaded and run by the device should be identical between the 2 versions.
In most cases, the Play Store version (AAB) and the APK should behave the same. However, there have been instances where the Play Store version crashed while the APK didn't. So, it's important to keep in mind that they may not be completely identical. But we can still release both versions simultaneously.
We can discuss the release flow in our weekly meeting and decide how often we want to release them. Automatically releasing the APK with every PR merge into master might not be the best approach.
- can we get an AAB and convert it back to APK or APK(s)? NOT to do this.
- just use the the APK we generated before generative AAB, usually, this APK should be fine. Note that, we ran into some issue before (assuming this is quite a rare case)..
when should we update the play store version?
- merging of every PR
- per release (backend updates, major bug fixes, etc.).
Play Store/App Store per release (backend updates, major bug fixes, etc.): SOC Integration or Regular submission
Looks the release here https://github.com/mlcommons/mobile_app_open/releases/tag/v5.0 is older than playstore version @anhappdev ?
@Mostelk Should I create a new Github release and upload the APK with the same build number as in Playstore?
Or should we release a new version with the updated about, licensing and privacy information as in https://github.com/mlcommons/mobile_app_open/pull/1025 to both Playstore and Github?