a557c81baf
Die Fehlermeldung führte in die Irre: "cannot be registered to your development team because it is not available" klingt nach einem Namenskonflikt mit einem fremden Team. Tatsächlich versuchte Xcode, eine App-ID anzulegen, die es schon gab — mit bereits angehakter WeatherKit-Capability. Nach dem erneuten Lauf mit -allowProvisioningUpdates wurde das passende Profil gefunden und eingebettet. Im signierten Build stehen jetzt alle sechs Entitlements: weatherkit, application-groups, personal-information.calendars, personal-information.location, automation.apple-events und device.audio-input.
70 lines
3.0 KiB
XML
70 lines
3.0 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
|
<plist version="1.0">
|
|
<dict>
|
|
<!-- Bewusst KEIN com.apple.security.app-sandbox.
|
|
|
|
Die Calendarr-Integrationsanleitung fordert die Sandbox, aber sie ist
|
|
mit Onyx unvereinbar: eine sandboxed App kann keinen privilegierten
|
|
SMAppService-Daemon registrieren (kein Lüfter, kein Ladelimit), kommt
|
|
nicht an IOKit/IOReport (kein Hardware-Monitor) und kann /usr/bin/perl
|
|
nicht so starten, dass dessen MediaRemote-Entitlement noch greift.
|
|
|
|
Der App-Group-Container ist auf macOS unabhängig von der Sandbox, solange
|
|
beide Apps im selben Team signiert sind und die Group-ID mit dem
|
|
Team-Präfix beginnt. Nachgemessen in docs/spikes/D-appgroup.md. -->
|
|
|
|
<key>com.apple.security.application-groups</key>
|
|
<array>
|
|
<string>PP34X97WS3.group.com.scarriffleservices.calendarr</string>
|
|
</array>
|
|
|
|
<!-- Das mitgelieferte MediaRemoteAdapter.framework ist ad-hoc signiert,
|
|
der Host mit Team-Zertifikat. Ohne das wird es nicht geladen. -->
|
|
<key>com.apple.security.cs.disable-library-validation</key>
|
|
<true/>
|
|
|
|
<!-- Bei aktivierter Hardened Runtime verlangt TCC diese Entitlements —
|
|
auch ohne Sandbox. Das ist die verbreitete Fehlannahme: sie gelten
|
|
nicht nur für sandboxed Apps.
|
|
|
|
Fehlt eine davon, weigert sich macOS, den Berechtigungsdialog
|
|
überhaupt anzuzeigen. Die Anfrage kommt kommentarlos mit `false`
|
|
zurück, der Status bleibt `notDetermined`, und die App taucht in den
|
|
Systemeinstellungen nie auf — dort lässt sich auch nichts von Hand
|
|
nachtragen. Der Grund steht ausschließlich im Protokoll von tccd:
|
|
|
|
"Prompting policy for hardened runtime; service: kTCCServiceCalendar
|
|
requires entitlement com.apple.security.personal-information.calendars
|
|
but it is missing"
|
|
|
|
Nachgemessen mit einer minimalen Test-App: ohne die Entitlement kein
|
|
Dialog, mit ihr sofort. -->
|
|
|
|
<!-- Kalender-Widget (Phase 3) -->
|
|
<key>com.apple.security.personal-information.calendars</key>
|
|
<true/>
|
|
|
|
<!-- Wetter am aktuellen Standort (Phase 3) -->
|
|
<key>com.apple.security.personal-information.location</key>
|
|
<true/>
|
|
|
|
<!-- AppleScript-Rückfall für Spotify und Musik (Phase 4) -->
|
|
<key>com.apple.security.automation.apple-events</key>
|
|
<true/>
|
|
|
|
<!-- Per-App-Lautstärke über Core-Audio-Taps (Phase 7). Aufgezeichnet wird
|
|
nichts; die Berechtigung heißt nur so. -->
|
|
<key>com.apple.security.device.audio-input</key>
|
|
<true/>
|
|
|
|
<!-- Wetterdaten von Apple.
|
|
Anders als die Einträge darüber genügt hier die Entitlement allein
|
|
nicht: sie erzwingt ein echtes Provisioning-Profil, und die App-ID
|
|
com.scarriffleservices.onyx muss im Developer-Portal die
|
|
WeatherKit-Capability tragen. -->
|
|
<key>com.apple.developer.weatherkit</key>
|
|
<true/>
|
|
</dict>
|
|
</plist>
|