ah, new “unsupported” dialog. Introduced with Issue 178: Show alert dialog for unsupported apps (!115) · Merge requests · e / os / App Lounge · GitLab - checkUnsupportedApplication() was looking for if
(!fusedApp.isFree && fusedApp.price.isBlank()) and changed later to (!fusedApp.filterLevel.isUnFiltered())
I think you @luc_pcm run on newer app-lounge code than @aibd - and isUnFiltered() is tripping up on the App. Maybe worth a bugrep if it should not be filtered
Thank you Aibd, unfortunately, i believe tcl offers this functionality only with the application (no web app).
my way of thinking in this is - the filter function is doing what it is supposed to do but is overly strict. TCL ticket seems to have paid functions (well, transport tickets), but is not a paid app.
I really haven’t looked into all details of what the Code tries to achieve (isFree / price.isBlank) vs isUnFiltered - maybe you can go in more depth and report back?
This explanation sounds good, because you are wright we can purchase the ticket directly on the app.
I will try to look at the code to precise the report, but I am a basic user, I don’t even know if I will be able to read it 
.
Is there a documentation or something to start ?
documentation for this is the merge request and its discussion, commit messages and function headers - probably the latter explain most. See the introduced enumeration for filtered apps that explains why “N/A” would be shown - https://gitlab.e.foundation/e/os/apps/-/commit/030e8f46d2a5a137af60c8341fafcc4dfd0319d1?merge_request_iid=161
if we detect that the app is not downloadable for a region, we use [UI] level filter
this is what you see with N/A
now I’m unsure if the geo-restriction is enforced by the google-play remote and would otherwise be unexplained to the user why it is failing (so better show N/A) or it has legal reasons to not circumvent them, the MR doesn’t explain the reason, some issue links are internal.
Ok so some restriction on the App makes it unavailble for users and this restriction could be lifted for the app
Thank you for your help !
but if the geo-restriction is enforced by the remote (Google Play), the code wouldn’t be able to do something about it but better warn the user. I think the georestriction hinges on the google account that you got assigned from a pool.
I think you could try to log out (in the App Lounge Settings) and relogin (and again possibly) until the app is offered to you?
Perhaps a stupid question but if the issue is that the apps is geo-restricted… Did you have enabled hide-ip function for advanced privacy which coule make you appear in another country?
Your are wright : my position was fake, my ip adresse also, and trackers blocked in app Lounge (default settings)
I’ve all turned to enabled,but the result is still the same
Ok thank you for the tips.
I relog out and signed in one time with my real google account,and with an other randomly attributed and each time it fails ! (And also on aurora store to compare)
I try also tried with my old smartphone [honor 9 lite - android 9] (connection on aurora store with the same google account) this time it works.
As the version is the same (v4.1.1(41)), I guess wether the issue come from a phone setting whether form the android version ?
So some more information, i looked up to the app description. Thé description is quite similar. The last update for both of them is on 25/11/2022
There is juste the config file which seems to be a bit diffrent (on x in the name and some kB of diffrence). May be because of the android version ? Can it be responsible ?
As the description also list some phone on which the app doesn’t work, it may also come form there ? (The NFC is availab’e and the FP4 is not on the list,but maybe it should be ? 
)
(config file difference is fine, that’s a profile for the devices screen resolution)
It was easy to debug cleanapk responses, as the api was quite simple and required no auth.
To see the google play server response for the tcl eticket app would maybe explain why it is filtered. I guess the app-lounge developers have something setup for themselves to debug and make sense of a response.
You mean a bugreport file or something even different, specific for the App Lounge ?
Are you able to download the app on, say, a PC then copy the .apk to the phone and have it installed by your browser or whatever?
This might side step App Lounge “selective” behaviour.
I mean to know more than the App interface tells, one needs to query with play-api utilities to get a raw response to step through/compare textually, see the aurora credits for projects that can do this or use gplayapi itself - README.md · master · Aurora OSS / GPlayApi · GitLab
Reading again the merge description, contrary to what I thought (“hinges on the google account”), ip country location seems to be a criteria. See their “test procedure” to clear app-lounge caches when changing network/ip.
In what country is ipinfo.io placing you when you test? maybe you should add this to the gitlab issue.
If your IP is shown as being a french network and the App is not listed, then it qualifies as bug.
btw - for me the tcl-e-ticket App is filtered at the DATA level (german ip) → not shown at all in the listing, while for you it was filtered at the UI level → shown, but with N/A button
the logic to decide all this is at getAppFilterLevel()
Ok thank you very much, my ip seems to locate me at the real location .
Not listed +bfrench network ->qualify as bug
Okay I am sorry, I think the app is not compatible with the FP4
tcl e-ticket app assistance
In the question related to the compatibility section :
"Is my phone compatible with the TCL E-Ticket app?
The TCL E-Ticket application is compatible with an Android mobile phone, version 5 or higher, with an NFC chip, except for the Nexus 5X and 5, Pixel 2, 2XL, XL, 3, 3a, 3a XL, 3XL, 4, 4a, 4XL, Asus Z00A, Z00A_1, Z00A_3, Fairphone4 FP4, Motorola Nexus 6, moto g pro, Vivo V2066"
Should I close the issue on the gitlab ?
Leaving your final explanation will surely help others before you close. Maybe app-lounge can have a helptext with hints. I wouldnt have guessed its due to NFC chip incompatability
