- with-rebreak-protection-android plugin now copies the source
accessibility_service_config.xml via withDangerousMod instead of generating
it from a string. Eliminates the silent regression where prebuild wrote
flagReportViewIds + missing packageNames, leaving Samsung's content scan
unable to read OEM dialogs.
- ProtectionOnboardingSheet refresh() now calls activateFamilyControls()
once a11y is detected as enabled, so armTamperLock() actually runs.
Previously the sheet auto-completed on getDeviceState() alone, leaving
tamper_armed=false and the service permanently passive.
- RebreakProtectionModule.isAccessibilityServiceEnabled() now trusts the
AccessibilityManager list as authoritative when AM is available (even when
empty). Settings.Secure fallback only kicks in if AM is null/exception.
Fixes the banner falsely showing "Schutz aktiv" when the system has
unbound the service but ENABLED_ACCESSIBILITY_SERVICES still holds the id.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Android Theme parent → Theme.MaterialComponents.DayNight.NoActionBar.Bridge
(fix BadgeDrawable crash in react-native-bottom-tabs after AccessibilityService toggle)
- Plugin with-material-theme-android keeps theme idempotent across prebuilds
- Plugin with-release-signing-android wires release signingConfig from key.properties
- Splash: align native splash image with JS BrandSplash (icon.png) to eliminate
double-splash flicker on app start
- DM: reset partner/messages/replyTo state on userId change, disable cache for
history query, switch spinner condition to isLoading||isFetching so reopens
always load fresh and never show empty-state with stale partner
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
It was commented out wholesale in 398b7b9 so the App-Store/TestFlight provisioning
profile would build (Apple hasn't granted the *Distribution* Family Controls
entitlement yet). But that also killed it for the dev-client, so denyAppRemoval /
ManagedSettings throws "NSCocoaErrorDomain:4099 — can't talk to the helper app"
when you flip the Blocker-page App-Lock.
Gate it on REBREAK_ENABLE_FAMILY_CONTROLS, set to "1" in eas.json's development
profile (internal distribution → Development entitlement, which we do have). The
preview/production profiles stay without it until Apple approves the Distribution
entitlement — then add the flag there too + bump buildNumber.
NOTE: the next `eas build -p ios --profile development` will re-provision the main
app profile to include the entitlement; if Apple turns out NOT to have granted the
*Development* one either, that build will fail the same way the TestFlight one did.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The EAS error message "Xcode 14 resource bundle signing" was a misleading wrapper.
Pulled the actual Xcode log via the EAS CLI; the real failures were:
error: Provisioning profile "...AppStore..." doesn't support the Family Controls
(Development) capability.
error: Provisioning profile ... doesn't include the com.apple.developer.family-controls
entitlement.
error: Signing for "RebreakURLFilter" requires a development team. (in target
'RebreakURLFilter' from project 'ReBreak')
Two fixes:
1. Family Controls is requested with Apple but not yet granted (Distribution), so
EAS can't generate an AppStore provisioning profile that includes it → comment
out the family-controls entitlement claim in withMainAppEntitlements. Re-enable
once Apple grants the entitlement. The iOS Swift code still imports
FamilyControls/ManagedSettings (public frameworks, link fine without the
entitlement); activateFamilyControls would throw at runtime — handled by the
JS layer's catch. Net: TestFlight build works, iOS App-Lock feature is dormant
until the entitlement lands.
2. The RebreakURLFilter extension target had no DEVELOPMENT_TEAM set — EAS managed
credentials only set it on the main app target; sub-targets don't inherit.
Hardcoded the team ID 84BQ7MTFYK on the extension's build configurations
(matches eas.json submit.production.ios.appleTeamId).
(The resource-bundle-signing fix from the previous attempt stays — it's
not the cause here but is correct hygiene for static-frameworks builds.)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First attempt targeted only `target_installation_results.resource_bundle_targets` —
too narrow. With privacyManifestAggregationEnabled the Pods project has additional
bundle targets (aggregated privacy manifests) that also need code-signing disabled.
Brute-force fix: set CODE_SIGNING_ALLOWED/REQUIRED = NO and clear
EXPANDED_CODE_SIGN_IDENTITY on every target in installer.pods_project — pod
targets don't need signing, only the main app does. Added a Pod::UI.puts so we
can see the fix run in the EAS build log.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
EAS iOS build failed: "Starting from Xcode 14, resource bundles are signed by
default, which requires setting the development team for each resource bundle
target." Cause: we build with useFrameworks: "static" (expo-build-properties),
so CocoaPods generates resource-bundle targets for pods with resources, and
Xcode 14+ wants them signed. EAS has no dev team for those.
New plugin with-resource-bundle-signing-fix injects into the Podfile's existing
post_install hook: sets CODE_SIGNING_ALLOWED = 'NO' for every pod resource-bundle
target (they don't need signing). Idempotent; runs as withDangerousMod('ios')
during prebuild so it survives EAS's clean prebuild.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Plugin referenced @string/accessibility_service_summary +
@xml/accessibility_service_config in AndroidManifest but never created the
underlying resource files. EAS Cloud prebuild --clean exposed this — local
dev worked because resources were sometimes already there from previous builds.
- withStringsXml: adds accessibility_service_summary string (DE)
- withDangerousMod: writes res/xml/accessibility_service_config.xml at prebuild
- Config flags match native service (TYPE_WINDOW_CONTENT_CHANGED + STATE_CHANGED,
canRetrieveWindowContent for URL-bar reading)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
