BOINC Manager for Android

[Vitalii Koshura]

Hello everyone,

In this email I want to inform everyone (especially project owners) who are interested in BOINC Manager for Android.

Starting from Android API 28 Google add some restrictions to native executables: https://android-review.googlesource.com/c/platform/system/sepolicy/+/804149
Basically this means that we have no ability to download and run project executables anymore.

This is done to make Android more secure and prevent W^X violation https://en.wikipedia.org/wiki/W%5EX

In order to be up-to-date and secure, I decided to change the architecture of BOINC Manager for Android. This is the only way I see to continue our mission.

The main change is next: now BOINC Manager for Android will include all project executables inside the bundle ( https://developer.android.com/guide/app-bundle/ ).

This means that only projects that provide their executables to put inside the bundle will be able to run on Android. I understand that this adds a lot of complexity but we have to do this if we want to support newest devices.

GitHub ticket to follow: https://github.com/BOINC/boinc/issues/3561

If you have any questions feel free to ask then here or reach me directly in slack ( https://boincworkspace.slack.com/join/shared_invite/enQtNzA3MTQ4NDA0Njc4LTM4NTEyZTY1MWEwZjAyNTVmOTg3NDA2NjVjZDQzMWQ3NmFjYTc4MTNkNTEyNjRkOTQ4MWU5Nzk3NzRhNTg0NDI ) or discord ( https://discord.gg/wPRafUq )

Best regards,

Vitalii Koshura

[Vitalii Koshura]

> So is that gonna be Android 10 only or are older versions gonna be affected to?  

This would be a change for all supported versions (more accurate list will be provided during the development phase).

> How big is the app gonna be then to include those executables?

We will support bundles (see the link in my first email). This means that core APK will contain only necessary executables (BOINC client I mean). All other files will be downloaded on demand when user connects to some particular project (only executables from that project will be downloaded).

>  Also, that means anytime there's a new version of an app, a new version of BOINC has to be released...? 

Unfortunately, yes.

 >  Are we gonna have 2 versions? The existing BOINC and then a version for the newer API? 

Until we find new version stable - yes, there will be two versions. 

>  That said, does that create the potential for iOS support since this sounds rather similar to their store policy? 

Yes 

Best regards,

Vitalii Koshura

вс, 5 апр. 2020 г. в 23:46, David Chubrick <yava...@gmail.com>:

So is that gonna be Android 10 only or are older versions gonna be affected to?

How big is the app gonna be then to include those executables? With SETI on hiatus, that doesn't leave many projects with Android support, but still...

Also, that means anytime there's a new version of an app, a new version of BOINC has to be released...?

Are we gonna have 2 versions? The existing BOINC and then a version for the newer API? That said, does that create the potential for iOS support since this sounds rather similar to their store policy?

Best,

David C.

--
You received this message because you are subscribed to the Google Groups "boinc_admin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to boinc_admin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/boinc_admin/CAECimMXm%2BJhTHf%3D%3DbRznmHQnEky4Aw8xRx2euyZ7FydL92oYew%40mail.gmail.com.

[Bernd Machenschalk]

First, thanks Vitali for your effort.

On 06.04.20 00:09, Vitalii Koshura wrote:

>  Also, that means anytime there's a new version of an app, a new version of BOINC has to be released...? 

Unfortunately, yes.

I suggest we should plan for a fixed update cycle of the official BOINC Client (bundle) then, say, every quarter, with reasonable deadlines for projects to submit their apps or app versions. This, however, means that projects need to test and fix their apps internally.

I wonder whether it would be possible to have a development version of the client then. Projects can submit their apps automatically to that bundle, and some CI would automatically generate a new version of the client every time a new app version is submitted. That would probably lead to increadebly short release cycles of that app, but only for a limited audience that is willing to live with that.

Bernd

[Oliver Behnke]

(shouldn't we move this discussion to GitHub?)

On 06.04.20 10:50 , Bernd Machenschalk wrote:
> I suggest we should plan for a fixed update cycle of the official BOINC
> Client (bundle) then, say, every quarter, with reasonable deadlines for
> projects to submit their apps or app versions.

This is way too long, I think. Consider urgent bug fixes needed in any
of the apps included. I think the goal needs to be *automated* weekly
builds!

Apart from that: has anyone yet thought about how to integrate and
sign-off the apps included (and updated)? That's political, procedural
and even legal challenge as BOINC is responsible what it does, as a
monolithic app, on client devices. I doubt that the Android/iOS policies
allow execution of 3rd party code (downloaded or integrated) which would
in fact mean that BOINC has to accept responsibility, doesn't it?

To potentially avoid this issue I'm curious to know what kind of
alternatives have been discussed and rejected in the background of
#3561. Has anyone ever evaluated the possibility of having independent
per-project apps? Is there a way to have them communicate among each
other to coordinate execution slots?

Oliver

[Jord van der Elst]

On Mon, Apr 6, 2020 at 12:09 AM Vitalii Koshura <lestat.d...@gmail.com> wrote:

> How big is the app gonna be then to include those executables?

We will support bundles (see the link in my first email). This means that core APK will contain only necessary executables (BOINC client I mean). All other files will be downloaded on demand when user connects to some particular project (only executables from that project will be downloaded).

Now you're being confusing to me. If only executables from the project will be downloaded, then why add it into the BOINC installer (bundle)?

But the question asked wasn't answered. How big will the BOINC app become when it has to add several applications into the bundle?

Also, isn't it better to reject some Android versions and go for Android 7 and above support only? This to limit the amount of applications per project?

 

>  Also, that means anytime there's a new version of an app, a new version of BOINC has to be released...? 

Unfortunately, yes.

Projects testing new apps on Android is going to be atrocious then. They can't all test internally as proposed by Bernd.

I do propose that projects that expect to be testing a new app/apps to temporarily be releasing their own BOINC with just their own test app(s) included. Possibly set this test-BOINC at a set version number.

Jord.

[Vitalii Koshura]

>  I wonder whether it would be possible to have a development version of the client then. 

Yes, debug builds, let's say, weekly.
 

> Projects can submit their apps automatically to that bundle, and some CI would automatically generate a new version of the client every time a new app version is submitted.

This is not first priority but possible.

> To potentially avoid this issue I'm curious to know what kind of alternatives have been discussed and rejected in the background of #3561

There is only one alternative: revert back to the API used in 7.4.53 and use it until it will be not discontinued by Google. If we want to support latest Android releases - we have to follow the changes that is done by Google. Now is a perfect moment to change the architecture because we still ave old version run even on newest devices. I don't know how long it will be still possible. One day we can just face a situation that there is newest Android released and we can't support it.

> Has anyone ever evaluated the possibility of having independent per-project apps? Is there a way to have them communicate among each other to coordinate execution slots?

This means that every project should communicate with each other in the same way. And even in this case we could face an issues because Google restrict heavy applications work in background, that means 

that there is only one application could run on foreground while alll other will never be executed because of Google scheduling policy.

> If only executables from the project will be downloaded, then why add it into the BOINC installer (bundle)?

Because they will be downloaded as a part of the same package, not as a 3rdparty downloaded application.

> How big will the BOINC app become when it has to add several applications into the bundle?

If you connect all projects - result application will be the same size as it has now when installed and projects are assigned. The only difference is that you will not downloaded that part of bundles that contain projects you're not connected to. So this doesn't mean that if, for example, all projects executable will be 1GB, you will download 1GB from Play Market. You will download around 10 MB, and further while adding projects, all other necessary parts will be downloaded in background.

> Projects testing new apps on Android is going to be atrocious then. They can't all test internally as proposed by Bernd.

I do propose that projects that expect to be testing a new app/apps to temporarily be releasing their own BOINC with just their own test app(s) included. Possibly set this test-BOINC at a set version number.

This could be discussed of course.

Best regards,

Vitalii Koshura

пн, 6 апр. 2020 г. в 11:44, Jord van der Elst <els...@gmail.com>:

[Nicolás Alvarez]

El dom., 5 de abr. de 2020 a la(s) 19:09, Vitalii Koshura
(lestat.d...@gmail.com) escribió:

> > That said, does that create the potential for iOS support since this sounds rather similar to their store policy?
>
> Yes

Almost. iOS applications must indeed include all executable code
(signed) and can't download code at runtime, so this Android change
gets it closer to iOS. But they also can't start new processes, so in
addition to shipping project apps in the app bundle, we would need to
run them in-process.

I think BOINC on iOS would need an incredible amount of work, and I'd
be reluctant to spend any time on it without *assurance* that Apple
won't reject it from the appstore for its very nature (eg. they could
use guideline 2.4.2 "Apps should not rapidly drain battery, generate
excessive heat, or put unnecessary strain on device resources").

--
Nicolás

[Vitalii Koshura]

>  I think BOINC on iOS would need an incredible amount of work, and I'd be reluctant to spend any time on it without *assurance* that Apple won't reject it from the appstore for its very nature (eg. they could use guideline 2.4.2 "Apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources").  

I have just a short answer for you: https://apps.apple.com/de/app/dreamlab/id1273619275

Best regards,

Vitalii Koshura

пн, 6 апр. 2020 г. в 21:05, Nicolás Alvarez <nicolas...@gmail.com>:

[David Chubrick]

So is that gonna be Android 10 only or are older versions gonna be affected to?

How big is the app gonna be then to include those executables? With SETI on hiatus, that doesn't leave many projects with Android support, but still...

Also, that means anytime there's a new version of an app, a new version of BOINC has to be released...?

Are we gonna have 2 versions? The existing BOINC and then a version for the newer API? That said, does that create the potential for iOS support since this sounds rather similar to their store policy?

Best,

David C.

On Sun, Apr 5, 2020, 14:08 Vitalii Koshura <lestat.d...@gmail.com> wrote:

--

[David Chubrick]

On Mon, Apr 6, 2020 at 12:05 PM Nicolás Alvarez <nicolas...@gmail.com> wrote:be reluctant to spend any time on it without *assurance* that Apple

won't reject it from the appstore for its very nature (eg. they could
use guideline 2.4.2 "Apps should not rapidly drain battery, generate
excessive heat, or put unnecessary strain on device resources").

Check out DreamLab created by Vodafone Australia. It seems like they have limiters similar to BOINC but it's not user configurable. It's basically like BOINC's simple view. I noticed a few months ago that my devices didn't seem to run as warm with a newer version of DreamLab. I don't know if performance was affected any as I never 'benchmarked' it before or after. Also, they appear to let you continue running older version of the client for older Android versions but you only get 3 out of the 4 available projects. I believe to run newer projects you have to update to the newer version. I would think for the Apple iOS audience that a fixed limiter could be put in. I don't have any Apple devices so I don't know if there is any kind of app that can forcibly tell the device to run full bore. I would think games would be a greater impact on the device...

David C.

[Stefano B]

" Also, that means anytime there's a new version of an app, a new version of BOINC has to be released...?"

Ralph@Home (the beta project of Rosetta@Home) has released 3 different version of app during the last week

3 different version of Boinc???

You received this message because you are subscribed to the Google Groups "boinc_projects" group.
To unsubscribe from this group and stop receiving emails from it, send an email to boinc_project...@ssl.berkeley.edu.
To view this discussion on the web visit https://groups.google.com/a/ssl.berkeley.edu/d/msgid/boinc_projects/CALz-iERdurEr1SLemGeNinpHQ-mf6XOpP7z5vhc8jocZnQ9DCg%40mail.gmail.com.

[Vitalii Koshura]

> Ralph@Home (the beta project of Rosetta@Home) has released 3 different version of app during the last week

3 different version of Boinc???

Yes, unfortunately, there is no other way to do this. If you have some ideas - please tell me, because I'm also not very happy with this.

Best regards,

Vitalii Koshura

вт, 7 апр. 2020 г. в 09:32, Stefano B <bobo...@gmail.com>:

[Charlie Fenton]

> Ralph@Home (the beta project of Rosetta@Home) has released 3 different version of app during the last week
> 3 different version of Boinc???

When a project distributes an app and only then finds it has a critical flaw (for example, one that crashes the app, returns bad results or even worse, crashes BOINC), they can change their tasks to require the updated app. BOINC then automatically downloads the new app.

Rosetta@home needed to update their new app because after deployment they found that their app crashed only on Macs with a certain configuration, and it took some experimentation to determine the cause. My understanding is that this problem did not show up during beta testing on Ralph@home.

Some / many users set their device to not download and install updates automatically (I am one of them, as I don't want updates happening at inopportune times). And I suspect there is a significant percentage of users who rarely update their apps.

If I understand correctly, the scheme under discussion here would require these users to update BOINC (or at least the project app) themselves, unless they have their device set to get updates automatically.

I don't know how big a problem that would be, but it is something to consider.

On Apr 7, 2020, at 2:01 AM, Vitalii Koshura <lestat.d...@gmail.com> wrote:
> If you have some ideas - please tell me, because I'm also not very happy with this

Might it be possible to find someone in Android development or support who might be willing to help us with this, given the important humanitarian work BOINC projects do? Is Android still developed by Google? Does anyone here have a good contact there?

Cheers,
--Charlie

[Stefano B]

Use something like docker/virtualbox on Android? You download boinc+virtualizer and executables are downloaded and executed in a sandbox.

[James Wanless]

I have been using UserLAnd (and Termux) on my Amazon Fire tablets.

(Don’t know how easy it would be to automate)

J

To view this discussion on the web visit https://groups.google.com/a/ssl.berkeley.edu/d/msgid/boinc_projects/CAP3hrSFrVgzYX8Wigp%2B2n8315-iMYOXj9OS2yHjruYnMU%3DQgoQ%40mail.gmail.com.

[Stefano B]

Another idea is to "certificate" the projects, if possible, with Google. All executables released by a "certified project" is automatically authorized.

I don't know how to certificate a project.

[Vitalii Koshura]

I don't believe Google will make an exception because this will create a precedent. And this means a lot of changes in kernel. Do this just for one application - definitely won't be done.

вт, 7 апр. 2020 г. в 17:40, Stefano B <bobo...@gmail.com>:

--

Best regards,
Vitalii Koshura

Sent via iPhone

[David E. Kim]

Previous to the COVID-9 pandemic, R@h has been in production without app updates for 2 years.  This recent activity has been specifically to add up-to-date protocols/methods for COVID-19. It’s unlikely that we’d need such frequent updates in the future.  Also, we would be able to skip android for such updates in the future if necessary, to continue work.

David K

To view this discussion on the web visit https://groups.google.com/a/ssl.berkeley.edu/d/msgid/boinc_projects/CAP3hrSELUWrsNc7rTjoRVL0E2fpbA_kTh8TCcvufTjPHS4wVxQ%40mail.gmail.com.

[David P. Anderson]

- The Google app store lets you create "tracks" for testing:

https://support.google.com/googleplay/android-developer/answer/3131213?hl=en

We could use this for project app testing/debugging.

- For users who disabled auto update, we can have the BOINC app detect when

there's a new version and notify the user, perhaps aggressively.

[Stefano B]

True. But Rosetta is only an example. Also WCG add new projects or other projects can change their apps.

So virtualization/docker seems a possibility..

To view this discussion on the web visit https://groups.google.com/a/ssl.berkeley.edu/d/msgid/boinc_projects/5E116101-292C-409B-88E3-6D5DC2681D7D%40uw.edu.

[Nicolás Alvarez]

Docker just changes cgroups and namespaces and runs the program in the
resulting environment. Messing with cgroups from the Android sandbox
might not be allowed, but even if it is, you're then just... running a
downloaded executable. You're back to the original problem.

Virtualization needs a *kernel module*.

--
Nicolás

El mar., 7 de abr. de 2020 a la(s) 19:39, Stefano B
(bobo...@gmail.com) escribió:

[Jérôme Cadet]

Hi all

I'm no developer nor boinc/android user (it killed one of my previous android device due to battery constant stress / refill, I didn't try with the next device) but this discussion is very interesting.

May I mention the fact that any user can check the "accept beta tasks" in his account for many projects, so maybe you also have to consider this in your reflection - like : Android version should only allow stable versions ?

Good luck with this complex problem and stay safe wherever you are.

Jerome

To view this discussion on the web visit https://groups.google.com/a/ssl.berkeley.edu/d/msgid/boinc_projects/CAP3hrSF%3Ds1iysqD_UfX3ykK3W9QhQq%2Bbg8%2BLSYtQTog0tABPuA%40mail.gmail.com.

[David Chubrick]

On Thu, Apr 9, 2020, 03:34 Jérôme Cadet <jerome...@pobox.com> wrote:

Hi all

I'm no developer nor boinc/android user (it killed one of my previous android device due to battery constant stress / refill, I didn't try with the next device) but this discussion is very interesting.

You can turn down the max temperature and reduce the cores. Plus there are apps to help monitor the temp.

May I mention the fact that any user can check the "accept beta tasks" in his account for many projects, so maybe you also have to consider this in your reflection - like : Android version should only allow stable versions ?

Well, the point being made was sometime issues pop up that don't in testing and a new version of the project executable needs to be pushed out asap.

David C.