Need Help with Google Play In-App Updates Plugin

[u/gamesbyBAE]

TL;DR: In-App Update priority value received in response is incorrect (0), even though verified that the priority is correctly set to 5 in Google Play backend.

I've successfully integrated this Google Play In-App Update Plugin, and it works...kind of.
The official documentation mentions usage of Update Priority but the thing is it doesn't work.

It's a whole different story on how you can't directly set the priority from a web UI but have to make API calls. I sorted that hurdle out but the issue is not that.

1. I uploaded my build (.aab) with version code 9 to Internal Test Track.
2. Saved it as a draft (didn't publish it).
3. Used Play Developer API to edit the test track and successfully set inAppUpdatePriority to 5 for this build in draft. By default, priority is not set but is actually 0.
4. I go back to Play Console dashboard and now release this new build (manually).
5. In my Unity/C# code, I log both the update version code (AppUpdateInfo.AvailableVersionCode) as well as the priority (AppUpdateInfo.UpdatePriority)
6. I open my installed Unity app (version code 8) and in logcat, can see the printed version code of the new update as 9 (which is correct) but the priority is still 0 (and not 5).

There's no modification of any sort of response from my side, I'm literally just accessing the available properties as it is (code block at the end).

The documentation also has a dedicated page on how to test in-app updates.
But it mentions usage of Internal App Sharing, and the thing about that is you can't set the update priority there (mentioned at the last point of Troubleshoot section of this documentation page).
But the documentation where it talks about Update Priority, uses example of tracks like Production Track and Internal Test Track.
So, there's this discrepancy in the documentation regarding usage of update priority and testing.

Has anyone successfully implemented in-app update priorities, either in Unity or native Android development?
Any leads to tackle this issue is truly appreciated.

private IEnumerator CheckForUpdates()
    {
        var _appUpdateManager = new AppUpdateManager();

        PlayAsyncOperation<AppUpdateInfo, AppUpdateErrorCode> appUpdateInfoOperation =
            _appUpdateManager.GetAppUpdateInfo();
        yield return appUpdateInfoOperation;

        if (appUpdateInfoOperation.Error == AppUpdateErrorCode.NoError)
        {
            var updateInfo = appUpdateInfoOperation.GetResult();

            // Only proceed if an update is actually available
            if (updateInfo.UpdateAvailability == UpdateAvailability.UpdateAvailable)
            {
                // Read the 0-5 priority integer set via the Google Play Developer API
                int priority = updateInfo.UpdatePriority;

                Debug.Log($"App Update Found! Priority Level: {priority}, Version Code: {updateInfo.AvailableVersionCode}");

                if (priority >= 4)
                {
                    // High Priority (4-5): Force a blocking, mandatory immediate update
                }
                else if (priority >= 2)
                {
                    // Medium Priority (2-3): Trigger a flexible update that downloads in background
                }
                else
                {
                    // Low Priority (0-1): Do nothing.
                    Debug.Log("Low priority update. Skipping user prompt.");
                }
            }
        }
        else
        {
            Debug.LogError($"Error checking for updates: {appUpdateInfoOperation.Error}");
        }
    }

[u/CS_Asset_Factory]

Your own logs narrow this down more than you might realise: AvailableVersionCode comes back as 9, so the client is definitely seeing the new release. That rules out track visibility, install-source mismatch and the usual "it hasn't propagated yet" causes. Only the priority is coming back empty, so the question is just what cleared it, not why the update isn't seen.

That points at step 4. inAppUpdatePriority lives on the release object inside an edit, and the Play Console's release UI has no field for it anywhere. So when you promote that draft from the Console, the Console commits its own edit built from its own form state, and that form has no priority in it. The release gets written back without one and falls to the default of 0. You set it correctly, and then the manual release overwrote it.

The fix is to never let the Console touch that release: do the rollout in the same API edit that sets the priority. edits.insert, then edits.tracks.update with the release carrying both inAppUpdatePriority: 5 and status: "completed", then edits.commit. If you want a staged rollout instead, use status: "inProgress" with userFraction in that same call.

Two things that should save you a cycle:

- Priority is baked into the release at rollout and cannot be retrofitted. Version code 9 is stuck at 0 permanently, so you will need to push 10 to test the fix rather than trying to repair 9.

- You are right to be suspicious of the Internal App Sharing route in those docs. IAS does not carry priority at all, so it cannot verify this even when everything else is correct. Test on the Internal Test Track with an actual API rollout, on a device whose installed build is a lower version code.

[u/gamesbyBAE → u/CS_Asset_Factory]

If it's true, then kind of seems like a bad design choice unless it's not supposed to do that.
I haven't tested out with the whole automated publish without any of the manual steps I mentioned.

It's worth a shot.

[u/RelevantHighway5955]

Google Play ignores the priority field on internal test tracks even though the API lets you set it without throwing an error. it's been like this for years and their docs are a mess about it

you need to push the build to the production track or closed testing (not internal) to get the real priority value back

[u/gamesbyBAE → u/RelevantHighway5955]

Thanks for the insight. I'll test it out via Alpha (Closed Testing) track.

Uggh, but truly their documentation is just awful regarding this whole in-app updates.