Our customer facing the same issue sent their logs through, and I have attached them here.

Deleted: passport_chromebase_logs.zip 28.7 KB

passport_chromebase_logs.zip 28.7 KB Download

I attempted to reproduce a successful case of the Robin app on M61 build 9765.81.0, chrome 61.0.3163.120 but the app launch spins forever.

In the android log (attached) there are frequent repeats of this error:

11-09 16:45:52.486   933  1018 E ConfigFileUtils: Failed to read config file: /data/data/com.google.android.gms/app_chimera/current_fileapks.pb: open failed: ENOENT (No such file or directory)
11-09 16:45:52.493   933  1018 W ChmraDebugLogger: Suspected failure status/reason: [5] 1ff
11-09 16:45:52.529   933  1015 E ConfigFileUtils: Failed to read config file: /data/data/com.google.android.gms/app_chimera/current_fileapks.pb: open failed: ENOENT (No such file or directory)
11-09 16:45:53.102  1020  1020 W Finsky  : [1] com.google.android.finsky.application.FinskyAppImpl.ap(1090): No account configured on this device.
11-09 16:45:53.304  1020  1020 W Finsky  : [1] com.google.android.finsky.application.FinskyAppImpl.ap(1090): No account configured on this device.

Deleted: robinpowerd.log 435 KB

robinpowerd.log 435 KB View Download

I tried M62 stable build 9901.54.0, chrome 62.0.3202.74; the Robin app launches fine, but it only occupies about one-ninth of the screen (upper-left).

I have not seen any similar behavior with other apps like YouTube, ImDB, Wikipedia or Angry Birds.

The android log is attached.

The app doesn't seem to have any active widgets, either in the visible app area or anywhere else on the display.

Deleted: robin_small.log 574 KB

robin_small.log 574 KB View Download

Interesting re: #4 - perhaps the robot/laforge account wasn't injected to the Android session?

Just tried the Robin app on a Veyron-Fievel, M-64 Dev channel, build 10116.0.0, chrome 64.0.3264.0.  The Robin app launches, still occupies only about one-ninth of the screen, but this time it is centered (see attached screenshot).

Android log also attached.

Deleted: 20171110-1340.png 377 KB

	20171110-1340.png 377 KB View Download

Deleted: robin_centered.log 480 KB

robin_centered.log 480 KB View Download

As reported, the activity was launched in full screen on 61.0.3163.120 that has Android M on AOpen Chromebase Mini, but launched only in windowed mode on 62.0.3202.74 that has Android N.

I suspect that this is because of different behavior of either the app, or window management of activities in lockTaskMode() on Android M and N.

Stefan, are you aware about such difference for activities in "trusted-pinned" = "lock task" mode?

In log attached to #5 there is suspicious line:
11-09 17:28:48.263   314   678 I TaskWindowPlacerArc: getResolvedRootLaunchBounds called with root activity {Pre-N-resizeable, L 960x600}

I can provide some additional context on the window settings com.robinpowered.rooms application applies.

Let me know if I can provide additional information that may be helpful. Here's a few points of interest:

AndroidManifest.xml Screen support:
```
<supports-screens android:smallScreens="false"
  android:normalScreens="false"
  android:largeScreens="true"
  android:xlargeScreens="true"
  android:requiresSmallestWidthDp="511" />
```

AndroidManifest.xml Activity configuration
```
<activity
  android:name=".MainActivity"
  android:label="@string/app_name"
  android:configChanges="keyboard|keyboardHidden|orientation|screenSize"
  android:windowSoftInputMode="adjustResize">
```

MainActivity applies window and layout settings:
- WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON
- WindowManager.LayoutParams.BRIGHTNESS_OVERRIDE_NONE
- Sets the following SystemUIVisibility:
  View.SYSTEM_UI_FLAG_LAYOUT_STABLE
    | View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
    | View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
    | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION
    | View.SYSTEM_UI_FLAG_FULLSCREEN
    | View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY

Two more cases with this issue: 14061329, 14219946
Please let me know if you need debug logs/screenshots/etc

Assigning to Stefan per #8 to provide feedback on windows behavior in lock task mode on NYC vs MNC.

Hi Stefan, any news on this issue? Please let me if you need any additional info. thank you

Hello! Sarry that I didn't see this earlier. ARC++ issues are usually only posted on buganizer and therefore I am only (busy / swamped) there. :)

The application you are looking it is a of type M. That app is not resizable and due to a high level decision in that case we default to phone size by default.

Having said that. We are currently investigating if - for tablet devices - we want to change this behavior.

Hi team! Do we have any update in this matter?

Is there anything we can recommend for an app developer to do to update their app to display as desired?

Hi team, 

Do we have any update on this matter?

Thanks in advance.

Customer claims that Android applications he was using in Kiosk mode used to be working properly in full screen a few months ago, hence it may not be related to the type M. 
Has something been changed regarding that type recently? Is it possible that the type M had not been "honored" or simply had been ignored in ARC++ at that time?

This issue is still occurring on Veyron-Tiger 

Stable version 10176.68.0 64.0.3282.144

attaching logs

Deleted: imageOne.jpg 938 KB

	imageOne.jpg 938 KB View Download

Deleted: logcat.txt 306 KB

logcat.txt 306 KB View Download

Deleted: debug-logs_20180215-100217.tgz 643 KB

debug-logs_20180215-100217.tgz 643 KB Download

skuhne@, can you please have another look? Was something changed recently so application stopped resizing properly as it had been doing all the time?

I did recently land a patch which will auto maximize legacy (M and prior) applications to the full screen.

However that change will come with M66 and that is a while out.

Kurt, can you have a quick look?

Hi - Emily here from Robin. Glad to hear that you've been able to reproduce and a fix is in the works. 

We have a large customer in the travel industry interested in purchasing hundreds of Chromebook mini devices with the expectation that our app is able to run in full screen as expected -- they're looking to roll out early Q2. What's the likelihood this will be addressed on the Chrome side by then? Anything we need to do on our end as app developers?  Thanks! 

@skuhne/pengxuhui,

- Any updates on the possibility of merging the patch to M65? This issue blocks Chrome kiosk deployment for multiple enterprise customers.
- Which release did the patch land in M66? ChromeOS Beta will soon reach M66. If the patch is included there, we can at least test it to confirm the issue resolution.

Not sure that that would work as we just got the UX review ok for this feature. Omri?

Created mirror bug in b/74808004 as Android only issues are usually not be looked at in the Chromium database.

The customer has shared a video of kiosk app behavior on v66:

https://drive.google.com/open?id=1DLTFpLwpu9xjOsgqz0fdiP9tmlIwIJ-j

It doesn't start at all. I requested debug logs.

Debug logs provided by customer:

https://drive.google.com/open?id=1754bzuvMXijvIBTnGTiqZdM49_KbvDqB

ykrychala - can you please add the additional information going forward in our buganizer entry as this is a pure ARC++ issue and therefore looked at in that database?

I've added an update from customer in b/74808004

 Issue 781393  has been merged into this issue.

Any update on this one that we can pass along to our shared customers? 

Any updates on this issue? We have some shared customers ready to deploy fleets of AOpen Chromebase Minis, but are held back on this particular issue.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Looks like the owner left Chrome. Stefan, could you please re-triage it?

This issue is still open, and has prevented our shared customers from deploying AOpen Chromebase Minis. Steps to reproduce, symptoms, and logs are attached above in this thread. 

Hi emily@ could you clarify which App you're still having issues with? I believe all apps need to be compiled for Android N. If need be the developers will need to be contacted to confirm it's compatible with the correct version of Android and make sure that that's not causing the issue.

Kiosk is currently using our NYC implementation of ARC++.

As this implementation is currently frozen, there will be no work on this. 
However... a fix is really simple from the customer side!!!

Recompile the application for at least of API level 24 / 25 (Nougat or Nougat MR1). With that it becomes resizeable and should automatically fill (please also check that the app does not require to be portrait only as that would not make much sense for Kiosk).

Note that you will have to do this anyways as the PlayStore does not accept submissions from earlier API levels anymore since 1st Nov 2018. You can alternatively add to the manifest file one of our meta flags which only have an effect on ChromeOS:

https://developer.android.com/topic/arc/window-management#launch_size

I hope this helps!

Thank you for the update skuhne@. 

I will mark this as Archived for now since there seems to be a work around. If comment #41 does NOT resolve your issue, please contact Support to open a Case so that the issue can be properly handled in a more timely manner.

Thank you!