ddyer0

Yea, it's all in the stub. I simply substituted "universalJavaApplicationStub" for JavaApplicationLauncher and that works great, except it's not acceptable to the app store because a raw shell script isn't...

jpackage sounds like the long term solution, but for now I can't even find a place to download it.

I finally found it - it's well concealed on macs. There's no binary called jpackager, though there is a brother of "java" called javapackager which doesn't run; and there's one...

The expected name is "jpackager" which is nowhere to be found on Macs. It's there on PCs.

After much screwing around with jpackage, I think I've got it to work. There are residual problems with code signing and info.plist, which I've solved by manually editing the info.plist...

Directly replacing JavaAppLauncher with universalApplicationStub fixes some problems, but because universalApplicationStub is a shell script, it can't be signed and can never get into the app store. If it were...

Looks promising. The safe areas seems to be somewhat larger than necessary to avoid the obstacles, but I can deal with that.

This almost solves the problem, except that when the notch is placed at the right, getSafeArea still reports that its on the left. This results in pictures like this. ...

This bug is becoming important - chromebooks run android apps fine, but they have real keyboards.

Yes, the source of the clip doesn't matter. In another variation, I made a binary in-memory file and read it using a ByteArrayInputStream; no difference.