Issues with new android build #3569
Comments
|
Thanks for bringing this up! For now, let’s hold off on releasing the new version until we’ve fully resolved this issue. I’ll work on verifying the problem and try to fix it as soon as possible. Also, thank you for your thorough testing, and I appreciate your efforts to test it further. (You can assign this bug to me) |
|
As a related question: Would it be alright to remove the or am I overlooking something? As an update for the issue: I don't understand why but running on a different emulator (Pixel 6, API 30) does not resolve the issue on that particular device, but the error persists. |
|
I tested the upgrade from the old version to the new one on both a Xiaomi 14 Pro and a Pixel 8 emulator, following the same steps, but I couldn’t reproduce the issue. In the old version, I specifically enabled WebDAV and confirmed via the Console that the Service Worker was loaded. After upgrading to the new version, I verified that the app was using the compatible URL (https://app.super-productivity.com), just like in your screenshots.
From the logs and screenshots, it appears that the compatible solution (https://app.super-productivity.com) is being loaded, but the issue might be related to a JavaScript parsing error, potentially caused by caching. Since you’re upgrading from an older version, could you provide details about the exact version you upgraded from, what actions you took, and the steps after the upgrade? Having a complete reproduction flow would help me track down the issue more effectively. Just to add, I tested this in both 5G and WiFi environments, and there were no network-related issues on my end. |
|
I also wanted to share the steps I followed during my testing:
I’ll try using a Release build later, but I assume the result will be similar. Could you check if these steps align with yours? |
|
Regarding your question about removing the isDebugBuild condition from config.gradle, my understanding is that this issue might not be directly related to that code. Here’s why:
That said, to be thorough, could you double-check the code changes just to ensure nothing else was unintentionally modified? It’s currently midnight here, so I’ll take a closer look at it tomorrow morning. Also, feel free to provide any additional reproduction details and logs. It would help us narrow down the issue more effectively.
|
|
Maybe we can try a different approach. Could you generate the FDroid Release APK (since you have the signing certificate, you’d need to generate it yourself) and then test it against the previous FDroid installation package? This way, we can at least confirm whether the final user-facing APK has the same issue. If the final release package works fine and only the testing builds have the issue, I personally think we can proceed with the release. We can then analyze the issue in the test builds afterward. This would ensure stability for end users while still allowing us to continue investigating. What do you think? （One more thing: I suggest not using npm run buildFrontend:stageWeb:unminified to generate the release package, as this command is mainly for generating debug-related builds. I’ve been using npm run dist:android:prod to create, so you might want to try that as a reference.） |
|
So I spend quite some time digging into this. The error has nothing to do with the changes you made, but depends on the webkit version. This interestingly seems to be completely independent from the android SDK version. My pixel 4 emulator with SDK29 had a newer webkit version than my pixel 6 emulator with SDK30. So it's a web frontend issue :) Sorry for bothering you with this!! Do you have by chance any knowledge of the market share of different webkit versions? ChatGPT says:
If this is true this sounds like we should be fine for the most part and can just continue with the release. What do you think? |
|
I’m glad we’ve pinpointed the root cause. Trues be told, when I was reviewing the Logcat logs yesterday, I noticed these lines:
Given my dev experience with mobile browsers, I suspected it could be a JSC/V8 version issue, especially since Chrome 61 is quite old (released in September 2017), that the underlying V8 engine in this version doesn’t support the newer JavaScript features introduced in ES2022. However, since you mentioned the issue occurred after upgrading from an older version, I initially thought the older version was working fine and didn’t consider the WebKit angle further.Next time, I’ll be sure to include all potential causes—sorry for overlooking this! In my experience working on large-scale apps, we have two main options:
That said, bundling Chromium isn’t really suitable for our project, so I’d strongly recommend focusing on Babel for compatibility. Regarding WebKit version distribution, I don’t have recent global data (my latest is from 2019), and I’m more familiar with the Chinese market. However, I believe Babel transpilation should be sufficient to cover most cases. Lastly, since WebView updates are now independent on most devices, I don’t think this will block the release. We can address the compatibility issue with Babel in future iterations. What do you think? 😄 |
|
I agree with you. I added support for a bit older browser engines (chrome 83, which came out in 2020). I think most android users should have a newer version installed anyway, so maybe in the future we can ditch this completely. I will try to make a new release now so we can test this out! |
|
Sounds good! Looking forward to testing the new release. |
|
I made a release for 10% of the android users just now. Fingers crossed that all goes well! :) |
|
To be honest, currently these 10% or more users are only using the compatibility mode. The real challenge lies with those new users who will directly use the brand new Connectivity-Free mode. Let's keep praying for continuous smoothness! 🚀 |
Hey @jiongxuan ! I encountered some issues with the new build and was hoping you could help. After merging all the PRs and the repositories I did the following:
npm run buildFrontend:stageWeb:unminified && npx cap syncapp_config.properties. The old version of the app was present with some data.This resulted in the errors bellow.
I can reliably reproduce this for every restart and re-deployment of the app.
I had the suspicion that this has to do something with the previously installed service workers but uninstalling them as well as deleting all the data from
chrome://inspect/#deviceshas no effect.The issue is fixed by deploying and running the app once with
LAUNCH_MODE=2andONLINE_SERVICE_IS_LOCAL=false. After that I can run the app with the default settings and all works fine.Any clues what might cause that? Do you think this would affect users when deploying a new android app?
Devtools:
Logcat:
The text was updated successfully, but these errors were encountered: