 Welcome again to my presentation today. On behalf of the Navit project, I will talk today about how we do testing of our app, this time again with device farms, but with a bit of a change compared to last year. As Navit is a GPS navigation software, which you can use as an alternative to Google Maps, I tried to frame my talk today in the shape of a trip, like when I was travelling from where I live in Selle, Germany, here to Brussels. So for all of that, one needs to have a map. We mostly use OpenStreetMap data and this is how my whole route was when I was starting in Germany and coming all down to Brussels. And if you go by car, then you start somewhere inside your car, you have your GPS snap ready to start your trip, and then you enter the motorway and go on your way. Now for our talk today, I structured it like this. That at first I give you a brief intro about Navit, then about device farms and our own device farm up here, and I will also mention a little bit what happened on the site, what other people in the project did during all of this time. But I will focus more on the things on the left. So what is Navit? It's an open source GPS app, which is multi-platform, covers many different platforms. It's offline, so you don't need any online connection during the operation, just once for downloading the maps. We use, as I already mentioned, OpenStreetMap data. We have been around already quite a while, more than 10 years now. And advantage for the end user is, as it's open source, it's highly customizable. It also does not need that much computing power, so you can also use pretty old devices. You can change the map layout, the on-screen display, which elements you want to have there, routing profiles, and also we have different text-to-speech systems. And the last point here, translations in many languages is always something where we also value community contributions a lot because we are just a small team and we just speak a handful of languages. So if you really want to have it localized in a large number of languages, you need to rely on volunteers. So if anyone here wants to contribute, we have it on launchpad, please feel free to. Because that will help everyone in the end. So what has happened since my talk last year? We improved the map server, which is used to transform the open-street map data for others to download. We resolved some issues in the map rendering. For example, we had some over-flooding of areas which should be land because the map data was not good enough. We worked on the translations. What I find most remarkable is that we still work on the traffic branch, which more or less does that we can have messages about traffic jams, blocked roads, or other problems when you are driving. And that can then be used to adapt the route dynamically. So that is something really nice and what I mostly worked on was the implementation of our new device farm. Why do we do a device farm in the first place? If you make a mobile phone app, usually you have a large number of different devices. The app is installed on, Android on top has a very large beauty that you have a fragmentation of many different Android versions. Right now we support, if I remember correctly, back till Android 2.3. So you have a lot to cover and testing is not really that simple because if you can just test locally, you just have each developer maybe has some devices, but you cannot share it or use it more on a global way or maybe others could also provide devices, but if it's always in one place, needs to be in one place of the developer working on it, it's pretty difficult. And if one looks at iPhones, which are not our focus right now, then that might also be available to everyone. So a device farm gives you the opportunity to have a web interface where you can imagine you have maybe one server or several servers and to those you have the different mobile phones connected and then via a central interface you can access all of them. You can run, for example, two I-based tests, that's what I will talk about today. You can manually do the actions on the phone and you could also compare the performance of different devices maybe to see which is the weakest for which one could do more optimization. commercially quite a few are available, Microsoft offers one, Google, Amazon and a few more but all of those have some limitations, of course, which we try to overcome and those are, of course, you are completely bound towards the vendor is offering you which phones are there, which functionality is there, you continuously need to pay in an abonnement or kind of reoccurring costs which for a small open source project is also not that easy and you cannot also not extend the functionality. So we said we want something on our own and the open STF project offers with STF a platform which you can install and just connect your phones and you have exactly the functionality which we want and that's what I was mostly looking at how to work with it. Right now we have it in a distributed, we want to have it in a distributed fashion as I already mentioned, one developer has the internal look and one has a dedicated x86 server so for those the implementation was pretty simple, there's a Docker image which you just need to run and things work and everything is nice and smooth. For the connection of the different nodes we want to do it via VPN because open STF despite having all the functionality you don't want to expose such things out to the internet without any access control still because they are not focusing too much on security and for embedded devices that was what I was more looking at to deploy it more widely like with a Raspberry Pi we said we want to have that dedicated server as master and all other nodes more or less as a slave and in the final stage it should be triggered like a general continuous integration system. So for the deployment that I mostly covered already what I used was a Raspbian based image but we also looked and also planned to look into maybe using OpenWRT to also have a larger number of devices we could address but that's more future work. And when I did it with a Raspberry Pi it was as I said I used Raspbian and I had to actually install two different packages at first ResyncDB which is a backend database and ResyncDB has a downside that it's not too largely developed anymore it's still somehow maintained and they mostly offer packages just for Intel platforms not for any Raspberry Pi but they have a community manual to compile it for Raspberry Pi and the earlier versions one to three of Raspberry Pi have not sufficient memory so you need to adjust also swap and yeah it takes some time for compiling but all of that I have done and also made a complete image which we can also then distribute to any user who wants to donate so to speak some devices that we can grow our platform. If you manage everything then the web interface will look like this here where you have at the top the different devices if you click on it then you can manually control it and you can also run automated tests which I will partially show today then up here I wanted to use to do these automated tests like last year for the reasons that it also supports quite a large number of platforms has clients for many different programming languages and it's also an open source library and when looking this year into up here I also noticed that there are some features which I wished to have already last year or to know about them you can do screen recording just also in the Python code do screenshots and even make a graphical comparison so if you have a sample picture and then if something changes then you see okay something obviously went wrong so those features seem pretty exciting and I just got to know about them this year and I did some initial implementation steps and ran some first simple tests like downloading the map which you would do anyway if you start using Navit here is how a sample code which does some of the things also some more things and this is just how you would do it in Python but as I mentioned you can also use Java, Ruby or many other languages and then here I have a video demo that I can now let's see does that work this is how it worked then when I was doing the animation so Navit was already starting and just by the Python code I download now the maps of the other islands that takes a couple of seconds so maybe I skim a bit forward and then at the end you have the screen and then one could compare okay did it really do what I wanted it to or did it crash somewhere in between and then see on which device did it crash and by that just giving you a lot more tools at hand to really make your code more mature and here was one screenshot which I also took by the Python code and that already brings me pretty close to the end of my talk and it's mostly Android Open STF but our project is not just limited to Android we have Linux, we have Sailfish OS Android of course, Windows it's running on Windows CE, TomTom but Open STF cannot not that many we had an Apple port for Navit but I don't think it's very well maintained I would say STF supports also Apple devices so if someone would give us an iPhone then or connect one it could also help other people looking into that port more but you know all depending on time and interest that's the idea behind actually that is the idea behind it's not fully functional yet but we want to get there we will have a documentation about it but right now it's not fully functional yet so that will be on our website certainly or in our wiki that is via that radio signal TSMC or I don't remember now if we have a branch for it where it's actually also running but it's still a bit in an experimental shape it's not in the main branch yet but people are working on it I'm pretty excited also about it anybody else, if not well thank you very much thank you for having me Ilya