OBB files are used in apps that need more than 100 megs to work well. This
is apps like MAPS.ME or games that put map info, media, etc. into the OBB
file. Also, OBB files provide a mechanism to deliver large data blobs that
do not need to be part of the APK. For example, a game's assets do not
need to change often, so they can be shipped as an OBB, then APK updates do
not need to include all those assets for each update.
https://developer.android.com/google/play/expansion-files.html
Many times in the past, we would ask for an apk based on its package name
and its version code. However multiple repositories provide apks with the
same package name and version code, and such queries would (seemingly)
nondeterministically choose one of these matching apks. This clarifies the
wording in the code around when we explicitly ask for a given apk, and
when we kind of guess which one we want.
Most the time we have an `App` handy, which has a specific repo associated
with it. This allows us to be more specific about requesting `Apk`s.
The times we are kind of guessing is when we rely on the "suggested version
code" of an apk by clicking the misc "Install" or "Upgrade" button in
app details. In the future, we'll need to clear this up so that a more
specific apk is chosen when touching these buttons.
The query which dynamically figured out the preferred metadata based on
repo priority ended up being quite slow (although it did work). On lower
end devices, it has the potential to make F-Droid quite sluggish. By
optimistically precalculating the preferred metadata where possible, we
don't need to ask the question during the usual usage of F-Droid, only
when:
* Repo priorities are changed (there is not currently a UI for this, but
there are tests)
* Repos are enabled/disabled
* Repo updates are performed
Includes:
* One of the functions querying for apps did not correctly specify
the repository the repos came from.
* Fix deletion code which refered to incorrect field.
* Cleanup code style in some places.
Two repositories can (and always could) end up with the same exact .apk file.
If that .apk is the "suggested version", then we should eliminate the idea of
"suggested version code" and instead have a "suggested apk" (which implicitly
includes the repository it comes from, so we choose the one with the better
priority). Right now, we kind of assume that it doesn't matter which repo
provides the suggested apk, as long as one of them has an .apk with the correct
version code and signing key.
It shouldn't _particularly_ matter from a security perspective, because
a malicious repo wont be able to trick a user into installing an apk with a
different signing key, but it would be good to iron this out.
This commit adds a TODO explaining this for th ebenefit of any CRer.
The tests are in the .updater packate to make them easier to run as
a suite in Android Studio. Now the package can be right clicked and
ran to run all the tests to do with updating.
The index jar files were updated so as to include info in most
metadata fields (e.g. URLs/descriptions/summary/etc) to show that
that particular part of metadata came from a specific repo. This
will allow more specific tests to show that we can indeed query for
an app with metadata provided by the repo with the highest priority.
Required for future work which will be better able to deal with multiple repos
providing the same app.
Instead of migrating data into that table, we will drop and recreate the tables.
This is because before this feature is out, we'll need to do that anyway.
It is often helpful during debugging to be able to dump the contents
of an SQL result `Cursor` to the debug watch list. This is difficult
to do under normal circumstances. This adds a utility method really
only designed to be used during interactive debugging, which will do
its best to build a `Map` for each row in the `Cursor`. This can then
be used to test queries while the debugger is paused.
Even though this is not used yet, it will be a requirement in the
near future for the `RepoProvider` to be the one who decides what
the priority of new repositories is. This will prevent clients of
this provider from specifying wrong priorities that result in gaps
For example, if we accidentally ended up with priorities of
1, 2, 4, and then 5, this would cause problems if the user tried to
drag the second repo to the position of the 4th repo. It is easier
to do these priority shuffles if we can assume that the priorities
are contiguous.
Originally, I hoped that the arguments a method took would help enough
to differentiate the intent of that method. This was the case for methods
such as `getContentUri()` and `find()`. However they are a little confusing
to work with, so this change renames a bunch of methods to be more specific.
In addition, it makes some renames from app -> package which will help with
the upcoming change to add a `package` table to the database.
Since e69a6d5a8f24e7745516001f58bee49e05f2ea9e, the Apk instance is
provided in the constructor and is available as a final instance variable.
No need to pass it around. Thanks to @pserwylo for spotting this.
ACTION_INSTALL_STARTED was being sent twice per transaction with the
default installer. Also, it should be sent as the first step of the install
process.
For now, this is disabled by default and hidden in the expert preferences
since it doesn't do anything yet inside of F-Droid. It is useful now for
whitelabel builds to fetch the install history from another app. #396
This allows a designated app to read the install history from F-Droid via a
ContentProvider. The app is designated by the packageName defined in the
string install_history_reader_packageName.
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
There are oddities with the way that Android has implemented the network
stack, as compared to OpenJDK or Oracle JDK. So running the tests on the
local JVM, i.e. Robolectric, will not provide good test coverage for real
world use cases.
Translators:
Ajeje Brazorf Sardinian
Enol P Asturian
Marian Hanzel Slovak
Michael Moroni Italian
Mladen Pejaković Serbian
Sérgio Marques Portuguese (Portugal)
Sveinn í Felli Icelandic
Дмитрий Михирев Russian
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.
