The most expensive part of this whole process is calculating the hash of the
whole APK. InstalledAppProvider already caches that, and the rest is OK to
query. If any particular part of the query is expensive, it could also be
moved to InstalledAppProviderService.
This moves all logic for setting up the local fdroid repo to its own
IntentService. That makes it much easier to interact with since things can
just use the static helper method to request it to update, and it'll do the
right thing.
Almost all of the nearby/swap view classes could be condensed into a single
base class that is instantiated in the view XML. This is the first step
towards making that happen.
It also lays the groundwork where "steps" are all SwapViews. The
original concept of "steps" put all steps together, whether
F-Droid could control them or not. For example, the Views were
mixed with the system Bluetooth prompts. This is the first step
towards converting the steps to always be SwapViews, which are
always under control of this app.
When coming back to a SwapView/step, it does not seem feasible to handle
automatically restarting things like permissions and Bluetooth prompts. If
there is a way, it should be possible to first load the proper SwapView
instance, then trigger the system prompt. The makes the SwapView a pure
View, without any Controller in it.
The date/time written to index.xml and index-v1.json should always be in
UTC format. These formats are often in the form of just a date, e.g.
2019-04-28. Those are then converted to UNIX seconds, which includes the
time. In the date only case, the time is assumed to be 00:00, which will
be different per time zone.
index-v1.json is better since it mostly uses Java-style UNIX time in millis
but the dates/times are parsed then stored in the local database in the old
format yyyy-MM-dd_HH:mm:ss which will result in different UNIX times when
the device is in different time zones.
fdroid/fdroidclient#1757
This also converts old Repo.lastUpdated values rather than just failing.
index.xml handling used to store the Repo "Last Updated" date used to store
the value as just an ISO date (2019-04-29), then the time was added. So if
date/time parsing fails, this falls back to trying to parse just the date.
null is returned when parsing fails, and the Latest Tab shows nothing if
the Last Updated is null.
Some related tests were also tweaked.
Hopefully:
closesfdroid/fdroidclient#1757
Throwable includes Errors and Exceptions. Fixes stacktraces like these:
java.lang.RuntimeException: An error occurred while executing doInBackground()
at android.os.AsyncTask$3.done(AsyncTask.java:325)
at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:354)
at java.util.concurrent.FutureTask.setException(FutureTask.java:223)
at java.util.concurrent.FutureTask.run(FutureTask.java:242)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
Caused by: java.lang.NoSuchMethodError: No virtual method toPath()Ljava/nio/file/Path; in class Ljava/io/File; or its super classes (declaration of 'java.io.File' appears in /system/framework/core-oj.jar)
at org.apache.commons.io.FileUtils.isSymlink(FileUtils.java:3107)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1616)
at org.fdroid.fdroid.DeleteCacheService.onHandleWork(DeleteCacheService.java:32)
at android.support.v4.app.JobIntentService$CommandProcessor.doInBackground(JobIntentService.java:391)
at android.support.v4.app.JobIntentService$CommandProcessor.doInBackground(JobIntentService.java:382)
at android.os.AsyncTask$2.call(AsyncTask.java:305)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
... 3 more
java.lang.NoSuchMethodError: No virtual method toPath()Ljava/nio/file/Path; in class Ljava/io/File; or its super classes (declaration of 'java.io.File' appears in /system/framework/core-oj.jar)
at org.apache.commons.io.FileUtils.isSymlink(FileUtils.java:3107)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1616)
at org.fdroid.fdroid.DeleteCacheService.onHandleWork(DeleteCacheService.java:32)
at android.support.v4.app.JobIntentService$CommandProcessor.doInBackground(JobIntentService.java:391)
at android.support.v4.app.JobIntentService$CommandProcessor.doInBackground(JobIntentService.java:382)
at android.os.AsyncTask$2.call(AsyncTask.java:305)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
This reverts commit c5daf1981a7f00de16e19120ac42575c0e4bc424.
Turns I was confused here. Yes, the job has to be called "pages" if the
job is deploying to GitLab Pages. But in the case of `fdroid nightly`, the
thing that is deploying to GitLab Pages is the .gitlab-ci.yml that is in
the *-nightly repo, which is auto-generated by `fdroid nightly`.
fdroid/fdroidserver#649
There are soo many of these:
org.fdroid.fdroid.net.HttpDownloaderTest > downloadThenCancel[avd27(AVD) - 8.1.0] FAILED
Test failed to run to completion. Reason: 'Instrumentation run failed due to 'Process crashed.''. Check device logcat for details
