Closed mykola-mokhnach closed 6 months ago
fyi:
% xcrun devicectl device info files --device=00008020-000E5CDA0A23002E --domain-type=appDataContainer --username mobile --domain-identifier=com.apple.testmanagerd
21:49:20 Acquired tunnel connection to device.
21:49:20 Enabling developer disk image services.
21:49:20 Acquired usage assertion.
1 file:
Name
--------------------------------------------------
.com.apple.mobile_container_manager.metadata.plist
fyi:
% xcrun devicectl device info files --device=00008020-000E5CDA0A23002E --domain-type=appDataContainer --username mobile --domain-identifier=com.apple.testmanagerd 21:49:20 Acquired tunnel connection to device. 21:49:20 Enabling developer disk image services. 21:49:20 Acquired usage assertion. 1 file: Name -------------------------------------------------- .com.apple.mobile_container_manager.metadata.plist
Files that we are looking for are located in the Attachments
subfolder of this container, so try to add --subdirectory= Attachments
to the above command line.
o, i see.
% xcrun devicectl device info files --device=00008020-000E5CDA0A23002E --domain-type=appDataContainer --username mobile --domain-identifier=com.apple.testmanagerd --subdirectory=Attachments
23:32:46 Enabling developer disk image services.
23:32:47 Acquired usage assertion.
0 files:
hm, it means not good..? > 0 files
wait, i might be wrong. Let me keep testing
% xcrun devicectl device info files --device=00008020-000E5CDA0A23002E --domain-type=appDataContainer --username mobile --domain-identifier=com.apple.testmanagerd --subdirectory=Attachments
00:05:12 Enabling developer disk image services.
00:05:12 Acquired usage assertion.
3 files:
Name
------------------------------------
08B61FA8-80CC-47F1-A214-64988F827E7A
0C177732-2609-4117-B464-AE77D9E1B0BE
EAD01F1D-C247-4036-B577-7FFB9A03B5CC
% xcrun devicectl device copy from --device=00008020-000E5CDA0A23002E --domain-type=appDataContainer --user mobile --domain-identifier=com.apple.testmanagerd --source=Attachments/08B61FA8-80CC-47F1-A214-64988F827E7A --destination=./file.mp4
00:34:19 Acquired tunnel connection to device.
00:34:19 Enabling developer disk image services.
00:34:19 Acquired usage assertion.
succeeded in getting a file to the local file.mp4.
hm, no method to delete stored file via devicectl
...?
% xcrun devicectl device copy from --device=00008020-000E5CDA0A23002E --domain-type=appDataContainer --user mobile --domain-identifier=com.apple.testmanagerd --source=Attachments/08B61FA8-80CC-47F1-A214-64988F827E7A --destination=./file.mp4 00:34:19 Acquired tunnel connection to device. 00:34:19 Enabling developer disk image services. 00:34:19 Acquired usage assertion.
succeeded in getting a file to the local file.mp4.
hm, no method to delete stored file via
devicectl
...?
It's actually .mov rather than .mp4:
file 577EA9E0-4C93-4DE1-AE5E-8489A29590FA
577EA9E0-4C93-4DE1-AE5E-8489A29590FA: ISO Media, Apple QuickTime movie, Apple QuickTime (.MOV/QT)
Regarding file deletion, I've added a workaround https://github.com/appium/WebDriverAgent/pull/858/files#diff-f437ff5a0a8b42227214d5e8edf7bba1aa8ca97eb4a9632f8f95394996b19b7eR49, although I can only observe files are deleted after WDA quits completely (calling /wda/shutdown
)
From native API perspective it is only possible to initiate file deletion via
@protocol XCTMessagingRole_AttachmentsDeleting
- (id)_IDE_deleteAttachmentsWithUUIDs:(NSSet *)arg1;
@end
protocol. This protocol is solely implemented by XCTMessagingChannel_IDEToDaemon
channel, which means it could only be called via an "external" tunnel interface (which appium-ios-device does not support, same as we don't support images mounting).
I confirmed when the WDA process ended with the shutdown endpoint, the created files were removed
i wonder if we should block this endpoint for real devices with a security flag to avoid accidental usage at least in appium-xcuitest layer
let me check if reset device (erase all data) could remove remained files
[update] I have also confirmed erase all data removed all files as well created by this. So it would be probably nice to leave comment or document in XCTest driver erase all data can remove these created files.
lgtm, overall
@Dan-Maor Do you have anything to add?
Sorry, it has been a hectic few days at the office so I wasn't able to look into it.
I would like to run some tests with my devices, however I'm working from home today and the device I have here at the moment failed to start recording with a "does not support screen recording" error (iOS 15.7).
I will be at the office tomorrow and will run some tests as soon as I can.
I would like to run some tests with my devices, however I'm working from home today and the device I have here at the moment failed to start recording with a "does not support screen recording" error (iOS 15.7).
this is expected. The feature has been added by Apple only since Xcode 15/iOS 17
:tada: This PR is included in version 7.1.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
The XCUITest Driver already had a method to record the screen, which would also make available a stream of the screen. This new feature is just about recording the screen or can it also be used to stream it in a better way?
The XCUITest Driver already had a method to record the screen, which would also make available a stream of the screen. This new feature is just about recording the screen or can it also be used to stream it in a better way?
It cannot be used for streaming as we only get the recorded video at the very end when we call the stop API
It is a resurrection of https://github.com/appium/WebDriverAgent/pull/724 with some major changes.
I was able to figure out that videos are actually available, but cannot be fetched directly from WDA. Instead they are stored into the testmanagerd's container. On Simulators the path looks like
$HOME/Library/Developer/CoreSimulator/Devices/F8E1968A-8443-4A9A-AB86-27C54C36A2F6/data/Containers/Data/InternalDaemon/4E3FE8DF-AD0A-41DA-B6EC-C35E5798C219/Attachments/A044DAF7-4A58-4CD5-95C3-29B4FE80C377
Where
$HOME/Library/Developer/CoreSimulator/Devices/F8E1968A-8443-4A9A-AB86-27C54C36A2F6/
is the common Simulators containers root,InternalDaemon/4E3FE8DF-AD0A-41DA-B6EC-C35E5798C219/Attachments
is the com.apple.testmanagerd 's domain and theA044DAF7-4A58-4CD5-95C3-29B4FE80C377
is the attachment UUID, which is uniquely assigned to each screen recording future upon startup.With the above knowledge we can already fetch these videos from simulators. Need to only figure out how to get the access to this container for real devices...