Okay, so next we're looking at moving towards the purely open ARSP.
As you've probably all seen, there's always some components of ARSP that are not really
quite open and that is something we should really be trying to fix.
So ARSP is a nice start, but it's not really complete and unfortunately this even tends to get
worse instead of getting better, like in early versions of ARSP, it included an email
client which I'd consider based functionality for any mobile, but that would remove to
the favor of using non-free tools. In the launch I've got pretty much started getting
pretty much no attention since start of the pixel launcher. The browser that is in the Android
else code is not really usable. At the same time expectations of functionality that we just
expect to be present and every device is growing. So instead of removing components we need to
be adding them and often ARSP isn't getting it on the Android phones that is through Google
or other vendor apps. So the question is, can we still build an open source phone and if yes,
how can we do that? We'll start with some fairly simple things and then get to the interesting
part. Obviously the interesting is just adding a couple of apps from third parties also
that replace all the stuff that you just get as fineries on your existing phone.
I'm going to mention the apps that I think are best to put in your fully open ARSP build.
Obviously they are not the only ones that exist, maybe I missed better options on
where so do your own research instead of plant detwashing me. First thing that you will probably
need on the browser, on the phone is a browser and it is best to use some version of Chromium.
There are a couple of alternatives to it but they don't implement the APIs that you need to replace
the system web view which is essentially a strip done Chromium that is going to be embedded into apps
for example when they want to display their HTML code. You won't notice that this is missing
in a fully open build because it's included in ARSP sources but as a pre-built binary.
So if you want to go fully open you have to rebuild that and only Chromium and closely
derived powers can do that. If you have concerns about privacy, if the reason why you want to
build an open phone is that you don't trust Google that they might be stealing your data.
You can use the Unbook for patches. I've actually done that on one phone and it works nicely
so there's no trust issues even if you're using Chromium code base. Next the smear will need a mail app.
Can I mail is probably the best way to go there? It's originally based on the email application
that was part of the earlier IOS people's when it's still head one and it's from then on when
it got removed it now has 17 years of improvements. In these days it is also known as Thunderbird
for Android but it doesn't actually share the code base of Death to Thunderbird. It's just
the name so don't get scattered. It will pull in 500 megabytes of dependencies or stuff like that.
Next the smaps. Obviously the challenge there is to have something that will still have
accurate maps of order routes and trails and everything you might find. I found two pretty interesting
replacements for maps where one is organic maps uses open street map data and in many ways it's
even better than Google Maps. It has more complete offline support like you can just if you have
to storage down that maps of the entire planet to your phone. You get not just the roads you also have
hiking trails, contour lines if you're enjoying outdoor activities it's much better than Google Maps
for that and then other option is Osman which also uses open street map data. It's also a
good choice. It has pretty good navigation but if you want a fully open build you have to be a
little bit careful because it includes some non-free artwork so you may have to replace a couple of
icons and a couple of markers that will be drawn on the map but the code base itself is open so
it's certainly another good starting point. Next we'll need a media player. There's at least
two good options for that. MPV Android which is based on MPV NFF MPEC can give us just about every
format you might run across but probably doesn't have to best support for half of best acceleration
decoding and then as we'll see Android the Android part of the real C player probably everyone has seen
that also works pretty well for this task. Next most phones that you see in a shop have a weather
widget. We have one in the open source world as well. This is forecast eaves. When I could find
that works pretty reliably and you can also put it on the desktop as a widget so you get pretty
much functionality you would also see in a Samsung phone or so. Next is the launcher while I was
peacefully includes one. It hasn't been getting all the features lately and it just can compete with
to once did I in real Android phones so fortunately there's already a couple of folks of it that
do a better job at keeping up to date for us to feature. It works pretty pretty much like the pixel
launcher so there's launcher there's police launcher's weave about which there will be another
presentation here a bit later and there's one I won't even pronounce because I'm not
watching a language to where it's from but because it's open and it also seems to be a pretty good option.
Then last thing we need a way to get some more apps on it. We need to replace the play store.
After all it has become pretty much the agreed upon place to go for all the open source apps so
you certainly want to build that into an open phone and if you also need non-free apps
if you just say the system itself should be open source but it's not a problem if the apps on
it aren't there's some way to put those in as well. For example, after it an AP camera
a pretty good place is to just find the non-free AP case that you can install to get those apps.
The AP camera app is currently unmaintained so maybe there's volunteer here to take it over
but it's still pretty useful.
Now that we've covered the apps, we get two more interesting parts.
Next step is a lot of the apps rely on cloud services and you want some connectivity to rest
of the world and of course, in the fully open world you don't have those pre-included with
AOSP. Fortunately you can replace Gmail with a standard IMF and SMTPs over just use post-fix
and a lot of similar things. For Google Meet you can use Gitsy, for Google Drive and Canada.
You can use Next Cloud and in Next Cloud app there are also automatically uploads photos to your
sound storage so you can get rid of any dependency on not necessarily trusted services.
You don't need to modify the camera app to do this because next cloud monitors to directory
in which the camera puts its fast so you don't need to use the modified camera thing from
Android. You can just use the AOSP camera or another camera app like Open Camera.
Then as of course there's the problem that you might not have service running those things already
but fortunately many of the open source projects that we've seen in the previous slide
already are hosted services so you can go there or you can go to a provider like federated
provides hosted versions of all those cloud services and you get all the free versions
of what you'd have in terms of Google integration in Android phone.
Okay now we're getting to the very interesting parts if you start removing all
non-free bits of the AOSP so now you've removed all the non-free bits you've added all the
apps in it you've replaced the cloud services but then have the non-free apps your installs
through app to it or app camera or some other source will fail and the reason is because they use
Google logo services which is a to the standard library that integrates Google services like the
finding data from a map or getting your user data stuff like this but fortunately we have a
solution for that as well. There's an open re-implementation of pretty much all of GMS it might
still be missing a couple of things which you can find at microG.org. MicroG does a pretty clever thing
because there's non-free apps to keep checking the for security reasons that they're talking
into the real library so microG needs to the other way to trick them into thinking that
they can talk to microG instead it introduces a patch for a signature spoofing so app see
would see the Google signature even when it's not there. Unfortunately it has been done
in a way that is secure you don't open yourself up to getting your bank apps on a different
sources since stealing your data because with the signature spoofing patches that are part of
microG you can define in a read-only way what particular code is allowed to spoof a signature so
you don't open yourself to all sorts of factors by using this. So now we have a phone on which
pretty much all the apps work and you have replacements for everything that comes with core android
but you notice your phone's battery drains much faster than the non-free version and that's
because of the hidden setting. If you look in the ARS P code base in framework space core
rest values config XMA you will find a couple of hidden switches one of them is enable order
power modes which is disabled by default in ARS P and enable by default in android. The idea behind
this difference is that in android you have a couple of apps that are allowed to bypass power
saving like the GNS generally bypasses power saving to check the current integration to
if you're notification when you've received something but in plain ARS P that is features disabled
because it doesn't have a list of applications that are safe enough to bypass power management.
This is simply shut down and when the phone is in your pocket the apps will not be permitted to
communicate with or to check for emails and likes but fortunately you can just flip that
switch to true and then edit a couple of files explaining which applications can do this.
You can see examples of definitions for what files can override power management by looking
at framework space data it is the platform XMA that you can see what is already done by ARS P
android adds a few more of those for gms and it's a good idea to do that in any open modification
as well. You want to add 100 google dot android dot gms to the list of allowed apps even if you're
not using gms because micro g also uses common google android gms to identify itself and you want
micro g to be able to override power management and necessary. This is what the side of
could look like to make sure that the apps you're using will have sufficient access to override
power management and check for things in the background. Essentially it's an XMA file where you
just open the config and then you put tags allow and powers safe which allows for
generally to do things even while the phone is supposed to be saving power. There's allow
and data usage safe which allows to bypass data storage and then there's another one in middle
allowing powers safe except either which still allows an app to override power safe but not when
it's completely either so that is a bit of a compromise between allowing it to draw more battery
and allowing it to access what it needs to access. So now we have a fully functional phone
and all the close parts that we've seen initially have been replaced but it's unfortunately still
not a fully open phone because if you look closer you will find that there's still a bit of close
source drivers and unfortunately this is one point where I have to say we cannot get rid of all
of them just yet but we can reduce the number and we can get closer to replacing all of them.
First thing to look at would be graphic drivers. We've had good successes building AOSP burdens
with open graphic drivers. The pen first driver which takes care of pretty much all modern iterations
of the arm-malli chipset is known to work. For example on the CADAS VIM3 board you can find a
Wikipedia chat ready for explaining how to do it. That also has a local manifest attached that will
allow to just pull in the needed modifications. FreeDreno is also known to work that works for
many Qualcomm chipsets. There has been a talk hit the 2023s XDC about this so I'm not going to repeat
to what those guys have already been saying. You can look at what they've been saying. It's been
archived online. So what you need to do to integrate open graphic drivers you need to rebuild
to kernel because close source drivers usually have their own closed corner modules and
phone vendor kernels that use their closed drivers were generally not have their open equivalence
enabled in the corner. Usually while at that you want to use a newer kernel because those drivers
keep getting better but of course you might need some other patches to keep rest of the chipset
in your device going. You need new device three files unfortunately because while they refer to
the same hardware, the closed drivers and the open drivers specify how to operate as differently.
So you will have to check what data your particular open driver needs to know and then extract
that data from the closed driver device three files and put it into the right format and added
to your device three config. You will need a miserable build which is pretty bad documented.
You will probably need a couple of patches to a mini GBM. It doesn't by support but default support
all the pixel formats you might run into on a phone but fortunately those patches keep getting smaller.
So where do we still have problems? Some sensors are not very well supported yet. Some
Wi-Fi and Bluetooth chipsets don't yet have open drivers and bootloads and TE's.
The modem drivers are a big pain point. Voice calls even though probably nobody
really uses a phone to make voice calls. If you are interested in working on those parts
there is a project called Replicant which has beginnings of open drivers. Unfortunately it is
stuck on a really ancient codebase and on really old phones like Samsung S3 but it's still a
good point to see how the APIs work, how to possibly write a radio interface there so if someone
is interested in doing that for a new phone on your device it's still a pretty good starting point.
Next there's a problem with some pre-built build tools in the S3. This don't get on the phone
but there are needed at built-time. While there's a generally just build of open S3's
unfortunately defective deliveries in the AOSP S3 means that you cannot build AOSP on non-X86
machines at the moment. There seems to be some effort to fix things at least at later points
but if you check out the main branch of AOSP in some regions you can see on 64 best binaries
unfortunately that's not going to have a few building on a rest-five machine or so
so it would be really nice to have a way to rebuild those built tools. It shouldn't be complicated
because they are all open but somebody has to do it. With that we're pretty much at the end
if there's questions or feedbacks or maybe truck lives of dog food let me know
and of course you can join AOSP Devs under Discord to find all of us who have been
organizing the Devs room and get mine for mason.
Do we have any questions?
I know there's a few absent for example the HOS that replace the calendar and the contacts
is there any chance that those kinds of apps could ever enter the AOSP through their
statuses and they'll go because the one thing is that's a good question. So the question is
there are additional apps like replacing their calendar and stuff in the lineage OS and other
reports. Is there any chance that those will end up in the AOSP tree at some point?
I wish I could say yes definitely unfortunately I don't think it's
currently very likely because the AOSP tree is pretty much under the control of Google and
they don't really want those replacements for their binary things in because they don't
want the additional workload of having to maintain another thing that's not going to be used
in any of their devices but of course what we can do is put up a tree on AOSP Devs also there
you can just put them all in with one call to a local manifest so that's not quite as good as
really upstreaming them into AOSP but it's a good compromise. And see us yeah.
So the question was is it possible to improve the powers of things to make it more configurable
without having to edit those XML files? At the moment the answer is there's no tool that does it
at least not that I could find and there will be some problems implementing it because those files
are on a with only partition so you cannot just change it at one time and have a UI saying
okay I want this test map to do this that would be accessible to the user but
there's really nothing that would prevent someone from patching it in.
Yeah at the moment the only known way is to put those XML files into a distribution
of false them in through site loading or through ADB or the likes.
Yeah out of time but if you have a quick question quick so what they were asking about
does lineage always still find the category of power saving being broken and not being set up so
if I wanted to get power saving of my own lineage I would have to with any of those files at
the runtime, any amount of rate of light and any of those files right? Yes okay yeah I just got to
find saying please repeat the question so it's about getting the power management stuff into
the lineage or a certain that the way to do it is to add those files but put them into the
build or allow user to install them through ADB.