Igor assigning you as the owner as you were the primary for Chrome Enterprise Bug Triage on Jan 10.

Hi @Igor, 

How are you getting on with this bug? We haven't heard anything from you since January. 

We are receiving additional complaints from other clients. 

Kind regards,

Tony Gibbs.
Customer Experience Director EMEA. 
Appspace. 

Assigning to chrome/browser/extensions/updater/ OWNER

@rdevlin - can we schedule a quick discussion to explain the issue we're seeing?

I was able to reproduce this issue using a ninja on m64 stable 10176.68.0.

What are the next steps?

I'm not too familiar with the pinning mechanism.  Over to benwells@ for apps triage.

Also cc'ing some enterprise/policy folks.

Punting to atwilson as this looks very enterprise specific. Andrew - can you triage?

So, I suspect OS-pinning doesn't matter.

vaandres, can you please clarify the repro steps? Specifically, it sounds like the repro is:

1) Deploy a kiosk app with ID "abcd..."
2) Later, Deploy a different kiosk app with ID "efgh"
3) Rebooting the device doesn't switch to app #2.

Is that correct? Or do the extensions in step #1 and #2 have the same ID?

Finally, re: chrome.runtime.reload() - that's not supported in kiosk apps, it's chrome.runtime.restart() that *is* supported in kiosk apps, not the other way around per https://developer.chrome.com/apps/runtime#method-restart

Having worked with this with other clients.  This issue is has appeared since the OS pinning option has been available.

We have found that the app ID (gmdgbdlpbnhiogedlhmdiceocbgcbpgi?en=gb) is consistant no matter what version.

atwilson@

The app has the same extension ID, just minor differences inside the manifest.json

Repro steps

0. Enroll device in your domain, and move it to proper domain
1. Deploy an application in the CWS without the chrome os pinning value set inside the manifest.json(Lets call this app YYY)
2. Inside Cpanel, under device settings -> kiosk apps. Configure YYY application for auto launch. Save settings.
3. Reload policy for you device and assure application is running.
4. Update YYY's manifest.json file with OS.pinning and change the name of the application inside the manifest.json file. Save the file and publish the changes to CWS.

The application should update automatically(Depending on the policy refresh rate)and reflect the changes made for the application name in the splash screen.

vaandres: Under what circumstances does the app itself get updated? Or are you saying that it's *never* updated, no matter how long you leave the device/how often you restart it?

Also, can you provide logs (including omaha logs) so we can tell why Omaha isn't installing a new app?

If the current application(YYY) was running in kiosk mode, and the current version of that application is 0.1.5, Chrome should download the updated version of the application this case it would be 0.1.6. That version of the applications is saved locally. Once the device is rebooted,the application should update and show the changes made.

In my case the application is not being updated, I tried doing a soft reboot using the API call chrome.runtime.restart() and disconnecting the power cable.

Attaching logs

Deleted: update_engine.log 58.7 KB

update_engine.log 58.7 KB View Download

Deleted: debug-logs_20180430-140709.tgz 968 KB

debug-logs_20180430-140709.tgz 968 KB Download

I was able to get the application to update by un-enrolling the device from the current domain. Rebooting the device. Then enrolling the device to the same domain.

Is there any progress on identifying the root cause?  We have live, customer-facing deployments impacted.

Sergey, can you and Marton take a look at the logs?

Hi,

I think the issue is that the app is not updating because the new app's required_platform_version doesn't match the current platform version, and the OS is not updating because the the required_platform_version is older than the OS's current version (since it updated to the newest version when you didn't have required_platform_version set).

See also  crbug.com/673527 

Can you please check whether it's working for you if you specify always_update=true in your app's manifest like this?

  "kiosk": {
    "required_platform_version": "9765",
    "always_update": true
  },

This should ignore the required_platform_version check when checking for updates for your kiosk app, and you should get the update even if your device is ahead of the required_platform_version.

After applying that line to the manifest file, the application was successfully updated after a restart. Thanks hunyadym@

syed.husain@appspace.com@ Would you be able to verify on your end that your application updates after specifying "always_update" in your manifest file?

I'll try it later today. A question, will the OS pinning still works if I use the always_update flag?

Yes, OS pinning will continue to work: devices with older images will only update up until the pinned version (but devices with already newer images won't roll back).

always_update only applies to the kiosk app itself, not the OS.

all - just to inform you that the always_update flag works as expected. Our app got updated once we add this flag. Can we add the always_update flag information to the official documentation so that others can benefit from it? Previously when we implemented the OS pinning, we solely based on this documentation: https://support.google.com/chrome/a/answer/3316168?hl=en.

Thanks for everyone help! This should help us manage a few burning issues with our customers.

Reassigning to PM to update documentation.

Same problem here. The document should be updated.

b/116388258 for documentation