This adds a new PendingInstall event which broadcasts that an install
process has started, but the state of it is not yet known, like
whether it needs to be downloaded still, or is ready to install. It
marks the very first step of the whole InstallManagerService process.
Installer events should only be directly related to the install process as
managed by the Installer set of classes. The newer AppStatusUpdate stuff
now tracks the whole lifecycle of the process.
This mostly reverts f0d6acd974548e24662a64271ae57922f74c3225 since there is
now the overarching concept of "Pending Install" to mark packages that are
somewhere in the whole process.
refs #828
refs #1357
For fullstack custom builds, they'll also need a whitelabel build of
Privileged Extension, which will have a different Application ID and
signing key than F-Droid Privileged Extension.
Before, if the Data/WiFi Settings made it so the update process is not
allowed to run and the device was not offline or in Airplane Mode, it would
show this Toast then it would show the "your device is offline" Toast.
This merges the triedEmptyUpdate preference into the lastUpdateCheck pref,
and uses that to determine whether the index update has ever run. It seems
that lastUpdateCheck used to be used for that, but was semi-disabled. Then
triedEmptyUpdate was added. This merges the two into lastUpdateCheck, which
also tracks the timestamp of the last index update.
The initial start time is getting pretty slow, so hopefully this will save
a little bit. It also makes it consistent with other places in the code,
like UpdateService.
This was doing a couple of things wrong:
* the scheduled job should always require a network, NONE doesn't work
* when the preferences change, it should cancel any scheduled job first,
so that if the user chooses to disable auto-updates, that takes effect
closes#1474closes#1451closes#1457
This changes the logic to only use a SharedPreference to track pending
installs, and to set the "pending install" mark as soon as possible
while waiting until final confirmation to unmark. Before, there was a
complicated combination of a SharedPreference and the use of the APK in the
cache as a mark.
!488
refs #962closes#1311closes#1031closes#1271
Since there are many ways to uninstall an app, including from Google
Play, {@code adb uninstall}, or Settings -> Apps, this method cannot
ever be sure that the app isn't already being uninstalled. So it
needs to check that we can actually get info on the installed app,
otherwise, just call it interrupted and quit.
closes#1435
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)
Since !705 will allow OEMs, ROM makers, etc. to add repos, there needs to
be a way for the user to prevent those from automatically installing or
uninstalling apps for users of the full F-Droid app, which guarantees user
control.
ACRA is sometimes problematic or annoying. Also, whitelabel versions might
want to disable ACRA. The setting the preference defaultValue is an easy
way to do that.
refs #1483
When debugging issues, tracking the client can be quite useful. This makes
an "Expert" preference that adds the app version and a randomly generated,
stored UUID to the query string each time it downloads an index or an app
package.
This is also useful in whitelabeling, for use cases where there needs to be
some kind of identifier to make it work.
If you quickly cycle between installing an app and uninstalling it, then
`app.installedApk` will still be null when AppDetails2.startUninstall()
calls InstallerService.uninstall(). It is better to crash earlier here,
before the Intent is sent with a null APK, because InstallerService is set
to receive Sticky Intents. That means they will automatically be resent
by the system until they successfully complete.
The notification that shows the download/parse progress of the index update
is now controled by the "Show available updates" preference. That means it
will not be shown at all in the notifications bar if that preference is
disabled. There will still be the header inside of F-Droid. Ideally, the
Updating process would be shown in the Updates tab.
This preference is meant for whitelabel builds that are meant to be
entirely controlled by the server, without user interaction, e.g.
"appliances". Some users have asked for such a thing, so it makes sense to
have it available as an expert preference. In general, we want to ensure
that installs/updates always show a notification so that the user is aware
of what is being installed on their computers. That is the same policy as
other app stores like Google Play, etc.
This should make them less scary to people who do not want to see them at
all. It also means that there can be quite a few expert preferences without
making the list super long for most users.
This labels all network, HTTP, and SSL related errors as CONNECTION_FAILED
so that the mirror selection logic will try the connection again with a new
mirror.
