Android: [RELEASE] 2.14

Created on 18 Nov 2019  路  23Comments  路  Source: owncloud/android

TASKS:

  • [x] [COM] Ping marketing guys
  • [x] [GIT] Create branch release_1.0.4 in owncloud/android-library from master
  • [x] [GIT] Create branch release_2.14 in owncloud/android from master
  • [x] [DEV] Update version number and name in build.gradle in owncloudComLibrary module
  • [x] [DEV] Update version number and name in build.gradle in owncloudApp module
  • [x] [DIS] Create changelog file (< 500 chars) and add to CHANGELOG.md in owncloud/android
  • [x] [DEV] Add new wizard steps:

    • [x] End of support for <10 servers

    • [x] End of support for <5 Android devices

  • [x] [QA] Design Test plan
  • [x] [QA] Regression Test plan [WIP]
  • [x] [DIS] Generate test APK file from release_2.14 branch in owncloud/android
  • [x] [GIT] Create and sign tag oc-android-2.14 in HEAD commit of release_2.14 branch, in owncloud/android
  • [x] [GIT] Create and sign tag 1.0.4 in HEAD commit of release_1.0.4 branch, in owncloud/android
  • [x] [DIS] Generate final APKs from signed commit in owncloud/android
  • [x] [QA] Perform some minor tests in the final apk, including an update from previous version.
  • [x] [DIS] Create new release on Github Android repository
  • [x] [DIS] Upload & publish release APK and changelog in Play Store
  • [x] [DIS] Update screenshots and store listing, if needed, in Play Store
  • [x] [GIT] Merge branch release_1.0.4 in owncloud/android-library, into master
  • [x] [GIT] Merge branch release_2.14 in owncloud/android, into master
  • [x] [SPREAD THE WORD] Write topic in central about the new release
  • [x] [COM] Ping marketing guys to write the blogpost
  • [x] [GIT] merge release_1.0.4 branch into stable, in owncloud/android-library
  • [x] [GIT] merge release_2.14 branch tag into stable, in owncloud/android
  • [x] [DOC] Update owncloud.org/download version numbers (notify rocketchat #marketing)

Release communication (and wizard steps):

  • [x] Announce deprecation of Android 4.4 (https://github.com/owncloud/android/issues/2738)
  • [x] Announce stop supporting <10 servers (https://github.com/owncloud/android/issues/2636)

Regression test:

https://github.com/owncloud/QA/blob/master/Mobile/Android/Release_2.14.0/Regression_2.14.md

BUGS & IMPROVEMENTS

PRs:

Estimation - 5 (L) Release

All 23 comments

(2) [FIXED]

Logs from logcat are duplicated.

  1. Open the app
  2. Generate some logs by performing some actions
  3. Open Settings -> Logs -> Logcats

Current: Duplicated logs
Expected: Every log appears once

Nexus 5X v8

Interesting, in my version I don't have duplicated entries. (I use a Pixel 2 Android Q)
Additional I don't have a Nexus 5X.

Maybe you can run my version on a Nexus 5X too.
If with this version there are duplicated too, then it's located to the device.
If not, it's probably your apk. My apk is at least public !

My apk is at least public !

Yeah, thats a disadvantage of the bitrise.io CI we're using for a while. I'd love to have the CI errors and builds public available. @jesmrec Could you post the link to the "Public install page" manually?

@hannesa2 Send me your mail, I'd love to invite you to the bitrise project.

@michaelstingl you see it in commits author.
Btw, I see a lot of disadvantages with bitrise. I can't improve/test it with a pull request and it's no more public.

I will stay will Travis, and yes: with x86 tests with Travis.
With Travis I can publish any intermediate release too.

We worked with Travis for long time. Disadvantages of Travis from our side:

  • Long queues to execute the jobs: oC account to support many repos, and waiting times usually took many hours and sometimes more than two days to execute the jobs.
  • Timeouts in test execution. For a small set of unit tests is OK. When you have a large set of instrumented tests, execution became even slower and leading to internal timeouts. Unaffordable.

For these main reasons, the team decided to move to another tool. BitRise has also itsown inconvenients (mainly reagarding UI tests), that we are working to fix from our side in several PRs you will find in the list. Currently tests are passing in BitRise, but there are some concerns to agree, in which it is interesting to get more info, like the one i ask you here: https://github.com/owncloud/android/pull/2737#issuecomment-559785273

We can check if BR allows to make public the final artifacts, if it is really interesting for the community.

Finally, this thread is for the Release 2.14. If you want to comment/discuss other stuff, please use a different issue. Thanks.

2746 I found the twice logs

thanks, i will check.

I can't improve/test it with a pull request

Related? https://devcenter.bitrise.io/tips-and-tricks/use-bitrise-yml-from-repository/

(4) [FIXED]

  1. Set a low qouta in the Users panel, f. ex 30MB
  2. Create a folder in root, and upload inside several files which size exceeds the quota

Current: Files starts to uploads, and finally appears as uploaded (they aren't really). If you browse in the containing folder (created in 2.), app crashes.

Expected: Files are not uploaded with a correct error, due to lack of space.

Xiaomi MiA9 v9

NOTE: This problem is already in 2.13.1, so it is not a regression. It is a nice to have since crashes are not desirable.

(5) [WONT FIX]

  1. Share by link a file/folder that is not in root folder
  2. Open "Shared by link" section in the drawer
  3. Long press on the recent shared item and select share icon on toolbar
  4. Remove the share link created in 1.

Current: Item is not removed from the list
Expected: Item removed from the list, because the link was removed.

The difference here is the location of the file/folder. If it is located in root folder, it is removed from the list after removing the link.

Xiaomi MiA2 v9

(5)
Share by link a file/folder that is not in root folder
Open "Shared by link" section in the drawer
Long press on the recent shared item and select share icon on toolbar
Remove the share link created in 1.

This is related to https://github.com/owncloud/android/pull/2705#issuecomment-561141380.

When performing the steps you describe, the share is properly removed but the file/folder is not synchronized in "Shared by link" view so still has the shared flag enabled; to make it disappear we would need to discover it (browse to it) using the "All files" view.

It's not a good behaviour but I think there's nothing we can do without synchronizing the whole files tree

Thanks for the explanation... it's a feature not a bug :D. Will mark as won't fix

(6) [FIXED]

  1. In web UI disable "Allow resharing" capability
  2. In app, user1 shares something with user2
  3. User2 tries to reshare

Current: When long pressing the item in user2's list, the option share is enabled in the toolbar
2.13.1: When long pressing the item in user2's list, the option share is not enabled in toolbar, because such content is not allowed to be reshared.

Nexus 6P v7
10.3.1

(4)

  1. Set a low qouta in the Users panel, f. ex 30MB
  2. Create a folder in root, and upload inside several files which size exceeds the quota

Current: Files starts to uploads, and finally appears as uploaded (they aren't really). If you browse in the containing folder (created in 2.), app crashes.

Expected: Files are not uploaded with a correct error, due to lack of space.

Xiaomi MiA9 v9

NOTE: This problem is already in 2.13.1, so it is not a regression. It is a nice to have since crashes are not desirable.

I've fixed the crash but the files will be first uploaded and removed later, that's the app behaviour for a long time. To avoid the upload we would need extra effort (perform an extra operation to check the available space since I'm not sure the upload operation itself retrieves that kind of information). Anyway, should be addressed in a separate issue, not as a part of this release.

I've fixed the crash but the files will be first uploaded and removed later, that's the app behaviour for a long time. To avoid the upload we would need extra effort (perform an extra operation to check the available space since I'm not sure the upload operation itself retrieves that kind of information). Anyway, should be addressed in a separate issue, not as a part of this release.

not a problem. If the bug itself is not a regression, the behaviour you describe is even older. The point is, that after performing the action, the app is consistent with the final result. Maybe more desirable to avoid the uploads (saving time and bandwidth), but as you said, this is a separate feature. Fixing the crash is more than enough here.

(7) [WONT FIX HERE]

  1. User1 shares a folder with User2, with no "create" permission
  2. User2 uploads a file inside the shared folder

Current: File starts to uploads. Finally, in uploads view appears as completed. But, file is not in the file list.
2.13.1: Error in uploads view: Permissions error.

Nexus 6P v7

(7)

  1. User1 shares a folder with User2, with no "create" permission
  2. User2 uploads a file inside the shared folder

Current: File starts to uploads. Finally, in uploads view appears as completed. But, file is not in the file list.
2.13.1: Error in uploads view: Permissions error.

Nexus 6P v7

I've just noticed this behaviour in 2.13.1:

  • Files smaller than 1MB (non chunked upload): upload fails with permission error.
  • Files bigger than 1MB (chunked upload): upload is completed and appears in uploads view. After this, there's a crash when browsing the shared folder.

In 2.14 the behaviour is the same except there's no crash when browsing to the shared folder. So I would say is not a regression, we could address it along with synchronization within new architecture

(8) [FIXED]

  1. Introduce an account (Account 1) from a server, long press a file and select share option to see the shares.
  2. Introduce an account from a different server (Account 2), long press a file and select share option to see the shares.

Current: in mitmproxy you will see that the query performed in the step 2 is made with the Account 1 credentials.
Expected: step 2 should use Account 2 credentials.

Nexus 5X v8.1.0

In 2.14 the behaviour is the same except there's no crash when browsing to the shared folder. So I would say is not a regression, we could address it along with synchronization within new architecture

Could you create a new issue and point it from the architecture epic out?

Regression stage finished with everything fixed. Let's go with the upgrade tests

Checks :

  • [x] Upgrade from 2.13.1
  • [x] Upgrade wizard
  • [x] Smoke test over the upgraded (special attention to sharing)

(9) [FIXED]

  1. Install 2.13.1 (release apk)
  2. Add an account
  3. Upgrade to 2.14
  4. Select any item by long pressing and select "Share" icon

Current: app crashes
Expected: list of shares

Samsung S9 v9, Nexus 5X v8, Nexus 6P v7
commit 42eb9f1e

Upgrading problem is fixed. So, testing tasks are done and the 2.14 version is ready to release.

Great job, team!!!

Was this page helpful?
0 / 5 - 0 ratings