Welcome to Android bites, powered by Esper, the podcast diving deep into the world of Android. I'm your host, Michelle Ramon. My co-host David Ruddick was unable to make it this time. So you'll be hearing even more from me this time around. Fortunately, we've got a great topic and guest I've been wanting to talk to for a very, very long time. We're finally dedicating an episode to talking about Google place services and that it's so complicated. It's basically Android's black box. This one app powers. So many different features, people think are actually part of AOS P and provides so many crucial APIs, which many apps depend on. It's a single biggest differentiator between AOS P and GMs, Android, and is both how Google is able to provide so many different features, services and APIs across Android devices, as well as lock those devices into their ecosystem that lock in is something today's guest takes issue with. On today's show. I'd like to introduce Marvin Feld, the principal maintainer of MicroG a free and open source reimplementation of Google place services. Welcome to the show, Marvin.

Hi, thanks for the introduction Rashi.

Yeah. So before we dive into this topic, I wanted to ask you to tell us a bit about yourself. What do you do right now? And how did you get your start in?

Right now I'm basically an open source developer. my main job is really open source development. I'm also freelancer for allowing me to get some more income so that I, can focus on open source development, which is not that well paid. And I'm mostly working on two projects. MicroG which you just mentioned and Dino, which is an instant messaging app, and yeah, in the development I started, I think around 2011, I got my first standard Android phone which was a HTC desire HD in case anyone remembers that device. And yeah, I seen begin thinking with it and playing around and things like that. And yeah started also developing first steps at that time. And. Around I think 2012, I already completely ditched Google services from my phone. that was basically also the time where I started also developing what could be considered the first precursors of MicroG which is an alternative to the network based location provider and an open source implementation of the Google lock in service. So, yeah, that's how I started into this

2011 was a wild time in that, era of Android. I think most of us in this, the tech industry who cover Android, for a living nowadays, we all started out like, Shopping around on XTA because the, stock Android experience on phones back then was just generally not very great. So, custom ROMs and all sorts of wild modifications were, really hot back then. But, nowadays it's not as popular. There are still a thriving community of users who want to DEO their devices and they want to, own the, the software running on their phone. So MicroG is a crucial project in enabling users to DEO their devices. But before we dive into MicroG, I wanted to lay down some background information. So our listeners are all on the same page as. So Google play services, it's present on all GMs and Android devices without exception. It's part of GMs core services. And in fact, Google even calls it GMs core internally. So we've talked extensively about how GMs is licensed and why OEMs choose to license GMs in previous episodes. So I won't be retreading old ground here. All you need to know is that Google play services is basically ubiquitous. In fact, whenever Google provides an estimate of how many Android devices are in the wild back at IO, they said there was about 3 billion active devices in use. They're likely using Google play service to make that estimation because it's literally installed on nearly every consumer, Android device out there with the exception. Devices that are sold by Huawei for reasons. You can look up that are more political than anything else, as well as devices sold in China, which is a long standing, Complication with Google services in China. Google services it's present on every device and it powers so many features that user may not have been aware of. Like there are features that it's actually part of Google based services, but the user may think it's part of the native OS or it's just built into their phone. Can you list some of the features that users may not be aware are actually, Google place services powered.

I guess for this, we want to just, split up those kind of services that Google play services provide and categorize them a little bit because there's four types of things that can be found in place services. So one is the APIs. it does provide two third party applications so that they can have the developers of third party applications can make use of some APIs. Then there's APIs that are specifically meant only for Google apps or good partners that are not publicly documented anywhere, but still exist inside play services. Then play services also extends the operating system directly by hooking into Some functions that AOSP provides allowing to extend features of the operating system. And then play services also has features that I would say are more like standalone features, which any app could technically provide, but for some reason, integrated into play services. So for each of them, there's probably a few things that people are not that familiar with. for the public APIs that are often used by applications I think the one that people most often do not have insight that this actually is Google things happening on that device is when applications have the QA code reader like, any, I dunno, share. Bike app or whatever. Then you have to unlocked the bike with the app and you're scanning the QR code and that part already ISS play services. So there's no obvious link to Google technology here or anything related to Google, but still it is running play services.

Oh, sorry. I just wanted to step in here just to list some user facing features, like I prepared a laundry list of features, cuz I kind of wanna give. A picture of just how massive this single app is and how, much it does. if you're familiar with the fine, my device feature, which is a way for you to locate your lost or stolen device, there's an app for that on Google play. But all that app is just a front end, the actual service that does the location tracking and, syncs with the Google servers is built into play services, Google pay and wallet. Sure. There's an app for that, but the actual service that handles adding your card and holding your wallet and making contactless payments, that's all in place services, the auto fill service that's place services, parental controls, the family link app. You can download all that does is let you manage settings. You have the backup support. So whenever you're setting up a device or you're making a backup that's play services. QR code scanner and Android 13, or the one that apps can integrate. As Marvin mentioned, fast play services, fast pair nearby share Google cast, the new game dashboard, Android, 13 Chromebook syncing, Google security, checkups, smart lock. There's just so much that Google play services does. That usually may not even be aware are actually provided by the app. And of course these are user facing features, so that's not really an issue if they compete with functionality offered by other applications, but there are also a lot of APIs that it offers that I think will, you'll start to understand why it's beneficial and a downside to have Google play services centralize all this. can you list some of these APIs that you were about to get into that? Marvin, can you list some of the most commonly used APIs provided by play services?

So I think the most popular API is probably the push notification API and the Google maps API. So whenever a map is displayed inside an application then that's a Google map's API typically. And whenever you yeah, somehow receive push notifications and that's the Google cloud messaging API for push notifications. So nowadays called fire based cloud messaging. Those are really, really popular APIs then also the fire base API set of fire base functionality set is handed. Through place services as well. So, that's applications making use of of Firebase authentication, Firebase database and a lot of these functionality that's provided by Google, which is for the Firebase SDK, which is meant to allow easy cross-platform application development. All of these functionalities rely on on play services as.

So you mentioned earlier about you originally started out MicroG as providing an implementation of the location provider. Can you explain what exactly Google based services deals with in terms of location? Like what does it offer to apps?

Okay. So, basically there's two parts to the location story and play service. First the operating system has some extension point where technically the operating system provider, which on a normal end device actually is the device manufacturer. Can inject some network location provider, which then when applications would like to request the operating systems or ask the operating system for, for what the current location of the devices they can either use the GPS or they can use the result from that network location provider. And then play services obviously provides one network location provider. But often enough the network location provider is actually overwritten or a different one is used by the operating system. Interestingly Qualcomm as one of the major manufacturers provides an alternative and many devices, actually, Yemen manufacturers decide to ship that and on their device instead of having Google play services enabled by default. That's why at some point Google made a new API called ause location provider API, which is basically an API that has the same feature set as a system location API, but would never use the system provider network location provider, but always use the Google location provider. So Google will learn about all network location requests and all of them goes through the Google API and never through any manufacturer decided network location.

So I can understand why developers would jump on using the maps API provided by place services. I mean, I think we can all agree that the quality of Google maps is just significantly better than other mapping services. But when it comes to push notifications through fireplace cloud messaging and, location, access through views, location provider, like I don't think it's leaps and bounds better than. services. So why do so many applications? Use these APIs instead of, alternatives, what is the benefit for app developers and why do they use them?

So, for app developers say app, the benefit that if they use the play services API or the Google provided APIs here, then they basically have some good documented and already provided code for that. So that's Google really has the advantage of. By providing the official Android documentation, they can easily get developers into using also their not open parts of Android. for example, look into the location provider API, the an a S P and the documentation for that you would actually then just directly in the head, I get an like the upper part, get some information that says basically, yeah, that C and not that good API, please use location provider API from Google play services instead. So, Google is really making obviously use here of being the first party for any information about the platform. And then the other part for push notifications. It's also the part that the play services provider for push notifications is already installed on every device. So, you already have that installed and you cannot easily Have set up an alternative push notification provider because those need to run always in the background and the aggressive battery safety measures of Android will make it impossible for certain parties to provide a push notification provider. So the only option that you actually have as a developer or the only really good option is to use the one from Google. it's also to some degree, just not having any options or any choice here. There's even libraries for developers that allow you to use the push notifications of Google or any other provider that is installed so that if you are on one of the few devices that have something else, you could actually use something else, but in practice, it will always be the Google push notifications. Anyway.

Right. I kind of wanted to, follow up on the point about push notifications because it's a really complicated subject. on a desktop PC, you can assume basically you have unlimited power, so you could have any number of push notification frameworks running, and it wouldn't really impact the overall system health all that much, but on an Android device, which you assume to be battery powered. If you have 10 different push notification services, all running, foreground services and, having these alerts come in, you want them to be real time alerts. If you have so many different things running at the same time, you will. Less of a chance for the device to enter its device idle state, or do mode as Google calls it. And so with Google play services, which is, allow listed from do mode and, any kind of network battery saver mode, it's able to. Actually react to push notification events in real time without having to be restricted by Androids, do mode and battery saving features, which are intended to save battery life. It's both. Reducing power usage, consolidating push notification services. But at the same time, it forces everyone to use fire based cloud messaging, which also means that push notifications become entirely dependent on Google. And there's one market where this is completely not true. And that's the Chinese market. And I wanted to ask you, Marvin, do you have any insights about the situation in the Chinese market? can you talk about. The decentralized push notification the other APIs there, because Chinese and your devices don't have Google play services. So can you talk a bit about that?

I'm also definitely not an expert on that, but I know there's several basically push providers in the Chinese market and often enough apps just provide their own version of a push provider. Or the, also the operating system comes even with multiple push providers installed already. Then the application can connect to those and have an option which push provider they want to use. But on the other hand that makes all the. Other Chinese custom versions of Android often having very weird behavior when it comes to battery optimization. So it can easily be that an application that works great on our GMs Android device will just not work properly on this Chinese branded ROMs because. the battery saving measures just, work completely different. That then basically causes maybe even more issues than just having the OID way, how Google does it. But I wanted all to chip in on the issue of push notification on the battery. I think there's generally a little bit. Misconception that if you have multiple push notification providers that would not significantly actually increase the battery usage because each of them, as long as it's only a push notification provider could be a good, well done efficient push notification provider, similar to how a DMS. Actually is in the, at least for the push notification part is very good in, in battery efficiency. But doing that three times or running that three times will not have any significant impact on the battery because basically that. A push notification provider that runs always in the background would just rarely actually cause any network or CPU activity because you just have to keep a persistent connection to the push notification server side and for a connection to be kept persistent. You just have to send some ping packet around two times an hour. waking up the device two times an hour to send just a single packet as obviously not a lot of resources, but doing that 10 times and sending 10 packets would also not be an issue if at least those 10 packets are sent at roughly the same time, because then you still have half of the hour that you can be in those mode and just wake up, send 10 pickets and then sleep another half an hour. And then basically you still have the same battery consumption or similar battery consumption than if you have just one push provider. So the issue is less that multiple push providers would need needing more energy. The issue is more that most alternative push providers that exist are just far less. Well done than the Google one. And that then obviously has other issues because the operating system would already take care. So AOS P already takes care of synchronizing those network requests so that they are at the same time those ping requests. So that would already be possible.

Okay. Yeah. Thanks for the insight. I wasn't really sure of how quantifiable the power use actually is from having multiple push notification providers. But I guess the user experience might be impacted because to have each of those. Per running persistently, even if the battery drain is negligible, they'd still require foreground services. Right. And that would thus require them to have, persistent notifications. And then you have all these different, notifications running for each app that needs to have notifications being sent. And then, notifications panel becomes kind of a mess. And yeah, I can see why, like a lot of OEMs, Chinese OEMs, reacted so aggressively with their battery saving measures because they can't really guarantee that a user is only using maybe one or two highly efficient push notification services or their apps are using are using those efficient push notification services. So they kind of respond with these highly aggressive background management features that are often enabled by default and. Those features are often enabled even on the international versions of their devices. So you have Western reviewers complaining about their apps, not working because app developers are expecting a S P like behavior, but then they're encountering these Battery saving measures that aren't really comporting. They aren't really following CTS and what you would expect on an AOSP device. So if you're wondering, the root cause of these aggressive battery saving measures on mostly Chinese branded OEM devices, this whole. Decentralized nature of the Chinese market without access to Google play services is the root cause it's to blame, but that's not being said, that is one benefit. One like tangible benefit to having a centralized, Google play services provider, providing all these APIs and services. But of course the downside is that. In the west, at least kind of most app developers. You kind of assume that if you're dealing with an enter device, it has Google play services installed, and that's not going to be true on every device, especially if you are a power user and you opt to install, an a O S P. Custom RO or you DEO your device or, you'd like to customize an off the shelf device for, enterprise use, then you're not going to have Google play services installed, but because most app developers assume it's there, they don't use the, libraries that Marvin mentioned that allow the app to actually change providers based on what's available on the device. So I wanted to ask you Marvin, can you talk. The experience of actually using an app that depends on play services on an AOSP device that doesn't have something like MicroG installed. What can users expect from their experience of using these apps?

Well, if the app really completely relies on play services, then often enough just start trying to solve. It will basically the app will just show in dialogue saying you need to update or install, play services. And if. Say yes or, okay. It will try to open the play store, which then doesn't happen because the play store is not installed and then will just not work at all. Some applications are a bit let's say more, resilient to that situation. But the behavior often is not, much better so often. For example, if if you have an application that shows Google map, API embedded normally, and then if play service is not installed and you are trying to open the part of the app where the map is shown, it would just crash instantly. So that's one thing that you can. Then obviously you have to issue that if the application silently ignores the fact that it does not receive push notifications, then the behavior of the application might make it completely unusable. Think of maybe WhatsApp, just without getting a notification for incoming messages. I mean, that would be completely useless as an application. If you always would have to open WhatsApp just to check if there's a new message or some applications even worse. Rely on the push notification system to actually show the notification to the user. So even if you would be opening the app manually, you would still not see the information that would be coming through the push notification. So some apps are really bad in supporting non GMs devices and behavior can vary lot. What you see a lot is really applications showing some popup saying you need to update, play services that are common. And then if you ignore that popup then what happens afterwards can be basically anything. and you're on your own if you try to use the app in

that situ. Yeah. And just to reiterate play services, the APIs it provide, it's not just push notifications and a location provider and the maps API. There's a laundry list of APIs that it provides also including Fido. So for authentication purposes, the new ultra wide band API ML kit you can provide in like a barcode scanner, as Marvin mentioned, play games. So if you're, wanna synchronize or store games, data, Google servers, safety net at a station the wearable API, if you want to transfer data to a wears device, Google fit, and any apps that use, fire base for analytics data, although, play services, doesn't directly provide it. Those SDKs do depend on play services being installed. So you might have an app that's completely nonfunctional or just crash on launch because they don't have an exception. For in the case of play services, not being installed, you might have an app that's just missing some functionality. Like, as Marvin mentioned, you not getting notifications, or you might just have some, one or two obscure bugs that you don't even realize until you actually try to, enable the feature. Your mileage is going to greatly vary because they. Don't really account for the situation where play services is not present. They kind of assume it's there. The vast majority of, apps distributed on Google play assume you have play services installed. And when you don't, you're on your own, you gotta figure things out. And there are websites and tools you can use to figure out, Will this app actually work? Will it work well on my, a SB device? You could install an AO S P build on in theor or a GSI on a real device and then run it and then just see what happens. See what's working and what doesn't work. You could also, inspect the APK to see if there's any, included permissions or libraries that, relate to GMs functionality. There are third party sites like plexus that, are user contributed and Exodus, which, analyzes, trackers. you could see if there's any fire base or any GMs or Google ad services. Like. Libraries integrated, but overall really you're on your own. You gotta test the app. You just gotta, if you know the app, and if you develop the app, then you probably know what you're using, but if you're a user of an app, then it's tough to actually work around and getting a lot of your favorite apps up and running. One thing you can do is install MicroG and while it doesn't provide every feature and API that Google play services provides. It does provide some of the core functionality or reimplement, some of the core functionality. So I wanted to ask you, Marvin, can you tell our listeners exactly what is MicroG and how does it, solve the issue of a lot of apps being completely broken or having key functionality missing on AOSP devices?

Sure. So, Myrie is basically just to complete reimplementation of the play services. But obviously it's not complete. So, it's currently only implementing as upset and it's very likely that it will never provides the full functionality just because Google is also constantly adding new functionality to play services. So, will be impossible to keep catch at any point. But at, at least for the APIs provided to a third party it's basically already good enough to have many apps working far from supporting every app. But yeah. also heavily depends on the functionality needed by the application. So just to give an idea which APIs have provided obviously push notification is provided so that applications using Google cloud messaging or fire based cloud messaging can receive push notification a location providers available Google maps, implementation based on actually open street map data design, and. original Google web data because that's not available to set parties functionality for safety net, which is used by a lot of banking implications. the QR code scanner that I mentioned is also available and then a few smaller parts where we try to at least have some. Stop implementation, implementation that is incomplete, or doesn't actually do something useful, but we'll make sure that the application trying to use that API will at least behave more useful than than if it wasn't present at all. So for example, if an application wants to use, Google drive API to access your Google drive contents. Then we would just return that your Google drive is always empty, which is still better than having the application crashing. Of course. So, yeah, that's something that, is in, in MicroG for APIs that are not actually properly supported. And yes, that's all the features, basically the idea of what MicroG can provide. So that third party applications get, the functionality back that they originally were meant to have. We are really focusing on the third party APIs and not the other parts of play services. Although it's always also interesting to look into those and. It's always motivation to also look into maybe implementing some of them but supporting applications or that wanna use the third party. APIs is much more important right now.

Yeah. So, first of all, I wanna really applaud you guys, you and whoever else contributes to MicroG because play services, as I mentioned is a complete black box. It is proprietary and closed source and there is no public documentation for all the features that it offers. So like being able to actually. Peel back the layers of play services and provide some of the same functionality in a way that's transparent apps is a really impressive feat. And it's a constant challenge to actually keep up with play services because through play services, Google is able to just roll out new features like that. The earthquake alerts, the air raid alerts, the COVID 19 exposure notifications is a big one where they, within a matter of months, we're able to roll out this feature to. Billions of devices around the world nearby sheriff is another one. And like all these features it's like being able to keep up with Google is not an easy feat, especially because none of these are open source. So, yeah. Great job on MicroG. I did wanted to ask you though, you implied this basically that apps don't really have to actually support MicroG. They don't really know that it's MicroG installed. They're using the same Google drive API call, but instead MicroG will feed them that the drive is empty. So instead of crashing, they'll just return empty, receive empty data. So this kind of implies that you're kind. Replacing Google play services transparently, but I wanted to ask you about this actual process. Like how do you actually install MicroG in a way that makes apps think they're talking to play services, but they're actually talking to MicroG.

Yeah, sure. So, maybe some history here. I mentioned I was doing the network location and Google look in manager. And also back then, what was called the Google services framework. And for all of those services, they work, they, came pre-installed on the device, of course. And they basically had. API, which on Android is basically specified using a service name and appropriate Android interface, definition, language file, which is. Then used to specify how to connect to that service. All of these services that Google provided previously had those available, and that was how applications were meant to access it. So basically replacing those. Was super easy because I would just have to provide the server side of those and install my application to, or my very end of that Google service to the system petition just like, the original one was. And then the application would just pick up that one. And because I provided a service which runs on the same intense filter. that's absolutely no issue. And when they introduced play services, they had the issue, they were doing something that was new. So, back then play services was not shipped on the device nowadays it's part of the system as well as any other Google system part, but when they originally introduced it, in the times of, I don't know, Android four got something, I don't know. Then They had to install it as a new application. Basically it was automatically installed through the play store, but still it was a new application that was not shipped with the operating system. And for that reason, they had to do something new to protect applications from using some malicious version of play services that could exist that Would then be installed the same way that play services installed, which is just a normal application at that time. So anyone could actually install, play, or in any play services thing could be installed because you could also just like a normal application, uninstall play services and then install another one. For that, they introduced some signature checks. So. Application that the third party application that tries to use play services will first before accessing as our APIs, which also are not that easily documented anymore, but that's another a story I would say. Before they did allow doing that they actually, connect to the service provided as a normal Android service they would check the signature of the APK that claims the package name of play services. And That became a major issue for developing something like MicroG because if MicroG would just take place there, the signature would not match. So the third party application would say, okay, the signature does not match and behaves basically as if. MicroG was not installed. So we had that issue. And the solution that I came up with is basically a small patch to the operating system that when the specific call that the applications or the place services, SDK, that applications use. To find figures out just the, the signature basically replacing that call or changing that call such that it returns the, the Googled signature, even When the MICG version of the, of play services is installed. So that is very good way to work around that issue, but unfortunately requires modifying the operating system. So installing becames much harder because it's not just, pushing some APK on your system petition thing, but it became. Modifying a S P itself. So yeah, but that's how we can basically transparently act as if we will play services. We're providing just the very same API and through that modification that is called signatures proofing. the application that normally would use play services the operating service system will just tell. That the MicroG version is the same as if it was the original play services version. So that's how we can do it completely trans.

Awesome. Thanks for that explanation. We've actually talked about this briefly in our previous episode where we invited a developer from graph OS to talk about their sandbox or they mentioned their sandbox play services implementation. So I recommend going back and listening to that. It's a alternative. To the MicroG approach, but both are completely valid. And so I don't really wanna, compare them here. I did wanna ask if you can share some additional insights into the play services app itself, because from all we've talked about, this laundry list of features and APIs and services that it offers yet on my pixel six pro the app itself only takes up. 550 megabytes of storage. And, I'm kind of surprised by how much it's able to offer without being way bigger than I thought it would be. So can you talk a bit about the actual structure or place services, how is it able to offer so much and yet, not take up multiple gigabytes of space.

Okay. So I, guess if you're talking about 500 megabytes of space, then that's probably already including the data part of the app, because I think the APK download itself is probably going to be, 100 or 200 megabytes only right. I'm following that. I'm not following that the amount, but should be around that. And that's because. other parts of play services can also be fetched later. So, Google invented some system here that allows to basically load modules of. From the Google server with status that do not come with the APK itself. And those modules can also be removed if they are not used anymore. Although that typically does not happen a lot. So once you have an application that uses an API that is only provided through module, that is an external module, then obviously you typically continue to use that application and then there's no way to uninstall. Module again. But yeah, basically they have a package manager inside place services to make sure that the needed features are there when needed. But that you do not need the full space for all the features all the time. But I also think that another trick that they do is what you already mentioned that for many of the features, like find my device, things like that., they have an extra app for actually using it. So while the core technology itself, the logic of the service is inside play services Also big parts of applications, which is, assets like images, user interfaces, and so on. That's not part of play services or often only parts of it part of play services. So that makes it easier for Google to. Ship all of these basically have find my device installed on your device already inside the play services. But if you want to use it and you need the user interface, then you'll download another package. And that can give you another few megabytes storage just for the launcher application as to say because that has the assets that are needed to, define my device and the same applies to other functionalities as well. Like, the Google pay, for example, it's a similar situation there.

Yeah. And often from what I see, Google tries to. Make these features appear as if they're, natively integrated into the Android OS by, some mechanism in the settings app itself that allows other system apps to inject their preferences by having like a special intent filter defined. And then, Google goes the extra mile in theming, a lot of these activities. So they feel like they're built into settings. a lot of these features, even though. Part of it is provided by play services. Part of it's provided by another app. You download, it all feels cohesive and part of Android itself, even though if you download a OSP, all of these are missing. there's just so much provided by this gargantuan mega app that you just probably will never be aware is actually provided by play services. Although it is quite easy to tell, is something play services or is it this actual app? Like if you open a settings page and then you just swipe up to the recents app, And then you long press on the app icon. If it says play services, that means it's part of play services. So it's actually pretty easy to find out what apps actually providing the functionality. Although it, it gets a little Meier. Once you start digging into the details of some of the backend APIs and services. I wanted to ask you, Marvin do you know of any APIs or features that were first baked into play services, but eventually were open sourced and added to AOS P like, do you know of anything like that?

we've seen quite a bunch of the other way around, like I mentioned location is basically just the situation. There's also GA fencing which basically allows you listen for the event of, being at home or at some certain spot in the world. That also was originally provided as a, a S P API. And I think technically it still is, but it just doesn't work on the as P API. So you have to use the Fu location provider for that as well. So when location we see is pretty much the opposite side but I, I'm not sure if there's really anything where they did it the other way around. They promised it to do, for example, for the exposure notifications, the COVID 19 API. Which when originally they said, yeah, we do it in play services because because you wanna ship it as fast as possible, but we will make it open to and put it in ASP in the next release. And then that never happened because nobody really was asking for that. And obviously they were not really interested in doing. Because they were already happy with the situation inside place services. So there was no need. So, I'm not really aware of Google opening things up that, they previously made close. So that's, that's something I, don't think would be really much in their interest. Although there could be something which I don't have in mind, right.

Now that you mention it, you do remind me of announcement. They made at Google IO about the cross device SDK, which was just released for developers as a beta. That's provided through place services right now, but at IO, they did mention that that was going to be added to a O S P with Android 14. So we'll see if that ends up happening year from now before we. Move on, to the closing things that I wanted to ask you, we've kind of made an assumption that if in SDK is offered through Google place services and an app tries to use it, and Google play service is not installed on the device. That, that functionality won't be possible. It won't be usable. Are there any SDKs that, an app can actually integrate, they can have a thin client for, and that even if play services is not installed, that functionality will still work regardless. Can you name any examples?

Yes, there's actually a few of those where if the app developer knows how to do that, then they can have it. and for some of them it's also the default or Google really pushes developers to do that. And I think the one where they really do that is the mobile ads. So that the advertisements are also shown on non GMs devices because that's also good for Google if those ads are shown. So they are interested in having that SDK shipped on as many devices as possible. And third party providers doing that for them's also good for them. So, that's why they do it at, for the mobile that, but there's also few, I think the the ML kit can do that, which is used for the uh,. RI for example also Google analytics can do that. if the app is using Google analytics or Firebase analytics for many of the Firebase services, that's actually technically possible, but many application developers do not. Make use of that or Maybe it's just not possible because they are not releasing the packages. So, at least from, what I can see on the MicroG side, how the requests are done I know that technically it could also be bonded for basically all of the fire base APIs. So, yeah, generally bundling some of the SDKs directly with the application is something that's possible for, some of the APIs, not all of them, of course. But yeah beside, for the mobile that I don't think it would really push us or lets developers know that this maybe a good idea. They would just not tell the user or make it a smaller site. And then they just have that feature because it might be just, it's a requirement for more providing that API for, I don't know, maybe some government or things like that, so they have it. But they don't really push developers to use it.

Right. And this is the part where I'm going to be plugging Esper, because if you've been listening through this entire episode, then I'm sure you'll agree. That play services is really, really complicated and it's not easy figuring out whether or not you actually. Need to have it installed on your device. And if you're an enterprise that asks questions about whether or not your fleet of dedicated devices needs play services and thus Google mobile services, come talk to us at Esther deploying GMs. Android may help you avoid app compatibility issues, but it's not always a fast, straightforward or cost effective solution. And it's certainly not one we recommend navigating yourself. If you have a kiosk point of sale terminal or exercise machine, it doesn't need full Google play access. But an app you want to deploy to those machines may need some APIs that are provided by play services, or it may not. We at Esper have extensive experience with building and deploying AOSP onto dedicated devices. So we can help you deal with any app compatibility issues or questions you might have on this front. Visit our website@esper.io to learn how to transform your device fleet. So, Marvin, before we calls off this episode, I wanted to ask where people can find you. Do you have any social media handles messaging at profiles or any chat rooms where people can find you in.

I am on, MasterONE. So, if you are happen to be a MasterONE user, which is an open federated alternative to Twitter then you can follow me there my nickname Lama, which is L a RMA. If you uh, want to do something else. Technically, I'm also available for chat on the X and P, which is also federated tech network for, for chat systems or instant messaging systems. So I'm available there as well. And you can probably figure out under which name and yeah, but you won't find me on any of the big social media platforms, because I just don't use them.

Yeah, you really adhere to the, Dego life I had to install Dino. I am on WSL on my windows PC, just, to chat with you for this call. And I'm glad you responded though. I was kind of worried. I wouldn't be able to reach you., but thank you for taking the time to join us on Android bys. And one last thing, if people wanna learn more about MicroG, where can people go to, maybe download it or just read up on it?

Yeah, we have a very small, probably not so good website. It's microg.org. But you can also from there, go to our, and there, they it's. Implementation of GMs core. That's a nice, nice Wiki where you can get some information you can also find a lot of information on third party sites. So that's we, we are kind of a bit weak on good documentation, to be honest. Also, especially for developers that wanna join If you happen to be a person that is interested in contributing to, to MicroG, then that's also very good reason to just get in touch with me directly. on X and PPP or using Masteron or if you're not on that, you can probably also find my email address on the internet.

Yeah. And if you are looking to DEO your device MicroG is definitely one of the top. Solutions you'll be looking at, along with, maybe a few custom ROMs, like graph OS that we've talked about before or lineage OS which is another popular option, but there are many different ways you can, take control of your device. It's whether or not it, you gotta evaluate your own threat model, your own privacy needs and, consider is this a route you want to take? And there are some challenges involved. But there's a vibrant community of people who have gone through this already who have, documented some of the worst offenders when it comes to AOSP compatibility. But I say this is someone who has used a Huawei device, which completely lacks any GMs, compatibility that it is usable. it's not something I'd recommend to my parents, but it's something I could definitely use on a day to day basis. So give it a shot. If you are interested in, removing access to Google play services or GMs, or just de Googling your life. And thank you again, Marvin for joining us and thank you to everyone for listening to another episode of Android bites.