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
Push requests for install/uninstall
This is the first basic implementation of the idea of "push requests" from the server. This implements two requests that the server can ask of all clients: `install` and `uninstall`. A default repository in the client can be marked to `ignore` or `always` accept push requests in this merge request. There is also the sketch of a third option called `prompt` which gives the user the standard "Just Once/Always" choice; that is not yet implemented.
This allows central management of app installs/uninstalls for a pool of devices, as well as other ideas.
A use case for this feature is documented here:
https://f-droid.org/wiki/page/Whitelabel_Builds
See merge request !386
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.
Include crash in ACRA subject
This makes it so the first chunk of the crash is put in email subject. This also lays the foundation for other ACRA customizations.
This is ready to be merged, but it is based on !386, so its marked WIP.
See merge request !391
TLS 1.2 support
At long last, there is a tested version of NetCipher that supports SNI. This uses that release to enable good TLS support and Tor for all repos. This moves the HTTP tests to the emulator, so that things are tested on the actual OS.
See merge request !398
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.
update to latest support lib bugfix version: v24.2.1
include the bugfix version of the support libs we are using since this is the last test before a stable release.
See merge request !397
This makes sure that the latest version of the core SDK components are
all current before running, which means that the builds will keep
working even when the docker image gets out of date. Then we can
finish the task we are working on before having to deal with updating
the docker image. Without that update line, we have to drop everything
and update the docker image when things are out of date.
Disk space and bandwidth is cheap, developer time is very scarce. We
should aim to keep the tests working as much as possible so that we
waste less developer time. Updating everytime only means it downloads
a little bit of XML each time, that's nothing compared to what gradle
downloads on every build.
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.
fix emulator tests on android-10
We have to work harder to get writeable dirs in the android-10 emulator, that seems to be the old issue on android-10.
See merge request !390
Remove any whitespace from fingerprint EditText input so that copy pasting is easier for users.
Hey,
I just added a line to remove the whitespace from fingerprints when adding a new Repo. Some repositories like https://microg.org have their fingerprint separated with spaces so copy pasting directly from there is more cumbersome if fdroid doesn't remove the whitespace by itself.
Hope it's ok. :)
See merge request !389
Translators:
Agus Galician
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
El Virolo French
Koen Glotzbach Dutch
Licaon Kter Romanian
Michael German
Mohamad Hasan Al Banna Indonesian
naofum Japanese
Olexandr Nesterenko Ukrainian
Osoitz Basque
Pyae Sone Burmese
Verdulo Esperanto
Verdulo Polish
YFdyh000 Simplified Chinese
handle install broadcasts after InstallManagerService was killed
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.
See merge request !387
Translators:
Adrià García-Alzórriz Catalan
Ajeje Brazorf Sardinian
Christophe CHAUVET French
Enol P Asturian
Laura Arjona Reina Spanish
Licaon Kter Romanian
Michael German
Mladen Pejaković Serbian
naofum Japanese
Osoitz Basque
Swyter Spanish
Sylvia van Os Dutch
Tobias Bannert German
Verdulo Esperanto
Verdulo Polish
Viktor Alojzije Coric Croatian
Waqar Ahmed Urdu
YFdyh000 Simplified Chinese
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.
Add option to hide anti feature apps
Added option under Setting to grey out apps requiring anti-features similar to ignoring rooted apps on a non-rooted device.
See merge request !384
