Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] "Clear data" button malfunctioning #4309

Closed
JuancaG05 opened this issue Feb 12, 2024 · 2 comments · Fixed by #4350
Closed

[BUG] "Clear data" button malfunctioning #4309

JuancaG05 opened this issue Feb 12, 2024 · 2 comments · Fixed by #4350

Comments

@JuancaG05
Copy link
Collaborator

JuancaG05 commented Feb 12, 2024

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 the android: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

  1. Go to device Settings > ownCloud > Storage > Manage storage/Clear data
  2. Press the button "Clear data" from our screen
  3. Notice the strange status when the app is opened again (a /Shares folder appears in root in Personal space, deep links are not working...)

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

@Aitorbp
Copy link
Contributor

Aitorbp commented Mar 13, 2024

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.

@Aitorbp Aitorbp linked a pull request Mar 19, 2024 that will close this issue
2 tasks
@Aitorbp Aitorbp linked a pull request Mar 26, 2024 that will close this issue
3 tasks
@Aitorbp
Copy link
Contributor

Aitorbp commented Apr 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment