From ff6a60ae26f5dc95b6ba4cb6af9c9269d0e5e5ae Mon Sep 17 00:00:00 2001 From: Peter Serwylo Date: Wed, 15 Feb 2017 10:31:41 +1100 Subject: [PATCH 1/2] Make exception more explicit by including root cause and package name. By omitting the cause of the exception, we are getting sub-standard stack traces. I suspect where the root cause is, because it is only thrown when a `PackageManager.NameNotFoundException` is thrown, but it would help if that was in the ACRA reports to stop future investigators from having to track that down. Also add the name of the package which we searched for in the exception. Knowing which apk was being uninstalled is not particularly helpful for debugging, but knowing if it is `null` or `""` is important, because that means that the `app.packageName` variable is not populated correctly. --- app/src/main/java/org/fdroid/fdroid/AppDetails.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/src/main/java/org/fdroid/fdroid/AppDetails.java b/app/src/main/java/org/fdroid/fdroid/AppDetails.java index 1def0e6ed..e1996a13d 100644 --- a/app/src/main/java/org/fdroid/fdroid/AppDetails.java +++ b/app/src/main/java/org/fdroid/fdroid/AppDetails.java @@ -993,7 +993,7 @@ public class AppDetails extends AppCompatActivity { return apk; } catch (PackageManager.NameNotFoundException e) { e.printStackTrace(); - throw new IllegalStateException("Couldn't find app while installing"); + throw new IllegalStateException("Couldn't find installed apk for " + app.packageName, e); } } From 94403d1d7e3fff89322525b956e8ee7d916a0d02 Mon Sep 17 00:00:00 2001 From: Peter Serwylo Date: Wed, 15 Feb 2017 13:36:20 +1100 Subject: [PATCH 2/2] When resuming the activity check for uninstall/install in the mean time. Fixes #854. There is a bunch of UI code which runs in `onResumeFragments()`. However it all depends on the `app` variable in `AppDetails` being up to date. There is a number of things which could've changed since last refresh, the most notable of which is that the app may have been installed/uninstalled. Thus, this particular change checks only for a difference in installed state. However it could equally do a deeper comparison between the old and new `App` objects if it becomes aparant that other state becomes stale between pause and resume in the future. It is true that this requires a database query to be run each time the activity is resumed, but it doesn't seem there is much else we can do to prevent bugs relating to stale state. --- app/src/main/java/org/fdroid/fdroid/AppDetails.java | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/app/src/main/java/org/fdroid/fdroid/AppDetails.java b/app/src/main/java/org/fdroid/fdroid/AppDetails.java index e1996a13d..857f433b6 100644 --- a/app/src/main/java/org/fdroid/fdroid/AppDetails.java +++ b/app/src/main/java/org/fdroid/fdroid/AppDetails.java @@ -432,6 +432,15 @@ public class AppDetails extends AppCompatActivity { myAppObserver); } + @Override + protected void onResume() { + App newApp = AppProvider.Helper.findHighestPriorityMetadata(getContentResolver(), app.packageName); + if (newApp.isInstalled() != app.isInstalled()) { + setApp(newApp); + } + super.onResume(); + } + @Override protected void onResumeFragments() { // Must be called before super.onResumeFragments(), as the fragments depend on the active