Thanks for filing the issue!

@Reporter: From comment#0 it is understood that the issue seems to be related to ChromeOS, Could you please give a confirmation on this. Your inputs helps us to triage this further in a better way.

We are also experiencing the same issue. It is on chromeOS.Unmanaged devices build prior 2017 kiosk mode restriction policy. Please advise if issue will be addressed 

Thank you

We also have the same issue. We have a set of customer applications using kiosk mode for education. Suddenly when the change from Windows/Mac occurred kiosk apps can no longer be published new without being invalid. Old apps can be updated but if we create a new one (new id) it will be INVALID APPLICATION in the Manage Kiosk screen. Unmanaged chromebooks. Can easily replicate all day long.

https://chrome.google.com/webstore/detail/codelab-trojan/hcoppeeebabkeegbopmdannpocllhnki?authuser=2

Try loading this as a kiosk app on your Chromebook. It is the exact same code as one that was loaded a year ago and works fine. But this new on will not work. And I have many more examples.

It is URGENT (we have been waiting over a month for a solution and customers are complaining) we get a solution to this ASAP.

As per the confirmation in C#3, 4 & 5, the issue seems to be related to Chrome OS, hence adding the appropriate OS label and requesting the respective team to have a look into this and help in further triaging it.

Thanks!

Chrome devices launched in 2017 and later only support kiosk mode with a management license. This is described at:

https://support.google.com/chromebook/answer/3134673?hl=en

Can someone reporting on this issue name the device they are testing with? I suspect these are newer devices.

We experience this issue on an Asus Chromebit CS10. This device was launched on 2 november 2015, so should not have this restriction.

I am experiencing this issue on a Samsung XE303 manufactured in 2013 running OS69.

As of this weekend we're seeing the same problem with our kiosk app. We getting many reports from customers who have bought a Chromebit or Chromebox to run our kiosk app, but cannot install it anymore. I'm assuming this has to do with Google's new policy to only allow kiosk apps to run on enterprise managed devices (https://support.google.com/chromebook/answer/3134673?hl=en&vid=0-542325946619-1537256023576). But that is completely not an option for our customers: they just want to have a device that auto-starts our (digital signage) app (which is just a webview component) in full screen mode on startup. 95% of them don't need and even don't *want* device management features and all the additional complexity. 

If there is a way to get a browser to autostart in fullscreen mode when the power comes on, which doesn't involve kiosk mode, then I'm desperate to hear about out. Because with this issue (and possible this policy), ChromeOS has effectively become useless for almost all of our customers.

This is incredibly urgent for us as well! Customers are now stuck with new devices that they cannot use and new customers don't have the option anymore to go for the easiest to use and best performing gear for our application.

Absolute agree with Comment 11. We are already in the works to return ~100 Chromebits and migrating to another non-Chrome OS solution.

I feel a little bit tricked with this sudden policy change by Google. Removing perfectly working functionality to push people to a subscription model is not classy. 

What version of chrome did this break in (ie, m69, m70)?

In my tests this is on v68.0.3440.118. I don't have the version numbers that our customers are using. Another thing that I'm wondering: is this even a client-side ChromeOS issue? Or is this a server-side Webstore enforced restriction?

We reported the same issue a month ago and Google has been doing nothing to fix it - in fact they have been making it worse with each iteration. Used to work fine before then new apps would not enroll in the Manage Kiosk screen anymore. And now older applications cannot enroll anymore. We are getting tons and tons of support calls thanks to this and there is nothing we can do and Google is doing nothing to fix it causing us a great deal of grief. We have thousands of Chromebooks under use of our clients which are now looking like they need to be returned and swapped for a non-Chromebook (currently looking like iPAD) solutions.

Given this is happening in m68 it sounds like this is not a views-login regression. Passing to enterprise team to take a look.

> We reported the same issue a month ago and Google has been doing nothing to fix it

Unfortunately it took some time to triage this issue and we were not aware of it until a few days ago. We're working on getting it fixed.

We make a kiosk app for administering standardized tests. It has been working for over 2 years. With Chrome OS 68 we started getting that "invalid app" error. My test device is a 2014 ASUS C200 but customers have been getting the error with a variety of Chromebooks. Not confirmed, but so far, we are seeing that users with Chromebook Management Console can successfully push out our app -- only local installation fails when trying to add kiosk app.

Like comment 18 we have been using the "local" install for years now and we have clients depending on this feature. Its unacceptable that all of a sudden there is a money grab by Google (which they don't need) requiring a license for every install when this is not the case of other Chrome Extensions and we have so many users already using it. 

As for comment 17 its incorrect to say you were unaware of it until a few days ago. I started sending emails and reports about this months ago and spoke to numerous representatives about this.

I then added a ticket on July 27th 2018 - almost 2 months now after all those emails.
https://bugs.chromium.org/p/chromium/issues/detail?id=868412#c4

@jdufault@chromium.org, we experience this on version 68. It looks like the restriction is enforced on the server-side.

Also see  issue #870300  (https://bugs.chromium.org/p/chromium/issues/detail?id=870300) which is identical.

Fully agree with comments before. We are have many Chromebits in stock for using the kiosk app, that cannot be configured to kiosk mode anymore.

This sudden and not communicated policy change is affecting our business directly. Therefore urgent attention needed.

The error may be coming from Chrome web store when trying to look the extension. Can someone having this issue:

1) close all tabs and apps
2) open chrome://net-logs and start a log dump with full details
3) open chrome://extensions and reproduce the problem, getting the invalid error
4) save and share the logs

I started looking into this problem and I confirm that it looks like an issue with Chrome web store, or the kiosk apps themselves (how they are deployed to web store).

In order to check it, I need to know the app ids. The is only one mentioned here (comment #4), for all other cases I don't know whether they have the same problem or not as there is no info about the app.

Please, share kiosk app id that you use.
The more I'll know, the better.

@poromov, our kiosk app id = ddifhejmfpbackldjcbecpbiamfdjkkn 

(I'm making a log right now as suggested by jayhlee)

The issue with all the apps mentioned above is the same:
Webstore response error (manifest): {"inline_install_not_supported":true,"redirect_url":"https://chrome.google.com/webstore/detail/codelab-trojan/hcoppeeebabkeegbopmdannpocllhnki?utm_source=inline-install-disabled"}

The issue is a bad response from Chrome Web Store, the same as in https://crbug.com/884011
Fix is already submitted on CWS and should be rolled out later this week.

Assigning to Devlin as it's an issue with extensions metadata fetching.

@jayhlee@google.com chrome://net-logs does not exists on my Chromebit. I have used chrome://net-export now.

Please find attached the log generated while reproducing the issue ("Strip private information" was selected).

Deleted: chrome-net-export-log.json 790 KB

chrome-net-export-log.json 790 KB View Download

 Issue 870300  has been merged into this issue.

As I reported in the now merged  Issue 870300 , we're seeing this with Asus Chromebit devices running the following kiosk app.

Kiosk 5.18.0

afhcomalholahplbjhnmahkoekoijban

https://chrome.google.com/webstore/detail/kiosk/afhcomalholahplbjhnmahkoekoijban

Hopefully the fix listed in comment 25 is relevant to this, as we've got jobs on hold waiting for a resolution.

Our application id is: ocpgnjbnohdpepopekcbldfbaonljdmm

Attached is the log file of the failing installation process, generated with chrome://net-export as well, since chrome://net-logs was unknown.

Deleted: chrome-net-export-log.json 5.3 MB

chrome-net-export-log.json 5.3 MB View Download

Thanks all, seems we have what we need a fix push into production is imminent, no further logs needed.

ID: occllekdedhlehpnahgibhimdajmkdii

ID: mliihnmidndhpcepfggjgobfpoemnpek

ID: klojidkkanchpajoapoidgajmoejkebc

We have lots - so let me know if you need more ids.

Is there any way to force some older version of chromeos on the acer cxi2 devices? i just bought 3 pieces to set up and now they are useless unless i can downgrade the software. Are there any HARDWARE problems in doing this? or maybe i can just install linux on the device.
I just need it to run a webpage that reloades once a day.
How has this not been stated any where? The only reason i upgraded from asus chromebox prior 2017 devices was because they were sold out everywhere.

-FYI i tried with raspberry pi's, but this was when you had to have usb wifi. it was too unreliable. Maybe the new versions of raspberry pi are more reliable.

-thx

@jayhlee@google.com That sounds great. When can we expect this to be live? 

And lastly: I think it's important to know if this was a bug or a conscious policy change by Google that now has been (temporarily?) reverted. In the latter case it's questionable how long we can rely on this feature to be available, in which case some of us might want to revisit our long-term ChromeOS usage/sales/recommendation strategy.

Will there be any notification when the fix has been implemented? I just tried to setup a new Chromebit and still get the same error when trying to add the Kiosk app.

This was a server-side (Chrome Web Store) issue and it doesn't depend on Chrome OS version.
The fix is already implemented and merged, but it's not yet rolled into production - that's why the issue is still affecting the devices. Roll out into production should happen soon (next days), I hope to update the thread as soon as it will be alive.

@poromov@chromium.org - Why is the explanatory bug #884011 secret and inaccessible?

Totally agree with comment#33 about the need to know official support policy for 2017+ devices. That's really important.

The fix is pushed to prod. Please, try again.

Tested and confirmed working with Kiosk 5.18.0.

afhcomalholahplbjhnmahkoekoijban

https://chrome.google.com/webstore/detail/kiosk/afhcomalholahplbjhnmahkoekoijban


THANK YOU! :-D

Yes, it's working! Thank you. 

But could you please also let us know the answer to my comment #33?

Yes, please tell us if a license must be purchased to use kiosk apps on 2017 and 2018 devices. Will the CWS server stop working in the same manner at some point in the future?

Thanks for fixing! Works for me.

I happened to have a phone conversation with two Google employees on Friday. Both confirmed that once the current devices, like the Asus Chromebit are end-of-life, there will be a requirement going forward for management licenses for kiosk mode devices. One thing that I didn't ask, but thought of later is what if Google forces end-of-life for those devices by dropping support for them in future updates? I already have ~1,500 Chromebit devices out today with double that going out in the next ~6 months. Surely they wouldn't kill their functionality in an effort to force purchasing managed devices and licenses. I can surely tell you that I would immediately switch to a Linux based solution in that case.