WEBVTT 00:00.000 --> 00:12.000 Okay, so next we're looking at moving towards the purely open ARSP. 00:12.000 --> 00:18.000 As you've probably all seen, there's always some components of ARSP that are not really 00:18.000 --> 00:24.000 quite open and that is something we should really be trying to fix. 00:24.000 --> 00:31.760 So ARSP is a nice start, but it's not really complete and unfortunately this even tends to get 00:31.760 --> 00:37.440 worse instead of getting better, like in early versions of ARSP, it included an email 00:37.440 --> 00:43.440 client which I'd consider based functionality for any mobile, but that would remove to 00:43.440 --> 00:49.600 the favor of using non-free tools. In the launch I've got pretty much started getting 00:49.600 --> 00:54.880 pretty much no attention since start of the pixel launcher. The browser that is in the Android 00:54.880 --> 01:02.320 else code is not really usable. At the same time expectations of functionality that we just 01:02.320 --> 01:08.320 expect to be present and every device is growing. So instead of removing components we need to 01:08.320 --> 01:15.200 be adding them and often ARSP isn't getting it on the Android phones that is through Google 01:15.200 --> 01:22.560 or other vendor apps. So the question is, can we still build an open source phone and if yes, 01:22.560 --> 01:30.000 how can we do that? We'll start with some fairly simple things and then get to the interesting 01:30.000 --> 01:36.240 part. Obviously the interesting is just adding a couple of apps from third parties also 01:36.240 --> 01:44.240 that replace all the stuff that you just get as fineries on your existing phone. 01:46.640 --> 01:53.440 I'm going to mention the apps that I think are best to put in your fully open ARSP build. 01:54.160 --> 01:58.000 Obviously they are not the only ones that exist, maybe I missed better options on 01:58.000 --> 02:05.680 where so do your own research instead of plant detwashing me. First thing that you will probably 02:05.680 --> 02:12.080 need on the browser, on the phone is a browser and it is best to use some version of Chromium. 02:12.080 --> 02:18.400 There are a couple of alternatives to it but they don't implement the APIs that you need to replace 02:18.400 --> 02:24.560 the system web view which is essentially a strip done Chromium that is going to be embedded into apps 02:24.560 --> 02:33.840 for example when they want to display their HTML code. You won't notice that this is missing 02:33.840 --> 02:38.880 in a fully open build because it's included in ARSP sources but as a pre-built binary. 02:39.680 --> 02:46.000 So if you want to go fully open you have to rebuild that and only Chromium and closely 02:46.000 --> 02:52.320 derived powers can do that. If you have concerns about privacy, if the reason why you want to 02:52.320 --> 02:57.120 build an open phone is that you don't trust Google that they might be stealing your data. 02:57.120 --> 03:03.360 You can use the Unbook for patches. I've actually done that on one phone and it works nicely 03:03.360 --> 03:14.480 so there's no trust issues even if you're using Chromium code base. Next the smear will need a mail app. 03:15.440 --> 03:23.120 Can I mail is probably the best way to go there? It's originally based on the email application 03:23.120 --> 03:29.120 that was part of the earlier IOS people's when it's still head one and it's from then on when 03:29.120 --> 03:36.160 it got removed it now has 17 years of improvements. In these days it is also known as Thunderbird 03:36.160 --> 03:42.400 for Android but it doesn't actually share the code base of Death to Thunderbird. It's just 03:42.400 --> 03:48.160 the name so don't get scattered. It will pull in 500 megabytes of dependencies or stuff like that. 03:52.880 --> 04:00.000 Next the smaps. Obviously the challenge there is to have something that will still have 04:00.000 --> 04:07.280 accurate maps of order routes and trails and everything you might find. I found two pretty interesting 04:07.280 --> 04:14.320 replacements for maps where one is organic maps uses open street map data and in many ways it's 04:14.320 --> 04:19.840 even better than Google Maps. It has more complete offline support like you can just if you have 04:19.840 --> 04:27.600 to storage down that maps of the entire planet to your phone. You get not just the roads you also have 04:27.600 --> 04:33.440 hiking trails, contour lines if you're enjoying outdoor activities it's much better than Google Maps 04:33.760 --> 04:41.440 for that and then other option is Osman which also uses open street map data. It's also a 04:41.440 --> 04:48.080 good choice. It has pretty good navigation but if you want a fully open build you have to be a 04:48.080 --> 04:53.440 little bit careful because it includes some non-free artwork so you may have to replace a couple of 04:53.440 --> 05:00.240 icons and a couple of markers that will be drawn on the map but the code base itself is open so 05:00.560 --> 05:10.320 it's certainly another good starting point. Next we'll need a media player. There's at least 05:10.320 --> 05:18.640 two good options for that. MPV Android which is based on MPV NFF MPEC can give us just about every 05:18.640 --> 05:25.840 format you might run across but probably doesn't have to best support for half of best acceleration 05:25.920 --> 05:33.760 decoding and then as we'll see Android the Android part of the real C player probably everyone has seen 05:34.560 --> 05:43.360 that also works pretty well for this task. Next most phones that you see in a shop have a weather 05:43.360 --> 05:50.720 widget. We have one in the open source world as well. This is forecast eaves. When I could find 05:50.720 --> 05:58.960 that works pretty reliably and you can also put it on the desktop as a widget so you get pretty 05:58.960 --> 06:07.760 much functionality you would also see in a Samsung phone or so. Next is the launcher while I was 06:07.760 --> 06:16.400 peacefully includes one. It hasn't been getting all the features lately and it just can compete with 06:16.480 --> 06:23.280 to once did I in real Android phones so fortunately there's already a couple of folks of it that 06:24.160 --> 06:29.920 do a better job at keeping up to date for us to feature. It works pretty pretty much like the pixel 06:29.920 --> 06:35.840 launcher so there's launcher there's police launcher's weave about which there will be another 06:35.840 --> 06:42.320 presentation here a bit later and there's one I won't even pronounce because I'm not 06:42.560 --> 06:50.800 watching a language to where it's from but because it's open and it also seems to be a pretty good option. 06:53.200 --> 07:01.040 Then last thing we need a way to get some more apps on it. We need to replace the play store. 07:01.840 --> 07:09.760 After all it has become pretty much the agreed upon place to go for all the open source apps so 07:09.840 --> 07:15.120 you certainly want to build that into an open phone and if you also need non-free apps 07:15.120 --> 07:21.760 if you just say the system itself should be open source but it's not a problem if the apps on 07:21.760 --> 07:28.320 it aren't there's some way to put those in as well. For example, after it an AP camera 07:29.200 --> 07:40.160 a pretty good place is to just find the non-free AP case that you can install to get those apps. 07:41.280 --> 07:48.160 The AP camera app is currently unmaintained so maybe there's volunteer here to take it over 07:48.160 --> 07:51.040 but it's still pretty useful. 07:52.000 --> 07:58.800 Now that we've covered the apps, we get two more interesting parts. 08:00.960 --> 08:07.600 Next step is a lot of the apps rely on cloud services and you want some connectivity to rest 08:07.600 --> 08:13.600 of the world and of course, in the fully open world you don't have those pre-included with 08:13.600 --> 08:24.480 AOSP. Fortunately you can replace Gmail with a standard IMF and SMTPs over just use post-fix 08:24.480 --> 08:31.040 and a lot of similar things. For Google Meet you can use Gitsy, for Google Drive and Canada. 08:31.040 --> 08:37.120 You can use Next Cloud and in Next Cloud app there are also automatically uploads photos to your 08:37.120 --> 08:45.040 sound storage so you can get rid of any dependency on not necessarily trusted services. 08:47.680 --> 08:52.560 You don't need to modify the camera app to do this because next cloud monitors to directory 08:52.560 --> 09:02.160 in which the camera puts its fast so you don't need to use the modified camera thing from 09:02.160 --> 09:08.240 Android. You can just use the AOSP camera or another camera app like Open Camera. 09:13.680 --> 09:18.160 Then as of course there's the problem that you might not have service running those things already 09:18.880 --> 09:24.720 but fortunately many of the open source projects that we've seen in the previous slide 09:24.720 --> 09:30.160 already are hosted services so you can go there or you can go to a provider like federated 09:30.240 --> 09:37.360 provides hosted versions of all those cloud services and you get all the free versions 09:38.560 --> 09:45.040 of what you'd have in terms of Google integration in Android phone. 09:47.440 --> 09:52.160 Okay now we're getting to the very interesting parts if you start removing all 09:52.240 --> 10:00.320 non-free bits of the AOSP so now you've removed all the non-free bits you've added all the 10:00.320 --> 10:06.960 apps in it you've replaced the cloud services but then have the non-free apps your installs 10:06.960 --> 10:13.360 through app to it or app camera or some other source will fail and the reason is because they use 10:13.360 --> 10:20.480 Google logo services which is a to the standard library that integrates Google services like the 10:20.480 --> 10:29.040 finding data from a map or getting your user data stuff like this but fortunately we have a 10:29.040 --> 10:35.600 solution for that as well. There's an open re-implementation of pretty much all of GMS it might 10:35.600 --> 10:46.960 still be missing a couple of things which you can find at microG.org. MicroG does a pretty clever thing 10:47.680 --> 10:54.400 because there's non-free apps to keep checking the for security reasons that they're talking 10:54.400 --> 11:02.800 into the real library so microG needs to the other way to trick them into thinking that 11:03.920 --> 11:11.920 they can talk to microG instead it introduces a patch for a signature spoofing so app see 11:11.920 --> 11:19.840 would see the Google signature even when it's not there. Unfortunately it has been done 11:19.840 --> 11:27.360 in a way that is secure you don't open yourself up to getting your bank apps on a different 11:27.360 --> 11:33.440 sources since stealing your data because with the signature spoofing patches that are part of 11:33.440 --> 11:41.360 microG you can define in a read-only way what particular code is allowed to spoof a signature so 11:41.360 --> 11:49.840 you don't open yourself to all sorts of factors by using this. So now we have a phone on which 11:49.840 --> 11:58.640 pretty much all the apps work and you have replacements for everything that comes with core android 12:00.240 --> 12:07.440 but you notice your phone's battery drains much faster than the non-free version and that's 12:07.440 --> 12:14.320 because of the hidden setting. If you look in the ARS P code base in framework space core 12:14.320 --> 12:21.840 rest values config XMA you will find a couple of hidden switches one of them is enable order 12:21.840 --> 12:32.000 power modes which is disabled by default in ARS P and enable by default in android. The idea behind 12:32.080 --> 12:40.800 this difference is that in android you have a couple of apps that are allowed to bypass power 12:40.800 --> 12:48.400 saving like the GNS generally bypasses power saving to check the current integration to 12:48.400 --> 12:56.240 if you're notification when you've received something but in plain ARS P that is features disabled 12:56.400 --> 13:02.080 because it doesn't have a list of applications that are safe enough to bypass power management. 13:04.560 --> 13:10.240 This is simply shut down and when the phone is in your pocket the apps will not be permitted to 13:11.520 --> 13:18.240 communicate with or to check for emails and likes but fortunately you can just flip that 13:18.800 --> 13:29.680 switch to true and then edit a couple of files explaining which applications can do this. 13:32.400 --> 13:40.640 You can see examples of definitions for what files can override power management by looking 13:40.640 --> 13:50.320 at framework space data it is the platform XMA that you can see what is already done by ARS P 13:51.760 --> 13:59.760 android adds a few more of those for gms and it's a good idea to do that in any open modification 13:59.760 --> 14:06.960 as well. You want to add 100 google dot android dot gms to the list of allowed apps even if you're 14:06.960 --> 14:14.800 not using gms because micro g also uses common google android gms to identify itself and you want 14:14.800 --> 14:26.560 micro g to be able to override power management and necessary. This is what the side of 14:26.560 --> 14:34.400 could look like to make sure that the apps you're using will have sufficient access to override 14:34.400 --> 14:41.600 power management and check for things in the background. Essentially it's an XMA file where you 14:41.600 --> 14:46.800 just open the config and then you put tags allow and powers safe which allows for 14:48.400 --> 14:55.120 generally to do things even while the phone is supposed to be saving power. There's allow 14:55.120 --> 15:06.160 and data usage safe which allows to bypass data storage and then there's another one in middle 15:06.160 --> 15:13.840 allowing powers safe except either which still allows an app to override power safe but not when 15:13.840 --> 15:21.040 it's completely either so that is a bit of a compromise between allowing it to draw more battery 15:21.040 --> 15:30.480 and allowing it to access what it needs to access. So now we have a fully functional phone 15:30.480 --> 15:38.160 and all the close parts that we've seen initially have been replaced but it's unfortunately still 15:38.160 --> 15:44.160 not a fully open phone because if you look closer you will find that there's still a bit of close 15:44.160 --> 15:50.880 source drivers and unfortunately this is one point where I have to say we cannot get rid of all 15:50.880 --> 15:56.400 of them just yet but we can reduce the number and we can get closer to replacing all of them. 15:58.720 --> 16:05.920 First thing to look at would be graphic drivers. We've had good successes building AOSP burdens 16:05.920 --> 16:14.000 with open graphic drivers. The pen first driver which takes care of pretty much all modern iterations 16:14.000 --> 16:21.440 of the arm-malli chipset is known to work. For example on the CADAS VIM3 board you can find a 16:21.440 --> 16:29.760 Wikipedia chat ready for explaining how to do it. That also has a local manifest attached that will 16:30.800 --> 16:38.080 allow to just pull in the needed modifications. FreeDreno is also known to work that works for 16:38.080 --> 16:46.720 many Qualcomm chipsets. There has been a talk hit the 2023s XDC about this so I'm not going to repeat 16:46.720 --> 16:53.280 to what those guys have already been saying. You can look at what they've been saying. It's been 16:53.280 --> 17:01.920 archived online. So what you need to do to integrate open graphic drivers you need to rebuild 17:02.000 --> 17:06.880 to kernel because close source drivers usually have their own closed corner modules and 17:08.560 --> 17:14.080 phone vendor kernels that use their closed drivers were generally not have their open equivalence 17:14.080 --> 17:20.560 enabled in the corner. Usually while at that you want to use a newer kernel because those drivers 17:20.560 --> 17:27.120 keep getting better but of course you might need some other patches to keep rest of the chipset 17:27.120 --> 17:35.360 in your device going. You need new device three files unfortunately because while they refer to 17:35.360 --> 17:42.400 the same hardware, the closed drivers and the open drivers specify how to operate as differently. 17:43.200 --> 17:50.400 So you will have to check what data your particular open driver needs to know and then extract 17:50.560 --> 17:58.800 that data from the closed driver device three files and put it into the right format and added 17:58.800 --> 18:05.440 to your device three config. You will need a miserable build which is pretty bad documented. 18:06.240 --> 18:13.440 You will probably need a couple of patches to a mini GBM. It doesn't by support but default support 18:13.520 --> 18:20.880 all the pixel formats you might run into on a phone but fortunately those patches keep getting smaller. 18:24.000 --> 18:30.800 So where do we still have problems? Some sensors are not very well supported yet. Some 18:30.800 --> 18:36.400 Wi-Fi and Bluetooth chipsets don't yet have open drivers and bootloads and TE's. 18:37.360 --> 18:43.360 The modem drivers are a big pain point. Voice calls even though probably nobody 18:43.360 --> 18:50.720 really uses a phone to make voice calls. If you are interested in working on those parts 18:50.720 --> 18:57.280 there is a project called Replicant which has beginnings of open drivers. Unfortunately it is 18:57.280 --> 19:07.600 stuck on a really ancient codebase and on really old phones like Samsung S3 but it's still a 19:07.600 --> 19:17.680 good point to see how the APIs work, how to possibly write a radio interface there so if someone 19:17.680 --> 19:24.320 is interested in doing that for a new phone on your device it's still a pretty good starting point. 19:28.240 --> 19:36.880 Next there's a problem with some pre-built build tools in the S3. This don't get on the phone 19:36.880 --> 19:43.520 but there are needed at built-time. While there's a generally just build of open S3's 19:45.520 --> 19:54.560 unfortunately defective deliveries in the AOSP S3 means that you cannot build AOSP on non-X86 19:54.560 --> 20:00.080 machines at the moment. There seems to be some effort to fix things at least at later points 20:00.080 --> 20:11.040 but if you check out the main branch of AOSP in some regions you can see on 64 best binaries 20:11.840 --> 20:15.920 unfortunately that's not going to have a few building on a rest-five machine or so 20:16.880 --> 20:26.320 so it would be really nice to have a way to rebuild those built tools. It shouldn't be complicated 20:26.320 --> 20:40.960 because they are all open but somebody has to do it. With that we're pretty much at the end 20:41.920 --> 20:48.560 if there's questions or feedbacks or maybe truck lives of dog food let me know 20:50.320 --> 20:57.520 and of course you can join AOSP Devs under Discord to find all of us who have been 20:57.520 --> 21:00.720 organizing the Devs room and get mine for mason. 21:11.200 --> 21:12.400 Do we have any questions? 21:14.400 --> 21:20.400 I know there's a few absent for example the HOS that replace the calendar and the contacts 21:21.280 --> 21:28.400 is there any chance that those kinds of apps could ever enter the AOSP through their 21:28.400 --> 21:36.800 statuses and they'll go because the one thing is that's a good question. So the question is 21:37.840 --> 21:44.080 there are additional apps like replacing their calendar and stuff in the lineage OS and other 21:44.400 --> 21:50.000 reports. Is there any chance that those will end up in the AOSP tree at some point? 21:52.160 --> 21:57.680 I wish I could say yes definitely unfortunately I don't think it's 21:57.680 --> 22:03.280 currently very likely because the AOSP tree is pretty much under the control of Google and 22:05.120 --> 22:09.920 they don't really want those replacements for their binary things in because they don't 22:09.920 --> 22:14.720 want the additional workload of having to maintain another thing that's not going to be used 22:14.720 --> 22:23.920 in any of their devices but of course what we can do is put up a tree on AOSP Devs also there 22:23.920 --> 22:31.360 you can just put them all in with one call to a local manifest so that's not quite as good as 22:31.360 --> 22:40.160 really upstreaming them into AOSP but it's a good compromise. And see us yeah. 23:02.320 --> 23:12.720 So the question was is it possible to improve the powers of things to make it more configurable 23:12.720 --> 23:22.320 without having to edit those XML files? At the moment the answer is there's no tool that does it 23:22.320 --> 23:28.240 at least not that I could find and there will be some problems implementing it because those files 23:28.320 --> 23:35.920 are on a with only partition so you cannot just change it at one time and have a UI saying 23:36.720 --> 23:42.000 okay I want this test map to do this that would be accessible to the user but 23:43.360 --> 23:47.440 there's really nothing that would prevent someone from patching it in. 23:58.480 --> 24:07.520 Yeah at the moment the only known way is to put those XML files into a distribution 24:08.800 --> 24:12.960 of false them in through site loading or through ADB or the likes. 24:14.160 --> 24:20.880 Yeah out of time but if you have a quick question quick so what they were asking about 24:20.880 --> 24:26.080 does lineage always still find the category of power saving being broken and not being set up so 24:26.080 --> 24:30.560 if I wanted to get power saving of my own lineage I would have to with any of those files at 24:30.560 --> 24:37.600 the runtime, any amount of rate of light and any of those files right? Yes okay yeah I just got to 24:37.600 --> 24:44.480 find saying please repeat the question so it's about getting the power management stuff into 24:44.480 --> 24:55.360 the lineage or a certain that the way to do it is to add those files but put them into the 24:55.360 --> 25:10.560 build or allow user to install them through ADB.