 So, for the next lightning talk, I want to ask Tobias to come on stage. My webinar buddy and colleague is going to talk about Android and cross-repository work and how Android teams work together and what they plan in the future. So, Toby, let me find your slides. Take this one. Yeah, it's yours. Nope. Go for it. Yeah. Thanks for the introduction. Yeah, I want to talk with you about how we want to work closely on the next slide between our two Android projects and, yeah, what is the past? The past was we, and we still have two different repositories on files and talk, but in the past we had no code exchange, no common infrastructure, for example, we had different Android versions which we're supporting and also we had different Java versions where we compiled the code on. So it was not really possible to help because you had always to switch to the different Android studios and actually there was no knowledge exchange, so, yeah, the teams were on their own and we just figured out that this is just kind of not good. And now we wanted to transition into a better system, so we evolved or implemented regular meetings where we're discussing new patterns, agreeing on new technologies. For example, we want to now switch our image library back from Android FIATS, it's a self-implemented version on talk we are using, as far as I remember, it's Fresco, and also we're using on FIATS another library that is called Clyde. So as you can see, we have three different libraries for exactly the same purpose. There is also no knowledge exchange possible, but we want to change this and also the ideas to help each other have hunting spikes down and also help each other when the others are on vacation. But that's not all. We also have now had the idea to create repositories where we exclude extract common code or common countrix and you can see here on the right that is a short small graphic which one of our Android developers created where you can see how the whole concept and how the whole idea is behind. So that everything like talk and files is using Android library, which is for communication to the server, Android common, which should then contain all our UI, UX stuff, common code and Android config is for their configuration part, which I will show you now. So yeah, config repo is including currently our GitHub actions and workflows, like the sale board, QL, which is a security scanner, and we are just implementing it once in common repo and then it's automatically synced all the changes back to Android library, Android files, Android talk, and I think that just helps to ease the application of work. On the common repository we plan to have releases which are following our semantic versioning similar to our Android library and right now it contains the first part of the material designs. And I did a great job in implementing first the material design on talk, then extracting the generic and common logic to this repository and also is now doing implementing the same under Android files, which I showed you recently yesterday in our keynote. So there you can see if there's one bug, for example there, the communication of color is not correct, this will now directly benefits both projects, files and talk. And as an outlook we want to have in talk, Android, the adding the single sign on library using the Android library, so again to ease the application of work. And we want now to extract even more code into our common repository like the user status dialogue which is currently just a duplication from Android files where I implemented it to Android talk and this is just not good because we have to change all the things double and twice. Similar for our test setup where we have many, many different tests like unit tests, end-to-end tests, and also screenshots testing, there's just a common test setup and we want to extract this to our repository. And on the config side we want to create even more CI checks, extract, spotless, detecting stuff so that again only we have to maintain one common CI and config changes. Yeah, and why am I telling this? Because of course it's open source, you can join us, you can use it in your own Android library so you can directly benefit from our ideas, from our help, how to create test setups, how to use it, and of course also you do not have to duplicate the word work and there's no limit. If you add any code which is only purely needed on your Android app, it might have still other Android apps in the future, so we can remove those unneeded things right now with ProGuard, so it has no problem to add those codes. And that's all, I don't have an exit slide, so thanks for that. Toby, thank you so much man, awesome work.