TS(TestSet): FAIL: Create first profile after install service and rs-mobile

[obrasero]

TC(TestCase): FAIL: Device: ZTE Blade A5 2019 (mobile) • android-arm • Android 9 (API 28)

apks

• Buildsystem: Windows: howto flutter/android studio #30 (comment)
• service: RetroShare_Android_Service-alpha-arm.apk at 05.08.
• rs-mobile: app-release.apk build(avin) at 05.08.

Steps: Create the first profile after install

1. OK: Copied both apks to the download section of mobile
2. OK: In Download click Service and install
3. OK: in Doenload click app-release.apk and install
4. OK: in Apps find "R": click service app
   4.1. => show with START-Button
5. OK: click START
   5.1. => shows STOP button
6. OK: in Apps find "R": click rs mobile
   6.1. => FAIL: shows entry view to create profile
   • => {instead it shows Can' connect...}
7. OK: in Apps find "R": click service app
   7.1 => FAIL: show still STOP
   • => {instead it shows START; the service got shut down as mosty - by crash or other reasoen i dont know}

[Kumaravinash9]

There is some problem with retroshare service.

[obrasero]

So i just did the above but now by debugging in as.

• OK:service started
• OK:Debug rs-mobile
• OK: clienz got installed on mobile and started within start window.
• OK: typed in the data to creater a first profile
• OK: pushed: create it
  1. => AS-debugger running a while through the code than a Socket-Exception appeard
  2. => checking the state of the service in mobile: stoped.

Taken over in mine: #31 to debug on this state allready.

---

crashing request: (cause: connection refused)(as service is downed)
the request exception gets not handled in:
requestAccountCreation
only response code return gets handled at account.dart l99
resulting in just client close
which than lastly phenomenological for the user results into a rs-client
endless cycling the processing wheel with no other reaction by the user on it possible: user view hanging.
exception = {SocketException} SocketException: OS Error: Connection refused, errno = 111, address = localhost, port = 50266
request = {Request} POST http://localhost:9092/rsLoginHelper/createLocationV2
method = "POST"
url = {_SimpleUri} http://localhost:9092/rsLoginHelper/createLocationV2
_contentLength = null
_persistentConnection = true
_followRedirects = true
_maxRedirects = 5
headers = {_CompactLinkedCustomHashMap} {content-type: text/plain; charset=utf-8}
_index = {_Uint32List} size = 8
_hashMask = 268435455
_data = {_List} size = 8
_usedData = 2
_deletedKeys = 0
_equality = {_Closure} Closure: (String, String) => bool
_hasher = {_Closure} Closure: (String) => int
_validKey = {_Closure} Closure: (dynamic) => bool from Function 'test':.
_finalized = true
_defaultEncoding = {Utf8Codec}
_bodyBytes = {_Uint8List} size = 87
this = {IOClient}
stream = {ByteStream}

[Kumaravinash9]

If this is throwing you socket exception than it is the problem with retroshare service. because the UI part seems good to me.

[obrasero]

yes in one way of view:

• the service should not crash/shutdown unawaited.
  but the question could be:
• is the service godown caused by its alone only because of he has to process requests
• or may it be that he goes down caused by delivered in any way invalid requests before this connection refused request.

what do i need in my build system to build and debug the service itself?

and aside from this, debugging the code is making me slowly but definitly more familiar with the rs-mobile and flutter-dart code. so in any way at least a win to me ;)

---

Another thing:
i think the client rs-mobile should, if not restarting the service by its own, at least allways tell the poore user what happens and how he can get it again into life.
But as long as the service goes down in common cases this is not helping as it is not realy usable.
so we will have to find out what to fix in this.
maybe i have luck and my doings give the team the right idea, or?

[obrasero]

@Kumaravinash9
ok. i listed above now the complete rquest and the reaction in the callstack upwards until user view.
maybe it gives a hint.

[obrasero]

do you now how a naive flutter-as beginner can setup an environment to debug the service itself? to get an idea why he socket refuses?

[defnax]

maybe some one know more about this issue @G10h4ck @sehraf @selankon @b1rdG

[selankon]

Hey!

I saw in your exception this:

 exception = {SocketException} SocketException: OS Error: Connection refused, errno = 111, address = localhost, port = 50266

Seem that is trying to connect to the port 50266, usually RS service run on 9092. But then at the POST operation you are pointing correctly the port 9092.

Some tricks:

To debug RetroShare on the phone you can use:

adb logcat | grep -i retro

Also you can do curl calls from the computer via adb using, this can help you to debug:

adb forward tcp:9091 tcp:9092
curl -u http://127.0.0.1:9091/RsJsonApi/version -vv

Try to debug further and paste the results

And about that:

i think the client rs-mobile should, if not restarting the service by its own, at least allways tell the poore user what happens and how he can get it again into life.

We resolve it here.

[obrasero]

@selankon
To debug RetroShare on the phone

I debug it with android studio on the phone.

Ok, tomorrow i will again debug it step by step.

We resolve it here.

As i understood, this is up to restart the downed service automatic again:OK
In my tests the service most time goes down, nearly every action with rs-mobile lets the service randomly go down. Sometimes the action works without going him down bust lot more than sporadic it goes down.

Are you aware or do you know that the service stay active in the background an endless time if no rs-mobile is active/installed also if you work with other apps in the phone meanwhile.
I documented this with Test: #33
So by my tests it seems always any "side-effect" between the service and the rs-mobile which forces the service down happen.

[selankon]

I debug it with android studio on the phone.

Yes but you are debugging the flutter app, not the retroshare service, youshould know why RS service fall if its falling.

To mantain a service up, on android, you will need to run this service as a foreground application, using an android notification to mantain it up.

On elrepo.io, we bundle the retroshare service apk on the flutter app and make it runing as foreground application. I think you will find how to do it on the issue i quoted. Otherwhise ask me of how to do this process.

If you dont do that, androidOS will set the service in idle status or something similar after a while, stopping RS servic until focus.

https://developer.android.com/guide/components/foreground-services

[Kumaravinash9]

I debug it with android studio on the phone.

Yes but you are debugging the flutter app, not the retroshare service, youshould know why RS service fall if its falling.

To mantain a service up, on android, you will need to run this service as a foreground application, using an android notification to mantain it up.

On elrepo.io, we bundle the retroshare service apk on the flutter app and make it runing as foreground application. I think you will find how to do it on the issue i quoted. Otherwhise ask me of how to do this process.

If you dont do that, androidOS will set the service in idle status or something similar after a while, stopping RS servic until focus.

https://developer.android.com/guide/components/foreground-services

Hii @selankon ,
Actually the problem with the retroshare service.Not with the retroshare mobile UI. I have tested it many times. One more help I need from your side that can you help me to create a new retroshare service mobile apk through retroshare repo.

[Kumaravinash9]

Could you please send me the proper steps how to compile the new retroshare service apk. Thanks

[obrasero]

Could you please send me the proper steps how to compile the new retroshare service apk. Thanks

Yes, as is asked above also "do you now how ... can setup an environment to debug the service itself?" that would be very good/helpfull.