> What you say sounds good, although I feel I only partially understand it. :-)
If it’s correct that normal applications don’t need the executable included Info.plist and jpackage can somehow get versions that don’t include it that seems the easiest and most hack free solution. Apple DTS did suggest including it might avoid some TCC check but I don’t know what that might be about. I don’t know how many apps try to include native commands but I have at least one non-App Store one that does. An attempt at a solution seems worthwhile rather than just throwing errors when a developer tries to get theirs into the App Store. > I assume the important point here is that the app get the > NSMicrophoneUsageDescription property, and afaict this can be provided by the > Info.plist file for the entire application, as you say. And possible the > problem here is that we embed metadata in the java executable at the same > time. Uh, this is something I again don’t understand. It seems questionable that most java applications would need this Info.plist key granting access to the microphone. https://developer.apple.com/documentation/bundleresources/information_property_list/nsmicrophoneusagedescription It should be up to the developer to include this in their application Info.plist if their application requires it. That is where I thought my earlier suggestion of allowing application post-processing before doing separate standalone signing would make sense. The current jpackage solution of allowing the developer to include a separate complete alternate Info.plist in a separate directory I found somewhat awkward. With post-processing you could include a tool like PlistBuddy https://www.unix.com/man-page/osx/8/PLISTBUDDY/ To script the Info.plist changes. I believe this is used by native OS/X applications for this purpose including from XCode. I think it is actually an Apple tool. With a funner name than usual for them. > There seems to be a lot of guessing here. :-) I assume we either need to read > up on how this works (which might be difficult if this is seem as a badly > documented corner case even by Apple tech support), or test some > alternatives, or perhaps both. > > That solution make take some time to get correct, so the jpackage team needs > to decide if they want to go with the workaround in this PR in the meantime. OK, one last possible misunderstanding on my part. The PR simply throws an error if commands are included. It doesn’t involve a workaround does it?
