Please refer to: owncloud/android#900

BTW. Is this a correct place to report this? Or the android repository as I did originally?

Actual behaviour

• Using Fiddler with new android 2.1.0, i can see there are new request to /owncloud/index.php/ocs/cloud/user?format=json with index.php acting as a handler of /ocs/cloud/user requests.

But, there are other requests to ocs like /owncloud/ocs/v1.php/cloud/capabilities?format=json and /owncloud/ocs/v1.php/apps/files_sharing/api/v1/shares?path=/&reshares=true&subfiles=true that does not uses index.php as handler, these old ones uses v1.php.

Why not to use the same v1.php to handle /cloud/user requests or create a new handler inside ocs folder and get in one place all the ocs controllers?

Environment data

ownCloud app version: android 2.1.0

ownCloud server version: 9.1.0.15

Hi,

it seems the android-library is currently using the HttpClient libs in version 3.1 released in 2007. This has reached End-Of-Life in 2011 (https://hc.apache.org/httpclient-legacy/index.html).

Have you considered to move to the still maintananced https://hc.apache.org/ ?

Edited by @davigonz from here on

ACs

• New library implementation should get rid of old endpoint (/remote.php/webdav) and start using the new endpoint (/remote.php/dav/files/davUser/). If something is still not implemented, open core issue. Have a look at the next list of useful issues/PRs related to the new endpoint:
  • owncloud/client#4007
  • owncloud/client#5332
  • owncloud-archive/documentation#2753
  • https://github.com/cernbox/smashbox/blob/master/protocol/protocol.md

TOPICS TO DISCUSS

• How to update OwnCloudClient:
  • Option 1: Extend OkHttpClient instead of HttpClient.
  • Option 2: Do not extend OkHttpClient and decouple it from OwnCloudClient, so that OkHttpClient can be easily used regardless of implementation details and OwnCloudClient is not too affected when upgrading OkHttpClient to future versions.
• How to implement the new WebDAV methods
  • Option 1: use a new wrapper for all the methods.

TASKS

• Look for active and trustable WebDAV + HTTP client libraries.
  Candidates:
  1. OKHttp 3.10.0: https://github.com/square/okhttp
  2. Sardine: https://github.com/lookfirst/sardine Not enough active nor trustable
  3. HttpUrlConnection: https://developer.android.com/reference/java/net/HttpURLConnection.html
• Include new network library dependency.
• Use our sample_client app to perform some tests:
  • GET to retrieve server status.
  • PROPFIND to read remote folder.
• Separate the previous tests in one branch for each candidate library:
  • OkHttp: https://github.com/owncloud/android-library/tree/test_ok_http
• Implement basic requests by using the sample client app and the new endpoint, without depending on ownCloud Android library => PR: #187
  • Check server (GET): show the server version
  • Refresh (PROPFIND): show the xml contained in propfind response with the list of files
  • Upload (PUT): show successful message if the upload is properly performed.
  • Download (GET): show successful message if the download is properly performed. The downloaded file won't be created locally in this stage.
  • Delete remote (DELETE): show successful message if the deletion is properly performed.
• Having a look at the code of a different library and testing it
• Create wrapper with generic WebDAV and non WebDAV methods.
  • WebDAV
    • Propfind
    • Copy
    • Move
    • Put
    • MkCol
  • Non WebDAV
    • Get
    • Post
    • Put
    • Delete
• Requests to implement, with the headers and properties required
  • Files (WEBDAV - /remote.php/dav/files/davUser/):
    • UploadRemoteFileOperation => PUT
      • Upload working
      • Upload progress in notification bar and uploads view
      • Cancel upload
      • Retry upload
    • ChunkedUploadRemoteFileOperation, use new chunking=> PUT
      • Upload working
      • Upload progress in notification bar and uploads view
      • Cancel chunked upload
        • Delete remote chunks folder when canceling upload
      • Retry chunked upload
    • DownloadRemoteFileOperation
    • RemoveRemoteFileOperation
    • CopyRemoteFileOperation => COPY
    • RenameRemoteFileOperation => LOCALMOVE (MOVE)
    • CreateRemoteFolderOperation => MKCOL
    • ExistenceCheckRemoteOperation => PROPFIND
    • MoveRemoteFileOperation => MOVE
    • ReadRemoteFileOperation => PROPFIND
    • ReadRemoteFolderOperation => PROPFIND
      • Request properties:
        • creationdate
        • quota-used-bytes
        • permissions
        • quota-available-bytes
        • id
        • getcontentlength
        • size
        • privatelink
  • OAuth:
    • OAuth2GetAccessTokenOperation
    • OAuth2RefreshAccessTokenOperation
  • Shares /ocs/v1.php/apps/files_sharing/api/v1/shares:
    • CreateRemoteShareOperation => POST
    • GetRemoteShareesOperation => GET
    • GetRemoteShareOperation => GET
    • GetRemoteSharesForFileOperation => GET
    • GetRemoteSharesOperation => GET
    • RemoveRemoteShareOperation => DELETE
    • UpdateRemoteShareOperation => PUT
  • Status:
    • GetRemoteStatusOperation /status.php => GET
    • GetRemoteCapabilitiesOperation /ocs/v1.php/cloud/capabilities => GET
  • Users:
    • GetRemoteUserAvatarOperation /index.php/avatar/=> GET
    • GetRemoteUserInfoOperation /ocs/v1.php/cloud/user => GET
    • GetRemoteUserQuotaOperation /ocs/v1.php/cloud/users/username => GET
• Create custom interceptors to put user agent and credentials headers in all the requests.
• Merge non ownCloud changes to dav4android by creating separate MRs
  • Move method support: https://gitlab.com/bitfireAT/dav4android/merge_requests/2
  • Copy method support: https://gitlab.com/bitfireAT/dav4android/merge_requests/3
  • Include more WebDAV properties: https://gitlab.com/bitfireAT/dav4android/merge_requests/4
• Update sample client app to use the current library operations.

TESTS

[TO DO]

RELATED ISSUES

• Send a unique X-Request-ID header to allow tracing requests in apache and owncloud logs owncloud/android#2055
• Chunked upload and resuming: owncloud/android#2070

I have no idea If I need to transplant my bug here myself or what. But here is a copy from this bug report against the client. owncloud/android#940

I've just done a logcat with the working and broken versions. Below is a snippet when it finally "fails". An error appears for every folder that is synced with the 1.7.1 version - which does not occur in 1.7.0

failed sync message:
D/SyncManager(21209): failed sync operation [email protected]:443 u0 (owncloud), org.owncloud, USER, latestRunTime 1141928554, EXPEDITED, reason: 10375, SyncResult: tooManyRetries: true delayUntil: 86400 stats []

Possible cause:
E/ReadRemoteFolderOperation(13246): java.lang.NumberFormatException: Invalid long: "3.89279745229E+12"

D/OwnCloudClient #1(13246): REQUEST PROPFIND /owncloud/remote.php/webdav/Documents%20at%20computer/some%20files/
I/ActivityManager(21209): Start proc com.google.android.youtube for service com.google.android.youtube/.app.remote.YouTubeTvRouteProviderService: pid=14090 uid=10073 gids={50073, 3003, 1028, 1015}
W/ActivityManager(21209): Permission Denial: Accessing service ComponentInfo{com.google.android.music/com.google.android.music.dial.DialMediaRouteProviderService} from pid=7398, uid=10023 that is not exported from uid 10061
E/ReadRemoteFolderOperation(13246): Synchronized /Documents at computer/some files/: Unexpected exception
E/ReadRemoteFolderOperation(13246): java.lang.NumberFormatException: Invalid long: "3.89279745229E+12"
E/ReadRemoteFolderOperation(13246): at java.lang.Long.invalidLong(Long.java:124)
E/ReadRemoteFolderOperation(13246): at java.lang.Long.parse(Long.java:361)
E/ReadRemoteFolderOperation(13246): at java.lang.Long.parseLong(Long.java:352)
E/ReadRemoteFolderOperation(13246): at java.lang.Long.parseLong(Long.java:318)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.lib.common.network.WebdavEntry.(WebdavEntry.java:140)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.lib.resources.files.ReadRemoteFolderOperation.readData(ReadRemoteFolderOperation.java:143)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.lib.resources.files.ReadRemoteFolderOperation.run(ReadRemoteFolderOperation.java:89)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:136)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.operations.RefreshFolderOperation.fetchAndSyncRemoteFolder(RefreshFolderOperation.java:284)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.operations.RefreshFolderOperation.run(RefreshFolderOperation.java:202)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:136)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.syncadapter.FileSyncAdapter.synchronizeFolder(FileSyncAdapter.java:291)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.syncadapter.FileSyncAdapter.fetchChildren(FileSyncAdapter.java:369)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.syncadapter.FileSyncAdapter.synchronizeFolder(FileSyncAdapter.java:311)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.syncadapter.FileSyncAdapter.fetchChildren(FileSyncAdapter.java:369)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.syncadapter.FileSyncAdapter.synchronizeFolder(FileSyncAdapter.java:311)
E/ReadRemoteFolderOperation(13246): at com.owncloud.android.syncadapter.FileSyncAdapter.onPerformSync(FileSyncAdapter.java:190)
E/ReadRemoteFolderOperation(13246): at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)
D/RefreshFolderOperation(13246): Synchronizing [email protected]:443/Documents at computer/some files/
D/FileSyncAdapter(13246): Send broadcast com.owncloud.android.syncadapter.FileSyncAdapter.EVENT_FULL_SYNC_FOLDER_CONTENTS_SYNCED
D/FileDisplayActivity(13246): Received broadcast com.owncloud.android.syncadapter.FileSyncAdapter.EVENT_FULL_SYNC_FOLDER_CONTENTS_SYNCED
D/FileSyncAdapter(13246): Send broadcast com.owncloud.android.syncadapter.FileSyncAdapter.EVENT_FULL_SYNC_END
D/SyncManager(21209): failed sync operation [email protected]:443 u0 (owncloud), org.owncloud, USER, latestRunTime 1141928554, EXPEDITED, reason: 10375, SyncResult: tooManyRetries: true delayUntil: 86400 stats []
D/SyncManager(21209): not retrying sync operation because it retried too many times: [email protected]:443 u0 (owncloud), org.owncloud, USER, latestRunTime 1141931912, EXPEDITED, reason: 10375
D/dalvikvm(21209): GC_EXPLICIT freed 1310K, 24% free 51401K/66848K, paused 4ms+8ms, total 143ms
D/FileDisplayActivity(13246): Setting progress visibility to true
D/FileDisplayActivity(13246): Received broadcast com.owncloud.android.syncadapter.FileSyncAdapter.EVENT_FULL_SYNC_END
D/FileDisplayActivity(13246): Setting progress visibility to false

I'm not really an expert at java - I actually know VERY little. But here is what I think is happening.

The long variable error occurs from the function mentioned in this log line:

E/ReadRemoteFolderOperation(13246): at com.owncloud.android.lib.common.network.WebdavEntry.(WebdavEntry.java:140)

This leads me to:
https://github.com/owncloud/android-library/blob/master/src/com/owncloud/android/lib/common/network/WebdavEntry.java#L140

Which clearly indicates that this is looking at the users quotas available bytes

137 // {DAV:}quota-available-bytes
138 prop = propSet.get(DavPropertyName.create(PROPERTY_QUOTA_AVAILABLE_BYTES));
139 if (prop != null) {
140 mQuotaAvailableBytes = Long.parseLong((String) prop.getValue());
}

My server has a "Default Limit" of Unlimited. And my user account has a Quota of "Default".

All is fine and well here, right?

The value being returned at this line of code is "3.89279745229E+12", which isn't in decimal format.

The limit of a long variable in java is:
Maximum value is 9,223,372,036,854,775,807 (inclusive). (2^63 -1)

You need to learn how to handle large numbers for your quota value check.

http://stackoverflow.com/questions/2722122/java-parse-a-number-in-exponential-notation

Also, your demo server doesn't have this large storage limit. Please consider that just because the demo server works when troubleshooting, it doesn't mean the issue is with the users server.

When I set my "Default Storage" value to 100GB, the issue with 1.7.1 went away. This is a OC Android library issue.

TL;DR: They can't handle large storage sizes in their quota checks. Set a quota limit for your "Default Storage" value that just exceeds what you need. I put in 100GB.

A common (heretic) question:

Why do a lot of stuff "by hand" and not using Retrofit ?

i am trying to download file in sample-client from owncloud server m getting File Not Found(404) in result of onRemoteOperationFinished()

Our network library is going to need an upgrade since we are currently using Jackrabbit-webdav 2.12.14, which depends on HttpClient 3.x, a pretty old library which is no longer being developed.

So, before trying to perform a complete replacement using a different library, we are going to try to upgrade the current one.

Hi,
I wanted to avoid having to enter password every time I start the app (because the final purpose is not just for my personal use).
Yet, if I try this:
ocClient = OwnCloudClientFactory.createOwnCloudClient(serverUri, activity, true);
ocClient.setCredentials(OwnCloudCredentialsFactory.newBearerCredentials(authToken));
authToken = ocClient.getCredentials().getAuthToken();

not only do I realize that the authToken is just the non-encrypted password, which prevents me from storing it anywhere on the user's phone, but additionally, it just does not work with the following error:
Credentials cannot be used for basic authentication: com.owncloud.android.lib.common.network.BearerCredentials

Am I doing something wrong?
Thanks.

With the changes done by removing the ok http singleton I also introduced a redundend use of the HttpClient wrapper.

The HttpClient gets introduced to the HttpMethod through the constructor:

However the execute() method of the HttpMethod is later called from the OwnCloudClient which extends the HttpClient wrapper:

Getting "in touch" twice with the client is redundant and should be removed. Here are two possible solutions:

1. Try to Inject the client from the constructor:

The HttpClient modifying methods in the `HttpBaseMethod` do not need to be changed: https://github.com/owncloud/android-library/blob/9d80a95a884715f9d71aa16f86bd36d0d50bce14/owncloudComLibrary/src/main/java/com/owncloud/android/lib/common/http/methods/HttpBaseMethod.kt#L110

But the code calling the method.execute() in the OwnCloudClient has to be moved to the HttpMethod:

2. Try to inject the client from the execute method:

The HttpClient modifying methods in the `HttpBaseMethod` need to be modified: https://github.com/owncloud/android-library/blob/9d80a95a884715f9d71aa16f86bd36d0d50bce14/owncloudComLibrary/src/main/java/com/owncloud/android/lib/common/http/methods/HttpBaseMethod.kt#L110

Instead of modifying the OkHttp client directly we could save the modifications and apply them when calling the execute(client) method.
The only change that need to be applied to OwnCloudClient would be that this is suplied the the execution() method.

Issue: #378
Library: #427
App: owncloud/android#3353

Hi,

I'm currently working on an eclipse legacy project, that uses the ownCloud library. I want to update the library in the project. To do so i need the library in JAR format. Unfortunately by building with gradle the outcome is in AAR format (at least on Jenkins instance the outcome is AAR).

I found some information on stackoverflow on how to convert an AAR to a JAR, which is basically extracting the classes.jar from the AAR and renaming it.
Unfortunately this doesn't seem to work. When i add the ownCloud-library.jar into my project's lib folder, eclipse is able to find all the classes and importing namespaces seems to work. Building the App works too. But as soon as i try to run the app on an emulator i get the following error(s):

Dx unsupported class file version 52.0
...while parsing com/owncloud/android/lib/BuildConfig.class
Dx 1 error; aborting
Conversion to Dalvik format failed with error 1

After searching a bit on the internet i found a few solutions suggesting to change the JRE version to 1.7 and also the java compliance level to 1.7. But none of these seem to work.

Another solution suggest to create an eclipse project, that references the extracted and renamed classes.jar. I also tried that but then eclipse is not able to resolve the namespaces within the my legacy project.

My thought was, that the above mentioned method to "convert" the AAR to JAR is not correct (or does not create a "dexable" JAR file).

So my first qestion would be: How can i build the ownCloud library with ANT, to get a correctly working JAR file?

I have seen this issue:

https://github.com/owncloud/android/pull/1621

which was about removing the ANT build from the library. The branch seems not to be available anymore, or? I couldn't find it (git clone complains it cannot find the branch).

I understand that ANT is not supported anymore by this library (for good reasons), but maybe someone can help me to get a working JAR?

Thanks in Advance,

Michael

What would be the proper way to cancel RemoteOperation?

I just tried CreateFolderTest. It succeeded. I noticed that several connection times outs occurred before I noticed that my connection was blocked.

I looks like timeouts are "accept" on purpose:

https://github.com/owncloud/android-library/blob/develop/test_client/tests/src/com/owncloud/android/lib/test_project/test/RemoteTest.java#L54

https://github.com/owncloud/android-library/blob/develop/test_client/tests/src/com/owncloud/android/lib/test_project/test/CreateFolderTest.java#L71

I do not understand the reasoning here. IMO, the tests require a working connection to the server, otherwise functionality cannot be tested. So if the connection breaks, the test should fail.

We created a fork of dav4Android a year ago approximately and started to use it in our communication library, along with OkHttp. Since there's new changes in the original library, we could perform a rebase and bring those changes to our project

• Update fork with latest version
• Check okhttp's dav4droid version
• Update library reference

Hi,

are there any basic functionality to connect and disconnect the connection to a server?

Hi, I just started contributing to the owncloud android project and I'm seeing a bug that I can't find the reason behind it:

• After some hours working with app (which I don't think it is relevant to time, since it happened in various situations) it kicks the user out and ask for user's password.
• after entering correct password it goes in but asks for password over and over again.

When executing operations (e.g. ReadRemoteFolderOperation) - logic always ends up attempting to use mAccount.getSavedAccount() inside client, which is always null for OwnCloudAccount instance if constructor public OwnCloudAccount(Uri baseUri, OwnCloudCredentials credentials) used for creation.

Is it even possible to work with plain username&password pair?

P. S.: is this even actual library to attempt to use for accessing ownCloud? It really looks like you gave up on implementing it in the middle of development and somehow gave it 'stable' status (at least I'm trying to use that branch).
Even your own sample app does not work (and it is, in fact, the only source of documentation for this library - every page related to Android client development redirects users to it).

All webDAV commands sent by sample client are sent twice:
First time without credentials (server returns 401), then with credentials (now sucess 2xx)

This is the server log:

IP - - [16/Jun/2015:22:03:11 +0200] "PROPFIND /remote.php/webdav/ HTTP/1.1" 401 1144 "-" "Jakarta Commons-HttpClient/3.1"
IP - test [16/Jun/2015:22:03:12 +0200] "PROPFIND /remote.php/webdav/ HTTP/1.1" 207 3570 "-" "Jakarta Commons-HttpClient/3.1"

There is probably just a single line missing somewhere. I cannot figure out what it should be and where to put.

PS: I added a simple SslSocketFactory which accepts my self-signed certificate. Could that pose a problem?

A general question concerning

Why do it needs a unique number OC_X_REQUEST_ID here and client don't save or handle it.
So from the client side there is no need doing it here. That means only server needs it ?
If yes, the server can give himself the number too ?

Do we really need a manual test for every PR, or what prevents a merge of
#224
#228
there is no logic changed at all there.

When I would approve it, I would merge it immediate

Or different asked:
How is the workflow ?

When i want to connect to the server with android api version under 19 i get this runtime exception but with api version upper than 19 it works correctly.

com.owncloud.android.lib.sampleclient E/com.owncloud.android.lib.sampleclient.MainActivity﹕ SSL recoverable exception
com.owncloud.android.lib.common.network.CertificateCombinedException
at com.owncloud.android.lib.common.network.AdvancedX509TrustManager.checkServerTrusted(AdvancedX509TrustManager.java:105)
at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.verifyCertificateChain(OpenSSLSocketImpl.java:597)
at org.apache.harmony.xnet.provider.jsse.NativeCrypto.SSL_do_handshake(Native Method) at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:398) at com.owncloud.android.lib.common.network.AdvancedSslSocketFactory.verifyPeerIdentity(AdvancedSslSocketFactory.java:248) at com.owncloud.android.lib.common.network.AdvancedSslSocketFactory.createSocket(AdvancedSslSocketFactory.java:185)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387 atorg.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at com.owncloud.android.lib.common.OwnCloudClient.executeMethod(OwnCloudClient.java:222) at com.owncloud.android.lib.resources.files.ReadRemoteFolderOperation.run(ReadRemoteFolderOperation.java:79)
at com.owncloud.android.lib.common.operations.RemoteOperation.run(RemoteOperation.java:303)

Hi,

Since it successfully builds on jitpack perhaps its worth adding dependency information to readme:
https://jitpack.io/#owncloud/android-library/oc-android-library-0.9.7

Would make it easier for others to include the library in their projects.

Following our way to use Moshi to parse http responses (Already parsing capabilities, sharees, user info with Moshi), next step is to use moshi to parse shares.

Currently we retrieve the xml response from the shares endpoint, and parse it manually.

With moshi, we need to retrieve the json response, and create a new ShareResponse. Moshi will do the rest.

This PR can be used as reference: #352

I am working on an integration of owncloud upload capabilities into the gpslogger android app (https://github.com/mendhak/gpslogger).
Following the documentation of the android-library (https://doc.owncloud.org/server/8.0/developer_manual/android_library/index.html), what I struggled with is getting upload of a file to run from a background thread. As far as I can see, the current API doesn't directly support that, there's two issues: (1) for the Factory to create a OwnCloudClient, one needs a context; and (2) for the UploadRemoteFileOperation.execute, one needs a Handler (but that can't be created in a background thread if I understand correctly - it fails with "Can't create a handler inside thread that has not called Looper.prepare()").
Circumventing (1) is easy through the readily available constructor. For (2), to avoid having to create a Handler. I ended up calling the run() method directly; for that, the UploadRemoteFileOperation class had to be made public, but then it worked.

I'm quite new to Android development so probably I've just missed a simple thing, if so, I would be very thankful if you pointed me in the right direction!

GetRemoteCapabilitiesOperation.kt takes care of parsing the capabilities retrieved from the server in JSON format and transform them into RemoteCapability object.

Similarly to what we detailed in owncloud/android#2704, we could use Moshi to make the parsing of capabilities.

Tasks:

• Move capabilities parsing from library to data layer, that will parse the JSON and transform it into OCCapability object.
• Get rid of RemoteCapability class since is basically the same as OCCapability.

See: owncloud/client#4459

And compare with: https://github.com/owncloud/android-library/search?utf8=%E2%9C%93&q=quota

If the actual transferred bytes on a GET operation do not correspond to the Content-Length header returned from the server, we fail without any notice what happened. We should should make the error thrown/created here more verbose:

FIX: #425

No contacts and calendar?

I'm trying out this sample_client and upload,download,delete works but refresh doesn't. List view never fills out. "TODO: operation finished in fail" toast every time. Is this a known situation? Doesn't seem like it should be this hard to test out. Just changed the setup.xml strings except user_agent

Remove the okHttpClient signleton from HttpCleint. Use propper injection which we can do from the OwnCloudClientFactory.

Tasks

• Make okHttpClient nonsingleton
• move library remoteoperations to nonsingleton
• move app remoteoperations to nonsingleton
• implement injection in library
  • research
• Add/fix Unit tests in library
• Add/fix Unit tests in app
• Test if application runs stable

Implementation

App: owncloud/android#3047
Library: #364

Hello,
i have installed owncloud server version 10, then i imported a wildcard certificate which is from comodo (*.domain.com). When I connect to the cloud via a browser the certicate works perfect.
When i try to connect with the android-library i get the following exception:

E/ReadRemoteFolderOperation: Synchronized /: SSL recoverable exception
                                                                             com.owncloud.android.lib.common.network.CertificateCombinedException
at com.owncloud.android.lib.common.network.AdvancedX509TrustManager.checkServerTrusted(AdvancedX509TrustManager.java:105)
                                                                                 at com.android.org.conscrypt.Platform.checkServerTrusted(Platform.java:117)
                                                                                 at com.android.org.conscrypt.OpenSSLSocketImpl.verifyCertificateChain(OpenSSLSocketImpl.java:556)
                                                                                 at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
                                                                                 at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:324)
                                                                                 at com.owncloud.android.lib.common.network.AdvancedSslSocketFactory.verifyPeerIdentity(AdvancedSslSocketFactory.java:247)
                                                                                 at com.owncloud.android.lib.common.network.AdvancedSslSocketFactory.createSocket(AdvancedSslSocketFactory.java:183)
                                                                                 at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
                                                                                 at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)

is there anybody who can help me with this problem?
Thanks!!

My app displays a list of owncloud accounts retrieved with AccountManager.get(this).getAccountsByType("owncloud")

After the user selects an account I try to create an OwnCloudClient with OwnCloudClientFactory.createOwnCloudClient(selectedAccount, MainActivity.this);.

But the application crashes with a runtime exception:

Caused by: java.lang.SecurityException: caller uid 10341 is different than the authenticator's uid
   at android.os.Parcel.readException(Parcel.java:1546)
   at android.os.Parcel.readException(Parcel.java:1499)
   at android.accounts.IAccountManager$Stub$Proxy.getUserData(IAccountManager.java:692)
   at android.accounts.AccountManager.getUserData(AccountManager.java:344)
   at com.owncloud.android.lib.common.accounts.AccountUtils.getBaseUrlForAccount(AccountUtils.java:141)
   at com.owncloud.android.lib.common.OwnCloudClientFactory.createOwnCloudClient(OwnCloudClientFactory.java:77)
...

I've integrated ownCloud library in my project as an ".aar" module.
I'm getting the following runtime error whenever I try to execute the following code after initializing ownCloud client:

ReadRemoteFolderOperation refreshOperation = new ReadRemoteFolderOperation(FileUtils.PATH_SEPARATOR);
refreshOperation.execute(client, this, handler);

I know that the ownCloud client is initialized properly and the credentials are correct because I've tested them with the sample app that comes with the SDK and it worked fine.

What could be the problem?

How I update passwords user. Thank you!

Under the owncloud-android-library/libs directory there's still some .jar that are not needed anymore:

• commons-httpclient-3.1.jar
• jackrabbit-webdav-2.12.4.jar

03-29 14:45:20.484 2583-2728/com.owncloud.android.lib.sampleclient E/ReadRemoteFolderOperation﹕ Synchronized /: The ownCloud server is not configured!
03-29 14:45:20.489 2583-2583/com.owncloud.android.lib.sampleclient E/com.owncloud.android.lib.sampleclient.MainActivity﹕ The ownCloud server is not configured!
03-29 14:45:22.502 2583-2597/com.owncloud.android.lib.sampleclient E/Surface﹕ getSlotFromBufferLocked: unknown buffer: 0xab7d3750

I guess this is not right any more, when I see dependencies

dependencies {
    api 'com.squareup.okhttp3:okhttp:3.10.0'
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.2.51"
    implementation 'com.gitlab.ownclouders:dav4android:oc_support'
}

Third party libraries

ownCloud Android Library uses Apache JackRabbit, version 2.2.5. Copyright (C) 2004-2010 The Apache Software Foundation. Licensed under Apache License, Version 2.0.

Apache JackRabbit depends on Commons HTTPClient version 3.1 and SLF4j version 1.7.5; both included also. Copyright (C) 2004-2010 The Apache Software Foundation. Licensed under Apache License, Version 2.0.

Or does com.gitlab.ownclouders:dav4android:oc_support uses this JackRabbit ?

Like the title says it would be nice to have an Operation to load a user's avatar.
This can imho be supported for oC v8.2 while being logged in requesting the image via
/index.php/avatar//

The Android client issue for this is: owncloud/android#778
The server issue is: owncloud/core#14856 (already merged/released)

when i call this method :

private void startRefresh() {

    ReadRemoteFolderOperation refreshOperation = new ReadRemoteFolderOperation("/uploads/");  

    refreshOperation.execute(mClient, this, mHandler);  

} 

the server return me code 405 . I don’t know what’s mean , probably httpMethod is incorrect ？
can you help me ?
Thank you.

There is no proguard handling at all.
Should be some classes kept ?

I've integrated ownCloud library in my project as an ".aar" module.
In my gradle I add the aar along with the HttpClient library (if I don't add the HttpClient library I get compile errors) I get as follows:

compile 'commons-httpclient:commons-httpclient:3.1'
compile(name: 'android-library-release', ext: 'aar')

I still get two warnings:

warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.apache.commons.httpclient.HttpMethodBase$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is not an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is not an inner class.

Could these two warnings affect the other issue that I mentioned in #134?

Because otherwise one doesn't know, which of the (already started several file download operations at this point) downloads finished, but to handle them, while others are downloaded, it's necessesary to know the filepath it's gotten saved at.

I did a small workaround, but it's probably not meant that way:
in file: lib-common-operations-RemoteOperationResult:

#115: private String mFilename;
#172: if ("filename".equals(current.getName().toLowerCase())) { mFilename = current.getValue(); }

public String getFilename() { return mFilename == null ? null : mFilename; }

in file: lib-resources-files-DownloadRemoteFileOperation:

// # 85: instead of "result = new RemoteOperationResult...." (custom header)
// old version was line 87
            Header[] headerArray = null;
            if (mGet != null) {
                headerArray = mGet.getResponseHeaders();
                ArrayList<Header> headerList = new ArrayList<Header>();
                Collections.addAll(headerList, headerArray);
                headerList.add(new Header("Filename", tmpFile.toString()));
                headerArray = new Header[headerList.size()];
                headerList.toArray(headerArray);
            } else {
                headerArray = null;
            }
            result = new RemoteOperationResult(isSuccess(status), status, headerArray);

Cheers!

I am attempting to connect to an owncloud server where the user has issued a self signed certificate.

I try to connect like so, and I am using the SelfSignedConfidentSslSocketFactory, so that any self signed certificate can be accepted. I got this initial code from the test app.

  Protocol pr = Protocol.getProtocol("https");
 if (pr == null || !(pr.getSocketFactory() instanceof SelfSignedConfidentSslSocketFactory)) {
     try {
         ProtocolSocketFactory psf = new SelfSignedConfidentSslSocketFactory();
         Protocol.registerProtocol( "https", new Protocol("https", psf, 443));

     } catch (GeneralSecurityException e) {
         tracer.error("Self-signed confident SSL context could not be loaded", e);
     }
 }

 OwnCloudClient client = OwnCloudClientFactory.createOwnCloudClient(Uri.parse(servername), AppSettings.getInstance(), true);
 client.setDefaultTimeouts('\uea60', '\uea60');
 client.setFollowRedirects(true);
 client.setCredentials(
         OwnCloudCredentialsFactory.newBasicCredentials(username, password)
 );

 String remotePath = directory + FileUtils.PATH_SEPARATOR + localFile.getName();
 String mimeType = "application/octet-stream"; //unused
 UploadRemoteFileOperation uploadOperation = new UploadRemoteFileOperation(localFile.getAbsolutePath(), remotePath, mimeType);
 uploadOperation.execute(client,this);

This attempts to connect and fails with

  01-30 00:23:28.774     948-2093/com.mendhak.gpslogger E/OwnCloudJob﹕ onRemoteOperationFinish:100 - SSL recoverable exception
      com.owncloud.android.lib.common.network.CertificateCombinedException: null
              at com.owncloud.android.lib.common.network.AdvancedX509TrustManager.checkServerTrusted(AdvancedX509TrustManager.java:105) ~[na:0.0]
              at com.android.org.conscrypt.Platform.checkServerTrusted(Platform.java:116) ~[na:0.0]
              at com.android.org.conscrypt.OpenSSLSocketImpl.verifyCertificateChain(OpenSSLSocketImpl.java:550) ~[na:0.0]
              at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method) ~[na:0.0]
              at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:318) ~[na:0.0]
              at com.owncloud.android.lib.common.network.AdvancedSslSocketFactory.verifyPeerIdentity(AdvancedSslSocketFactory.java:248) ~[na:0.0]
              at com.owncloud.android.lib.common.network.AdvancedSslSocketFactory.createSocket(AdvancedSslSocketFactory.java:185) ~[na:0.0]
              at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707) ~[na:0.0]
              at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361) ~[na:0.0]
              at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387) ~[na:0.0]
              at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) ~[na:0.0]
              at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) ~[na:0.0]
              at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) ~[na:0.0]
              at com.owncloud.android.lib.common.OwnCloudClient.executeMethod(OwnCloudClient.java:223) ~[na:0.0]
              at com.owncloud.android.lib.resources.files.UploadRemoteFileOperation.uploadFile(UploadRemoteFileOperation.java:120) ~[na:0.0]
              at com.owncloud.android.lib.resources.files.UploadRemoteFileOperation.run(UploadRemoteFileOperation.java:88) ~[na:0.0]
              at com.owncloud.android.lib.common.operations.RemoteOperation.run(RemoteOperation.java:331) ~[na:0.0]
              at java.lang.Thread.run(Thread.java:818) ~[na:0.0]

Is there something else I should be doing to trust self signed certs?

It seems we are trying to exhaust http responses when are already closed, which triggers the error below:

E/OwnCloudClient: Unexpected exception while exhausting not interesting HTTP response; will be IGNORED
    java.io.IOException: closed
        at okio.RealBufferedSource$1.read(RealBufferedSource.java:435)
        at java.io.InputStream.read(InputStream.java:101)
        at com.owncloud.android.lib.common.OwnCloudClient.exhaustResponse(OwnCloudClient.java:234)
        at com.owncloud.android.lib.resources.files.CreateRemoteFolderOperation.createFolder(CreateRemoteFolderOperation.java:112)
        at com.owncloud.android.lib.resources.files.CreateRemoteFolderOperation.run(CreateRemoteFolderOperation.java:84)
        at com.owncloud.android.lib.common.operations.RemoteOperation.runOperation(RemoteOperation.java:251)
        at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:213)
        at com.owncloud.android.operations.CreateFolderOperation.run(CreateFolderOperation.java:62)
        at com.owncloud.android.lib.common.operations.RemoteOperation.runOperation(RemoteOperation.java:251)
        at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:190)
        at com.owncloud.android.operations.common.SyncOperation.execute(SyncOperation.java:68)
        at com.owncloud.android.providers.DocumentsStorageProvider.createFolder(DocumentsStorageProvider.kt:236)
        at com.owncloud.android.providers.DocumentsStorageProvider.createDocument(DocumentsStorageProvider.kt:197)
        at android.provider.DocumentsProvider.callUnchecked(DocumentsProvider.java:1005)
        at android.provider.DocumentsProvider.call(DocumentsProvider.java:951)
        at android.content.ContentProvider$Transport.call(ContentProvider.java:401)
        at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:272)
        at android.os.Binder.execTransact(Binder.java:731)

After replacing the network library with OkHttp, we put TLS algorithm by default but we could use higher versions, v1, v1.1 or even v1.2. as we did previous the network library switch.

Comes from owncloud/client#10103

PROPFIND response 425 should be valid and not error.

currently there are such tag names

In my point of view they should only include numbers, like 1.0 so other apps can include it like

        implementation 'com.github.owncloud:android-library:1.0'

and not like current

        implementation 'com.github.owncloud:android-library:oc-android-library-0.9.24'

please see https://jitpack.io/#owncloud/android-library

The Sample app in the library is not used anymore, yet we still have to fix it from time to time in order to be able to compile the whole library without compiler issues. We should remove it as we have not user for it anymore.