The install and uninstall history has lots of uses, including displaying
to the user in the app itself, reporting to the Device Administrator to
enable tracking of installs/uninstalls from the admin's app repo, etc. It
can also be used as part of a "popularity contest" #396
Now that the packageName is included in the Installer broadcast Intents,
it can be used to fetch the app name from the database, if all other ways
fail.
If F-Droid or InstallManagerService get killed while an install is in
progress, that install will ultimately broadcast back to
InstallManagerService to manage the notifications. The state is gone
since things have been killed, so include the Apk instance in the
Intent that is included in the broadcasts so that
InstallManagerService can fetch all required info from the database.
closes#698
F-Droid shouldn't crash if a push request includes a bad package name. This
just makes it silently ignore those push requests. If its a debug build,
it will send a message to logcat. I'm not sure this is best way to handle
this, but this is better than crashing the app. This will make it harder
for repo operators to debug issues with push requests.
This allows whitelabel versions of apps to specify built-in app repos that
have push requests accepted by default. This is useful for the case where
there is a central manager of the core apps that are installed.
https://gitlab.com/fdroid/fdroidserver/issues/177
This is a step towards supporting easy whitelabeling, using gradle flavors.
This allows the whitelabel version to set the default repos just by making
their own default_repos.xml in app/src/whitelabel/res/values. That one
will then override the built-in F-Droid one.
Update to the latest NetCipher, which now fully supports SNI, in order to
support TLS 1.2 on all supported platform levels. Without this, a repo
that is TLS 1.2 only will be unusable on all but the most recent versions
of Android.
#431
This is far less brittle at runtime, but slightly more work at dev time.
The following things are undesirable but make it much easier to write:
* Use of `CREATE_TABLE_APP.replaceFirst(...)` to create the temp tables.
* Having to specify a list fo columns twice in `Schema` (`ALL_COLS` + `COLS`).
The `replaceFirst` means we don't need to maintain two separate create table
statements. It is a little messy because there is no compile time guarantee
that we are creating a valid SQL statement at the end, just our knowledge
that a create table statment tends to have the table name first and it
probably wont cause problems.
The `ALL_COLS` + `COLS` is required so that we don't have to type out a list
of fields when copying data in `TempAppProvider`. Otherwise, whenever a new
column is added, developers would need to know that it also needs to be added
to this third place. Currently it is in the `Schema` and the `CREATE_TABLE_*`
statements where one needs to add a new column. These are both intuitive and
hopefully easily discoverable. Having to add it to the `TempAppProvider` is
less intuitive and likely to result in bugs.
When performing the old style `CREATE TABLE ... AS SELECT ...` (CTAS) statement,
no indexes are added. In addition, rowid is not added. Even if manually
specifying an autoincrement column in the original schema, this autoincrement
column does not get recreated with the CTAS statement. So instead, this change
reuses the original `CREATE TABLE` statement which explicitly defines all of the
relevant columns. In addition, it explicitly adds an autoincrement integer primary
key. This has the same semantics as the existing implicit `rowid` column that
sqlite creates. From from https://sqlite.org/autoinc.html:
> In SQLite, a column with type INTEGER PRIMARY KEY is an alias for the ROWID
> (except in WITHOUT ROWID tables) which is always a 64-bit signed integer.
However, as it is explicit now, is copied when doing the
`INSERT INTO ... SELECT ...` statement to get data from the real table to the
temp table in preperation for updates (and back again after the update has
populated the temp table).
Note that this makes the `INSERT INTO ... SELECT ...` statements slightly more
brittle, because now we need the table definition used to create the temp table
(from `DBHelper.CREATE_APP_TABLE`) to have the same column order as those in the
real `fdroid_app` table. While this may sound like a silly comment to make, it
is important because database migrations can result in a database having the
correct set of columns, but in a different order to how they were specified
in the original create table statement.
If a database migration performs an `ALTER TABLE ... ADD COLUMN ...` the column
will be added at the end. If at the same time the `CREATE TABLE` is changed so
that the new column is specified as the second to last column in the list of
columns, then the `INSERT INTO ... SELECT ...` will not work as expected.
When the Privileged Extension is working, then enabling the preference
"Automatically download updates" will actually install those updates in the
background. So the preference should communicate that to the user. So now
it serves as a global "allow background updates"
#16closes#106
This gets rid of the notifications that say "Tap to Install Unknown", and
instead just cancels the notification. The downloaded APK will still be
cached, so when the user goes to click install or update again, it won't
need to download it again.
closes#758
If InstallManagerService was killed, it'll forget all of its state. If it
is killed while an install process is running, and that install fails,
InstallManagerService will receive a broadcast about the error but then it
can't find anything about the app in question besides its download URL.
That is enough to control the notification, but not enough to get the name
of the app in question. This is a workaround by showing the APK filename
when the app name cannot be found. Ideally, the packageName would somehow
magically be delivered to InstallManagerService in this case, but the
Installer stuff doesn't always have it to send.
With android-23, there is getActiveNotifications(), which we might be able
to use to stash the packageName and fetch it as needed.
This should be reverted once #698 is fixed. If execution has gotten this
far into InstallManagerService, there should always be App and Apk
instances. That is enforced when Intents are received by this Service.
This was saying that the Privileged Extension is enabled but not properly
configured. This is because the preference logic changed to default to on
unless the user explicitly disabled it. So using the Privileged
Extension based on whether its installed and whether the user has disabled
it.
related to ea0700d406101b7ed6907b1dbd2918dbc214f435
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)
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.
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.
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
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
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.
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.
