opensourcemirror
/
fdroid-client
mirror of https://gitlab.com/fdroid/fdroidclient.git
1
0
Fork 0
Code Issues Releases Wiki Activity
fdroid-client/app/src/main/java/org/fdroid/fdroid/data/App.java

1460 lines
57 KiB
Java
Raw Normal View History

Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
package org.fdroid.fdroid.data;
import android.content.ContentValues;
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
import android.content.Context;
Optimize imports a bit
2015-04-06 22:16:51 +02:00
import android.content.pm.ApplicationInfo;
import android.content.pm.FeatureInfo;
import android.content.pm.PackageInfo;
import android.content.pm.PackageManager;
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
import android.content.res.AssetManager;
use android-24+ LocaleList when choosing localized index data When choosing localized data from the index, this includes the new LocaleList feature that represents the user's preferred locale ranking https://developer.android.com/reference/android/os/LocaleList.html
2017-04-19 00:12:29 +02:00
import android.content.res.Resources;
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
import android.content.res.XmlResourceParser;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
import android.database.Cursor;
Add glide support to download library
2022-01-19 19:07:46 +01:00
import android.graphics.drawable.Drawable;
make app share URL based on the repo URL closes #1946
2021-09-10 10:08:17 +02:00
import android.net.Uri;
workaround Locale.toLanguageTag() requiring android-21
2021-02-06 01:23:53 +01:00
import android.os.Build;
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
import android.os.Environment;
use android-24+ LocaleList when choosing localized index data When choosing localized data from the index, this includes the new LocaleList feature that represents the user's preferred locale ranking https://developer.android.com/reference/android/os/LocaleList.html
2017-04-19 00:12:29 +02:00
import android.os.LocaleList;
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
import android.os.Parcel;
include all needed data in install Intents Including the App and Apk instances in the Intent that starts InstallManagerService ensures that the needed data is present in the Service no matter what happens outside of the Service. For example, if the index is updated or cleared while an install is in progress, the install process still needs to know the name and packageName of the app to update the Notification. A cleaner but more labor-intensive way to implement this would be to make App and Apk properly implement the full Parcelable interface. That would require tests to check that the Parcelable methods have all the same fields as toContentValues() and the database. closes #660 https://gitlab.com/fdroid/fdroidclient/issues/660
2016-05-19 20:30:17 +02:00
import android.os.Parcelable;
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
import android.text.TextUtils;
import android.util.Log;
run Android Studio's Ctrl-Alt-O Organize Imports on all .java files
2021-04-13 10:23:22 +02:00
Add glide support to download library
2022-01-19 19:07:46 +01:00
import com.bumptech.glide.Glide;
import com.bumptech.glide.RequestBuilder;
make Jackson inject repoId rather than looping later to add it repoId is used in Repo, App, and Apk instances to point to the Repo data in the database. It does not come from the index files, but rather the client database.
2017-03-22 13:58:27 +01:00
import com.fasterxml.jackson.annotation.JacksonInject;
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
import com.fasterxml.jackson.annotation.JsonIgnore;
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
import com.fasterxml.jackson.annotation.JsonProperty;
run Android Studio's Ctrl-Alt-O Organize Imports on all .java files
2021-04-13 10:23:22 +02:00
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
import org.apache.commons.io.filefilter.RegexFileFilter;
Add glide support to download library
2022-01-19 19:07:46 +01:00
import org.fdroid.download.DownloadRequest;
Introduce FileInstaller, a way to handle media files from F-Droid * This installer is invoked when for non-apk/media files, and copies them to an appropriate folder on the sdcard. * We also introduce a FileInstallerActivity to ask for storage permissions at runtime, as needed by Android 6.0 and above, and handle the install/uninstall process. * A toast is shown with the install path after installation. TODO: * Manage Installed Apps screen doesn't show media files.
2017-06-20 12:31:56 +02:00
import org.fdroid.fdroid.Preferences;
Don't hide unknown antifeatures
2021-10-30 14:09:37 +02:00
import org.fdroid.fdroid.R;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
import org.fdroid.fdroid.Utils;
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
import org.fdroid.fdroid.data.Schema.AppMetadataTable.Cols;
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
import org.xmlpull.v1.XmlPullParser;
import org.xmlpull.v1.XmlPullParserException;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
import java.io.File;
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
import java.io.FileFilter;
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
import java.io.IOException;
import java.io.InputStream;
import java.security.cert.Certificate;
import java.security.cert.CertificateEncodingException;
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
import java.util.ArrayList;
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
import java.util.Arrays;
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
import java.util.Collections;
Optimize imports a bit
2015-04-06 22:16:51 +02:00
import java.util.Date;
parse APK for <nativecode> info in local repos This parses the APKs for swapping, looking for what kinds of native code it includes. This is used in the compatibility check. closes #30 https://gitlab.com/fdroid/fdroidclient/issues/30
2016-05-17 23:49:33 +02:00
import java.util.Enumeration;
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
import java.util.HashMap;
parse APK for <nativecode> info in local repos This parses the APKs for swapping, looking for what kinds of native code it includes. This is used in the compatibility check. closes #30 https://gitlab.com/fdroid/fdroidclient/issues/30
2016-05-17 23:49:33 +02:00
import java.util.HashSet;
Introduce FileInstaller, a way to handle media files from F-Droid * This installer is invoked when for non-apk/media files, and copies them to an appropriate folder on the sdcard. * We also introduce a FileInstallerActivity to ask for storage permissions at runtime, as needed by Android 6.0 and above, and handle the install/uninstall process. * A toast is shown with the install path after installation. TODO: * Manage Installed Apps screen doesn't show media files.
2017-06-20 12:31:56 +02:00
import java.util.List;
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
import java.util.Locale;
import java.util.Map;
import java.util.Set;
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
import java.util.jar.JarEntry;
import java.util.jar.JarFile;
parse APK for <nativecode> info in local repos This parses the APKs for swapping, looking for what kinds of native code it includes. This is used in the compatibility check. closes #30 https://gitlab.com/fdroid/fdroidclient/issues/30
2016-05-17 23:49:33 +02:00
import java.util.regex.Matcher;
import java.util.regex.Pattern;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
run Android Studio's Ctrl-Alt-O Organize Imports on all .java files
2021-04-13 10:23:22 +02:00
import androidx.annotation.NonNull;
import androidx.annotation.Nullable;
import androidx.core.os.ConfigurationCompat;
import androidx.core.os.LocaleListCompat;
support new index-v1 format using Jackson parser This adds support for parsing the new index-v1.json data as defined in fdroidserver!221. This new index metadata format is required to support localization, graphics, screenshots, etc. refs #15
2017-03-22 21:38:33 +01:00
/**
* Represents an application, its availability, and its current installed state.
* This represents the app in general, for a specific version of this app, see
* {@link Apk}.
* <p>
* <b>Do not rename these instance variables without careful consideration!</b>
* They are mapped to JSON field names, the {@code fdroidserver} internal variable
* names, and the {@code fdroiddata} YAML field names. Only the instance variables
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
* decorated with {@code @JsonIgnore} are not directly mapped.
* <p>
* <b>NOTE:</b>If an instance variable is only meant for internal state, and not for
* representing data coming from the server, then it must also be decorated with
* {@code @JsonIgnore} to prevent abuse! The tests for
* {@link org.fdroid.fdroid.IndexV1Updater} will also have to be updated.
support new index-v1 format using Jackson parser This adds support for parsing the new index-v1.json data as defined in fdroidserver!221. This new index metadata format is required to support localization, graphics, screenshots, etc. refs #15
2017-03-22 21:38:33 +01:00
*
* @see <a href="https://gitlab.com/fdroid/fdroiddata">fdroiddata</a>
* @see <a href="https://gitlab.com/fdroid/fdroidserver">fdroidserver</a>
*/
Use App/Apk parceling instead of ContentVals The usage of ContentValues to send App/Apk objects to services was an hack in my opinion. This hack broke in https://gitlab.com/fdroid/fdroidclient/merge_requests/359 where the packageName has been removed from the toContentValues() method, which leads to NPEs in the services.
2016-07-25 16:59:53 +02:00
public class App extends ValueObject implements Comparable<App>, Parcelable {
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
@JsonIgnore
Remove "fdroid." from TAGs, add a comment on filtering by packagename
2015-05-08 23:28:32 +02:00
private static final String TAG = "App";
Logging fixes * Make expensive Log.d calls (inside loops) only in DEBUG * Always make TAG private to make sure it doesn't use a parent's TAG
2015-04-10 13:58:26 +02:00
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
/**
* {@link LocaleListCompat} for finding the right app description material.
* It is set globally static to a) cache this value, since there are thousands
* of {@link App} entries, and b) make it easy to test {@link #setLocalized(Map)} )}
*/
@JsonIgnore
public static LocaleListCompat systemLocaleList;
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
// these properties are not from the index metadata, but represent the state on the device
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
/**
* True if compatible with the device (i.e. if at least one apk is)
*/
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
@JsonIgnore
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
public boolean compatible;
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
@JsonIgnore
public Apk installedApk; // might be null if not installed
@JsonIgnore
public String installedSig;
@JsonIgnore
public int installedVersionCode;
@JsonIgnore
public String installedVersionName;
@JsonIgnore
private long id;
@JsonIgnore
private AppPrefs prefs;
Add "preferredSigner" field to App. At present, this is chosen from the first package in the index-v1 metadata.
2017-06-21 07:48:21 +02:00
@JsonIgnore
set App.preferredSigner when using index v0 #1086 This was an oversight when we added this functionality, though there was a related TODO. 41f85f3c9df934daba0ee0d60c4c01bb071fa6e7
2017-09-02 22:23:51 +02:00
@NonNull
Add "preferredSigner" field to App. At present, this is chosen from the first package in the index-v1 metadata.
2017-06-21 07:48:21 +02:00
public String preferredSigner;
Calculate whether an app is an APK or not when updating repos. This improves performance when we need to decide whether or not apps are installed or not while scrolling through large lists. Fixes #1143. Also change Jackson tests to properly ignore App#isApk.
2017-09-12 16:48:14 +02:00
@JsonIgnore
public boolean isApk;
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
/**
* Has this {@code App} been localized into one of the user's current locales.
*/
add flag to track localized apps for selecting in Latest tab
2019-03-22 13:36:53 +01:00
@JsonIgnore
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
boolean isLocalized;
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
Move comment to correct field.
2017-07-05 09:18:51 +02:00
/**
* This is primarily for the purpose of saving app metadata when parsing an index.xml file.
* At most other times, we don't particularly care which repo an {@link App} object came from.
* It is pretty much transparent, because the metadata will be populated from the repo with
* the highest priority. The UI doesn't care normally _which_ repo provided the metadata.
* This is required for getting the full URL to the various graphics and screenshots.
*/
use string name for JacksonInject to make it easy to read java
2017-03-22 21:45:59 +01:00
@JacksonInject("repoId")
make Jackson inject repoId rather than looping later to add it repoId is used in Repo, App, and Apk instances to point to the Repo data in the database. It does not come from the index files, but rather the client database.
2017-03-22 13:58:27 +01:00
public long repoId;
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
// the remaining properties are set directly from the index metadata
public String packageName = "unknown";
public String name = "Unknown";
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
public String summary = "Unknown application";
fix tests after icon changes
2020-02-21 17:16:07 +01:00
@JsonProperty("icon")
rename app.icon to app.iconFromApk This makes it clearer what this is actually referring to.
2020-02-21 16:08:08 +01:00
public String iconFromApk;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
public String description;
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
/**
* A descriptive text for what has changed in this version.
*/
public String whatsNew;
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
public String featureGraphic;
public String promoGraphic;
public String tvBanner;
public String[] phoneScreenshots = new String[0];
public String[] sevenInchScreenshots = new String[0];
public String[] tenInchScreenshots = new String[0];
public String[] tvScreenshots = new String[0];
public String[] wearScreenshots = new String[0];
show license in the links section This makes the license a link to the spdx.org page for the app's license. I think this is an improvement over the way the license was displayed before 0.103 since it provides a direct link to the actual text of the license. The license icon is a modified version of the public domain icon: https://commons.wikimedia.org/wiki/File:Cc-sa_white.svg closes #960
2017-05-01 20:57:12 +02:00
public String license;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
public String authorName;
public String authorEmail;
Add author/email/license display capabilities to app. (Closes: #532)
2016-01-04 23:53:28 +01:00
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
public String webSite;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
public String issueTracker;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
public String sourceCode;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
App Details: show the app's Translation links fdroid/fdroidserver!450 icon is: https://material.io/tools/icons/?search=trans&icon=translate&style=baseline
2019-03-22 15:22:11 +01:00
public String translation;
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
public String video;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
public String changelog;
Add support for changelog links
2015-06-04 11:57:16 +02:00
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
public String donate;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
public String bitcoin;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
public String litecoin;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
public String flattrID;
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
public String liberapay;
add liberapay field and donation option This add the liberapayID index field to the local db and then displays a donation badge for apps that provide this.
2018-02-14 22:48:00 +01:00
support OpenCollective as a donation option
2020-06-10 23:53:16 +02:00
public String openCollective;
rename App.upstreamVersionName to suggestedVersionName #1063
2020-01-10 16:59:21 +01:00
/**
* This matches {@code CurrentVersion} in build metadata files.
*
* @see <a href="https://f-droid.org/docs/Build_Metadata_Reference/#CurrentVersion">CurrentVersion</a>
*/
public String suggestedVersionName;
index-v1's suggestedVersionCode goes into client's upstreamVersionCode closes #1052 refs #1063
2017-06-16 22:56:57 +02:00
/**
init suggestedVersionCode to Integer.MIN_VALUE Java inits ints to 0. Since it is valid to have a negative Version Code, versionCodes are inited to Integer.MIN_VALUE; https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html closes #1063
2020-01-10 17:18:28 +01:00
* This matches {@code CurrentVersionCode} in build metadata files. Java
* inits {@code int}s to 0. Since it is valid to have a negative Version
* Code, this is inited to {@link Integer#MIN_VALUE};
set App.preferredSigner when using index v0 #1086 This was an oversight when we added this functionality, though there was a related TODO. 41f85f3c9df934daba0ee0d60c4c01bb071fa6e7
2017-09-02 22:23:51 +02:00
*
rename App.upstreamVersionCode to suggestedVersionCode #1063
2020-01-10 17:06:58 +01:00
* @see <a href="https://f-droid.org/docs/Build_Metadata_Reference/#CurrentVersionCode">CurrentVersionCode</a>
index-v1's suggestedVersionCode goes into client's upstreamVersionCode closes #1052 refs #1063
2017-06-16 22:56:57 +02:00
*/
init suggestedVersionCode to Integer.MIN_VALUE Java inits ints to 0. Since it is valid to have a negative Version Code, versionCodes are inited to Integer.MIN_VALUE; https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html closes #1063
2020-01-10 17:18:28 +01:00
public int suggestedVersionCode = Integer.MIN_VALUE;
s/curVersion/upstreamVersion/g, added suggestedVersion. Refactored QueryBuilder. In order to support suggested version, I didn't want to have both suggested version + versionCode in the App table. Rather, just the code, and then use that (and the apps id) to join onto the apk table. This is something we wanted to do elsewhere, so I refactored the QueryBuilder class from the ApkProvider so that it can also be used by the AppProvider.
2014-02-15 10:57:18 +01:00
/**
* Unlike other public fields, this is only accessible via a getter, to
* emphasise that setting it wont do anything. In order to change this,
rename App.suggestedVersionName to autoInstallVersionName #1063 # Conflicts: # app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
2020-01-10 17:41:29 +01:00
* you need to change {@link #autoInstallVersionCode} to an APK which is
* in the {@link Schema.ApkTable} table.
s/curVersion/upstreamVersion/g, added suggestedVersion. Refactored QueryBuilder. In order to support suggested version, I didn't want to have both suggested version + versionCode in the App table. Rather, just the code, and then use that (and the apps id) to join onto the apk table. This is something we wanted to do elsewhere, so I refactored the QueryBuilder class from the ApkProvider so that it can also be used by the AppProvider.
2014-02-15 10:57:18 +01:00
*/
rename App.suggestedVersionName to autoInstallVersionName #1063 # Conflicts: # app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
2020-01-10 17:41:29 +01:00
private String autoInstallVersionName;
Remove all trailing whitespaces in source files
2014-12-30 23:48:36 +01:00
rename App.suggestedVersionCode to autoInstallVersionCode #1063
2020-01-10 16:46:07 +01:00
/**
* The version that will be automatically installed if the user does not
* choose a specific version.
init suggestedVersionCode to Integer.MIN_VALUE Java inits ints to 0. Since it is valid to have a negative Version Code, versionCodes are inited to Integer.MIN_VALUE; https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html closes #1063
2020-01-10 17:18:28 +01:00
* TODO this should probably be converted to init to {@link Integer#MIN_VALUE} like {@link #suggestedVersionCode}
rename App.suggestedVersionCode to autoInstallVersionCode #1063
2020-01-10 16:46:07 +01:00
*/
public int autoInstallVersionCode;
s/curVersion/upstreamVersion/g, added suggestedVersion. Refactored QueryBuilder. In order to support suggested version, I didn't want to have both suggested version + versionCode in the App table. Rather, just the code, and then use that (and the apps id) to join onto the apk table. This is something we wanted to do elsewhere, so I refactored the QueryBuilder class from the ApkProvider so that it can also be used by the AppProvider.
2014-02-15 10:57:18 +01:00
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
public Date added;
public Date lastUpdated;
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
/**
* List of categories (as defined in the metadata documentation) or null if there aren't any.
Refactored categories field from column in metadata table to join table. When updating existing apps or inserting new apps, instead of splatting a comma separated list into a single sqlite3 column, we now put it into several rows in the `CatJoinTable`. This is done after deleting existing categories, to make sure that if the app has been removed from a category, then this is reflected during the update.
2016-10-13 01:17:54 +02:00
* This is only populated when parsing a repository. If you need to know about the categories
* an app is in any other part of F-Droid, use the {@link CategoryProvider}.
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
*/
Replace `CommaSeparatedList` with `String[]`. This is a combination of: * `String[].split(",")` and * `TextUtils.join(",", values)` It seems a bit wastefull to have our own implementation of these two things which lightly wrap this code, and produce a datastructure which is non standard and foreign to Java developers.
2016-06-20 14:24:52 +02:00
public String[] categories;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
/**
* List of anti-features (as defined in the metadata documentation) or null if there aren't any.
*/
Replace `CommaSeparatedList` with `String[]`. This is a combination of: * `String[].split(",")` and * `TextUtils.join(",", values)` It seems a bit wastefull to have our own implementation of these two things which lightly wrap this code, and produce a datastructure which is non standard and foreign to Java developers.
2016-06-20 14:24:52 +02:00
public String[] antiFeatures;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
/**
deprecate App.requirements[], was only used for RequiresRoot RequiresRoot is obsolete as a metadata field since there is the SUPER_USER permission. This `requirements` array was set up to handle other things, but that was never implemented.
2016-12-01 20:19:54 +01:00
* Requires root access (only ever used for root)
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
*/
deprecate App.requirements[], was only used for RequiresRoot RequiresRoot is obsolete as a metadata field since there is the SUPER_USER permission. This `requirements` array was set up to handle other things, but that was never implemented.
2016-12-01 20:19:54 +01:00
@Deprecated
Replace `CommaSeparatedList` with `String[]`. This is a combination of: * `String[].split(",")` and * `TextUtils.join(",", values)` It seems a bit wastefull to have our own implementation of these two things which lightly wrap this code, and produce a datastructure which is non standard and foreign to Java developers.
2016-06-20 14:24:52 +02:00
public String[] requirements;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
/**
rename app.icon to app.iconFromApk This makes it clearer what this is actually referring to.
2020-02-21 16:08:08 +01:00
* URL to download the app's icon. (Set only from localized block, see also
* {@link #iconFromApk} and {@link #getIconUrl(Context)}
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
*/
allow displaying localized icons Move the logic of calculating the correct iconUrl from sql to java. Fixes #1460.
2020-02-21 14:45:46 +01:00
private String iconUrl;
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
always set App.icon when instantiating from installed app The App(Context context, PackageManager pm, String packageName) constructor was not setting App.icon, which is required for lots of things. This makes it always get set, since its just a standard file name, and it does not have to even exist yet.
2016-05-17 16:23:59 +02:00
public static String getIconName(String packageName, int versionCode) {
return packageName + "_" + versionCode + ".png";
}
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
@Override
set App.preferredSigner when using index v0 #1086 This was an oversight when we added this functionality, though there was a related TODO. 41f85f3c9df934daba0ee0d60c4c01bb071fa6e7
2017-09-02 22:23:51 +02:00
public int compareTo(@NonNull App app) {
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
return name.compareToIgnoreCase(app.name);
}
parse APK for <nativecode> info in local repos This parses the APKs for swapping, looking for what kinds of native code it includes. This is used in the compatibility check. closes #30 https://gitlab.com/fdroid/fdroidclient/issues/30
2016-05-17 23:49:33 +02:00
public App() {
}
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
declare some key vars final to help the compiler optimize those Apparently, the Java compiler can in some cases reuse a final value instead of executing a method again. This is from @hotlittlewhitedog !653
2018-04-03 23:59:50 +02:00
public App(final Cursor cursor) {
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
checkCursorPosition(cursor);
declare some key vars final to help the compiler optimize those Apparently, the Java compiler can in some cases reuse a final value instead of executing a method again. This is from @hotlittlewhitedog !653
2018-04-03 23:59:50 +02:00
final int cursorColumnCount = cursor.getColumnCount();
for (int i = 0; i < cursorColumnCount; i++) {
final String n = cursor.getColumnName(i);
Log error when view finds unknown column in model This stricter behaviour would have reported a more meaningful error easing investigation for issue #276 on Android 2.1.
2015-06-22 23:01:39 +02:00
switch (n) {
Change join from `app` to `apk` table to auto increment integers rather than Android package name strings. This is important for the ability to refactor the database for better performance in the future. See #511 for details. For those interested in the details, here is a query plan of selecting the "All" category of apps before this commit: * `SCAN TABLE fdroid_app USING INDEX app_id` * `SEARCH TABLE fdroid_apk USING INDEX apk_id (id=?)` * `SEARCH TABLE fdroid_repo USING INTEGER PRIMARY KEY (rowid=?)` * `SEARCH TABLE fdroid_installedApp AS installed USING INDEX sqlite_autoindex_fdroid_installedApp_1 (appId=?)` * `SEARCH TABLE fdroid_apk AS suggestedApk USING INDEX sqlite_autoindex_fdroid_apk_1 (id=? AND vercode=?)` * `USE TEMP B-TREE FOR ORDER BY` And here is a query plan of afterwards: * `SCAN TABLE fdroid_app` * `SEARCH TABLE fdroid_apk USING INDEX apk_appId (appId=?)` * `SEARCH TABLE fdroid_repo USING INTEGER PRIMARY KEY (rowid=?)` * `SEARCH TABLE fdroid_installedApp AS installed USING INDEX sqlite_autoindex_fdroid_installedApp_1 (appId=?)` * `SEARCH TABLE fdroid_apk AS suggestedApk USING INDEX apk_appId (appId=?)` * `USE TEMP B-TREE FOR ORDER BY` The things of note are: * `SCAN TABLE` doesn't use an index, which means that it is really using the rowid index. Shouldn't behave much differently. * The second item now uses an integer primary key index rather than a package name index. Should increase search speed marginally which was the goal of this commit. As more apks exist, the speed improvement will also increase.
2016-06-23 03:30:01 +02:00
case Cols.ROW_ID:
id = cursor.getLong(i);
break;
WIP: Making metadata table work. Requires significant refactorings throughout :(
2016-07-28 04:25:17 +02:00
case Cols.REPO_ID:
repoId = cursor.getLong(i);
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.IS_COMPATIBLE:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
compatible = cursor.getInt(i) == 1;
break;
WIP: Making metadata table work. Requires significant refactorings throughout :(
2016-07-28 04:25:17 +02:00
case Cols.Package.PACKAGE_NAME:
Renamed App.id to App.packageName
2015-12-20 21:07:59 +01:00
packageName = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.NAME:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
name = cursor.getString(i);
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.SUMMARY:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
summary = cursor.getString(i);
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.ICON:
rename app.icon to app.iconFromApk This makes it clearer what this is actually referring to.
2020-02-21 16:08:08 +01:00
iconFromApk = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.DESCRIPTION:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
description = cursor.getString(i);
break;
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
case Cols.WHATSNEW:
whatsNew = cursor.getString(i);
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.LICENSE:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
license = cursor.getString(i);
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.AUTHOR_NAME:
authorName = cursor.getString(i);
Add author/email/license display capabilities to app. (Closes: #532)
2016-01-04 23:53:28 +01:00
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.AUTHOR_EMAIL:
authorEmail = cursor.getString(i);
Add author/email/license display capabilities to app. (Closes: #532)
2016-01-04 23:53:28 +01:00
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.WEBSITE:
webSite = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.ISSUE_TRACKER:
issueTracker = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.SOURCE_CODE:
sourceCode = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
App Details: show the app's Translation links fdroid/fdroidserver!450 icon is: https://material.io/tools/icons/?search=trans&icon=translate&style=baseline
2019-03-22 15:22:11 +01:00
case Cols.TRANSLATION:
translation = cursor.getString(i);
break;
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
case Cols.VIDEO:
video = cursor.getString(i);
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.CHANGELOG:
changelog = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.DONATE:
donate = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.BITCOIN:
bitcoin = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
case Cols.LITECOIN:
litecoin = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.FLATTR_ID:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
flattrID = cursor.getString(i);
break;
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
case Cols.LIBERAPAY:
liberapay = cursor.getString(i);
add liberapay field and donation option This add the liberapayID index field to the local db and then displays a donation badge for apps that provide this.
2018-02-14 22:48:00 +01:00
break;
support OpenCollective as a donation option
2020-06-10 23:53:16 +02:00
case Cols.OPEN_COLLECTIVE:
openCollective = cursor.getString(i);
break;
rename Cols.SuggestedApk to AutoInstallApk #1063
2020-01-10 16:54:09 +01:00
case Cols.AutoInstallApk.VERSION_NAME:
rename App.suggestedVersionName to autoInstallVersionName #1063 # Conflicts: # app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
2020-01-10 17:41:29 +01:00
autoInstallVersionName = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
Add "preferredSigner" field to App. At present, this is chosen from the first package in the index-v1 metadata.
2017-06-21 07:48:21 +02:00
case Cols.PREFERRED_SIGNER:
preferredSigner = cursor.getString(i);
break;
rename App.suggestedVersionCode to autoInstallVersionCode #1063
2020-01-10 16:46:07 +01:00
case Cols.AUTO_INSTALL_VERSION_CODE:
autoInstallVersionCode = cursor.getInt(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
rename App.upstreamVersionCode to suggestedVersionCode #1063
2020-01-10 17:06:58 +01:00
case Cols.SUGGESTED_VERSION_CODE:
suggestedVersionCode = cursor.getInt(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
rename App.upstreamVersionName to suggestedVersionName #1063
2020-01-10 16:59:21 +01:00
case Cols.SUGGESTED_VERSION_NAME:
suggestedVersionName = cursor.getString(i);
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.ADDED:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
added = Utils.parseDate(cursor.getString(i), null);
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.LAST_UPDATED:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
lastUpdated = Utils.parseDate(cursor.getString(i), null);
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.ANTI_FEATURES:
Completely removed `CommaSeparatedList` class, replaced with two helper methods in `Utils`. The two helper methods alleviate the need for copious null checks. They also provide consistent behaviour when there are zero elements (i.e. they return null, rather than an empty string or empty array, as was the case before).
2016-06-20 16:17:11 +02:00
antiFeatures = Utils.parseCommaSeparatedString(cursor.getString(i));
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.REQUIREMENTS:
Completely removed `CommaSeparatedList` class, replaced with two helper methods in `Utils`. The two helper methods alleviate the need for copious null checks. They also provide consistent behaviour when there are zero elements (i.e. they return null, rather than an empty string or empty array, as was the case before).
2016-06-20 16:17:11 +02:00
requirements = Utils.parseCommaSeparatedString(cursor.getString(i));
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.ICON_URL:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
iconUrl = cursor.getString(i);
break;
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
case Cols.FEATURE_GRAPHIC:
featureGraphic = cursor.getString(i);
break;
case Cols.PROMO_GRAPHIC:
promoGraphic = cursor.getString(i);
break;
case Cols.TV_BANNER:
tvBanner = cursor.getString(i);
break;
case Cols.PHONE_SCREENSHOTS:
phoneScreenshots = Utils.parseCommaSeparatedString(cursor.getString(i));
break;
case Cols.SEVEN_INCH_SCREENSHOTS:
sevenInchScreenshots = Utils.parseCommaSeparatedString(cursor.getString(i));
break;
case Cols.TEN_INCH_SCREENSHOTS:
tenInchScreenshots = Utils.parseCommaSeparatedString(cursor.getString(i));
break;
case Cols.TV_SCREENSHOTS:
tvScreenshots = Utils.parseCommaSeparatedString(cursor.getString(i));
break;
case Cols.WEAR_SCREENSHOTS:
wearScreenshots = Utils.parseCommaSeparatedString(cursor.getString(i));
break;
Calculate whether an app is an APK or not when updating repos. This improves performance when we need to decide whether or not apps are installed or not while scrolling through large lists. Fixes #1143. Also change Jackson tests to properly ignore App#isApk.
2017-09-12 16:48:14 +02:00
case Cols.IS_APK:
isApk = cursor.getInt(i) == 1;
break;
add flag to track localized apps for selecting in Latest tab
2019-03-22 13:36:53 +01:00
case Cols.IS_LOCALIZED:
isLocalized = cursor.getInt(i) == 1;
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.InstalledApp.VERSION_CODE:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
installedVersionCode = cursor.getInt(i);
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.InstalledApp.VERSION_NAME:
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
installedVersionName = cursor.getString(i);
break;
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
case Cols.InstalledApp.SIGNATURE:
Store installed app signature in cache This means we can fetch the signatures only once instead of every time we need them. Start by using the cache in AppDetails.
2015-10-22 19:42:39 +02:00
installedSig = cursor.getString(i);
break;
checkstyle: Add indentation
2015-10-08 21:41:38 +02:00
case "_id":
break;
default:
Log.e(TAG, "Unknown column name " + n);
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
}
}
}
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
/**
* Instantiate from a locally installed package.
do not crash when getting hash of APK that disappears This changes the logic of Utils.getBinaryHash() to return null on failure rather than only throwing exceptions. That makes it easier to handle these failures where Utils.getBinaryHash() is called. #1305 #855
2018-04-25 17:10:03 +02:00
* <p>
* Initializes an {@link App} instances from an APK file. Since the file
* could in the cache, and files can disappear from the cache at any time,
* this needs to be quite defensive ensuring that {@code apkFile} still
* exists.
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
*/
do not crash when getting hash of APK that disappears This changes the logic of Utils.getBinaryHash() to return null on failure rather than only throwing exceptions. That makes it easier to handle these failures where Utils.getBinaryHash() is called. #1305 #855
2018-04-25 17:10:03 +02:00
@Nullable
purge CacheSwapAppsService in favor of InstalledAppProvider 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.
2019-05-14 23:47:24 +02:00
public static App getInstance(Context context, PackageManager pm, InstalledApp installedApp, String packageName)
Optimize imports a bit
2015-04-06 22:16:51 +02:00
throws CertificateEncodingException, IOException, PackageManager.NameNotFoundException {
do not crash when getting hash of APK that disappears This changes the logic of Utils.getBinaryHash() to return null on failure rather than only throwing exceptions. That makes it easier to handle these failures where Utils.getBinaryHash() is called. #1305 #855
2018-04-25 17:10:03 +02:00
App app = new App();
reorganize swap's App() constructor to prepare for database caching To generate swap's index.jar, lots of information about all the installed APKs needs to be parsed. That can take a long time. Some of that can be stored in InstalledAppProvider. This prepares for those changes. Also, turns out that packageInfo.applicationInfo provides enough info, so there is no need to use pm.getApplicationInfo(). And the metadata from GET_META_DATA was not even being used.
2016-05-25 10:41:37 +02:00
PackageInfo packageInfo = pm.getPackageInfo(packageName, PackageManager.GET_PERMISSIONS);
SanitizedFile apkFile = SanitizedFile.knownSanitized(packageInfo.applicationInfo.publicSourceDir);
fix crasher caused by wrong init Also, app.installedApk.sig is set in App.initInstalledApk() from 3a5ecc5e8ec6c820dbfdb788dc06f7dbb0699c18 refs #1305 refs #855 java.lang.NullPointerException at org.fdroid.fdroid.data.App.getInstance(App.java:390) at org.fdroid.fdroid.localrepo.CacheSwapAppsService.onHandleIntent(CacheSwapAppsService.java:77) at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:137) at android.os.HandlerThread.run(HandlerThread.java:60)
2018-07-12 10:22:51 +02:00
app.installedApk = new Apk();
purge CacheSwapAppsService in favor of InstalledAppProvider 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.
2019-05-14 23:47:24 +02:00
if (installedApp != null) {
app.installedApk.hashType = installedApp.getHashType();
app.installedApk.hash = installedApp.getHash();
} else if (apkFile.canRead()) {
index.xml must use "sha256" as hash type, not "SHA-256" Otherwise the string matching in RepoXMLHandler.endElement() fails, and the swap repo's index.xml will use "SHA-256" instead of the correct "sha256".
2018-08-06 23:20:32 +02:00
String hashType = "sha256";
rename Utils.getBinaryHash() to Utils.getFileHexDigest() Since this method works on any file, not just APKs or binaries...
2022-01-26 10:45:34 +01:00
String hash = Utils.getFileHexDigest(apkFile, hashType);
do not crash when getting hash of APK that disappears This changes the logic of Utils.getBinaryHash() to return null on failure rather than only throwing exceptions. That makes it easier to handle these failures where Utils.getBinaryHash() is called. #1305 #855
2018-04-25 17:10:03 +02:00
if (TextUtils.isEmpty(hash)) {
return null;
}
app.installedApk.hashType = hashType;
app.installedApk.hash = hash;
}
app.setFromPackageInfo(pm, packageInfo);
app.initInstalledApk(context, app.installedApk, packageInfo, apkFile);
return app;
reorganize swap's App() constructor to prepare for database caching To generate swap's index.jar, lots of information about all the installed APKs needs to be parsed. That can take a long time. Some of that can be stored in InstalledAppProvider. This prepares for those changes. Also, turns out that packageInfo.applicationInfo provides enough info, so there is no need to use pm.getApplicationInfo(). And the metadata from GET_META_DATA was not even being used.
2016-05-25 10:41:37 +02:00
}
fix merge issues and tweak the header layouts a bit more
2018-12-09 08:37:18 +01:00
/**
* In order to format all in coming descriptions before they are written
* out to the database and used elsewhere, this is needed to intercept
* the setting of {@link App#description} to insert the format method.
*/
@JsonProperty("description")
private void setDescription(String description) { // NOPMD
this.description = formatDescription(description);
}
sanitize all packageNames from the index This is insurance to make sure that packageNames are not abused for exploiting F-Droid. The database queries already use SQL Prepared Statements, but who know what else might be exploitable. fdroid/fdroidclient#1588
2019-01-02 17:14:34 +01:00
/**
* Set the Package Name property while ensuring it is sanitized.
*/
@JsonProperty("packageName")
void setPackageName(String packageName) {
if (Utils.isSafePackageName(packageName)) {
this.packageName = packageName;
} else {
throw new IllegalArgumentException("Repo index app entry includes unsafe packageName: '"
+ packageName + "'");
}
}
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
/**
* {@link #liberapay} was originally included using a numeric ID, now it is a
* username. This should not override {@link #liberapay} if that is already set.
*/
@JsonProperty("liberapayID")
void setLiberapayID(String liberapayId) { // NOPMD
if (TextUtils.isEmpty(liberapayId) || !TextUtils.isEmpty(liberapay)) {
return;
}
try {
int id = Integer.parseInt(liberapayId);
if (id > 0) {
liberapay = "~" + liberapayId;
}
} catch (NumberFormatException e) {
// ignored
}
}
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
/**
* Parses the {@code localized} block in the incoming index metadata,
* choosing the best match in terms of locale/language while filling as
fully write up locale choosing for the 'localized' block This is how locales are handled when parsing the index from the server.
2017-04-28 10:17:20 +02:00
* many fields as possible. It first sets up a locale list based on user
* preference and the locales available for this app, then picks the texts
* based on that list. One thing that makes this tricky is that any given
* locale block in the index might not have all the fields. So when filling
* out each value, it needs to go through the whole preference list each time,
* rather than just taking the whole block for a specific locale. This is to
* ensure that there is something to show, as often as possible.
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
* <p>
fully write up locale choosing for the 'localized' block This is how locales are handled when parsing the index from the server.
2017-04-28 10:17:20 +02:00
* It is still possible that the fields will be loaded directly by Jackson
* without any locale info. This comes from the old-style, inline app metadata
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
* fields that do not have locale info. They should not be used if the
fully write up locale choosing for the 'localized' block This is how locales are handled when parsing the index from the server.
2017-04-28 10:17:20 +02:00
* {@code localized} block is included in the index. Also, null strings in
* the {@code localized} block should not overwrite Name/Summary/Description
* strings with empty/null if they were set directly by Jackson.
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
* <ol>
fully write up locale choosing for the 'localized' block This is how locales are handled when parsing the index from the server.
2017-04-28 10:17:20 +02:00
* <li>the country variant {@code de-AT} from the user locale list
* <li>only the language {@code de} from the above locale
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
* <li>next locale in the user's preference list ({@code >= android-24})
fully write up locale choosing for the 'localized' block This is how locales are handled when parsing the index from the server.
2017-04-28 10:17:20 +02:00
* <li>{@code en-US} since its the most common English for software
* <li>the first available {@code en} locale
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
* </ol>
fully write up locale choosing for the 'localized' block This is how locales are handled when parsing the index from the server.
2017-04-28 10:17:20 +02:00
* <p>
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
* The system-wide language preference list was added in {@code android-24}.
*
* @see <a href="https://developer.android.com/guide/topics/resources/multilingual-support">Android language and locale resolution overview</a>
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
*/
@JsonProperty("localized")
App.isLocalized() marks whether relevant translations are available !886
2020-07-14 19:28:46 +02:00
void setLocalized(Map<String, Map<String, Object>> localized) { // NOPMD
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
if (systemLocaleList == null) {
systemLocaleList = ConfigurationCompat.getLocales(Resources.getSystem().getConfiguration());
LocaleList is not properly sorted, so do our own best approx. It seems that LocaleList does not necessarily return the "Language Priority List" in the order that the user has prioritized things. So we have to kind of fake it by first adding the default locale, then adding the locales from LocaleList based on longest order first (e.g. de-AT then de). #987
2017-10-04 22:32:55 +02:00
}
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
Set<String> supportedLocales = localized.keySet();
setIsLocalized(supportedLocales);
String value = getLocalizedEntry(localized, supportedLocales, "whatsNew");
some layout modifications to Updates and AppDetails headers
2018-10-16 19:53:30 +02:00
if (!TextUtils.isEmpty(value)) {
whatsNew = value;
}
trim leading/trailing whitespace from name/summary/video This should make for predictable layouts, since fastlane entries are likely to have a tailing newline, but entries in the metadata YAML will not.
2021-02-06 00:31:31 +01:00
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
value = getLocalizedEntry(localized, supportedLocales, "video");
add Video to Links section of App Details
2017-04-17 12:12:27 +02:00
if (!TextUtils.isEmpty(value)) {
trim leading/trailing whitespace from name/summary/video This should make for predictable layouts, since fastlane entries are likely to have a tailing newline, but entries in the metadata YAML will not.
2021-02-06 00:31:31 +01:00
video = value.trim();
add Video to Links section of App Details
2017-04-17 12:12:27 +02:00
}
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
value = getLocalizedEntry(localized, supportedLocales, "name");
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
if (!TextUtils.isEmpty(value)) {
trim leading/trailing whitespace from name/summary/video This should make for predictable layouts, since fastlane entries are likely to have a tailing newline, but entries in the metadata YAML will not.
2021-02-06 00:31:31 +01:00
name = value.trim();
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
value = getLocalizedEntry(localized, supportedLocales, "summary");
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
if (!TextUtils.isEmpty(value)) {
trim leading/trailing whitespace from name/summary/video This should make for predictable layouts, since fastlane entries are likely to have a tailing newline, but entries in the metadata YAML will not.
2021-02-06 00:31:31 +01:00
summary = value.trim();
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
value = getLocalizedEntry(localized, supportedLocales, "description");
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
if (!TextUtils.isEmpty(value)) {
implement HTML with preserved newlines for app descriptions #1000 closes #1114
2017-12-01 12:40:39 +01:00
description = formatDescription(value);
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
value = getLocalizedGraphicsEntry(localized, supportedLocales, "icon");
allow displaying localized icons Move the logic of calculating the correct iconUrl from sql to java. Fixes #1460.
2020-02-21 14:45:46 +01:00
if (!TextUtils.isEmpty(value)) {
iconUrl = value;
}
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
featureGraphic = getLocalizedGraphicsEntry(localized, supportedLocales, "featureGraphic");
promoGraphic = getLocalizedGraphicsEntry(localized, supportedLocales, "promoGraphic");
tvBanner = getLocalizedGraphicsEntry(localized, supportedLocales, "tvBanner");
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
wearScreenshots = getLocalizedListEntry(localized, supportedLocales, "wearScreenshots");
phoneScreenshots = getLocalizedListEntry(localized, supportedLocales, "phoneScreenshots");
sevenInchScreenshots = getLocalizedListEntry(localized, supportedLocales, "sevenInchScreenshots");
tenInchScreenshots = getLocalizedListEntry(localized, supportedLocales, "tenInchScreenshots");
tvScreenshots = getLocalizedListEntry(localized, supportedLocales, "tvScreenshots");
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
LocaleList is not properly sorted, so do our own best approx. It seems that LocaleList does not necessarily return the "Language Priority List" in the order that the user has prioritized things. So we have to kind of fake it by first adding the default locale, then adding the locales from LocaleList based on longest order first (e.g. de-AT then de). #987
2017-10-04 22:32:55 +02:00
/**
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
* Sets the boolean flag {@link #isLocalized} if this app entry has an localized
* entry in one of the user's current locales.
*
* @see org.fdroid.fdroid.views.main.WhatsNewViewBinder#onCreateLoader(int, android.os.Bundle)
*/
private void setIsLocalized(Set<String> supportedLocales) {
isLocalized = false;
for (int i = 0; i < systemLocaleList.size(); i++) {
String language = systemLocaleList.get(i).getLanguage();
for (String supportedLocale : supportedLocales) {
if (language.equals(supportedLocale.split("-")[0])) {
isLocalized = true;
return;
}
}
}
}
/**
* Returns the right localized version of this entry, based on an imitation of
* the logic that Android uses.
LocaleList is not properly sorted, so do our own best approx. It seems that LocaleList does not necessarily return the "Language Priority List" in the order that the user has prioritized things. So we have to kind of fake it by first adding the default locale, then adding the locales from LocaleList based on longest order first (e.g. de-AT then de). #987
2017-10-04 22:32:55 +02:00
*
* @see LocaleList
*/
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
private String getLocalizedEntry(Map<String, Map<String, Object>> localized,
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
Set<String> supportedLocales, @NonNull String key) {
Map<String, Object> localizedLocaleMap = getLocalizedLocaleMap(localized, supportedLocales, key);
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
if (localizedLocaleMap != null && !localizedLocaleMap.isEmpty()) {
for (Object entry : localizedLocaleMap.values()) {
return (String) entry; // NOPMD
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
}
return null;
}
private String getLocalizedGraphicsEntry(Map<String, Map<String, Object>> localized,
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
Set<String> supportedLocales, @NonNull String key) {
Map<String, Object> localizedLocaleMap = getLocalizedLocaleMap(localized, supportedLocales, key);
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
if (localizedLocaleMap != null && !localizedLocaleMap.isEmpty()) {
for (String locale : localizedLocaleMap.keySet()) {
return locale + "/" + localizedLocaleMap.get(locale); // NOPMD
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
}
return null;
}
correct method name: getLocalizedListEntry() This gets the data, it does not set it. And it matches the other getLocalized*() methods.
2017-06-02 13:20:33 +02:00
private String[] getLocalizedListEntry(Map<String, Map<String, Object>> localized,
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
Set<String> supportedLocales, @NonNull String key) {
Map<String, Object> localizedLocaleMap = getLocalizedLocaleMap(localized, supportedLocales, key);
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
if (localizedLocaleMap != null && !localizedLocaleMap.isEmpty()) {
for (String locale : localizedLocaleMap.keySet()) {
ArrayList<String> entry = (ArrayList<String>) localizedLocaleMap.get(locale);
if (entry != null && entry.size() > 0) {
String[] result = new String[entry.size()];
int i = 0;
for (String e : entry) {
result[i] = locale + "/" + key + "/" + e;
i++;
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
return result;
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
}
}
return new String[0];
}
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
/**
* Return one matching entry from the {@code localized} block in the app entry
* in the index JSON.
*/
private Map<String, Object> getLocalizedLocaleMap(Map<String, Map<String, Object>> localized,
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
Set<String> supportedLocales, @NonNull String key) {
String[] localesToUse = getLocalesForKey(localized, supportedLocales, key);
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
if (localesToUse.length > 0) {
Locale firstMatch = systemLocaleList.getFirstMatch(localesToUse);
if (firstMatch != null) {
workaround Locale.toLanguageTag() requiring android-21
2021-02-06 01:23:53 +01:00
for (String languageTag : new String[]{toLanguageTag(firstMatch), null}) {
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
if (languageTag == null) {
languageTag = getFallbackLanguageTag(firstMatch, localesToUse); // NOPMD
}
Map<String, Object> localeEntry = localized.get(languageTag);
if (localeEntry != null && localeEntry.containsKey(key)) {
Object value = localeEntry.get(key);
if (value != null) {
Map<String, Object> localizedLocaleMap = new HashMap<>();
localizedLocaleMap.put(languageTag, value);
return localizedLocaleMap;
}
}
}
}
}
return null;
}
workaround Locale.toLanguageTag() requiring android-21
2021-02-06 01:23:53 +01:00
/**
* Replace with {@link Locale#toLanguageTag()} once
* {@link android.os.Build.VERSION_CODES#LOLLIPOP} is {@code minSdkVersion}
*/
private String toLanguageTag(Locale firstMatch) {
if (Build.VERSION.SDK_INT < 21) {
return firstMatch.toString().replace("_", "-");
} else {
return firstMatch.toLanguageTag();
}
}
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
/**
* Get all locales that have an entry for {@code key}.
*/
private String[] getLocalesForKey(Map<String, Map<String, Object>> localized,
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
Set<String> supportedLocales, @NonNull String key) {
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
Set<String> localesToUse = new HashSet<>();
App: rename "locales" to "supportedLocales" for clarity
2021-02-06 00:37:57 +01:00
for (String locale : supportedLocales) {
totally overhaul choosing locales from app metadata based on LocaleList This makes the selection logic heed the list of preferred locales from the user Settings. closes #987 closes #1186 refs #1440 #1882 #1730 !886
2021-02-05 16:36:47 +01:00
Map<String, Object> localeEntry = localized.get(locale);
if (localeEntry != null && localeEntry.get(key) != null) {
localesToUse.add(locale);
}
}
return localesToUse.toArray(new String[0]);
}
/**
* Look for the first language-country match for languages with multiple scripts.
* Then look for a language-only match, for when there is no exact
* {@link Locale} match. Then try a locale with the same language, but
* different country. If there are still no matches, return the {@code en-US}
* entry. If all else fails, try to return the first existing English locale.
*/
private String getFallbackLanguageTag(Locale firstMatch, String[] localesToUse) {
final String firstMatchLanguageCountry = firstMatch.getLanguage() + "-" + firstMatch.getCountry();
for (String languageTag : localesToUse) {
if (languageTag.equals(firstMatchLanguageCountry)) {
return languageTag;
}
}
final String firstMatchLanguage = firstMatch.getLanguage();
String englishLastResort = null;
for (String languageTag : localesToUse) {
if (languageTag.equals(firstMatchLanguage)) {
return languageTag;
} else if ("en-US".equals(languageTag)) {
englishLastResort = languageTag;
}
}
for (String languageTag : localesToUse) {
String languageToUse = languageTag.split("-")[0];
if (firstMatchLanguage.equals(languageToUse)) {
return languageTag;
} else if (englishLastResort == null && "en".equals(languageToUse)) {
englishLastResort = languageTag;
}
}
return englishLastResort;
}
implement HTML with preserved newlines for app descriptions #1000 closes #1114
2017-12-01 12:40:39 +01:00
/**
* Returns the app description text with all newlines replaced by {@code <br>}
*/
public static String formatDescription(String description) {
return description.replace("\n", "<br>");
}
make app share URL based on the repo URL closes #1946
2021-09-10 10:08:17 +02:00
/**
* Get the URL with the standard path for displaying in a browser.
*/
@NonNull
public Uri getShareUri(Context context) {
Repo repo = RepoProvider.Helper.findById(context, repoId);
return Uri.parse(repo.address).buildUpon()
.path(String.format("/packages/%s/", packageName))
.build();
}
Add glide support to download library
2022-01-19 19:07:46 +01:00
public RequestBuilder<Drawable> loadWithGlide(Context context) {
allow displaying localized icons Move the logic of calculating the correct iconUrl from sql to java. Fixes #1460.
2020-02-21 14:45:46 +01:00
Repo repo = RepoProvider.Helper.findById(context, repoId);
Add glide support to download library
2022-01-19 19:07:46 +01:00
if (repo.address.startsWith("content://")) {
return Glide.with(context).load(getIconUrl(context, repo));
} else {
return Glide.with(context).load(getDownloadRequest(context, repo));
}
}
@Nullable
@Deprecated // not taking mirrors into account
public String getIconUrl(Context context, Repo repo) {
allow displaying localized icons Move the logic of calculating the correct iconUrl from sql to java. Fixes #1460.
2020-02-21 14:45:46 +01:00
if (TextUtils.isEmpty(iconUrl)) {
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
if (TextUtils.isEmpty(iconFromApk)) {
allow displaying localized icons Move the logic of calculating the correct iconUrl from sql to java. Fixes #1460.
2020-02-21 14:45:46 +01:00
return null;
}
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
if (iconFromApk.endsWith(".xml")) {
ignore xml icons They will never work, they should not be set by fdroidserver but we can be defensive about not returning them to any views here.
2020-02-24 16:44:44 +01:00
// We cannot use xml ressources as icons. F-Droid server should not include them
// https://gitlab.com/fdroid/fdroidserver/issues/344
return null;
}
allow displaying localized icons Move the logic of calculating the correct iconUrl from sql to java. Fixes #1460.
2020-02-21 14:45:46 +01:00
String iconsDir;
if (repo.version >= Repo.VERSION_DENSITY_SPECIFIC_ICONS) {
iconsDir = Utils.getIconsDir(context, 1.0);
} else {
iconsDir = Utils.FALLBACK_ICONS_DIR;
}
Add Repo.getFileUrl() method to get file URL in a standard way
2020-11-08 09:00:28 +01:00
return repo.getFileUrl(iconsDir, iconFromApk);
allow displaying localized icons Move the logic of calculating the correct iconUrl from sql to java. Fixes #1460.
2020-02-21 14:45:46 +01:00
}
Add Repo.getFileUrl() method to get file URL in a standard way
2020-11-08 09:00:28 +01:00
return repo.getFileUrl(packageName, iconUrl);
allow displaying localized icons Move the logic of calculating the correct iconUrl from sql to java. Fixes #1460.
2020-02-21 14:45:46 +01:00
}
Add glide support to download library
2022-01-19 19:07:46 +01:00
@Nullable
@Deprecated // not taking mirrors into account
public String getIconUrl(Context context) {
Repo repo = RepoProvider.Helper.findById(context, repoId);
return getIconUrl(context, repo);
}
@Nullable
public DownloadRequest getDownloadRequest(Context context, Repo repo) {
String path;
if (TextUtils.isEmpty(iconUrl)) {
if (TextUtils.isEmpty(iconFromApk)) {
return null;
}
if (iconFromApk.endsWith(".xml")) {
// We cannot use xml resources as icons. F-Droid server should not include them
// https://gitlab.com/fdroid/fdroidserver/issues/344
return null;
}
String iconsDir;
if (repo.version >= Repo.VERSION_DENSITY_SPECIFIC_ICONS) {
iconsDir = Utils.getIconsDir(context, 1.0);
} else {
iconsDir = Utils.FALLBACK_ICONS_DIR;
}
path = repo.getPath(iconsDir, iconFromApk);
} else {
path = repo.getPath(packageName, iconUrl);
}
return repo.getDownloadRequest(path);
}
@Nullable
public DownloadRequest getDownloadRequest(Context context) {
Repo repo = RepoProvider.Helper.findById(context, repoId);
return getDownloadRequest(context, repo);
}
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
public String getFeatureGraphicUrl(Context context) {
if (TextUtils.isEmpty(featureGraphic)) {
return null;
}
Repo repo = RepoProvider.Helper.findById(context, repoId);
Add Repo.getFileUrl() method to get file URL in a standard way
2020-11-08 09:00:28 +01:00
return repo.getFileUrl(packageName, featureGraphic);
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
public String getPromoGraphic(Context context) {
if (TextUtils.isEmpty(promoGraphic)) {
return null;
}
Repo repo = RepoProvider.Helper.findById(context, repoId);
Add Repo.getFileUrl() method to get file URL in a standard way
2020-11-08 09:00:28 +01:00
return repo.getFileUrl(packageName, promoGraphic);
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
public String getTvBanner(Context context) {
if (TextUtils.isEmpty(tvBanner)) {
return null;
}
Repo repo = RepoProvider.Helper.findById(context, repoId);
Add Repo.getFileUrl() method to get file URL in a standard way
2020-11-08 09:00:28 +01:00
return repo.getFileUrl(packageName, tvBanner);
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
}
public String[] getAllScreenshots(Context context) {
Repo repo = RepoProvider.Helper.findById(context, repoId);
ArrayList<String> list = new ArrayList<>();
if (phoneScreenshots != null) {
Collections.addAll(list, phoneScreenshots);
}
if (sevenInchScreenshots != null) {
Collections.addAll(list, sevenInchScreenshots);
}
if (tenInchScreenshots != null) {
Collections.addAll(list, tenInchScreenshots);
}
if (tvScreenshots != null) {
Collections.addAll(list, tvScreenshots);
}
if (wearScreenshots != null) {
Collections.addAll(list, wearScreenshots);
}
String[] result = new String[list.size()];
int i = 0;
for (String url : list) {
Add Repo.getFileUrl() method to get file URL in a standard way
2020-11-08 09:00:28 +01:00
result[i] = repo.getFileUrl(packageName, url);
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
i++;
}
return result;
}
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
/**
* Get the directory where APK Expansion Files aka OBB files are stored for the app as
* specified by {@code packageName}.
*
* @see <a href="https://developer.android.com/google/play/expansion-files.html">APK Expansion Files</a>
*/
public static File getObbDir(String packageName) {
return new File(Environment.getExternalStorageDirectory().getAbsolutePath()
+ "/Android/obb/" + packageName);
}
Remove redundant throw clauses found by Studio
2016-06-07 23:24:27 +02:00
private void setFromPackageInfo(PackageManager pm, PackageInfo packageInfo) {
reorganize swap's App() constructor to prepare for database caching To generate swap's index.jar, lots of information about all the installed APKs needs to be parsed. That can take a long time. Some of that can be stored in InstalledAppProvider. This prepares for those changes. Also, turns out that packageInfo.applicationInfo provides enough info, so there is no need to use pm.getApplicationInfo(). And the metadata from GET_META_DATA was not even being used.
2016-05-25 10:41:37 +02:00
this.packageName = packageInfo.packageName;
Add some final keywords Especially in constants within classes, which allows for inlining.
2015-04-01 16:11:56 +02:00
final String installerPackageName = pm.getInstallerPackageName(packageName);
catch NameNotFoundException when looking up installer name If an application was installed via ADB, then it won't have an installer package/name set. Therefore, looking up the label will cause a NameNotFoundException, which should be ignored and not passed to the method that called App() since it does not refer to the packageName that the method is trying to look up, but instead the packageName of the missing installer app.
2014-05-07 05:15:51 +02:00
CharSequence installerPackageLabel = null;
if (!TextUtils.isEmpty(installerPackageName)) {
try {
ApplicationInfo installerAppInfo = pm.getApplicationInfo(installerPackageName,
PackageManager.GET_META_DATA);
installerPackageLabel = installerAppInfo.loadLabel(pm);
Optimize imports a bit
2015-04-06 22:16:51 +02:00
} catch (PackageManager.NameNotFoundException e) {
checkstyle: enable and apply WhitespaceAfter
2015-10-08 19:44:31 +02:00
Log.w(TAG, "Could not get app info: " + installerPackageName, e);
catch NameNotFoundException when looking up installer name If an application was installed via ADB, then it won't have an installer package/name set. Therefore, looking up the label will cause a NameNotFoundException, which should be ignored and not passed to the method that called App() since it does not refer to the packageName that the method is trying to look up, but instead the packageName of the missing installer app.
2014-05-07 05:15:51 +02:00
}
}
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
if (TextUtils.isEmpty(installerPackageLabel)) {
add summary/description to installed apps based on installed info First try to get the description from APK, which is seems that no one sets so it is usually null. Then get info about how it was installed, like which app store, when it was installed and upgraded.
2014-05-06 23:09:19 +02:00
installerPackageLabel = installerPackageName;
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
}
catch NameNotFoundException when looking up installer name If an application was installed via ADB, then it won't have an installer package/name set. Therefore, looking up the label will cause a NameNotFoundException, which should be ignored and not passed to the method that called App() since it does not refer to the packageName that the method is trying to look up, but instead the packageName of the missing installer app.
2014-05-07 05:15:51 +02:00
reorganize swap's App() constructor to prepare for database caching To generate swap's index.jar, lots of information about all the installed APKs needs to be parsed. That can take a long time. Some of that can be stored in InstalledAppProvider. This prepares for those changes. Also, turns out that packageInfo.applicationInfo provides enough info, so there is no need to use pm.getApplicationInfo(). And the metadata from GET_META_DATA was not even being used.
2016-05-25 10:41:37 +02:00
ApplicationInfo appInfo = packageInfo.applicationInfo;
Add some final keywords Especially in constants within classes, which allows for inlining.
2015-04-01 16:11:56 +02:00
final CharSequence appDescription = appInfo.loadDescription(pm);
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
if (TextUtils.isEmpty(appDescription)) {
add summary/description to installed apps based on installed info First try to get the description from APK, which is seems that no one sets so it is usually null. Then get info about how it was installed, like which app store, when it was installed and upgraded.
2014-05-06 23:09:19 +02:00
this.summary = "(installed by " + installerPackageLabel + ")";
fix crash if an APK has a short embedded description caught java.lang.StringIndexOutOfBoundsException: at java.lang.String.substring(String.java:1651) at java.lang.String.subSequence(String.java:2040) at org.fdroid.fdroid.data.App.setFromPackageInfo(App.java:298) at org.fdroid.fdroid.data.App.<init>(App.java:268) at org.fdroid.fdroid.localrepo.CacheSwapAppsService.onHandleIntent(CacheSwapAppsService.java:78) at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:59) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:130) at android.os.HandlerThread.run(HandlerThread.java:60)
2016-06-01 22:44:03 +02:00
} else if (appDescription.length() > 40) {
add summary/description to installed apps based on installed info First try to get the description from APK, which is seems that no one sets so it is usually null. Then get info about how it was installed, like which app store, when it was installed and upgraded.
2014-05-06 23:09:19 +02:00
this.summary = (String) appDescription.subSequence(0, 40);
fix crash if an APK has a short embedded description caught java.lang.StringIndexOutOfBoundsException: at java.lang.String.substring(String.java:1651) at java.lang.String.subSequence(String.java:2040) at org.fdroid.fdroid.data.App.setFromPackageInfo(App.java:298) at org.fdroid.fdroid.data.App.<init>(App.java:268) at org.fdroid.fdroid.localrepo.CacheSwapAppsService.onHandleIntent(CacheSwapAppsService.java:78) at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:59) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:130) at android.os.HandlerThread.run(HandlerThread.java:60)
2016-06-01 22:44:03 +02:00
} else {
this.summary = (String) appDescription;
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
}
Fix minsdk to be 8 instead of 7 Java 1.7 is supported from 8, not 7, so we dropped support for 7 long ago. Very few devices run 7 and quite a few things wouldn't work on 7 anyway.
2015-05-19 13:08:55 +02:00
this.added = new Date(packageInfo.firstInstallTime);
this.lastUpdated = new Date(packageInfo.lastUpdateTime);
add summary/description to installed apps based on installed info First try to get the description from APK, which is seems that no one sets so it is usually null. Then get info about how it was installed, like which app store, when it was installed and upgraded.
2014-05-06 23:09:19 +02:00
this.description = "<p>";
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
if (!TextUtils.isEmpty(appDescription)) {
add summary/description to installed apps based on installed info First try to get the description from APK, which is seems that no one sets so it is usually null. Then get info about how it was installed, like which app store, when it was installed and upgraded.
2014-05-06 23:09:19 +02:00
this.description += appDescription + "\n";
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
}
add summary/description to installed apps based on installed info First try to get the description from APK, which is seems that no one sets so it is usually null. Then get info about how it was installed, like which app store, when it was installed and upgraded.
2014-05-06 23:09:19 +02:00
this.description += "(installed by " + installerPackageLabel
+ ", first installed on " + this.added
+ ", last updated on " + this.lastUpdated + ")</p>";
this.name = (String) appInfo.loadLabel(pm);
rename app.icon to app.iconFromApk This makes it clearer what this is actually referring to.
2020-02-21 16:08:08 +01:00
this.iconFromApk = getIconName(packageName, packageInfo.versionCode);
new CacheSwapAppsService for caching parsed apps to be swapped Since it takes a chunk of time to generate and write the app index.jar when swapping apps, this service starts running in the background immediately when SwapService starts. It first indexes the installed apps that were not cached, then caches apps based PACKAGE_ADDED broadcasts. It does not index system apps, since there are many and they are rarely swapped.
2016-05-27 23:02:54 +02:00
this.installedVersionName = packageInfo.versionName;
this.installedVersionCode = packageInfo.versionCode;
mark as compatible when App/Apk instances are from installed apps By definition, an app that is already installed is compatible.
2016-05-18 14:46:07 +02:00
this.compatible = true;
reorganize swap's App() constructor to prepare for database caching To generate swap's index.jar, lots of information about all the installed APKs needs to be parsed. That can take a long time. Some of that can be stored in InstalledAppProvider. This prepares for those changes. Also, turns out that packageInfo.applicationInfo provides enough info, so there is no need to use pm.getApplicationInfo(). And the metadata from GET_META_DATA was not even being used.
2016-05-25 10:41:37 +02:00
}
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
public static void initInstalledObbFiles(Apk apk) {
File obbdir = getObbDir(apk.packageName);
FileFilter filter = new RegexFileFilter("(main|patch)\\.[0-9-][0-9]*\\." + apk.packageName + "\\.obb");
File[] files = obbdir.listFiles(filter);
if (files == null) {
return;
}
Arrays.sort(files);
for (File f : files) {
String filename = f.getName();
String[] segments = filename.split("\\.");
if (Integer.parseInt(segments[1]) <= apk.versionCode) {
if ("main".equals(segments[0])) {
apk.obbMainFile = filename;
rename Utils.getBinaryHash() to Utils.getFileHexDigest() Since this method works on any file, not just APKs or binaries...
2022-01-26 10:45:34 +01:00
apk.obbMainFileSha256 = Utils.getFileHexDigest(f, apk.hashType);
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
} else if ("patch".equals(segments[0])) {
apk.obbPatchFile = filename;
rename Utils.getBinaryHash() to Utils.getFileHexDigest() Since this method works on any file, not just APKs or binaries...
2022-01-26 10:45:34 +01:00
apk.obbPatchFileSha256 = Utils.getFileHexDigest(f, apk.hashType);
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
}
}
}
}
do not crash when getting hash of APK that disappears This changes the logic of Utils.getBinaryHash() to return null on failure rather than only throwing exceptions. That makes it easier to handle these failures where Utils.getBinaryHash() is called. #1305 #855
2018-04-25 17:10:03 +02:00
@SuppressWarnings("EmptyForIteratorPad")
reorganize swap's App() constructor to prepare for database caching To generate swap's index.jar, lots of information about all the installed APKs needs to be parsed. That can take a long time. Some of that can be stored in InstalledAppProvider. This prepares for those changes. Also, turns out that packageInfo.applicationInfo provides enough info, so there is no need to use pm.getApplicationInfo(). And the metadata from GET_META_DATA was not even being used.
2016-05-25 10:41:37 +02:00
private void initInstalledApk(Context context, Apk apk, PackageInfo packageInfo, SanitizedFile apkFile)
throws IOException, CertificateEncodingException {
mark as compatible when App/Apk instances are from installed apps By definition, an app that is already installed is compatible.
2016-05-18 14:46:07 +02:00
apk.compatible = true;
Rename Apk.version to Apk.versionName Updates #37.
2016-04-19 13:00:17 +02:00
apk.versionName = packageInfo.versionName;
Rename Apk.vercode to Apk.versionCode Updates #37.
2016-04-19 12:49:00 +02:00
apk.versionCode = packageInfo.versionCode;
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
apk.added = this.added;
include targetSdkVersion in Apk In order to work well with the Android 6.0+ permissions, the client needs to know whether an APK has been built against android-23 or higher. closes #682 https://gitlab.com/fdroid/fdroidclient/issues/682
2016-06-10 10:28:25 +02:00
int[] minTargetMax = getMinTargetMaxSdkVersions(context, packageName);
apk.minSdkVersion = minTargetMax[0];
apk.targetSdkVersion = minTargetMax[1];
apk.maxSdkVersion = minTargetMax[2];
Renamed Apk.id to Apk.packageName
2015-12-21 11:07:45 +01:00
apk.packageName = this.packageName;
rename Apk.permissions to requestedPermissions like PackageInfo android.content.pm.PackageInfo is the Android class for representing data about an APK/package. Since Apk.permission is the same thing, we should use the same name.
2016-10-07 09:42:43 +02:00
apk.requestedPermissions = packageInfo.requestedPermissions;
Rename Apk.vercode to Apk.versionCode Updates #37.
2016-04-19 12:49:00 +02:00
apk.apkName = apk.packageName + "_" + apk.versionCode + ".apk";
parse APK for <nativecode> info in local repos This parses the APKs for swapping, looking for what kinds of native code it includes. This is used in the compatibility check. closes #30 https://gitlab.com/fdroid/fdroidclient/issues/30
2016-05-17 23:49:33 +02:00
support "APK Extension" files aka .obb for large apps and games 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
2016-06-28 00:07:50 +02:00
initInstalledObbFiles(apk);
make sure cached file exists before trying to scan it Files in the cache can be deleted at any time, without warning. F-Droid's CleanCacheService can do it, the user can do it in Settings --> Apps, etc. So when working with files from the cache, the methods need to be extra defensive, checking that the file that they were given still exists. closes #1305
2018-02-08 23:52:23 +01:00
final FeatureInfo[] features = packageInfo.reqFeatures;
if (features != null && features.length > 0) {
apk.features = new String[features.length];
for (int i = 0; i < features.length; i++) {
apk.features[i] = features[i].name;
}
}
if (!apkFile.canRead()) {
return;
}
apk.installedFile = apkFile;
reorganize swap's App() constructor to prepare for database caching To generate swap's index.jar, lots of information about all the installed APKs needs to be parsed. That can take a long time. Some of that can be stored in InstalledAppProvider. This prepares for those changes. Also, turns out that packageInfo.applicationInfo provides enough info, so there is no need to use pm.getApplicationInfo(). And the metadata from GET_META_DATA was not even being used.
2016-05-25 10:41:37 +02:00
JarFile apkJar = new JarFile(apkFile);
parse APK for <nativecode> info in local repos This parses the APKs for swapping, looking for what kinds of native code it includes. This is used in the compatibility check. closes #30 https://gitlab.com/fdroid/fdroidclient/issues/30
2016-05-17 23:49:33 +02:00
HashSet<String> abis = new HashSet<>(3);
Pattern pattern = Pattern.compile("^lib/([a-z0-9-]+)/.*");
do not crash when getting hash of APK that disappears This changes the logic of Utils.getBinaryHash() to return null on failure rather than only throwing exceptions. That makes it easier to handle these failures where Utils.getBinaryHash() is called. #1305 #855
2018-04-25 17:10:03 +02:00
for (Enumeration<JarEntry> jarEntries = apkJar.entries(); jarEntries.hasMoreElements(); ) {
parse APK for <nativecode> info in local repos This parses the APKs for swapping, looking for what kinds of native code it includes. This is used in the compatibility check. closes #30 https://gitlab.com/fdroid/fdroidclient/issues/30
2016-05-17 23:49:33 +02:00
JarEntry jarEntry = jarEntries.nextElement();
Matcher matcher = pattern.matcher(jarEntry.getName());
if (matcher.matches()) {
abis.add(matcher.group(1));
}
}
Completely removed `CommaSeparatedList` class, replaced with two helper methods in `Utils`. The two helper methods alleviate the need for copious null checks. They also provide consistent behaviour when there are zero elements (i.e. they return null, rather than an empty string or empty array, as was the case before).
2016-06-20 16:17:11 +02:00
apk.nativecode = abis.toArray(new String[abis.size()]);
parse APK for <nativecode> info in local repos This parses the APKs for swapping, looking for what kinds of native code it includes. This is used in the compatibility check. closes #30 https://gitlab.com/fdroid/fdroidclient/issues/30
2016-05-17 23:49:33 +02:00
Throw some more final keywords in
2015-04-30 20:40:19 +02:00
final JarEntry aSignedEntry = (JarEntry) apkJar.getEntry("AndroidManifest.xml");
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
if (aSignedEntry == null) {
apkJar.close();
throw new CertificateEncodingException("null signed entry!");
}
purge enableBouncyCastleOnLollipop, minSdkVersion is higher
2022-01-17 09:51:22 +01:00
final InputStream tmpIn = apkJar.getInputStream(aSignedEntry);
byte[] buff = new byte[2048];
//noinspection StatementWithEmptyBody
while (tmpIn.read(buff, 0, buff.length) != -1) {
/*
* NOP - apparently have to READ from the JarEntry before you can
* call getCerficates() and have it return != null. Yay Java.
*/
}
tmpIn.close();
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
purge enableBouncyCastleOnLollipop, minSdkVersion is higher
2022-01-17 09:51:22 +01:00
if (aSignedEntry.getCertificates() == null
|| aSignedEntry.getCertificates().length == 0) {
apkJar.close();
throw new CertificateEncodingException("No Certificates found!");
Disable spongycastle before verifying jar files. Fixes issue #111. This is a workaround rather than a full solution, but it solves the problem. There is a bug in Lollipop, whereby including spongycastle as a security provider causes problems verifying .jar files. As a result, it is now disabled when actually performing verification, so that the libraries provided by Android do the work, and then re-enabled afterwards. There is an ever so slight chance that the period when this is disabled may align with the period when spongycastle may actually be required (i.e. for signing a local repo index). This is a risk which I cnanot see how to avoid, and will likel7 cause either the signing to fail due to the unavailability of the relevant security classes. However this is very minimal, hard to reproduce (I couldn't get it to happen) and also has the effect of the local repo failing, rather than the updating of apps failing (which is arguably more important) and so is worth it in my opinion. See comments at https://gitlab.com/fdroid/fdroidclient/issues/111 for much greater detail.
2014-11-17 12:21:18 +01:00
}
purge enableBouncyCastleOnLollipop, minSdkVersion is higher
2022-01-17 09:51:22 +01:00
final Certificate signer = aSignedEntry.getCertificates()[0];
byte[] rawCertBytes = signer.getEncoded();
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
apkJar.close();
always use fingerprint hashes in lowercase * Utils.getBinaryHash() converts it to lowercase() * Utils.getPackageSig() outputs lowercase * fdroidserver outputs lowercase for all hash entries
2021-01-05 15:26:38 +01:00
apk.sig = Utils.getsig(rawCertBytes);
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
}
Extract getInstalledApk() from AppDetails2 to App
2017-07-05 09:28:46 +02:00
/**
* Attempts to find the installed {@link Apk} from the database. If not found, will lookup the
* {@link InstalledAppProvider} to find the details of the installed app and use that to
* instantiate an {@link Apk} to be returned.
LocaleList is not properly sorted, so do our own best approx. It seems that LocaleList does not necessarily return the "Language Priority List" in the order that the user has prioritized things. So we have to kind of fake it by first adding the default locale, then adding the locales from LocaleList based on longest order first (e.g. de-AT then de). #987
2017-10-04 22:32:55 +02:00
* <p>
Extract getInstalledApk() from AppDetails2 to App
2017-07-05 09:28:46 +02:00
* Cases where an {@link Apk} will not be found in the database and for which we fall back to
* the {@link InstalledAppProvider} include:
LocaleList is not properly sorted, so do our own best approx. It seems that LocaleList does not necessarily return the "Language Priority List" in the order that the user has prioritized things. So we have to kind of fake it by first adding the default locale, then adding the locales from LocaleList based on longest order first (e.g. de-AT then de). #987
2017-10-04 22:32:55 +02:00
* <li>System apps which are provided by a repository, but for which the version code bundled
* with the system is not included in the repository.</li>
* <li>Regular apps from a repository, where the installed version is old enough that it is no
* longer available in the repository.</li>
Extract getInstalledApk() from AppDetails2 to App
2017-07-05 09:28:46 +02:00
*/
@Nullable
public Apk getInstalledApk(Context context) {
try {
PackageInfo pi = context.getPackageManager().getPackageInfo(this.packageName, 0);
Apk apk = ApkProvider.Helper.findApkFromAnyRepo(context, pi.packageName, pi.versionCode);
if (apk == null) {
InstalledApp installedApp = InstalledAppProvider.Helper.findByPackageName(context, pi.packageName);
if (installedApp == null) {
throw new IllegalStateException("No installed app found when trying to uninstall");
}
apk = new Apk(installedApp);
}
return apk;
} catch (PackageManager.NameNotFoundException e) {
return null;
}
}
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
public boolean isValid() {
if (TextUtils.isEmpty(this.name)
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
|| TextUtils.isEmpty(this.packageName)) {
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
return false;
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
}
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
if (this.installedApk == null) {
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
return false;
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
}
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
if (TextUtils.isEmpty(this.installedApk.sig)) {
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
return false;
checkstyle: obey NeedBraces on multi-line stmts We still allow them in single-line statements, like: if (foo) bar; for (int i : ints) bar; Everything else should use braces to help readability and avoid silly human mistakes that might result in bugs. These changes were completely automated via a python script.
2016-02-17 12:58:35 +01:00
}
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
Throw some more final keywords in
2015-04-30 20:40:19 +02:00
final File apkFile = this.installedApk.installedFile;
Run "code cleanup" in Android Studio This basically removes public, static and final from interfaces since it's always that way.
2015-05-04 00:06:32 +02:00
return !(apkFile == null || !apkFile.canRead());
constructor to create App from an installed APK Using PackageManager and Context, this will create an App instance from the APK specified by the packageName.
2014-05-06 22:24:05 +02:00
}
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
public ContentValues toContentValues() {
Throw some more final keywords in
2015-04-30 20:40:19 +02:00
final ContentValues values = new ContentValues();
Change join from `app` to `apk` table to auto increment integers rather than Android package name strings. This is important for the ability to refactor the database for better performance in the future. See #511 for details. For those interested in the details, here is a query plan of selecting the "All" category of apps before this commit: * `SCAN TABLE fdroid_app USING INDEX app_id` * `SEARCH TABLE fdroid_apk USING INDEX apk_id (id=?)` * `SEARCH TABLE fdroid_repo USING INTEGER PRIMARY KEY (rowid=?)` * `SEARCH TABLE fdroid_installedApp AS installed USING INDEX sqlite_autoindex_fdroid_installedApp_1 (appId=?)` * `SEARCH TABLE fdroid_apk AS suggestedApk USING INDEX sqlite_autoindex_fdroid_apk_1 (id=? AND vercode=?)` * `USE TEMP B-TREE FOR ORDER BY` And here is a query plan of afterwards: * `SCAN TABLE fdroid_app` * `SEARCH TABLE fdroid_apk USING INDEX apk_appId (appId=?)` * `SEARCH TABLE fdroid_repo USING INTEGER PRIMARY KEY (rowid=?)` * `SEARCH TABLE fdroid_installedApp AS installed USING INDEX sqlite_autoindex_fdroid_installedApp_1 (appId=?)` * `SEARCH TABLE fdroid_apk AS suggestedApk USING INDEX apk_appId (appId=?)` * `USE TEMP B-TREE FOR ORDER BY` The things of note are: * `SCAN TABLE` doesn't use an index, which means that it is really using the rowid index. Shouldn't behave much differently. * The second item now uses an integer primary key index rather than a package name index. Should increase search speed marginally which was the goal of this commit. As more apks exist, the speed improvement will also increase.
2016-06-23 03:30:01 +02:00
// Intentionally don't put "ROW_ID" in here, because we don't ever want to change that
// primary key generated by sqlite.
WIP: Making metadata table work. Requires significant refactorings throughout :(
2016-07-28 04:25:17 +02:00
values.put(Cols.Package.PACKAGE_NAME, packageName);
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
values.put(Cols.NAME, name);
WIP: Making metadata table work. Requires significant refactorings throughout :(
2016-07-28 04:25:17 +02:00
values.put(Cols.REPO_ID, repoId);
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
values.put(Cols.SUMMARY, summary);
rename app.icon to app.iconFromApk This makes it clearer what this is actually referring to.
2020-02-21 16:08:08 +01:00
values.put(Cols.ICON, iconFromApk);
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
values.put(Cols.ICON_URL, iconUrl);
values.put(Cols.DESCRIPTION, description);
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
values.put(Cols.WHATSNEW, whatsNew);
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
values.put(Cols.LICENSE, license);
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
values.put(Cols.AUTHOR_NAME, authorName);
values.put(Cols.AUTHOR_EMAIL, authorEmail);
values.put(Cols.WEBSITE, webSite);
values.put(Cols.ISSUE_TRACKER, issueTracker);
values.put(Cols.SOURCE_CODE, sourceCode);
App Details: show the app's Translation links fdroid/fdroidserver!450 icon is: https://material.io/tools/icons/?search=trans&icon=translate&style=baseline
2019-03-22 15:22:11 +01:00
values.put(Cols.TRANSLATION, translation);
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
values.put(Cols.VIDEO, video);
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
values.put(Cols.CHANGELOG, changelog);
values.put(Cols.DONATE, donate);
values.put(Cols.BITCOIN, bitcoin);
values.put(Cols.LITECOIN, litecoin);
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
values.put(Cols.FLATTR_ID, flattrID);
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
values.put(Cols.LIBERAPAY, liberapay);
support OpenCollective as a donation option
2020-06-10 23:53:16 +02:00
values.put(Cols.OPEN_COLLECTIVE, openCollective);
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
values.put(Cols.ADDED, Utils.formatDate(added, ""));
values.put(Cols.LAST_UPDATED, Utils.formatDate(lastUpdated, ""));
Add "preferredSigner" field to App. At present, this is chosen from the first package in the index-v1 metadata.
2017-06-21 07:48:21 +02:00
values.put(Cols.PREFERRED_SIGNER, preferredSigner);
rename App.suggestedVersionCode to autoInstallVersionCode #1063
2020-01-10 16:46:07 +01:00
values.put(Cols.AUTO_INSTALL_VERSION_CODE, autoInstallVersionCode);
rename App.upstreamVersionName to suggestedVersionName #1063
2020-01-10 16:59:21 +01:00
values.put(Cols.SUGGESTED_VERSION_NAME, suggestedVersionName);
rename App.upstreamVersionCode to suggestedVersionCode #1063
2020-01-10 17:06:58 +01:00
values.put(Cols.SUGGESTED_VERSION_CODE, suggestedVersionCode);
Make it explicit that the `CATEGORIES` column is not for selecting from. Renamed the `Schema.AppMetadata.Categories.CATEGORIES` constant into the `Schema.AppMetadata.ForWriting.Categories.CATEGORIES` constant. This is to make it very clear that it is not for reading from the database.
2016-10-20 04:03:03 +02:00
values.put(Cols.ForWriting.Categories.CATEGORIES, Utils.serializeCommaSeparatedString(categories));
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
values.put(Cols.ANTI_FEATURES, Utils.serializeCommaSeparatedString(antiFeatures));
values.put(Cols.REQUIREMENTS, Utils.serializeCommaSeparatedString(requirements));
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
values.put(Cols.FEATURE_GRAPHIC, featureGraphic);
values.put(Cols.PROMO_GRAPHIC, promoGraphic);
values.put(Cols.TV_BANNER, tvBanner);
values.put(Cols.PHONE_SCREENSHOTS, Utils.serializeCommaSeparatedString(phoneScreenshots));
values.put(Cols.SEVEN_INCH_SCREENSHOTS, Utils.serializeCommaSeparatedString(sevenInchScreenshots));
values.put(Cols.TEN_INCH_SCREENSHOTS, Utils.serializeCommaSeparatedString(tenInchScreenshots));
values.put(Cols.TV_SCREENSHOTS, Utils.serializeCommaSeparatedString(tvScreenshots));
values.put(Cols.WEAR_SCREENSHOTS, Utils.serializeCommaSeparatedString(wearScreenshots));
Extracted AppProvider.DataColumns to Schema.AppTable.Cols
2016-06-30 05:14:01 +02:00
values.put(Cols.IS_COMPATIBLE, compatible ? 1 : 0);
Calculate whether an app is an APK or not when updating repos. This improves performance when we need to decide whether or not apps are installed or not while scrolling through large lists. Fixes #1143. Also change Jackson tests to properly ignore App#isApk.
2017-09-12 16:48:14 +02:00
values.put(Cols.IS_APK, isApk ? 1 : 0);
add flag to track localized apps for selecting in Latest tab
2019-03-22 13:36:53 +01:00
values.put(Cols.IS_LOCALIZED, isLocalized ? 1 : 0);
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
return values;
}
Introduce FileInstaller, a way to handle media files from F-Droid * This installer is invoked when for non-apk/media files, and copies them to an appropriate folder on the sdcard. * We also introduce a FileInstallerActivity to ask for storage permissions at runtime, as needed by Android 6.0 and above, and handle the install/uninstall process. * A toast is shown with the install path after installation. TODO: * Manage Installed Apps screen doesn't show media files.
2017-06-20 12:31:56 +02:00
public boolean isInstalled(Context context) {
Calculate whether an app is an APK or not when updating repos. This improves performance when we need to decide whether or not apps are installed or not while scrolling through large lists. Fixes #1143. Also change Jackson tests to properly ignore App#isApk.
2017-09-12 16:48:14 +02:00
// First check isApk() before isMediaInstalled() because the latter is quite expensive,
// hitting the database for each apk version, then the disk to check for installed media.
return installedVersionCode > 0 || (!isApk() && isMediaInstalled(context));
}
private boolean isApk() {
return isApk;
Introduce FileInstaller, a way to handle media files from F-Droid * This installer is invoked when for non-apk/media files, and copies them to an appropriate folder on the sdcard. * We also introduce a FileInstallerActivity to ask for storage permissions at runtime, as needed by Android 6.0 and above, and handle the install/uninstall process. * A toast is shown with the install path after installation. TODO: * Manage Installed Apps screen doesn't show media files.
2017-06-20 12:31:56 +02:00
}
public boolean isMediaInstalled(Context context) {
return getMediaApkifInstalled(context) != null;
}
/**
* Gets the installed media apk from all the apks of this {@link App}, if any.
*
* @return The installed media {@link Apk} if it exists, null otherwise.
*/
public Apk getMediaApkifInstalled(Context context) {
// This is always null for media files. We could skip the code below completely if it wasn't
if (this.installedApk != null && !this.installedApk.isApk() && this.installedApk.isMediaInstalled(context)) {
return this.installedApk;
}
// This code comes from AppDetailsRecyclerViewAdapter
final List<Apk> apks = ApkProvider.Helper.findByPackageName(context, this.packageName);
for (final Apk apk : apks) {
boolean allowByCompatability = apk.compatible || Preferences.get().showIncompatibleVersions();
boolean allowBySig = this.installedSig == null || TextUtils.equals(this.installedSig, apk.sig);
if (allowByCompatability && allowBySig) {
if (!apk.isApk()) {
if (apk.isMediaInstalled(context)) {
return apk;
}
}
}
}
return null;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
}
/**
* True if there are new versions (apks) available
*/
Adding our own cache of currently installed apks in the database. Previously the data was not stored anywhere, and each time we wanted to know about all installed apps, we built a ridiculously long SQL query. The query had essentially one "OR" clause for each installed app. To make matters worse, it also required one parameter for each of these, so we could bind the installed app name to a "?" in the query. SQL has a limit of (usually) 999 parameters which can be provided to a query, which meant it would fall over if the user had more than 1000 apps installed. This change introduces a new table called "fdroid_installedApps". It is initialized on first run, by iterating over the installed apps as given by the PackageManager. It is subsequenty kept up to date by a set of BroadcastReceivers, which listen for apps being uninstalled/installed/upgraded. It also includes tests to verify that queries of installed apps, when there are more than 1000 apps installed, don't break. Finally, tests are also now able to to insert into providers other than the one under test. This is due to the fact that the providers often join onto tables managed by other providers.
2014-04-13 16:08:31 +02:00
public boolean hasUpdates() {
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
boolean updates = false;
rename App.suggestedVersionCode to autoInstallVersionCode #1063
2020-01-10 16:46:07 +01:00
if (autoInstallVersionCode > 0) {
updates = installedVersionCode > 0 && installedVersionCode < autoInstallVersionCode;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
}
return updates;
}
Completely removed preferences from app table.
2016-07-25 10:11:31 +02:00
public AppPrefs getPrefs(Context context) {
if (prefs == null) {
prefs = AppPrefsProvider.Helper.getPrefsOrDefault(context, this);
}
return prefs;
}
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
/**
* True if there are new versions (apks) available and the user wants
* to be notified about them
*/
Completely removed preferences from app table.
2016-07-25 10:11:31 +02:00
public boolean canAndWantToUpdate(Context context) {
Adding our own cache of currently installed apks in the database. Previously the data was not stored anywhere, and each time we wanted to know about all installed apps, we built a ridiculously long SQL query. The query had essentially one "OR" clause for each installed app. To make matters worse, it also required one parameter for each of these, so we could bind the installed app name to a "?" in the query. SQL has a limit of (usually) 999 parameters which can be provided to a query, which meant it would fall over if the user had more than 1000 apps installed. This change introduces a new table called "fdroid_installedApps". It is initialized on first run, by iterating over the installed apps as given by the PackageManager. It is subsequenty kept up to date by a set of BroadcastReceivers, which listen for apps being uninstalled/installed/upgraded. It also includes tests to verify that queries of installed apps, when there are more than 1000 apps installed, don't break. Finally, tests are also now able to to insert into providers other than the one under test. This is due to the fact that the providers often join onto tables managed by other providers.
2014-04-13 16:08:31 +02:00
boolean canUpdate = hasUpdates();
Completely removed preferences from app table.
2016-07-25 10:11:31 +02:00
AppPrefs prefs = getPrefs(context);
rename App.suggestedVersionCode to autoInstallVersionCode #1063
2020-01-10 16:46:07 +01:00
boolean wantsUpdate = !prefs.ignoreAllUpdates && prefs.ignoreThisUpdate < autoInstallVersionCode;
do not disable update button because of antifeatures This testing at the wrong point, namely in the app details where you are already looking at the antifeatures which might be present. In the list view there's an additional direct check with isDisabledByAntiFeatures() anyway. Fix fdroid/fdroidclient#1845
2020-02-25 15:47:33 +01:00
return canUpdate && wantsUpdate;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
}
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
/**
purge broken, semi-used root filtering preference RequiresRoot should become an Anti-Feature or <uses-feature> or something like that. Having it a one-off makes it too brittle fdroid/fdroidclient#928
2018-07-30 18:03:12 +02:00
* @return if the given app should be filtered out based on the
Allow choosing which antifeatures to show
2021-10-14 11:25:25 +02:00
* {@link Preferences#PREF_SHOW_ANTI_FEATURES Show Anti-Features Setting}
convert App comments to javadoc so they can be read in popups, etc. Decent Java editors have all sorts of nice ways to show javadoc comments, whether they are for public or private APIs. So comments should be in that format whenever possible.
2016-05-27 20:48:09 +02:00
*/
Don't hide unknown antifeatures
2021-10-30 14:09:37 +02:00
public boolean isDisabledByAntiFeatures(Context context) {
Allow choosing which antifeatures to show
2021-10-14 11:25:25 +02:00
if (this.antiFeatures == null) {
return false;
}
Add "Other anti-features" option
2021-10-30 22:44:46 +02:00
List<String> chooseableAntiFeatures = Arrays.asList(
Don't hide unknown antifeatures
2021-10-30 14:09:37 +02:00
context.getResources().getStringArray(R.array.antifeaturesValues)
);
Allow choosing which antifeatures to show
2021-10-14 11:25:25 +02:00
Set<String> shownAntiFeatures = Preferences.get().showAppsWithAntiFeatures();
for (String antiFeature : this.antiFeatures) {
Add "Other anti-features" option
2021-10-30 22:44:46 +02:00
if (chooseableAntiFeatures.contains(antiFeature)) {
if (!shownAntiFeatures.contains(antiFeature)) {
return true;
}
} else {
if (!shownAntiFeatures.contains(context.getResources().getString(R.string.antiothers_key))) {
return true;
}
Allow choosing which antifeatures to show
2021-10-14 11:25:25 +02:00
}
}
return false;
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
}
s/curVersion/upstreamVersion/g, added suggestedVersion. Refactored QueryBuilder. In order to support suggested version, I didn't want to have both suggested version + versionCode in the App table. Rather, just the code, and then use that (and the apps id) to join onto the apk table. This is something we wanted to do elsewhere, so I refactored the QueryBuilder class from the ApkProvider so that it can also be used by the AppProvider.
2014-02-15 10:57:18 +01:00
Use correct URIs when attempting to show donate links. This extracts the functionality from the old AppDetails which prefixes donation links with the relevant scheme (bitcoin: or litecoin:) or URL (https://flattr.com/thing/) into the App class.
2016-11-30 12:28:12 +01:00
@Nullable
public String getBitcoinUri() {
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
return TextUtils.isEmpty(bitcoin) ? null : "bitcoin:" + bitcoin;
Use correct URIs when attempting to show donate links. This extracts the functionality from the old AppDetails which prefixes donation links with the relevant scheme (bitcoin: or litecoin:) or URL (https://flattr.com/thing/) into the App class.
2016-11-30 12:28:12 +01:00
}
@Nullable
public String getLitecoinUri() {
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
return TextUtils.isEmpty(bitcoin) ? null : "litecoin:" + bitcoin;
Use correct URIs when attempting to show donate links. This extracts the functionality from the old AppDetails which prefixes donation links with the relevant scheme (bitcoin: or litecoin:) or URL (https://flattr.com/thing/) into the App class.
2016-11-30 12:28:12 +01:00
}
support OpenCollective as a donation option
2020-06-10 23:53:16 +02:00
@Nullable
public String getOpenCollectiveUri() {
return TextUtils.isEmpty(openCollective) ? null : "https://opencollective.com/"
+ openCollective + "/donate/";
}
Use correct URIs when attempting to show donate links. This extracts the functionality from the old AppDetails which prefixes donation links with the relevant scheme (bitcoin: or litecoin:) or URL (https://flattr.com/thing/) into the App class.
2016-11-30 12:28:12 +01:00
@Nullable
public String getFlattrUri() {
return TextUtils.isEmpty(flattrID) ? null : "https://flattr.com/thing/" + flattrID;
}
add liberapay field and donation option This add the liberapayID index field to the local db and then displays a donation badge for apps that provide this.
2018-02-14 22:48:00 +01:00
@Nullable
public String getLiberapayUri() {
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
return TextUtils.isEmpty(liberapay) ? null : "https://liberapay.com/" + liberapay;
add liberapay field and donation option This add the liberapayID index field to the local db and then displays a donation badge for apps that provide this.
2018-02-14 22:48:00 +01:00
}
Added "Installed Apps" activity to top of settings. This is as per the mockup in issue #840, and does the following: * Adds a new `PreferencesCategory` of "My Apps" at the top of the preferences screen. * Adds a "Manage Installed Apps" preference, and moves the "Repositories" preference into this category. * Repeals an existing change which prevented "updateable" apps from appearing in the list of "installed" apps. This is because the two lists of apps are no longer displayed alongside eachother. * Enhances the `AppListItemController` to also be able to display whether or not the currently installed version is the recommended version or not. * Also adds option to display whether the user has asked to ignore any updates for any specific apps.
2017-02-13 23:07:00 +01:00
/**
rename App.suggestedVersionName to autoInstallVersionName #1063 # Conflicts: # app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
2020-01-10 17:41:29 +01:00
* @see App#autoInstallVersionName for why this uses a getter while other member variables are
Added "Installed Apps" activity to top of settings. This is as per the mockup in issue #840, and does the following: * Adds a new `PreferencesCategory` of "My Apps" at the top of the preferences screen. * Adds a "Manage Installed Apps" preference, and moves the "Repositories" preference into this category. * Repeals an existing change which prevented "updateable" apps from appearing in the list of "installed" apps. This is because the two lists of apps are no longer displayed alongside eachother. * Enhances the `AppListItemController` to also be able to display whether or not the currently installed version is the recommended version or not. * Also adds option to display whether the user has asked to ignore any updates for any specific apps.
2017-02-13 23:07:00 +01:00
* publicly accessible.
*/
rename App.suggestedVersionName to autoInstallVersionName #1063 # Conflicts: # app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
2020-01-10 17:41:29 +01:00
public String getAutoInstallVersionName() {
return autoInstallVersionName;
checkstyle: Add curly checks
2015-10-09 11:40:50 +02:00
}
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
/**
include targetSdkVersion in Apk In order to work well with the Android 6.0+ permissions, the client needs to know whether an APK has been built against android-23 or higher. closes #682 https://gitlab.com/fdroid/fdroidclient/issues/682
2016-06-10 10:28:25 +02:00
* {@link PackageManager} doesn't give us {@code minSdkVersion}, {@code targetSdkVersion},
* and {@code maxSdkVersion}, so we have to parse it straight from {@code <uses-sdk>} in
* {@code AndroidManifest.xml}. If {@code targetSdkVersion} is not set, then it is
* equal to {@code minSdkVersion}
*
enforce max line length at 118 gitlab's diff views wrap badly when lines are longer than 118. Android Studio places a grey line in the UI at 120. @SuppressWarnings("LineLength") is added to a bunch of files to prevent making this commit huge. People can remove that as they work on those files, and fix the issues then. I also ran Android Studio's default Ctrl-Alt-L code formatter, where it was easy to do, and I was already in the file.
2017-06-06 16:11:46 +02:00
* @see <a href="https://developer.android.com/guide/topics/manifest/uses-sdk-element.html">&lt;uses-sdk&gt;</a>
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
*/
include targetSdkVersion in Apk In order to work well with the Android 6.0+ permissions, the client needs to know whether an APK has been built against android-23 or higher. closes #682 https://gitlab.com/fdroid/fdroidclient/issues/682
2016-06-10 10:28:25 +02:00
private static int[] getMinTargetMaxSdkVersions(Context context, String packageName) {
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
int minSdkVersion = Apk.SDK_VERSION_MIN_VALUE;
include targetSdkVersion in Apk In order to work well with the Android 6.0+ permissions, the client needs to know whether an APK has been built against android-23 or higher. closes #682 https://gitlab.com/fdroid/fdroidclient/issues/682
2016-06-10 10:28:25 +02:00
int targetSdkVersion = Apk.SDK_VERSION_MIN_VALUE;
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
int maxSdkVersion = Apk.SDK_VERSION_MAX_VALUE;
try {
AssetManager am = context.createPackageContext(packageName, 0).getAssets();
XmlResourceParser xml = am.openXmlResourceParser("AndroidManifest.xml");
int eventType = xml.getEventType();
while (eventType != XmlPullParser.END_DOCUMENT) {
if (eventType == XmlPullParser.START_TAG && "uses-sdk".equals(xml.getName())) {
for (int j = 0; j < xml.getAttributeCount(); j++) {
if (xml.getAttributeName(j).equals("minSdkVersion")) {
minSdkVersion = Integer.parseInt(xml.getAttributeValue(j));
include targetSdkVersion in Apk In order to work well with the Android 6.0+ permissions, the client needs to know whether an APK has been built against android-23 or higher. closes #682 https://gitlab.com/fdroid/fdroidclient/issues/682
2016-06-10 10:28:25 +02:00
} else if (xml.getAttributeName(j).equals("targetSdkVersion")) {
targetSdkVersion = Integer.parseInt(xml.getAttributeValue(j));
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
} else if (xml.getAttributeName(j).equals("maxSdkVersion")) {
maxSdkVersion = Integer.parseInt(xml.getAttributeValue(j));
}
}
break;
}
eventType = xml.nextToken();
}
fix crash on bad values in minSdkVersion java.lang.NumberFormatException: For input string: "@2131034146" at java.lang.Integer.parseInt(Integer.java:615) at java.lang.Integer.parseInt(Integer.java:650) at org.fdroid.fdroid.data.App.getMinTargetMaxSdkVersions(App.java:1092) at org.fdroid.fdroid.data.App.initInstalledApk(App.java:769) at org.fdroid.fdroid.data.App.getInstance(App.java:395) at org.fdroid.fdroid.localrepo.CacheSwapAppsService.onHandleIntent(CacheSwapAppsService.java:77) at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:76) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:193) at android.os.HandlerThread.run(HandlerThread.java:65)
2019-03-28 19:52:21 +01:00
} catch (PackageManager.NameNotFoundException
| IOException
| XmlPullParserException
| NumberFormatException e) {
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
Log.e(TAG, "Could not get min/max sdk version", e);
}
include targetSdkVersion in Apk In order to work well with the Android 6.0+ permissions, the client needs to know whether an APK has been built against android-23 or higher. closes #682 https://gitlab.com/fdroid/fdroidclient/issues/682
2016-06-10 10:28:25 +02:00
if (targetSdkVersion < minSdkVersion) {
targetSdkVersion = minSdkVersion;
}
return new int[]{minSdkVersion, targetSdkVersion, maxSdkVersion};
only parse <uses-sdk> once when looking for min/max SDK version When building APK instances from installed apps, the minSdkVersion and maxSdkVersion needs to be parsed directly from the APK's Android Manifest, since PackageManager does not provide a method to get it how we need it. Previously, the whole AndroidManifest.xml file was parsed entirely twice, once for minSdkVersion then for maxSdkVersion.
2016-05-23 14:26:52 +02:00
}
Change join from `app` to `apk` table to auto increment integers rather than Android package name strings. This is important for the ability to refactor the database for better performance in the future. See #511 for details. For those interested in the details, here is a query plan of selecting the "All" category of apps before this commit: * `SCAN TABLE fdroid_app USING INDEX app_id` * `SEARCH TABLE fdroid_apk USING INDEX apk_id (id=?)` * `SEARCH TABLE fdroid_repo USING INTEGER PRIMARY KEY (rowid=?)` * `SEARCH TABLE fdroid_installedApp AS installed USING INDEX sqlite_autoindex_fdroid_installedApp_1 (appId=?)` * `SEARCH TABLE fdroid_apk AS suggestedApk USING INDEX sqlite_autoindex_fdroid_apk_1 (id=? AND vercode=?)` * `USE TEMP B-TREE FOR ORDER BY` And here is a query plan of afterwards: * `SCAN TABLE fdroid_app` * `SEARCH TABLE fdroid_apk USING INDEX apk_appId (appId=?)` * `SEARCH TABLE fdroid_repo USING INTEGER PRIMARY KEY (rowid=?)` * `SEARCH TABLE fdroid_installedApp AS installed USING INDEX sqlite_autoindex_fdroid_installedApp_1 (appId=?)` * `SEARCH TABLE fdroid_apk AS suggestedApk USING INDEX apk_appId (appId=?)` * `USE TEMP B-TREE FOR ORDER BY` The things of note are: * `SCAN TABLE` doesn't use an index, which means that it is really using the rowid index. Shouldn't behave much differently. * The second item now uses an integer primary key index rather than a package name index. Should increase search speed marginally which was the goal of this commit. As more apks exist, the speed improvement will also increase.
2016-06-23 03:30:01 +02:00
public long getId() {
return id;
}
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
@Override
public int describeContents() {
return 0;
}
Don't allow uninstalling system apps. * F-Droid cannnot uninstall system apps, only their updates, but even with the privileged extension, that can get complicated. * Let's just not allow uninstalling system apps, the phone's settings app can happily disable/re-enable system apps, and also uninstalls their updates on disabling.
2017-04-18 13:51:18 +02:00
public boolean isUninstallable(Context context) {
Introduce FileInstaller, a way to handle media files from F-Droid * This installer is invoked when for non-apk/media files, and copies them to an appropriate folder on the sdcard. * We also introduce a FileInstallerActivity to ask for storage permissions at runtime, as needed by Android 6.0 and above, and handle the install/uninstall process. * A toast is shown with the install path after installation. TODO: * Manage Installed Apps screen doesn't show media files.
2017-06-20 12:31:56 +02:00
if (this.isMediaInstalled(context)) {
return true;
} else if (this.isInstalled(context)) {
Don't allow uninstalling system apps. * F-Droid cannnot uninstall system apps, only their updates, but even with the privileged extension, that can get complicated. * Let's just not allow uninstalling system apps, the phone's settings app can happily disable/re-enable system apps, and also uninstalls their updates on disabling.
2017-04-18 13:51:18 +02:00
PackageManager pm = context.getPackageManager();
ApplicationInfo appInfo;
try {
appInfo = pm.getApplicationInfo(this.packageName,
PackageManager.GET_UNINSTALLED_PACKAGES);
} catch (PackageManager.NameNotFoundException e) {
return false;
}
Introduce FileInstaller, a way to handle media files from F-Droid * This installer is invoked when for non-apk/media files, and copies them to an appropriate folder on the sdcard. * We also introduce a FileInstallerActivity to ask for storage permissions at runtime, as needed by Android 6.0 and above, and handle the install/uninstall process. * A toast is shown with the install path after installation. TODO: * Manage Installed Apps screen doesn't show media files.
2017-06-20 12:31:56 +02:00
// System apps aren't uninstallable.
Don't allow uninstalling system apps. * F-Droid cannnot uninstall system apps, only their updates, but even with the privileged extension, that can get complicated. * Let's just not allow uninstalling system apps, the phone's settings app can happily disable/re-enable system apps, and also uninstalls their updates on disabling.
2017-04-18 13:51:18 +02:00
final boolean isSystem = (appInfo.flags & ApplicationInfo.FLAG_SYSTEM) != 0;
Introduce FileInstaller, a way to handle media files from F-Droid * This installer is invoked when for non-apk/media files, and copies them to an appropriate folder on the sdcard. * We also introduce a FileInstallerActivity to ask for storage permissions at runtime, as needed by Android 6.0 and above, and handle the install/uninstall process. * A toast is shown with the install path after installation. TODO: * Manage Installed Apps screen doesn't show media files.
2017-06-20 12:31:56 +02:00
return !isSystem && this.isInstalled(context);
Don't allow uninstalling system apps. * F-Droid cannnot uninstall system apps, only their updates, but even with the privileged extension, that can get complicated. * Let's just not allow uninstalling system apps, the phone's settings app can happily disable/re-enable system apps, and also uninstalls their updates on disabling.
2017-04-18 13:51:18 +02:00
} else {
return false;
}
}
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeByte(this.compatible ? (byte) 1 : (byte) 0);
dest.writeString(this.packageName);
dest.writeString(this.name);
WIP: Making metadata table work. Requires significant refactorings throughout :(
2016-07-28 04:25:17 +02:00
dest.writeLong(this.repoId);
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
dest.writeString(this.summary);
rename app.icon to app.iconFromApk This makes it clearer what this is actually referring to.
2020-02-21 16:08:08 +01:00
dest.writeString(this.iconFromApk);
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
dest.writeString(this.description);
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
dest.writeString(this.whatsNew);
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
dest.writeString(this.license);
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
dest.writeString(this.authorName);
dest.writeString(this.authorEmail);
dest.writeString(this.webSite);
dest.writeString(this.issueTracker);
dest.writeString(this.sourceCode);
App Details: show the app's Translation links fdroid/fdroidserver!450 icon is: https://material.io/tools/icons/?search=trans&icon=translate&style=baseline
2019-03-22 15:22:11 +01:00
dest.writeString(this.translation);
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
dest.writeString(this.video);
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
dest.writeString(this.changelog);
dest.writeString(this.donate);
dest.writeString(this.bitcoin);
dest.writeString(this.litecoin);
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
dest.writeString(this.flattrID);
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
dest.writeString(this.liberapay);
support OpenCollective as a donation option
2020-06-10 23:53:16 +02:00
dest.writeString(this.openCollective);
Add "preferredSigner" field to App. At present, this is chosen from the first package in the index-v1 metadata.
2017-06-21 07:48:21 +02:00
dest.writeString(this.preferredSigner);
rename App.upstreamVersionName to suggestedVersionName #1063
2020-01-10 16:59:21 +01:00
dest.writeString(this.suggestedVersionName);
rename App.upstreamVersionCode to suggestedVersionCode #1063
2020-01-10 17:06:58 +01:00
dest.writeInt(this.suggestedVersionCode);
rename App.suggestedVersionName to autoInstallVersionName #1063 # Conflicts: # app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
2020-01-10 17:41:29 +01:00
dest.writeString(this.autoInstallVersionName);
rename App.suggestedVersionCode to autoInstallVersionCode #1063
2020-01-10 16:46:07 +01:00
dest.writeInt(this.autoInstallVersionCode);
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
dest.writeLong(this.added != null ? this.added.getTime() : -1);
dest.writeLong(this.lastUpdated != null ? this.lastUpdated.getTime() : -1);
dest.writeStringArray(this.categories);
dest.writeStringArray(this.antiFeatures);
dest.writeStringArray(this.requirements);
dest.writeString(this.iconUrl);
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
dest.writeString(this.featureGraphic);
dest.writeString(this.promoGraphic);
dest.writeString(this.tvBanner);
dest.writeStringArray(this.phoneScreenshots);
dest.writeStringArray(this.sevenInchScreenshots);
dest.writeStringArray(this.tenInchScreenshots);
dest.writeStringArray(this.tvScreenshots);
dest.writeStringArray(this.wearScreenshots);
Calculate whether an app is an APK or not when updating repos. This improves performance when we need to decide whether or not apps are installed or not while scrolling through large lists. Fixes #1143. Also change Jackson tests to properly ignore App#isApk.
2017-09-12 16:48:14 +02:00
dest.writeByte(this.isApk ? (byte) 1 : (byte) 0);
add flag to track localized apps for selecting in Latest tab
2019-03-22 13:36:53 +01:00
dest.writeByte(this.isLocalized ? (byte) 1 : (byte) 0);
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
dest.writeString(this.installedVersionName);
dest.writeInt(this.installedVersionCode);
dest.writeParcelable(this.installedApk, flags);
dest.writeString(this.installedSig);
dest.writeLong(this.id);
}
protected App(Parcel in) {
this.compatible = in.readByte() != 0;
this.packageName = in.readString();
this.name = in.readString();
WIP: Making metadata table work. Requires significant refactorings throughout :(
2016-07-28 04:25:17 +02:00
this.repoId = in.readLong();
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
this.summary = in.readString();
rename app.icon to app.iconFromApk This makes it clearer what this is actually referring to.
2020-02-21 16:08:08 +01:00
this.iconFromApk = in.readString();
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
this.description = in.readString();
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
this.whatsNew = in.readString();
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
this.license = in.readString();
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
this.authorName = in.readString();
this.authorEmail = in.readString();
this.webSite = in.readString();
this.issueTracker = in.readString();
this.sourceCode = in.readString();
App Details: show the app's Translation links fdroid/fdroidserver!450 icon is: https://material.io/tools/icons/?search=trans&icon=translate&style=baseline
2019-03-22 15:22:11 +01:00
this.translation = in.readString();
support "What's New" and "Video" fields from index-v1 fdroidserver currently only supports a single WhatsNew field that comes from the CurrentVersionCode of the app. Google Play and fastlane supply support a WhatsNew field per-release, but we don't use that data anywhere, and implementing that in the data structures would add a lot of complexity since Apk would then need to have its own "localized" section like App does. The "Video" field is just a URL pointing to a video. closes #910
2017-04-14 01:31:33 +02:00
this.video = in.readString();
rename App instance vars to match fdroidserver field names This makes the name of the instance variables in the App class match the names of the metadata fields in the new fdroidserver .yml YAML format. This means that the Jackson parser can automatically instantiate instances for us, which will be more efficient and maintainable. These names aren't great, but it would a ton of work to rename the field names in all of the metadata files, the docs, fdroidserver code, etc.
2016-11-25 23:36:37 +01:00
this.changelog = in.readString();
this.donate = in.readString();
this.bitcoin = in.readString();
this.litecoin = in.readString();
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
this.flattrID = in.readString();
support new Liberapay: field, with migration support for LiberapayID: Liberapay was originally included using a numeric ID, since they had not yet finalized the public URLs. Now it is a username. So this logic prefers the username in Liberapay: field, and uses the old LiberapayID: as a fallback. LiberapayID: will not override Liberapay: if it is already set. This reuses the old database key since it is stored and processed as a String anyway.
2020-06-16 10:12:24 +02:00
this.liberapay = in.readString();
support OpenCollective as a donation option
2020-06-10 23:53:16 +02:00
this.openCollective = in.readString();
Add "preferredSigner" field to App. At present, this is chosen from the first package in the index-v1 metadata.
2017-06-21 07:48:21 +02:00
this.preferredSigner = in.readString();
rename App.upstreamVersionName to suggestedVersionName #1063
2020-01-10 16:59:21 +01:00
this.suggestedVersionName = in.readString();
rename App.upstreamVersionCode to suggestedVersionCode #1063
2020-01-10 17:06:58 +01:00
this.suggestedVersionCode = in.readInt();
rename App.suggestedVersionName to autoInstallVersionName #1063 # Conflicts: # app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
2020-01-10 17:41:29 +01:00
this.autoInstallVersionName = in.readString();
rename App.suggestedVersionCode to autoInstallVersionCode #1063
2020-01-10 16:46:07 +01:00
this.autoInstallVersionCode = in.readInt();
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
long tmpAdded = in.readLong();
this.added = tmpAdded == -1 ? null : new Date(tmpAdded);
long tmpLastUpdated = in.readLong();
this.lastUpdated = tmpLastUpdated == -1 ? null : new Date(tmpLastUpdated);
this.categories = in.createStringArray();
this.antiFeatures = in.createStringArray();
this.requirements = in.createStringArray();
this.iconUrl = in.readString();
support localized text and graphics in index-v1 metadata This sets the App instance variables using the localized index-v1 fields. It trys to fill as many fields as possible, falling back to locales of the same language, then finally English. This is based on the Jackson JSON parser's ability to map a JSON key to a method, e.g. @JsonProperty("localized")
2016-12-06 11:04:22 +01:00
this.featureGraphic = in.readString();
this.promoGraphic = in.readString();
this.tvBanner = in.readString();
this.phoneScreenshots = in.createStringArray();
this.sevenInchScreenshots = in.createStringArray();
this.tenInchScreenshots = in.createStringArray();
this.tvScreenshots = in.createStringArray();
this.wearScreenshots = in.createStringArray();
Calculate whether an app is an APK or not when updating repos. This improves performance when we need to decide whether or not apps are installed or not while scrolling through large lists. Fixes #1143. Also change Jackson tests to properly ignore App#isApk.
2017-09-12 16:48:14 +02:00
this.isApk = in.readByte() != 0;
add flag to track localized apps for selecting in Latest tab
2019-03-22 13:36:53 +01:00
this.isLocalized = in.readByte() != 0;
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
this.installedVersionName = in.readString();
this.installedVersionCode = in.readInt();
this.installedApk = in.readParcelable(Apk.class.getClassLoader());
this.installedSig = in.readString();
this.id = in.readLong();
}
do not let Jackson set instance vars that never come from index Tell the Jackson JSON parser to ignore App/Apk fields that should never come from the index, but instead are set locally to keep track of the current state of things on the device. There are two forms of tests to enforce that the proper things get ignored. It is not possible to do this with decorators alone, so I chose to use @JsonIgnore and leave the variables we want filled in undecorated. Also, all of the instance variables in Apk/App/Repo should come directly from the index metadata so that they are pure data classes. Currently some state info is stored in them, those are decorated with @JsonIgnore. The tests then include lists of accepted and ignored properties, and anything that is not in those lists will cause the tests to fail. So if someone is adding a new instance variable, they will get a fail until the tests are updated. One set of tests actually writes blank instances out as JSON since that's the easiest test to write, and Jackson treats @JsonIgnore the same in both directions. Then there is another test that reads a JSON file with added, unsupported values to make sure that they are properly ignored.
2017-03-22 16:14:43 +01:00
@JsonIgnore
Make App and Apk classes really Parcelable
2016-07-25 16:52:39 +02:00
public static final Parcelable.Creator<App> CREATOR = new Parcelable.Creator<App>() {
@Override
public App createFromParcel(Parcel source) {
return new App(source);
}
@Override
public App[] newArray(int size) {
return new App[size];
}
};
Correctly check for 'suggestedApk' in app details. Take into account the preferred/installed signature instead of just the version code.
2017-06-30 04:14:15 +02:00
/**
* Choose the signature which we should encourage the user to install.
* Usually, we want the {@link #preferredSigner} rather than any random signature.
* However, if the app is installed, then we override this and instead want to only encourage
* the user to try and install versions with that signature (because thats all the OS will let
* them do).
LocaleList is not properly sorted, so do our own best approx. It seems that LocaleList does not necessarily return the "Language Priority List" in the order that the user has prioritized things. So we have to kind of fake it by first adding the default locale, then adding the locales from LocaleList based on longest order first (e.g. de-AT then de). #987
2017-10-04 22:32:55 +02:00
* <p>
Added doc comment clarifying unsigned media
2017-09-12 00:43:17 +02:00
* Will return null for any {@link App} which represents media (instead of an apk) and thus
* doesn't have a signer.
Correctly check for 'suggestedApk' in app details. Take into account the preferred/installed signature instead of just the version code.
2017-06-30 04:14:15 +02:00
*/
Don't assume all apps have a preferred signer, as media apps don't Fixes #1156.
2017-09-05 04:56:05 +02:00
@Nullable
Correctly check for 'suggestedApk' in app details. Take into account the preferred/installed signature instead of just the version code.
2017-06-30 04:14:15 +02:00
public String getMostAppropriateSignature() {
if (!TextUtils.isEmpty(installedSig)) {
return installedSig;
} else if (!TextUtils.isEmpty(preferredSigner)) {
return preferredSigner;
}
Don't assume all apps have a preferred signer, as media apps don't Fixes #1156.
2017-09-05 04:56:05 +02:00
return null;
Correctly check for 'suggestedApk' in app details. Take into account the preferred/installed signature instead of just the version code.
2017-06-30 04:14:15 +02:00
}
Removed DB, implemented AppProvider. Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
2014-02-02 09:38:36 +01:00
}