This commit adds support for using directory separators / in the filename template. The separators are only allowed in the parts of the template controlled by the user (eg. outside of variables or inside the ${date:<arg>} argument). If the separator appears in any other variable, like the caller ID, it is replaced with an underscore. While . and
.. are properly handled in AOSP's FileSystemProvider (the default DocumentsProvider used when the user selects a directory on the internal storage or SD card), BCR will silently omit these path segments to avoid potential security issues when a 3rd party cloud app output directory is chosen.
All existing features are supported when subdirectories are used, including the file retention feature. However, due to the absurd slowness of Android's Storage Access Framework, using subdirectories may cause the saving of the recording (at the end of the call) to take a significant amount of time.
The slowness of SAF is primarily due to slow directory traversal and file lookup by path. SAF has no way to access a file directly. It must start from the user's chosen tree (output directory) and iterate through the path, one segment at a time. At each directory level, it must scan through each child, stat()'ing every one, until the next path segment is found. This is true even with the most optimized ContentResolver query, like we already do in findFileFast().
On devices with "good" SAF implementations, like the Pixel series, I measured between 50-100x slowdown compared to operating with raw files for these types of operations. On other devices, I suspect it will be even slower. We know from past bug reports where some devices take 8+ seconds just to check if a file exists via SAF. Those devices will likely have delays of multiple minutes if the user chooses to use subdirectories. There's nothing BCR can do to work around that.
Also, SAF has basically no guarantees with regards to safety when creating files. There are TOCTTOU issues everywhere. If the user has anything else writing to the same locations as BCR at the same time, there will likely be trouble.
This commit adds support for using directory separators
/in the filename template. The separators are only allowed in the parts of the template controlled by the user (eg. outside of variables or inside the${date:<arg>}argument). If the separator appears in any other variable, like the caller ID, it is replaced with an underscore. While.and..are properly handled in AOSP'sFileSystemProvider(the defaultDocumentsProviderused when the user selects a directory on the internal storage or SD card), BCR will silently omit these path segments to avoid potential security issues when a 3rd party cloud app output directory is chosen.All existing features are supported when subdirectories are used, including the file retention feature. However, due to the absurd slowness of Android's Storage Access Framework, using subdirectories may cause the saving of the recording (at the end of the call) to take a significant amount of time.
The slowness of SAF is primarily due to slow directory traversal and file lookup by path. SAF has no way to access a file directly. It must start from the user's chosen tree (output directory) and iterate through the path, one segment at a time. At each directory level, it must scan through each child,
stat()'ing every one, until the next path segment is found. This is true even with the most optimizedContentResolverquery, like we already do infindFileFast().On devices with "good" SAF implementations, like the Pixel series, I measured between 50-100x slowdown compared to operating with raw files for these types of operations. On other devices, I suspect it will be even slower. We know from past bug reports where some devices take 8+ seconds just to check if a file exists via SAF. Those devices will likely have delays of multiple minutes if the user chooses to use subdirectories. There's nothing BCR can do to work around that.
Also, SAF has basically no guarantees with regards to safety when creating files. There are TOCTTOU issues everywhere. If the user has anything else writing to the same locations as BCR at the same time, there will likely be trouble.
Fixes: #357