Mirror the check already being done in the other fragment. As reported
via ACRA:
ANDROID_VERSION=4.4.4
APP_VERSION_NAME=0.100-alpha6
STACK_TRACE=java.lang.NullPointerException
at org.fdroid.fdroid.AppDetails$AppDetailsHeaderFragment.updateViews(AppDetails.java:1524)
at org.fdroid.fdroid.AppDetails$AppDetailsHeaderFragment.updateViews(AppDetails.java:1519)
at org.fdroid.fdroid.AppDetails.refreshHeader(AppDetails.java:624)
at org.fdroid.fdroid.AppDetails.onAppChanged(AppDetails.java:549)
at org.fdroid.fdroid.AppDetails.access$000(AppDetails.java:100)
at org.fdroid.fdroid.AppDetails$AppObserver.onChange(AppDetails.java:141)
at android.database.ContentObserver$NotificationRunnable.run(ContentObserver.java:180)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5146)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:732)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:566)
at dalvik.system.NativeStart.main(Native Method)
This was very probably introduced with the new CleanCacheService stuff.
Reported via ACRA:
ANDROID_VERSION=6.0.1
APP_VERSION_NAME=0.100-alpha6
STACK_TRACE=java.lang.NullPointerException: Attempt to get length of null array
at org.fdroid.fdroid.Utils.clearOldFiles(Utils.java:349)
at org.fdroid.fdroid.Utils.clearOldFiles(Utils.java:351)
at org.fdroid.fdroid.Utils.clearOldFiles(Utils.java:351)
at org.fdroid.fdroid.CleanCacheService.onHandleIntent(CleanCacheService.java:54)
at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:66)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.os.HandlerThread.run(HandlerThread.java:61)
There is nothing to clear if the directory could not be obtained for
some reason, so this seems like a reasonable fix. Anything is better
than a crash anyway.
See the following crash reported via ACRA:
java.lang.NullPointerException
at org.fdroid.fdroid.net.DownloaderService.getNotificationTitle(DownloaderService.java:188)
at org.fdroid.fdroid.net.DownloaderService.createNotification(DownloaderService.java:167)
at org.fdroid.fdroid.net.DownloaderService.handleIntent(DownloaderService.java:274)
at org.fdroid.fdroid.net.DownloaderService$ServiceHandler.handleMessage(DownloaderService.java:107)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.os.HandlerThread.run(HandlerThread.java:61)
I'm not sure what the source of the null App was (could be that we
couldn't access the DB for some reason, or perhaps that somehow the app
wasn't in it anymore). In any case, it doesn't hurt to double check
here.
If the app is null, simply fall back to the title without the app name.
For some reason, even when showing the entire description some words at
the end of lines and paragraphs still get cut off. This results in
little parts of the description being completely inaccessible.
Ellipsizing is just cosmetic, so ditch it on 2.X altogether. I tested
and proved that this fixes the issue with an android-10 x86 emulator,
after reproducing the bug.
Keep the ellipsizing on newer versions, as it doesn't misbehave on
those.
Fixes#510.
The only remaining error was ClipboardCompat, which was unnecessarily
exposing three top-level classes. Make the two implementation classes be
nested, private and static.
Installer UI updates and lint fixes
This updates UI classes of the installer to reflect the changes of AOSP's installer and fixes some lint errors.
* No more differentiation between personal and device permissions (didn't even notice that there was a differentiation here...)
* Icon for "other" permission group
I carefully merged only the changes from AOSP that are related to us and decided against maintaining different versions of the AppSecurityPermissions.
There will be more changes and discussions to the installer UI coming in the next days.
See merge request !277
Translators:
Adrià García-Alzórriz Spanish
Alberto Moshpirit Spanish
Danial Behzadi Persian
Enol P Asturian
Kristjan Räts Estonian
Marcelo Santana Portuguese (Brazil)
Mohamad Hasan Al Banna Indonesian
Verdulo Esperanto
Verdulo Polish
CleanCacheService
This creates `CleanCacheService` to do all of the cache clean up at the lowest possible priority. It also adds a preference to set how long to keep cached APKs.
See merge request !260
Updater speed improvements during "Saving Application Details"
I've been able to reproduce #324 OutOfMemory errors on an emulator with 12MiB of heap space. This branch did _not_ have an OOM error when updating with F-Droid and F-Droid Archive repos enabled. They successfully update without problem.
Fixes#45.
The "Saving Application Details" stage of repository updating is where each apk has its suggested version calculated, icon URLs calculated, etc. These all require [correlated subqueries](https://en.wikipedia.org/wiki/Correlated_subquery) resulting in a full scan of the apk table for each row in the app table. This takes in the order of 25 seconds on my Moto X 2nd Gen.
This branch improves this process by doing the queries in an [sqlite in-memory database](https://sqlite.org/inmemorydb.html), with the results transferred to the database on disk when done. The time required drops from 25 seconds to ~0.5 seconds on my device.
*Note:* I was hoping this would also improve the "Processing ..." Part of the udpater, given it was inserting into an in memory table instead of on disk. If it did have any effect, it was negligible though, so that part is still likely slower than it could be. Each 50 apps (and their associated apks) takes between 150ms and 500ms on my Moto X.
*Secondary Note:* When creating the in memory database, I create indexes for some columns as per before. This technically should slow down the inserts we do, however in practice they had almost no effect. As such, I've left the index creation there because it is required for the correlated subqueries to not suck.
See merge request !269
Security-sensitive code should not be changed unless there is a good reason
to do so. It is too easy to introduce bugs. This change does not address
an issue, so I'm reverting it. See comment in javadoc header for the class.
This reverts commit 2074718391c2c17a974218bc6565cce2dc05407e for just the
RepoUpdater.java file.
This schedules CleanCacheService to run regularly, and delete files older
than the value set in the new "Keep cached apps" preference. It auto-
migrates the old "Cache packages" pref to the new one. The default cache
time for people who did not have "Cache packages" enabled is one day.
This moves the cache file deletion to a dedicated IntentService that runs
at the lowest possible priority. The cache cleanup does not need to happen
with any kind of priority, so it shouldn't delay the app start or take any
resources away from foreground processes.
This also changes the logic around the "Cache packages" preference. The
downloader always saves APKs, then if "Cache packages" is disabled, those
APKs are deleted when they are older than an hour.
This also simplifies Utils.deleteFiles() since the endswith arg is no
longer needed.
* if there is a file there, remove it
The paths are all from the system, so are safe. No SanitizedFile is needed.
Plus, this method was not checking if the original and sanitized versions
where different, and instead just creating the sanitized version. I worry
that could cause odd bugs.
By putting these comments into javadoc, they are directly describing the
code where it is, and there are many tools in IDEs for searching, viewing,
sorting, etc. javadoc comments. Plain comments do not have those tools.
Fixes for priv extension install
For now, disable install of privileged extension on Android >=5.1 until we found better methods.
Also, fix crash of dialogs on Android 6 using a workaround for transparent activities and some code simplifications.
See merge request !259
This increases the speed of the complex queries required at the end
of the update process to:
* calculate suggested version codes
* figure out icon urls
* etc,
by two orders of magnitude.
This was there as a workaround for #1, but that has subsequently
been fixed. Thus, the hack is no longer required. Also removed an
additional `AND` because it is already performed in the `JOIN`.
I supsect this last one would've been eliminated by the sqlite
optimizer anyway, but the query is slightly simpler now.
This fix doesn't improve performance as much as I'd hoped, but it
is something.
Translators:
Danial Behzadi Persian
fastest noob Turkish
Fert Bálint Hungarian
Green Lunar Hebrew
Jean-Baptiste French
Karola Marky Japanese
Kristjan Räts Estonian
Licaon Kter Romanian
Marian Hanzel Slovak
Mohamad Hasan Al Banna Indonesian
naofum Japanese
Tobias Bannert German
YFdyh000 Simplified Chinese
Added cancel action to notifications.
See merge request !267
This happened to me when I clicked on an app link for a new app which
was already in the repo, but I had not ran an index update yet since the
app got built. Stack trace prior to the fix follows.
java.lang.RuntimeException: Unable to destroy activity {org.fdroid.fdroid/org.fdroid.fdroid.AppDetails}: java.lang.NullPointerException:
Attempt to invoke virtual method 'void android.support.v4.content.LocalBroadcastManager.unregisterReceiver(android.content.BroadcastReceiver)' on a null
object reference
at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3865)
at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:3883)
at android.app.ActivityThread.-wrap5(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1417)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5461)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void
android.support.v4.content.LocalBroadcastManager.unregisterReceiver(android.content.BroadcastReceiver)' on a null object reference
at org.fdroid.fdroid.AppDetails.unregisterDownloaderReceivers(AppDetails.java:469)
at org.fdroid.fdroid.AppDetails.onDestroy(AppDetails.java:569)
at android.app.Activity.performDestroy(Activity.java:6422)
at android.app.Instrumentation.callActivityOnDestroy(Instrumentation.java:1143)
at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3852)
... 9 more
