I guess APKs could disappear, or perhaps not be readable.
closes#699
Here's the stacktrace:
java.io.FileNotFoundException:
/system/priv-app/ATT_Ready2Go/ATT_Ready2Go.apk: open failed: ENOENT (No such file or directory)
at org.fdroid.fdroid.Utils.getBinaryHash(Utils.java:405)
at org.fdroid.fdroid.data.InstalledAppProviderService.onHandleIntent(InstalledAppProviderService.java:164)
at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.os.HandlerThread.run(HandlerThread.java:61)
use Privileged Extension by default, when installed
Now that the 0.2 release of Privileged Extension is tagged, it is starting to be integrated into ROMS, and is easy to flash to ROMed devices, it is time to make F-Droid use the Privileged Extension by default, if it is installed.
See merge request !382
This totally changed the logic of the "Use Privileged Extension" preference
making it based on whether the Privileged Extension is installed and usable
rather than storing the user's selection. This code now only stores when
the user manually disables using the Privileged Extension even when it is
installed.
closes#729
The root install method that is available via the "Expert" preferences does
not work on newer than android-19. So when that's the case, this hides
that item from the preferences screen entirely.
Move code causing verify error into separate helper class
Fixes#748.
I'm not 100% sure on how the `@TargetApi` and `VerifyError` work
together. However it is something along the lines of:
* Class loader needs `CleanCacheService`.
* At this point, it loads the bytecode for that class and verifies
that it all makes sense.
* The bytecode within the method targeted at API 21 is not understood
by earlier APIs, because the entire `Os` class was introduced in 21.
* By putting it into a different class, that class is only loaded
at runtime on devices with API of 21 or higher.
Previously, `@TargetApi` + the relevant guard condition to check
the build version at runtime suffices to prevent this. However it seems
that if the entire class does not even exist on earlier APIs, then it
is no longer good enough.
See merge request !379
I'm not 100% sure on how the `@TargetApi` and `VerifyError` work
together. However it is something along the lines of:
* Class loader needs `CleanCacheService`.
* At this point, it loads the bytecode for that class and verifies
that it all makes sense.
* The bytecode within the method targeted at API 21 is not understood
by earlier APIs, because the entire `Os` class was introduced in 21.
* By putting it into a different class, that class is only loaded
at runtime on devices with API of 21 or higher.
Previously, `@TargetApi` + the relevant guard condition to check
the build version at runtime suffices to prevent this. However it seems
that if the entire class does not even exist on earlier APIs, then it
is no longer good enough.
Ensure that description is not null when parsing index.
At time of writing (and for some time before), fdroidserver has forced
a description of "No description available" for apps which don't have
descriptions at all:
* https://gitlab.com/fdroid/fdroidserver/blob/0.6.0/fdroidserver/metadata.py#L876
However, if the description is not set for whatever reason, it should not
crash the client.
Identified in the now closed#739.
See merge request !380
At time of writing (and for some time before), fdroidserver has forced
a description of "No description available" for apps which don't have
descriptions at all:
* https://gitlab.com/fdroid/fdroidserver/blob/0.6.0/fdroidserver/metadata.py#L876
However, if the description is not set for whatever reason, it should not
crash the client.
Big cache update
So I messed up the caching a bit with my update in the past, so this is a big update to fix lots of bugs (hopefully) and add a couple of nice cache clean up features. This should move us towards making F-Droid maintain itself more and more. More comments in the commits.
See merge request !378
The icon files are downloaded for each version of the app. Over time, old
versions will pile up. This cleans out the ones that have not been used in
over a year.
On < android-21, this will delete icons that were downloaded over a year
ago even if they are still in use because it is only possible to check
mtime, not atime.
If CleanCacheService runs while an APK is being installed, it should not
delete the APK that is in the process of being installed. This does that
by only deleting those files if they are older than an hour. Same goes for
the index files.
#738
It was passing the wrong time value in the recursion, which made for a
really old "olderThan" time. This also then flipped the logic on the
next round through the recursion, causing files to be deleted even if
"Keep Cache Time" was set to "Forever".
closes#719closes#736
Before, CleanCacheService was only scheduled at app start for once a day.
If the user selects a time less than a day, then CleanCacheService should
run more frequently.
closes#719
In android-21, they exposed the formerly internal method for getting stat
structs of files. From that, we can get the last access time, which is a
much better way to determine which files to delete rather than last
modified time.
closes#644
Hash fixes
Two semi-related commits about hashes. This standardizes all APK hashes to be all lowercase like in the _fdroidserver index.xml_. The other then stops swallowing hash-related exceptions so we have a chance of debugging the issue. @pserwylo we discussed a0f716c0db705f137749eef3d4964b8ba1050b18 in relation to #699.
See merge request !377
By catching the exception here and returning null, the problem is then
passed on further down the line where it is harder to debug. The hash is
required wherever this method is called, so this should fail immediately.
#699
ApkVerifier Tests
This are some tests for ApkVerifier. More will follow when we merge https://gitlab.com/fdroid/fdroidserver/merge_requests/150 and implement parsing of permissions with min and max sdk versions.
NOTE: This androidTest cannot run as a Robolectric test because the required methods from PackageManger are not included in Robolectric's Android API.
The corresponding exception by robolectric:
```
org.fdroid.fdroid.installer.ApkVerifierTest > testVerifier FAILED
00:31:18.241 [DEBUG] [TestEventLogger] java.lang.NoClassDefFoundError: java/util/jar/StrictJarFile
00:31:18.241 [DEBUG] [TestEventLogger] at java.lang.Class.getDeclaredMethods0(Native Method)
00:31:18.241 [DEBUG] [TestEventLogger] at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
00:31:18.241 [DEBUG] [TestEventLogger] at java.lang.Class.getDeclaredMethod(Class.java:2128)
00:31:18.241 [DEBUG] [TestEventLogger] at org.robolectric.util.ReflectionHelpers.callStaticMethod(ReflectionHelpers.java:224)
00:31:18.241 [DEBUG] [TestEventLogger] at org.robolectric.internal.bytecode.RobolectricInternals.performStaticInitialization(RobolectricInternals.java:54)
00:31:18.241 [DEBUG] [TestEventLogger] at org.robolectric.internal.bytecode.ShadowWrangler.classInitializing(ShadowWrangler.java:119)
00:31:18.241 [DEBUG] [TestEventLogger] at org.robolectric.internal.bytecode.RobolectricInternals.classInitializing(RobolectricInternals.java:18)
00:31:18.241 [DEBUG] [TestEventLogger] at android.content.pm.PackageParser.<clinit>(PackageParser.java)
00:31:18.241 [DEBUG] [TestEventLogger] at android.content.pm.PackageManager.getPackageArchiveInfo(PackageManager.java:3545)
00:31:18.241 [DEBUG] [TestEventLogger] at org.fdroid.fdroid.installer.ApkVerifier.verifyApk(ApkVerifier.java:56)
00:31:18.241 [DEBUG] [TestEventLogger] at org.fdroid.fdroid.installer.ApkVerifierTest.testVerifier(ApkVerifierTest.java:78)
00:31:18.242 [DEBUG] [TestEventLogger] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
[...]
00:31:18.244 [DEBUG] [TestEventLogger]
00:31:18.244 [DEBUG] [TestEventLogger] Caused by:
00:31:18.245 [DEBUG] [TestEventLogger] java.lang.ClassNotFoundException: java.util.jar.StrictJarFile
00:31:18.245 [DEBUG] [TestEventLogger] at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
00:31:18.245 [DEBUG] [TestEventLogger] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
00:31:18.245 [DEBUG] [TestEventLogger] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
00:31:18.245 [DEBUG] [TestEventLogger] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
00:31:18.245 [DEBUG] [TestEventLogger] at org.robolectric.internal.bytecode.InstrumentingClassLoader.loadClass(InstrumentingClassLoader.java:124)
00:31:18.245 [DEBUG] [TestEventLogger] at java.lang.Class.getDeclaredMethods0(Native Method)
00:31:18.245 [DEBUG] [TestEventLogger] at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
00:31:18.245 [DEBUG] [TestEventLogger] at java.lang.Class.getDeclaredMethod(Class.java:2128)
00:31:18.245 [DEBUG] [TestEventLogger] at org.robolectric.util.ReflectionHelpers.callStaticMethod(ReflectionHelpers.java:224)
00:31:18.245 [DEBUG] [TestEventLogger] at org.robolectric.internal.bytecode.RobolectricInternals.performStaticInitialization(RobolectricInternals.java:54)
00:31:18.245 [DEBUG] [TestEventLogger] at org.robolectric.internal.bytecode.ShadowWrangler.classInitializing(ShadowWrangler.java:119)
00:31:18.245 [DEBUG] [TestEventLogger] at org.robolectric.internal.bytecode.RobolectricInternals.classInitializing(RobolectricInternals.java:18)
00:31:18.245 [DEBUG] [TestEventLogger] at android.content.pm.PackageParser.<clinit>(PackageParser.java)
00:31:18.245 [DEBUG] [TestEventLogger] at android.content.pm.PackageManager.$$robo$$getPackageArchiveInfo(PackageManager.java:3545)
00:31:18.245 [DEBUG] [TestEventLogger] at android.content.pm.PackageManager.getPackageArchiveInfo(PackageManager.java)
00:31:18.245 [DEBUG] [TestEventLogger] at org.fdroid.fdroid.installer.ApkVerifier.verifyApk(ApkVerifier.java:56)
00:31:18.246 [DEBUG] [TestEventLogger] at org.fdroid.fdroid.installer.ApkVerifierTest.testVerifier(ApkVerifierTest.java:78)
00:31:18.246 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[...]
```
See merge request !367
More misc code cleanup around database code
I'm pulling out the final bit of unrelated code from my database refactor branch in the hope of making the final diff easier. This cleans up a few switch statements with only one option, closes some cursors, and removes some dead code. Comments in the commits explain the dead code.
See merge request !374
F-Droid Privileged Extension fixes
A couple of small fixes related to the process of finalizing the new Privileged Extension for a real release! @dschuermann hopefully just renaming is enough when installing FPE via the root method. Or do you think we should handle removing existing installs in the old location?
See merge request !376
AS picked up that the statement is always false, so the body of the if is
never executed. This is indeed the case, because the constructor assigns
the object which is being checked for null.
The code only existed so that it could be used in a test. Subsequently,
a further test was written to test this code (used by the first test).
Since none of the code is actually used in the app, it has been removed.
Renamed AppTable to AppMetadataTable
See #511 for details. This is in prep ration for having an even more normalized `fdroid_package` table. That table will be the authoritative reference of what "packages" are known about in the client. The "app" table (now "metadata") will be specific to each repository which provides different metadata about that app.
This is a fairly straightforward "Rename Interface" refactoring from Android Studio" and is done so as to minimize the diff in a forthcoming MR.
See merge request !373
See #511 for details. This is in prepration for having an even more normalized
`fdroid_package` table. That table will be the authoritative reference of what
"packages" are known about in the client. The "app" table (now thought of as "app metadata") will
be specific to each repository which provides different metadata about that app.
Move user specified data to separate table
Right now, the "Ignore update for version X" and "Ignore all updates for this app" are stored in `fdroid_app`. This means that if a repo is disabled then re-enabled, these preferences are lost. This MR separates out the user specified metadata from the metadata provided by the repository, such that one can change without affecting the other.
For convenience sake, this drops the `fdroid_app` and `fdroid_apk` tables rather than migrating them, and then sets a flag in preferences that forces F-Droid to do an index update when started. This is done _after_ migrating already existing user preferences out of `fdroid_app` and into `fdroid_appPrefs`.
See merge request !372
