Because it is mandatory as of nov 2018:
https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html
As the default Notification.Builder constructor is deprecated in API 26,
this change also adds the use of the new constructor, which requires a
notification channel Id.
Note: since the users are now in full-control of the notifications,
they can now choose to completely block the auto-upload notification
channel. Given that the main goal of the notification was to keep the
app in memory in order for auto-upload to work, one could expect that
blocking the channel would defeat the notification's purpose. However,
as far as I could test, auto-uploading seems to still be working even
after disabling the channel, and letting the activity die (tip: in
devoloper options, one can tick "Don't keep activities"). In fact,
Perkeep Uploader still always runs as a service.
Also build pk-put shipped in the app with Go 1.11.
Fixes#1202
Change-Id: I8f98e0df742915cb504b6c1cfaa42ca6dc7b6189
-busy/munching pudgy is replaced with a "dancing" keepy
-sad pudgy replaced by a sad keepy
-everywhere else is normal keepy (which is one sprite of the dancing
keepy animation)
-we still need an "interested" keepy for when the user is about to drop
something on the d&d area
-glitch embedy directory has not been removed yet, to keep the pudgy
animations technique as a reference for future work.
We also need to update the animation in the GCE launcher.
Updates #1177
Change-Id: I95fe53cb51f93b8f498c8f026eddc07285c20db7
Also removed misc/buildbot while at it (which contained camput
references) since we don't use it anymore at all.
TODO: the OSX app seems to be relying on finding a binary in ../bin,
which we do not use anymore. This will probably need fixing.
Updates #981
Change-Id: I14220fbad2e81181330fca4bb2d2e5fe170e1bd6
So far, errors in the uploader configuration leading to upload failures
are not reported to the user in a meaningful way. The upload process
simply stops without further feedback, which is annoying especially when
either certificate hash or password are wrong.
This change adds a text widget below the upload stats, reporting
camput's stderr output as-is. While not ideal from a usability
standpoint (log entries are too wide and too verbose, and not clearly
marked as errors), it is better to receive those verbose messages than
none at all. The error text widget is cleared when a new upload is
started.
Change-Id: I75e79d802cf64981b92c80ce9fc12d2a26552169
As far as I understood, for the auto-uploading to work reliably, the
file observers need to be permanently referenced, so they can watch for
new file creations constantly. It seems that it was not the case, as
they are referenced by the upload service, which itself was meant to be
stopped as soon as it's done uploading.
Moreover, as android memory management is getting more aggressive, it is
apparently getting more likely that the service would get killed anyway,
even if it did not stop itself.
This change is therefore two-fold:
1) The service does not try to stop itself anymore when it's done
uploading. Also, the activity starts it before binding to it (because
otherwise a service that has been automatically "bound-started" gets
destroyed as soon as all its binders disconnect from it).
2) The service is declared to run on the foreground, to make it the
least likely possible for the system to kill it. That means adding a
notification to which it is tied. The notification action leads to the
settings page, so that the auto-uploading can be toggled on/off.
At first I tried creating a new service class, that would be the
smallest possible (having only the file observers), to reduce the size
of what would have to be in the foreground. But it proved harder than I
thought and would require more time to rework the app as a whole, and
I'm not sure that's the best thing to do right now. Which is why I
resorted to make the whole UploadService a foreground one. I do not know
yet whether this is an acceptable trade-off.
In addition, this CL tries harder to find the directories with
interesting files to upload, by trying directories on the SD card too.
Fixes#1049
Change-Id: I311f31acc0a1db43791a7502a45a9f2da92cf39a
-android plugin 3.0.1
-gradle 4.1 (requirement for the above)
-gomobile to 069be623eb8e75049d64f1419849b3e92aab1c81
-go 1.9.3
-removed permission to write on storage from the manifest
-added permission to read from storage on the manifest
-added permission checking code for reading files on storage, which is
compulsory with modern android APIs.
-add missing code to update textByteStatus and textFileStatus TextViews
Notes:
-the app won't work with a server older than rev
6e8a5930c9 as the server/client protocol
to check for existing files on the server changed at this point.
-i think with Android O there's a much higher chance that the
CamliFileObserver gets garbage collected, which breaks the
auto-uploader. We probably need to switch to a different architecture,
like running as a Foreground Service, or using the Job Scheduler to
regularly fire up the file observer. In another CL.
Updates #1049
Change-Id: I079da8e5df5be820c3985749a9e109cf0775b495
- Updates the naming from Camlistore to Perkeep
- Adjusts the mount point to ~/Desktop/perkeep
- Uses the new pk-mount binary
- Uses Perkeep.log instead of Camlistore.log
- Updates to minimum build of OSX 10.10
- Moves everything a directory level higher
Still uses the old branding, will need updated assets for this.
Tested: Built manually, all features appear to work now.
point to use ~/Desktop/perkeep
Change-Id: I0e267525f342afa43b8c1f59b46b5e2a75aa7844
The web UI support the old sha1 blob hash only.
Add initial support for sha224 blob refs.
Also add sha2.js and sha224.js to goog/crypt in the embedded resources.
Change-Id: If52d75d254d6163a737c56cf1676be1ef7eddb31
Part of the project renaming, issue #981.
After this, users will need to mv their $GOPATH/src/camlistore.org to
$GOPATH/src/perkeep.org. Sorry.
This doesn't yet rename the tools like camlistored, camput, camget,
camtool, etc.
Also, this only moves the lru package to internal. More will move to
internal later.
Also, this doesn't yet remove the "/pkg/" directory. That'll likely
happen later.
This updates some docs, but not all.
devcam test now passes again, even with Go 1.10 (which requires vet
checks are clean too). So a bunch of vet tests are fixed in this CL
too, and a bunch of other broken tests are now fixed (introduced from
the past week of merging the CL backlog).
Change-Id: If580db1691b5b99f8ed6195070789b1f44877dd4
Due to a change in the Android NDK (starting from r16), building the
docker container fails with an error during the installation of
gomobile:
fatal error: 'stdlib.h' file not found
This issue was addressed in more recent versions of gomobile, which
are compatible with the new NDK.
See https://github.com/golang/go/issues/21802
This CL simply updates gomobile to the most recent commit.
Change-Id: I87c468c34de441bc6acd40b717d1d950014e5a99
The ~/.gradle and ~/.android dirs are mounted as volumes for the docker
container when building the app, because we want the gradle and android
deps to be cached on the host after they've been downloaded.
The build process was assuming that these dirs always already existed,
and this assumption makes the building process fail if they actually
don't.
Therefore this change creates the directories on the host if they don't
already exist.
Change-Id: I90b5f73db0ffcbe76adc12157e142091808bde2b
It seems that on other (more modern?) configurations, the cgroup for
processes in docker is /system.slice/docker.service instead of /docker.
I have not been able to reproduce such a configuration. But until we have
a better way to detect whether a process is in docker, it's probably ok
to just add the new path to validate the detection, which this change
does.
Fixes#973
Change-Id: I9d52bcd79a906fdc1f8310b2c8063930cf9807fb
Android Studio requires newer versions of the Android SDK Build-Tools
and Gradle to build the uploader application.
In this commit, Gradle is updated to version 3.3 (as suggested by
Android Studio) and the Android SDK Build-Tools to the most recent
release.
Change-Id: Ief04ec56a6fffb0b46bd28820134c8e7a1ebbede
When reinstalling the app, using shell commands to set executable
permissions on the camput binary sometimes fails for unknown reasons.
The camput binary keeps 0660 permissions even though no error is
reported. The frequency of failed deployments seems to increase when
more recent build tools are used in the build process. On a Nexus 5X,
observed failure rates are in the order of one in twenty up to one in
six.
This commit removes all use of shell commands for deploying camput and
utilizes native java methods instead. While the resulting permissions of
camput change from 0700 to 0760, this is acceptable as the group is
app-specific and not shared.
A call to fsync is added to ensure that all file data (not just
metadata) is committed to disk before the file is renamed. This should
be safer in the event of a power loss as we're most likely writing to an
ext4 file system (the noauto_da_alloc mount option is used on modern
devices, see [1]).
With these changes, no failures to set executable permission bits could
be observed, regardless of build tool version used (v19.1 and v26.0,
n=30 each).
Fixes#932
[1] https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
Change-Id: I290b4ce896aa449afef89ac87cdd0431752ceb93
When building the uploader application with a newer version of the build
tools, the build fails in stage app:lintVitalRelease with a lint error of
type WifiMangerLeak. The wifi manager instance should always be obtained
from an application context in order to avoid a memory leak on Android
versions before N. See:
https://developer.android.com/reference/android/net/wifi/WifiManager.html
This commit implements the recommendation to obtain the wifi manager
instance through the application context.
Change-Id: I59ff0dfb381b82d9b4f201b646f11b34b3de3cff
While the log message claims that the permissions of the camput binary
were set to 0700, they were actually set to 0777.
Change-Id: Ic5adbc05af161431823a3fb1685af5fa9a4b6647
Android applications nowadays are supposed to be developped with Android
Studio, which uses gradle as the build system, with the android plugin.
This change modifies the app setup and file tree layout so it can be
built with gradle (in docker by default) instead of with ant.
The initial motivation for this change is to make changes to the app in
Go, using 'gomobile bind' to call the Go code from java. As the canonical
example at golang.org/x/mobile/example/bind/hello uses gradle, the
first step was to migrate the app to gradle.
Even if we don't end up using gomobile, this change is interesting as it
makes it easier for android apps developpers to contribute to the app if
it uses the recommended "modern" way.
Change-Id: I8386012db640324b62e18ffc128b68ba971fa953
On some devices, updating notifications and status text at a high rate
causes whole-system UI lag and even complete system freezes. On a
Nexus 5, the uploader is completely unusable and requires a hard phone
restart almost every time "upload all" is triggered from the UI. The
device freezes happen across multiple stock Android releases.
This commit reduces the update rate of the UI significantly by updating
the notification only when the integer percent value of the upload
progress changes. It also reduces the update rate of the status text to
around 30 fps, which should still be plenty. With both of the changes,
the uploader behaves as expected. Either change alone is not enough to
get rid of the device freezes.
Change-Id: I2c170772d29c4670c8c10d09cdaea96207fc9e61
- Added a null check I missed in my last commit.
- Fixed duplicated Permission ACCESS_NETWORK_STATE in manifest.
Change-Id: I0da93b3e83ac584cb8fe36b2c3b9f1c711b08a8a
This is a first shot at
https://code.google.com/p/camlistore/issues/detail?id=496.
A user can enter a SSID and the upload will only run over Wifis with
this SSID. If the SSID option is left empty, everything works as before.
Change-Id: Ief3642c5b9c14d059f42696531fa33d1d780ab1c
I scratched my own itch and addressed
https://code.google.com/p/camlistore/issues/detail?id=494
for my HTC One M8 which stores pictures taken with its camera
to /sdcard/DCIM/100MEDIA.
Hardcoding these paths is far from being a good solution. I hope I can
find the time to get deeper into Android coding and come up with some
for https://code.google.com/p/camlistore/issues/detail?id=37 over the
next weeks.
Change-Id: I4e351c1915c5c7f66948d434d72763c826a25a16
mpl
