Closed JuancaG05 closed 3 months ago
In the following text I will explain in detail the research I have done on this issue.
This problem happens only in OCIS
.
First of all, let's clarify what the Clear data button is for. The Android message that appears when we click on this option is the following: All of this application's data will be deleted permanently. This includes all files, settings, accounts, databases etc
. I want to point out that according to this text the accounts associated to the application should be deleted, but as we have the application this is not happening and it could be one of the focuses to solve the problem. We manage the accounts in the ManageAccount
, so the Clear data
does not affect this object.
The data that is being deleted by pressing the Clear data button are the following: Sharedpreferences, temporary files and the local database being cleared.
Once put in context about what clears the clear data, for some as yet undiscovered reason this option leaves the app in an inconsistent state. First of all the network call to the capabilities is not working. We get the following error: javax.net.ssl.SSLHandshakeException: com.owncloud.android.lib.common.network.CertificateCombinedException.
This causes us to not have Spaces and therefore does not detect that we are in an OCIS account.
The capabilities request has been reviewed and both when we receive an ok and when we receive an error, the request is the same:
Request{method=GET, url=https://ip/ocs/v2.php/cloud/capabilities?format=json, headers=[OCS-APIREQUEST:true]}
. The call header is also the same.
Behaviour when logging in for the first time:
In this flow we have no associated account, therefore when in the Main.app
enters the isFirstRun()
validation the code enters this flow.
Behaviour when pressing clear data:
When the account is not deleted, it tries to perform a normal flow but the capabilities fail and I think this is what triggers the inconsistency of the application.
Regarding this inconsistency, when we click on clear data, a Shares folder appears that we have not created. We receive this folder when we make the ReadRemoteFolderOperation
call. The request is as follows:Request{method=GET, url=https://ip/remote.php/dav/files/admin/}
. As it is an OCIS account we should receive a spaceId, but everything related to spaces we get null because the capabilities don't work. The spaceWebDavUrl is null so it makes the construction of the request as I have shown above and not as it should be, something similar to this: Request{method=GET, url=https://ip/dav/spaces/1c4ed431-2ca6-4694-ab1f-d2711c3b6bd3$c0f2eda5-c9fc-4435-b379-a00e496d4833/}
.
To sum up, I have failed to see what is causing this inconsistency. At this point I propose to delete the account when we do the clear data so that it does a base login.
After the above investigation, it has been decided to clear the application's accounts when the user clicks on Clear data button.
In order for the application to internally know that the Clear data button has been pressed, a Shared Preferences
called PREFERENCE_CLEAR_DATA_ALREADY_TRIGGERED
has been created. This variable will be given a value in the FileDisplayActivity
, if it has no value it indicates that the preferences have been cleared, therefore a Clear data has been made.
In the same way, the change of version of the application has been controlled in the Clear data condition, as it could be the case that if a user upgrades to a new version, in this new version, the Clear data preference will still not exist in this flow and therefore the accounts will be deleted. This is why the version change has been managed.
EPIC:
Actual behaviour
When going to the device Settings > Apps > ownCloud > Storage > Manage storage/Clear data, a screen of our own is opened with a button that says "Clear data". Pressing it lets the app and its database in a weird and inconsistent state (a new folder /Shares is created, spaces ID are removed from the files...), which leads to unexpected behaviours.
Expected behaviour
The usual behaviour here is removing all the data from the app, letting the OS take care of it. The key here is, if we currently remove
ManageSpaceActivity.java
and theandroid:manageSpaceActivity="com.owncloud.android.ui.activity.ManageSpaceActivity"
property from the Android Manifest, the OS takes care of clearing the data but the strange status continues happening. So, there is something in the logic of our app that makes it put itself into this inconsistent status, that's what we have to research here.Steps to reproduce
Can this problem be reproduced with the official owncloud server? (url: https://demo.owncloud.org, user: test, password: test) Yes, this seems to be a problem related to the app itself so the server shouldn't affect.
Environment data
Android version: 9
Device model: Samsung Galaxy S9
Stock or customized system: Stock
ownCloud app version: 4.1.1
ownCloud server version: doesn't mind here