Audio & Video not opening

[McLoo]

as they return null on getThumbnailUri().

Proceed-only-if-getThumbnailUri()-not-null check was introduced in #3412 (aa37d6e) to prevent empty image previews.

2.18.1
on CM12.1 and Z1c 5.0.2

[rhodey]

:'(

[rhodey]

some context:

I need to stop testing things on my Nexus 5. this pr doesn't actually revert all of aa37d6e and it is correct that it does not do that. the second null check in my #3412 pr is entirely unnecessary and also the source of this bug.

when I wrote aa37d6e I originally did not include that second null check, but then TS crashed in my tests, I noticed it was related to the secure media dialog and so i was like "oh, of course i should have a null check there too!" and then added it.

adding the null check solved my crash but turns out the source of the crash was actually not a null check issue but a permissions issue caused by the way I install two TextSecure apks side by side on my Nexus 5 (change of application ID and package name).

In conclusion:

1. @McLoo's PR here is not a full reversion but is correct
2. I'm not going to do the application id build flavor hack anymore

[McLoo]

@rhodey I got the feeling you're a little upset.
May I offer you a hot beverage?
3 cups of steaming open-media-espresso?

[rhodey]

@McLoo thanks :) unfortunately we can't easily test attachments related things because when you leave the app under test android test frameworks immediately pronounce the test failed, browsing through your gallery for photo, audio, or video counts as leaving the app :/

[McLoo]

I see.
Just a short note before going too off topic: I wonder if its possible to use

• code generated media
• or resources
• or a prefilled database

for that case, instead of picking something from outside. Might not cover that pick and return part and playback, but the rest of media handling?!
At minimum when In-App-Camera is merged?

[rhodey]

yeah I think it is possible for us to test these things just not as easy as others so i don't have much hope in getting a test in any time soon. ideally we would test the app in the same way the user interacts with it, so no mocks, hacks, or tricks, but I think for attachments (except for the in app camera fragment on it's way) I think we have to do some hacking by creating fake message receive jobs and attachment download jobs, etc.