You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Patrol is built into a release app, even when it is a dev_dependency #681
It also hints at a much bigger problem – Patrol's native code is built into an app binary in release mode, which increases its size. I haven't done any benchmarks, but gRPC which we're using isn't known for being lightweight...
(Android) Verify that Patrol's code is built into the app
Build the app (debug mode, release mode - shouldn't matter. We're a dev_dependency, so we shouldn't be included anyway).
$ flutter build apk
Use apkanalyzer to see that Patrol's code is included in the resulting dex:
# run in the directory with app's pubspec.yaml
$ apkanalyzer -h dex packages build/app/outputs/flutter-apk/app-debug.apk | grep pl.leancode.patrol | wc -l
In my case, it prints 5112, but it should be 0 instead.
The same can be done for other dev_dependencies that shouldn't land in the app binary, but they do, e.g. integration_test:
@KonAtPropertyMe I'm working on a fix (or rather a nicer workaround, because the root cause lies in Flutter itself)
For the time being, you can update to the newest Patrol (v0.10.5) and use the below script (made by @jarekb123) to remove dependency on patrol in your CI:
# This script is run before fastlane build (mainly iOS build)## It's a workaround for Apple app rejection: # ITMS-90338: Non-public API usage - The app references non-public selectors in Frameworks/patrol.framework/patrol: terminate.
cp pubspec.yaml pubspec_copy.yaml
sed '/patrol/d' pubspec_copy.yaml > pubspec.yaml
rm pubspec_copy.yaml
flutter pub get
Reacted by creativecreatorormaybenot and Pavlo Trinko
#727 introduced a workaround for this. Now the terminate() function that App Store is angry about is guarded by an #ifdef, which by default evaluates to false.
The app references non-public selectors in Payload/Runner.app/Frameworks/patrol.framework/patrol: alerts, exists, isHittable, launch, sharedDevice, tap
Oh, so that means App Store has broadened its definition of "non-public selectors". We need to get this fixed ASAP. cc @jBorkowska@mateuszwojtczak - this prevents apps that import patrol to be published on App Store.
however, another issue arises - assets from dev_dependencies are included for flutter test, and when running tests with patrol - no dev assets are bundled at all
Activity
[-]Patrol is built into a release APK[/-][+]Patrol is built into a release app, which App Store doesn't allow for[/+][-]Patrol is built into a release app, which App Store doesn't allow for[/-][+]Patrol is built into a release app[/+][-]Patrol is built into a release app[/-][+]Patrol is built into a release app, even when it is a dev_dependency[/+]bartekpacia commentedon Dec 19, 2022
(Android) Verify that Patrol's code is built into the app
Build the app (debug mode, release mode - shouldn't matter. We're a dev_dependency, so we shouldn't be included anyway).
Use apkanalyzer to see that Patrol's code is included in the resulting dex:
In my case, it prints
5112, but it should be0instead.The same can be done for other dev_dependencies that shouldn't land in the app binary, but they do, e.g.
integration_test:KonAtPropertyMe commentedon Dec 21, 2022
Got the same issue @bartekpacia. Looking forward to a fix, although it is not stopping us as we dropped back to 0.9.1 for now.
bartekpacia commentedon Dec 21, 2022
@KonAtPropertyMe I'm working on a fix (or rather a nicer workaround, because the root cause lies in Flutter itself)
For the time being, you can update to the newest Patrol (v0.10.5) and use the below script (made by @jarekb123) to remove dependency on
patrolin your CI:bartekpacia commentedon Jan 12, 2023
#727 introduced a workaround for this. Now the
terminate()function that App Store is angry about is guarded by an#ifdef, which by default evaluates to false.jeremiahlukus commentedon Mar 15, 2023
Still getting this on the latest version
bartekpacia commentedon Mar 15, 2023
Oh, so that means App Store has broadened its definition of "non-public selectors". We need to get this fixed ASAP. cc @jBorkowska @mateuszwojtczak - this prevents apps that import
patrolto be published on App Store.@jeremiahlukus For now, you can remove the
patroldependency automatically before building a binary that gets uploaded to App Store.bartekpacia commentedon Mar 17, 2023
This should be fixed (again) in v1.0.8.
bartekpacia commentedon Apr 3, 2023
This is still a problem. Yes, we do have a workaround implemented, but we'd like to see it fixed upstream :)
emakar commentedon Feb 13, 2025
this is fixed in 3.29?
flutter/flutter#161343
https://docs.flutter.dev/release/release-notes/release-notes-3.29.0
upd: nope, 3.30 likely - flutter/flutter#161828
ahlstro commentedon Mar 19, 2025
Should this be open? We are experiencing increased build time and size in release app, could it be this or is it fixed in latest patrol version?
creativecreatorormaybenot commentedon Mar 31, 2025
@ahlstro this issue is still open. Only the Flutter issue linked by @emakar is closed.
emakar commentedon Sep 12, 2025
this should be resolved now in 3.35 with flutter/flutter#160443 (comment)
however, another issue arises - assets from
dev_dependenciesare included forflutter test, and when running tests with patrol - no dev assets are bundled at all