Duplicate CFBundleIdentifier in copied _Testing_* overlay frameworks breaks simulator install
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 62/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- ios, shell
- Lĩnh vực
- build-system, mobile
Hướng nghiên cứu
Lỗi nằm trong vòng lặp sao chép của copy_bundle.sh, script mà giai đoạn build của InjectionNext chạy, và trong cách khắc phục tạm thời được đề xuất là fix_testing_framework_ids.sh. Bắt đầu bằng cách chạy vòng lặp PlistBuddy trong issue trên thư mục Frameworks của iPhoneSimulator trong Xcode để xác nhận rằng _Testing_CoreTransferable.framework báo cáo định danh CoreGraphics. Hoàn thành khi bản build Debug cài được lên simulator, mọi overlay Testing* đều có CFBundleIdentifier duy nhất, và script không làm gì ngoài cấu hình Debug.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Note: includes fix
Summary
copy_bundle.sh copies every Testing*.framework from the platform developer frameworks directory into the app's Frameworks/ directory. Apple ships _Testing_CoreTransferable.framework with a copy-pasted CFBundleIdentifier that duplicates _Testing_CoreGraphics.framework's. Two frameworks sharing one identifier inside a single app bundle makes installd reject the install, so any Debug build with the InjectionNext build phase fails to launch on the simulator.
Error
Please try again later. Found bundle at
/Users/<me>/Library/Developer/CoreSimulator/Devices/<UDID>/data/Library/Caches/
com.apple.mobile.installd.staging/temp.Y6ODte/extracted/Payload/Allstar.app/
Frameworks/_Testing_CoreGraphics.framework with the same identifier
(com.apple.dt.swift-testing.overlay.CoreGraphics) as bundle at
.../Frameworks/_Testing_CoreTransferable.framework
Root cause
The identifiers as shipped by Xcode:
$ D="$(xcode-select -p)/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks"
$ for f in "$D"/_Testing_*.framework; do
echo "$(basename $f): $(/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' "$f/Info.plist")"
done
_Testing_CoreGraphics.framework: com.apple.dt.swift-testing.overlay.CoreGraphics
_Testing_CoreImage.framework: com.apple.dt.swift-testing.overlay.CoreImage
_Testing_CoreTransferable.framework: com.apple.dt.swift-testing.overlay.CoreGraphics ← wrong
_Testing_Foundation.framework: com.apple.dt.swift-testing.overlay.Foundation
_Testing_UIKit.framework: com.apple.dt.swift-testing.overlay.UIKit
This is an Apple bug in the toolchain, but InjectionNext is what surfaces it: nothing else copies these overlays into a shipping app bundle. The relevant loop in copy_bundle.sh:
(cd "$PRODUCTS_DIR" && for fwork in $TESTING_FRAMEWORKS \
"$PLATFORM_DEVELOPER_LIBRARY_DIR"/Frameworks
TESTING_COPIED="$CODESIGNING_FOLDER_PATH/Frameworks/$(basename "$fwork")"
if [ -f "$fwork/Info.plist" -a ! -d "$TESTIN
rsync -a "$fwork" "$CODESIGNING_FOLDER_PATH/Frameworks" &&
codesign -f --sign "$EXPANDED_CODE_SIGN_
--preserve-metadata=identifier,entitlements,flags ... "$TESTING_COPIED"
fi
done)
Note --preserve-metadata=identifier — the bad identifier is carried through to the signature as well.
Reproduce
- Add the standard InjectionNext run-script phase to an iOS app target.
- Build & run in Debug on a simulator with an Xansferable.framework carries the CoreGraphicsidentifier.
- Install fails with the error above. Allstar.ath overlays with identical CFBundleIdentifiers.
Environment
┌───────────────┬──────────────────────┐
│ │ │
├───────────────┼──────────────────────┤
│ Xcode │ 27.1 │
├───────────────┼──────────────────────┤
│ InjectionNext │ 2.0.1 |
├───────────────┼──────────────────────┤
│ Destination │ iOS Simulator, Debug │
└───────────────┴──────────────────────┘
Suggested fix (upstream)
Derive each overlay's identifier from its own fr, and stop preserving identifier when re-signing:
(cd "$PRODUCTS_DIR" && for fwork in $TESTING_FRA
"$PLATFORM_DEVELOPER_LIBRARY_DIR"/Frameworks/_Testing_*.framework; do
TESTING_COPIED="$CODESIGNING_FOLDER_PATH/Fra")"
if [ -f "$fwork/Info.plist" -a ! -d "$TESTING_COPIED" ]; then
rsync -a "$fwork" "$CODESIGNING_FOLDER_P
# Xcode ships _Testing_CoreTransferable with CoreGraphics' identifier;
# installd rejects two bundles sharing a
OVERLAY="$(basename "$fwork" .framework)" &&
/usr/libexec/PlistBuddy -c \
"Set :CFBundleIdentifier com.apple.dt.swift-testing.overlay.${OVERLAY#_Testing_}" \
"$TESTING_COPIED/Info.plist" &&
codesign -f --sign "$EXPANDED_CODE_SIGN_IDENTITY" --timestamp=none \
--preserve-metadata=entitlements,fla
--generate-entitlement-der "$TESTING_COPIED"
fi
done)
Rewriting all overlays (rather than special-casing CoreTransferable) keeps the script correct if Apple duplicates another
identifier later.
Workaround (verified working)
For anyone hitting this before an upstream fix lld phase after the InjectionNext phase thatrepairs the copied overlays in place.
BuildScripts/fix_testing_framework_ids.sh:
#!/bin/bash
#
# Apple ships _Testing_CoreTransferable.framework with the same CFBundleIdentifier as
# _Testing_CoreGraphics.framework (com.apple.dt.Graphics).
# InjectionNext's copy_bundle.sh copies every _Testing_* overlay into the app, and
# installd refuses to install a bundle containinidentifier.
#
# Rewrite each copied overlay's identifier to ma, then re-sign.
# Must run after the InjectionNext build phase.
[[ "$CONFIGURATION" =~ Debug ]] || exit 0
FRAMEWORKS="$CODESIGNING_FOLDER_PATH/Frameworks"
[ -d "$FRAMEWORKS" ] || exit 0
shopt -s nullglob
for fwork in "$FRAMEWORKS"/_Testing_*.framework; do
plist="$fwork/Info.plist"
[ -f "$plist" ] || continue
name="$(basename "$fwork" .framework)"
want="com.apple.dt.swift-testing.overlay.${n
have="$(/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' "$plist" 2>/dev/null)"
[ "$have" == "$want" ] && continue
echo "fixing $name: $have -> $want"
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier $want" "$plist" &&
codesign -f --sign "${EXPANDED_CODE_SIGN_IDEe \
--preserve-metadata=entitlements,flags --generate-entitlement-der "$fwork"
done
Then chmod +x it and add a New Run Script Phase last (after InjectionNext):
"${SRCROOT}/BuildScripts/fix_testing_framework_i
It's idempotent, no-ops outside Debug, and --prey drops identifier so the new one makes it intothe signature.
- Ngôn ngữ chính
- Swift
- Star
- 437
- Fork
- 32
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của johnno1962/InjectionNext
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 56/100
johnno1962/InjectionNext#173 · 2 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
johnno1962/InjectionNext#167 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
johnno1962/InjectionNext#147 · 1 bình luận ·
-
Issue injecting on real device – Code signature invalid & Unhide Symbols restart loopCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
johnno1962/InjectionNext#81 · 18 bình luận · 2 reaction ·
Tất cả issue của johnno1962/InjectionNext
Issue tương tự
-
type: cleanup
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
googleapis/google-cloud-swift#1477 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
🐛 Bug Report: Console `/join` shows an endless spinner for invited users who are not signed inĐang mởproduct / auth product / console product / databases product / messaging product / self-hosted product / sites product / storage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
P1 status: first-line-handled status: needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
a2ui-project/a2ui#3282 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
binding:web core docs p3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
RunanywhereAI/runanywhere-sdks#1123 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
omacom/try-omarchy#359 ·
Maintainer thường phản hồi trong vòng 1 ngày