Chat for meisa

[Jean-BaptisteC]

Hi @PatDyn

I have create this discussion to answer at your question on Exodus project :)

To answer at your question ask on IRC:

• First, what is your preferred mode of development on the app? E.g. do you need write access to the pull request branches? Or would it be possible to get push access to the repo?
  • I prefere you push commits on your fork and after create pulls requests foreach bugs fixed
• Did you follow any of the popular architectural patterns for android? Like MVC, MVP, MVVM etc?
  • On project, we used MVVM architectural
• Access to Google Play Console?
  • We can give you access to Google Play Console to get more logs if necessary but i try to give more details
• I'm not able to reproduce bug 238 -> check issue Native method - android.os.MessageQueue.nativePollOnce : Input dispatching timed out #238, i have give more details (if you can't find reason of crash, no problem, fix another bug)
• To reproduce Download reports and trackers doesn't start #201, build with enable optimizations in build.gradle (add this https://github.com/Exodus-Privacy/exodus-android-app/blob/196c2f5ec66c9c5bf5c63b4fe7f33837bb781e67/app/build.gradle#LL31C3-L34C3 on build.gradle -> build app and start app)

[PatDyn]

Hi @Jean-BaptisteC

Thank you for the answers! :)

A few Infos from our side:
We forked the exodus-android-app repository here: https://github.com/DomainDrivenArchitecture/exodus-android-app
We set up projects for the first two issues here: https://github.com/orgs/DomainDrivenArchitecture/projects

On Friday we will follow up with a status report.

[PatDyn]

* Access to Google Play Console?
  
  * We can give you access to Google Play Console to get more logs if necessary but i try to give more details

Access to the GP Console would help us understand the roots of the problem more quickly.
Thus less time will be spent on trial and error for this and any future issue :)

[Jean-BaptisteC]

We can see to give you access but logs is not enough explicit to help on #238

[Jean-BaptisteC]

If i give you all logs from Google Play for this crash (logs foreach thread on different devices), that help you ?

[PatDyn]

I think that might help me - although i would need them in some ordered way split by device or so.

[Jean-BaptisteC]

Somes logs for Native method - android.os.MessageQueue.nativePollOnce
Input dispatching timed out
stacktrace OnePlus 7T Pro 5G - SDK30.log
stacktrace Redmi Note 10 Pro -SDK31.log
stacktrace realme RMX2020 - SDK29.log
stacktrace Galaxy A33 5G - SDK33.log

[PatDyn]

* To reproduce [Download reports and trackers doesn't start #201](https://github.com/Exodus-Privacy/exodus-android-app/issues/201), build with enable optimizations in build.gradle (add this https://github.com/Exodus-Privacy/exodus-android-app/blob/196c2f5ec66c9c5bf5c63b4fe7f33837bb781e67/app/build.gradle#LL31C3-L34C3 on build.gradle -> build app and start app)

That is exactly what i did :) In two ways:

1. Copy 'n paste the build optimizations, build and run on the up to date code base
   1. This way the App does start without crashes and does download tracker infos.
2. Go back in git history to commit 196c2f5, build and run
   1. This way the App starts, but the download of tracker info seems to lag. This might be a hint, although logcat does not show any related errors.

I tested this on:
A Galaxy S5 running Android 11 without Google Services and an Android Virtual Device (Pixel 4) running Android 13 and Android 7 both with Google Services.

[Jean-BaptisteC]

I have forgotten to tell you
You need to build a release, to reproduce crash
You can generate a key on Android Studio to build signed release

[Jean-BaptisteC]

Can you check others bugs and tell me if you have need more information or logs from Google Play ?
Because i go to travel next 2 weeks

[Jean-BaptisteC]

#201 For this issue you need to build release with optimizations enabled in build config
#244 I can't give you more logs, Google Play don't have more explicitly logs, to fix this bug, you need to add a control to check if phone => API 30 and ignore battery optimizations to execute foreground service in background (more informations in issue)
#181 In this case app crash because, we store apps icon in database and in somes cases icons is too big and database have a limit size, we need to find a solution (reduce size of icon in database or store icons in other place)

Please check each issue, i try to give more information as possible :)

[PatDyn]

Hi @Jean-BaptisteC,
About Issue 260 and 264, it seems that the packageManager Operations would need to be moved off the main thread. This has some implications, i'll try to summarize them here:

Options:

• 1. most thorough but most time consuming (probably more than one day):
  • Refactoring to repository pattern as with ExodusAPIRepository
  • Testability would be given
  • but changes in more than one place would be necessary
• 2. less thorough as we do not strictly follow pattern:
  • implementation inside PackageManagerModule (PMM)
  • testability unclear as of now
  • changes only in PMM
• 3. patches only:
  • do not implement at all and try to work around
  • might be quick, but may not fully solve the problem
  • limited testability should be given
  • more try/catch blocks in the PMM code

I already did a little patching here: bacee48

But for everything else, i'd like to know your Opinion.

[Jean-BaptisteC]

If i understand, we have ANR because main thread is too busy with all tasks ? (download reports and trackers, save in database and get information from PMM) And like somes tasks take too time, some processus generate timeout ?

I prefere first solution, to have same patterns everywhere in app. In first solution, you use dispatcher ?
Use multiple thread, improve performance ? But what about consumption battery ?

[PatDyn]

The app should do less work on its main thread now. We moved network operations to co routines here: #254 and database operations too in this PR: #257
The ANR is likely happening on phones with a lot of apps, so a lot of calls to the PackageManager are done.
bacee48 should have mitigated that a bit.

In the first solution i would use kotlin coroutines/dispatchers. It could improve performance, if we do some async work. Battery life could be impacted a little bit by this, but that could also be offset by faster operations. However, i'm not sure if i can get it to work within a reasonable time frame. As is said, it might cost more than a working day to get the refactorings done and well tested. (My guess is two to three days).

[Jean-BaptisteC]

Ok, no problem, if it's take 3 days

[Jean-BaptisteC]

I have execute unit tests with latest dependencies
Latest coroutines broke test, you can find log here #237
Latest com.google.material broke permission subfragment, in this case, only first permission is show, to see all permission users need to click on first expand
And if we have enough time, i suggest to migrate to Gradle 8.0