Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ActivityNotFoundException in Instrumentation.checkStartActivityResult() #6

Closed
GoogleCodeExporter opened this issue Jun 26, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

Error report from the Android Market. No time to research it now and no helpful 
user messages to add context, but it looks like someone was trying to use ES 
File Explorer to select an import file or export folder and Cryptnos could not 
find the ES File Explorer activity. Maybe they uninstalled the app, or perhaps 
it was moved to the SD card and the user had just mounted or unmounted the 
card. (I've seen this happen if I put the device in drive mode and connect it 
to a computer. It can sometimes take several minutes before apps moved to the 
SD card to becomes available again after mounting it again.) A simple chech to 
make sure the Intent has a target available should fix this. There's already a 
method in the app to check this; I just need to put a check in whenever the 
pick file intent is created.

Stack Trace:
android.content.ActivityNotFoundException: No Activity found to handle Intent { 
act=com.estrongs.action.PICK_FILE (has extras) } at 
android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:1410) 
at android.app.Instrumentation.execStartActivity(Instrumentation.java:1380) at 
android.app.Activity.startActivityForResult(Activity.java:2817) at 
com.gpfcomics.android.cryptnos.ImportActivity$2.onClick(ImportActivity.java:262)
 at android.view.View.performClick(View.java:2461) at 
android.view.View$PerformClick.run(View.java:8888) at 
android.os.Handler.handleCallback(Handler.java:587) at 
android.os.Handler.dispatchMessage(Handler.java:92) at 
android.os.Looper.loop(Looper.java:123) at 
android.app.ActivityThread.main(ActivityThread.java:4627) at 
java.lang.reflect.Method.invokeNative(Native Method) at 
java.lang.reflect.Method.invoke(Method.java:521) at 
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:858) 
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616) at 
dalvik.system.NativeStart.main(Native Method)

Original issue reported on code.google.com by jeff.darlington@gmail.com on 2 Jul 2011 at 1:48

@GoogleCodeExporter
Copy link
Author

I've done a bit more research and it appears the hypothesis above is the most 
likely scenario. The exception is definitely being thrown when Cryptnos tries 
to launch ES File Explorer but can't seem to find it. Unfortunately, I am 
unable to reproduce the error myself. There is actually code in place within 
Cryptnos to retest for the presence of the preferred file manager before the 
Import (and also Export) UI is displayed. Thus if the preferred file manager 
has been uninstalled, Cryptnos should detect that and not even show the buttons 
to launch the file manager. That is the behavior I got when I ran through all 
my tests. How the user managed to uninstall ES File Explorer after the Import 
activity's UI was built, I don't have the faintest idea. The moved-to-SD theory 
is the only thing I can think of, and I'm not sure how to test it.

That said, I should have been catching this ActivityNotFoundException to begin 
with, regardless of the test when the UI is built. This needs to be done 
anywhere third-party intents are used, which also means the Export activity 
should have a similar check.

Original comment by jeff.darlington@gmail.com on 5 Jul 2011 at 7:35

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

This issue was updated by revision r41.


Added try/catch block around calling third-party file manager intents in both 
ImportActivity and ExportActivity. Added error text to strings.xml for the 
error message when the file manager activity is not found. Tentatively bumped 
version number up to 1.2.6, but further testing is required.

Original comment by jeff.darlington@gmail.com on 5 Jul 2011 at 7:50

@GoogleCodeExporter
Copy link
Author

Since I can't replicate the error, I'm going to have to assume that the fix 
works (and I can't see why it shouldn't). We'll call this fixed with Version 
1.2.6 unless it crops up again.

Original comment by jeff.darlington@gmail.com on 6 Jul 2011 at 1:48

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant