Timur Dyushaliev

Thank you, Eric, for the explanation and for the video, which shows that the workaround solves the issue. I will try it later and let you know. But for now, the crashes on Android is more important for us and I'm working on that. If we look to the stacktrace:

       at android.os.StrictMode.onFileUriExposed(StrictMode.java:2141)
       at android.net.Uri.checkFileUriExposed(Uri.java:2391)
       at android.content.Intent.prepareToLeaveProcess(Intent.java:11848)
       at android.content.Intent.prepareToLeaveProcess(Intent.java:11797)
       at android.app.Instrumentation.execStartActivity(Instrumentation.java:1722)
       at android.app.Activity.startActivityForResult(Activity.java:5377)
       at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java)
       at android.app.Activity.startActivityForResult(Activity.java:5335)
       at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java)
       at android.app.Activity.startActivity(Activity.java:5721)
       at android.app.Activity.startActivity(Activity.java:5674)
       at zendesk.support.request.CellBindHelper.openAttachment(CellBindHelper.java:31)
       at zendesk.support.request.CellBindHelper.access$000(CellBindHelper.java)
       at zendesk.support.request.CellBindHelper$1.onClick(CellBindHelper.java:8)
   ...

we can see this function (from the "CellBindHelper" class) was called:

private void openAttachment(Context context, StateRequestAttachment requestAttachment) {
    final Intent intent = Belvedere.from(context)
            .getViewIntent(requestAttachment.getParsedLocalUri(), requestAttachment.getMimeType());
    final PackageManager manager = context.getPackageManager();
    if (manager.queryIntentActivities(intent, 0).size() > 0) {
        context.startActivity(intent);
    }
}

If I understood correctly, this function opens the file picker page. So, I think, our app crashes, because it can't in some cases pass a file's URI to the file picker page (Belvedere package) according to the docs: https://developer.android.com/reference/kotlin/android/os/FileUriExposedException

 The exception that is thrown when an application exposes a file:// android.net.Uri to another app.

But is Belvedere another app? I mean it just opens another app (for example some system app, which serves to browse files)? If it is, I can't understand why we can't reproduce this in our side. Maybe in some devices (or maybe settings, installed apps and etc) it opens another app, and in other devices it's just a page (which is within the app scope). Or maybe it's just about some privacy settings.. idk..

I want to debug this issue inside your Android SDK code to understand completely and to try to fix it. The fact that your Android SDK repository is in  jfrog, instead of usual github makes things harder to me (I wasn't able to find the repo in github). I will create a new post about this, when I collect more information and maybe come up with a fix. For now, I just think replacing "file://" prefix in URI to "content://" solves the problem, as described in docs:

Instead, apps should use content:// Uris so the platform can extend temporary permission for the receiving app to access the resource.

Aahh.. I've got this. Now I know the reason, why my message "disappeared". Its status was "Pending approval" (as well as my current reply about the workaround) and it didn't pass. But another question raises in my mind: "Why?".

And also, our crashes have been growing since I implemented attaching a file automatically (as a pre-selected file) on Android.

Logs:

CellBindHelper.java line 31
zendesk.support.request.CellBindHelper.openAttachment

Fatal Exception: android.os.FileUriExposedException: file:{path_to_file_here} exposed beyond app through Intent.getData()
       at android.os.StrictMode.onFileUriExposed(StrictMode.java:2141)
       at android.net.Uri.checkFileUriExposed(Uri.java:2391)
       at android.content.Intent.prepareToLeaveProcess(Intent.java:11179)
       at android.content.Intent.prepareToLeaveProcess(Intent.java:11128)
       at android.app.Instrumentation.execStartActivity(Instrumentation.java:1724)
       at android.app.Activity.startActivityForResult(Activity.java:5444)
       at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java)
       at android.app.Activity.startActivityForResult(Activity.java:5395)
       at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java)
       at android.app.Activity.startActivity(Activity.java:5795)
       at android.app.Activity.startActivity(Activity.java:5748)
       at zendesk.support.request.CellBindHelper.openAttachment(CellBindHelper.java:31)
       at zendesk.support.request.CellBindHelper.access$000(CellBindHelper.java)
       at zendesk.support.request.CellBindHelper$1.onClick(CellBindHelper.java:8)
       at android.view.View.performClick(View.java:7507)
       at android.view.View.performClickInternal(View.java:7484)
       at android.view.View.access$3600(View.java:839)
       at android.view.View$PerformClick.run(View.java:28689)
       at android.os.Handler.handleCallback(Handler.java:938)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loop(Looper.java:236)
       at android.app.ActivityThread.main(ActivityThread.java:8037)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)

I wasn't able to reproduce this. Maybe it's a known issue and you know the reason? Or should I open a new post?

That's weird... I was able to see the message for about 15-30 minutes. Even when I closed the web page and opened again via a link after some short period of time. But, after several hours, when I opened the web page again, my message just disappeared. Idk the reason, but nvm, that doesn't matter now.

So.. about the workaround. I didn't try it yet, but what I see from the code:

@objc private func submitRequestCompleted(notification: NSNotification){
        let helpCenter = HelpCenterUi.buildHelpCenterOverviewUi(withConfigs: [])
        self.navigationController?.popToRootViewController(animated: true)
        self.navigationController?.pushViewController(helpCenter, animated: true)
    }

The callback is called whenever a ticket is submitted. So, inside the callback we just close the current Zendesk support page and open it again, but without pre-selected file. I see 2 problems here:

1.  This (closing and reopening) will be seeable to a user because of the animations. That sounds not good.
2. Okay, the first ticket is submitted with pre-selected file. Okay, a user was able to see that the page suddenly reopened. But what about new tickets? The wanted file won't be attached to them automatically, because the reopened page will be with a new config, which doesn't include the file. We expect the file will be automatically attached to every new ticket (but not for replies), as it works on your Android SDK.

Because of these - I don't think it is a solution for us. But again.. I didn't try it yet. These are just my theoretical thoughts from what I see from the code. If I'm wrong, please let me know. I will try it in our project, but after the new year. I'm tired and took a rest from the job.

By the way. It was unpleasant to me to read that you won't fix the bug, because I'm the only one, who faced this. A problem is a problem, no matter how many people are facing it. I've even created the sample project, which illustrates the problem, so you were able to reproduce the issue and agreed there is a bug. We've been using your services for several years and paying for them. This case gives us a thought, that you won't fix problems, when we meet them.

Why did you delete my last reply, where I explained why your workaround doesn't solve the problem (and even makes worse)? And you guys really call this "Community" after it? 

Okay. Thank you Eric. Much appreciated!

I've created a simple demo project (also a free-trial demo account), which illustrates the problem. Can you please take a look? Thanks!

link to the repo: https://github.com/TimurDyushaliev/zendesk_support_ios_demo

Hey Eric. Thanks for the response. What do you mean with "a simple example application"? Should I create a demo application (which also requires me to create a demo Zendesk Support account), build it, and then distribute it to TestFlight, so you can install and reproduce the issue? Maybe I just should create a demo project, push it to Github, and then give you a link to the repo, so you can clone the project and build it?

You can reproduce the issue easily, if you have an example app, which uses the `fileAttachments` field. I guarantee you will face the same problem.

Hello there! We’re using Support SDK for iOS (and also for Android, but this topic is about iOS version). Idk, can I call this an issue, but however, when we're adding pre-selected file attachments to tickets (using the `fileAttachments` field of the `RequestUiConfiguration`) the pre-selected files attaches every time when we open a ticket screen (either if we open a new ticket, either if we open old ticket). For example: I’ve opened a ticket screen to start a new conversation, the pre-selected file is attached as expected, I’ve submitted a ticket with pre-selected file attached and everything is okay, but when I open this ticket again (for example - someone answered me) - the pre-selected file is attached again, but I’ve sent this file and don’t want to send it again. 

In iOS configuring "Request" with tags to only HelpCenterUI works very well.