Below are my findings on the BOINC projects list for Android client.
Done from memory.
I wished I could re-edit the post later on to correct any errors (Moderators, would this be possible to extend edit time on this to a few days?).

Green: working (no modification necessary in the list or in Boinc MGR):
- Asteroids
- Collatz Conjecture
- Einstein
- Moo! Wrapper
- PrimeGrid
- Universe (also has work for Android 10 devices)
- Yoyo

Olive: Working, but will need list update soon:
- Seti (project will go down on 3/31/2020)

Orange: Listed as working, and visible in MGR, but no tasks available to test if it's really working:
- Rosetta

Brown: Not listed as working, though visible in MGR, but no tasks available to verify if it's working
Project doesn't warn of incompatibility, and project should not be visible in MGR:
- BOINC@TACC
- CAS
- DENIS
- Gerasim
- GPUGrid.net
- Nanohub
- RakeSearch
- ODLK1 & ODLK

Blue: Android is listed as supported, but not visible in MGR:
- LHC
- Quake Catcher Network

Red: Listed as Android compatible, but not working. List needs update:
- World Community Grid (doesn't support ARM processors)

Indigo: Listed, with other issues:
- Radioactive (Supports single board computers, not standard Android devices, due it it needing a radioactive probe that fits on the GPIO pins)

Violet: Not listed as working, Not working, but still visible in Boinc MGR (should not be visible)
- MindModeling
- Milkyway

World Community Grid (WCG) DOES support and currently running on Android ARM - Smash Childhood Cancer tasks.

There was a temporary hiatus on tasks while they were waiting for more data from the science team behind the subprojects origin.

PrimeGrid does NOT run on ARM or Android.
https://www.primegrid.com/apps.php

# Edit to add #
Collatz does NOT run on ARM or Android.
https://boinc.thesonntags.com/collatz/apps.php

Brown: Not listed as working, though visible in MGR, but no tasks available to verify if it's working
Project doesn't warn of incompatibility, and project should not be visible in MGR:
- BOINC@TACC
- CAS
- DENIS
- Gerasim

* DENIS - DEAD PROJECT -- no work and no posts from project owner/scientists for over 1 year, forum spam not being removed. Should be removed from the ACTIVE BOINC project list all together.
- BOINC@TACC - Android & ARM NOT supported https://boinc.tacc.utexas.edu/apps.php.
- CAS - Android & ARM NOT supported http://casathome.ihep.ac.cn/apps.php.
- Gerasim - Android & ARM NOT supported - Windows 64-bit only supported http://gerasim.boinc.ru/users/viewApps.aspx.

Brown: Not listed as working, though visible in MGR, but no tasks available to verify if it's working
Project doesn't warn of incompatibility, and project should not be visible in MGR:
- GPUGrid.net
- Nanohub

- GPUGrid.net - Android & ARM NOT supported - Windows 64-bit, Linux 64-bit AND MUST HAVE NVIDA GPU http://www.gpugrid.net/.
- Nanohub - Android & ARM NOT supported https://boinc.nanohub.org/nanoHUB_at_home/apps.php.

Brown: Not listed as working, though visible in MGR, but no tasks available to verify if it's working
Project doesn't warn of incompatibility, and project should not be visible in MGR:
- RakeSearch
- ODLK1 & ODLK

- RakeSearch - Android & ARM NOT supported https://rake.boincfast.ru/rakesearch/apps.php.
- ODLK / ODLK1 - Android & ARM NOT supported on either project https://boinc.progger.info/odlk/apps.php / https://boinc.multi-pool.info/latinsquares/apps.php.

One of the reasons I made this thread is just to accurately update the list.
I wanted to correct some errors yesterday, after I saw by using boinc bam account manager, that a lot of projects from my bam account on my desktop (x86/64) were imported on the arm boards. Hence the confusion.

This definitely needs to be taken a look at! Bam should not port x86 jobs to managers running on incompatible hardware or software.
If a project doesn't support the CPU architecture, or the operating system, it shouldn't automatically add the project!

The 'Science projects' list on this website and the list in BOINC Manager are both generated from the same source. Named projects are added to the list (on request) by David Anderson. The devices supported by each project are generated automatically from the plan_class names exported by each project.

Having updated the code which generates the 'supported device' icons in BOINC Manager (#2643), I'm pretty sure it's robust. I'm only aware of one false positive - LHC's 'native_theory' and 'native_mt' plan classes falsely trigger the 'ATI supported' flag for the project.

BAM! is an independent third party initiative, not under the control of BOINC. You'll have to take up any issues with them directly.

Below are my findings on the BOINC projects list for Android client.

7.16.5 presently being tested has an Android only listing of Androids, Einstein, LHC, Moo!, Rosetta, Seti, Universe, World Community Grid, Yoyo and the BAM!, Gridrepublic, Science United and GRCPool account managers.

This definitely needs to be taken a look at! Bam should not port x86 jobs to managers running on incompatible hardware or software.

Any problems you have with BAM! you best post at their forums so Willy can take a look at it. BAM!, other than using the BOINC name, is in no way or sense affiliated with BOINC.

The 'Science projects' list on this website and the list in BOINC Manager are both generated from the same source. Named projects are added to the list (on request) by David Anderson. The devices supported by each project are generated automatically from the plan_class names exported by each project.

Having updated the code which generates the 'supported device' icons in BOINC Manager (#2643), I'm pretty sure it's robust. I'm only aware of one false positive - LHC's 'native_theory' and 'native_mt' plan classes falsely trigger the 'ATI supported' flag for the project.

BAM! is an independent third party initiative, not under the control of BOINC. You'll have to take up any issues with them directly.

Bam manager does use BM (Boinc Manager). Boinc Manager is the one that interfaces with BAM.
Sounds to me that either one of them could do it.

Bam manager does use BM (Boinc Manager). Boinc Manager is the one that interfaces with BAM.
Sounds to me that either one of them could do it.

Really? Methinks you need to read Account Management. And remember the role of the client.

Bam manager does use BM (Boinc Manager). Boinc Manager is the one that interfaces with BAM.
Sounds to me that either one of them could do it.

Really? Methinks you need to read Account Management. And remember the role of the client.

Why does Boinc Manager allow BAM to import erroneous projects?
Even if BAM does what it shouldn't, the Manager "aka managing", should refuse the request.
It makes no sense that a third party add-on is able to essentially 'break the system'.
I also don't like to pingpong issues that are clearly supposed to be dealt by manager to other departments.
If BAM is responsible, then so is Manager!
It will be a security flaw, if add-ons accepted by manager, are going to allow for misconfigurations, or worse, could break the system.
It is a Manager issue!

Your understanding falls short of the way shut managers are intended to function, and, in the main, do function.
BAM, along with other BOINC managers, are there to manage the way your client(s) work.
They do not manage the way to projects manage themselves. The projects are independent of each other, and are run by independent groups. The projects send out, or at least are meant to send out, regular status reports; not every project does so, also projects are supposed to "tell the world" when they shut down, again not every project that has shut down has done so.

And remember the role of the client.

Why does Boinc Manager allow BAM to import erroneous projects?
Even if BAM does what it shouldn't, the Manager "aka managing", should refuse the request.

BOINC Manager manages BOINC, the client. It does not manage anything external. BOINC Manager is a graphical user interface that allows you to easily control and manage the BOINC client. Because else you'd all have to do that via command line and [url+https://boinc.berkeley.edu/wiki/Boinccmd_tool]boinccmd tool[/url].

BAM, Gridrepublic, Gridcoin, SU and whatever other account managers there are are websites via which you set which projects you want to run and these communicate that to the BOINC client.

BAM, GR, GC and SU are all independent entities, just as each and every project is its own entity. Any problems you have with the account managers you should report to the account managers as else they can't check if it is their problem or not.

I would appreciate it if you followed the links we point to, so you can read up on how things work, before you point out something that isn't a problem again.

---

And remember the role of the client.

Why does Boinc Manager allow BAM to import erroneous projects?
Even if BAM does what it shouldn't, the Manager "aka managing", should refuse the request.

BOINC Manager manages BOINC, the client. It does not manage anything external. BOINC Manager is a graphical user interface that allows you to easily control and manage the BOINC client. Because else you'd all have to do that via command line and [url+https://boinc.berkeley.edu/wiki/Boinccmd_tool]boinccmd tool[/url].

BAM, Gridrepublic, Gridcoin, SU and whatever other account managers there are are websites via which you set which projects you want to run and these communicate that to the BOINC client.

BAM, GR, GC and SU are all independent entities, just as each and every project is its own entity. Any problems you have with the account managers you should report to the account managers as else they can't check if it is their problem or not.

I would appreciate it if you followed the links we point to, so you can read up on how things work, before you point out something that isn't a problem again.

Sorry to keep bouncing heads, but I totally disagree with the assessment that it's a BAM issue.

If the manager is nothing but the GUI face of the client, then this is a client issue.
I see the manager and client as one unit. But to be technical, yes, you're right there. It's the client that is responsible for allowing projects on the hardware.

The client should be responsible for not allowing tasks to be imported that the hardware doesn't support.
BAM does what it does as a remote setting or configuration that covers a plethora of hardware, and makes no error. There's just no humanly good way to adjust BAM to suit a variety of hardware out there.
It would mean adjusting a new profile for every different hardware used.
This is not feasible.
Instead BAM can be used to generate a global profile, and depending on the hardware capabilities of the PC/server/whatever you're running it on, the client can decide which projects to allow, and which ones to remove from the project list.

BAM can't distinguish between the hardware I'm running on one unit vs another.
The client does.
Therefor I would say that it's not a BAM issue.

I think the client should protect the hardware from the most common mis-configurations used by BAM or other, since it needs to be a local program that is in control of these settings; not a remote one.

Your understanding falls short of the way shut managers are intended to function, and, in the main, do function.
BAM, along with other BOINC managers, are there to manage the way your client(s) work.
They do not manage the way to projects manage themselves. The projects are independent of each other, and are run by independent groups. The projects send out, or at least are meant to send out, regular status reports; not every project does so, also projects are supposed to "tell the world" when they shut down, again not every project that has shut down has done so.

I'm not talking about that.
I'm telling how a BAM profile, with attached projects can be imported into a client running incompatible hardware.
That shouldn't happen.

BAM can't distinguish between the hardware I'm running on one unit vs another.
The client does.
Therefor I would say that it's not a BAM issue.

You are still not understanding what an account manager is. An account manager is a website through which you can set for multiple machines at once which projects these machines should add into BOINC.
As with any project, you can setup several different groups of venues/locations, so to split your computers into groups with the same hardware.
That way you can set per venue which projects should be added and which not. So there's some responsibility at setting up an account manager, just like you have that responsibility when you add projects manually.

Now, as to projects without ARM capability being added to ARM devices, that's completely possible. Because in the future the project may decide to add ARM capability, and then at least your devices are already ready to receive. They will ask for work, but never get any as long as the project does not have an application that cannot run on that hardware.

So there's nothing wrong with BOINC, it's all working as intended. Even BAM is working as intended.
And if you don't want this to happen, if you want your ARM devices only to get the projects that have an ARM application NOW, then you should just spend some time to group your hosts into groups: https://www.boincstats.com/bam/hosts/, https://www.boincstats.com/bam/hostGroups/

---

Like I said before, grouping them is not a feasible option (at all).
It's basically asking thousands of people to configure more than 10k clients just to bypass this malfunction!

I think what the client is missing, and projects, is read the 'flag' of the project.
If the project is flagged as 'x86', the client should reject the project if it doesn't support that architecture. Kind of like the little icons you see in each project indicating 'nvidia', 'ATI/AMD', x86. intel, arm, android.
It's not only incompatible hardware, but the client does the same thing for software as well.
It will allow a 'windows' or 'linux'-only project to be imported on Android or visa versa, in which some there also are compatibility issues.

If a project is later upgraded to supporting ARM, the flag can be modified, and the client can allow such projects to be loaded on the host.
This works for Linux vs Windows only projects as well.

I think simpler it can't be explained. The host grouping is a total disaster and a mess!
There's no order in this.
I mean, you can continue to argue that there's nothing wrong with all of this, but yes..
There is something wrong. And I'm just pointing it out.
And all it needs is a bug report and a good few hours of coding, to implement a 'flag' system inside the software, to filter out the incompatible projects.

You still don't get it. What you ask for is already built into the client, it's been there since the beginning of BOINC.
When your client asks for work from a project, it may already ask for work for CPU and GPU. The latter because you have a capable GPU in your system. With what you ask, the client would just ask for CPU work and only that, forever.

But BOINC is more intelligent than that: it'll ask for work for CPU and GPU, even if the project doesn't have any GPU applications, so that in the future, when the project decides to develop a GPU application, work requests for it are seamlessly done already. And depending on the GPU, given.

And then it asks for and get work based on the architecture it's installed on. A Linux client will only get Linux science applications, a Windows client will only get Windows science applications. A Mac... An Android... One can only load the wrong architecture onto the Android client by spoofing it to be something it isn't.

When BOINC makes a work request a lot happens in that request. The whole output of the sched_request_project_name.xml file is sent to the project in a handful of seconds, with the whole of the sched_reply_project_name.xml file as answer. When you enable the http_debug flag you can see all of that in the event log. Then you can also see what your client is asking work for.

In my case for instance, key lines Milkyway@Home | Requesting new tasks for AMD/ATI GPU, [http] [ID#1] Sent header to server: User-Agent: BOINC client (windows_x86_64 7.16.5). This means my client can't get AMD/ATI GPU work for Linux, because the server sees I don't have it. I can only get work for Windows (32bit and 64bit applications).
Android BOINC will for instance have the BOINC client starting with version N for aarch64-android-linux-gnu, this means no x86 applications, or Windows, or Mac, or pure Linux even can be sent to it. Unless the project names their science applications and plan classes illogically.

Your Android client can even be asking for work for a (Mali) GPU which none of the projects have an application for. But one might in the future, and then BOINC will be ready to ask work for it, without you having to keep an eye on things. Asteroids@home|Requesting new tasks for Mali-T720

---