Forum Discussion
Private app package name already in use
I got an APK from our Digital Signage vendor Poppulo (formerly known as Four Winds Interactive) and tried to upload it as a private Google Play app through the iframe in Intune. Got this error: ...
Custom DPC just offers significantly more control over fully managed line of business Android devices right now. Google wants everyone to move to AMAPI but they've largely neglected the line of business device use case on AMAPI and don't offer parity. I don't consider any AMAPI only EMMs like Intune to be capable of effectively managing line of business Android devices and won't ever think that until Google can get close to parity. I don't care if Google wants to deprecate Custom DPC they need to continue to hear that they aren't offering us a valid alternative in AMAPI yet.
If you were using a Custom DPC based EMM for example you'd be able to install this Poppulo app directly on your devices without any question. You're frustrated that Poppulo isn't aligning their software release practices to the limitations of your own EMM.
Thanks for your perspective. I suppose I'm only left with one question: how much work is it to publish an app in Google Play? The apk they gave me had "googleplay" in the file name and I'm not sure what to make of that. Really hope this isn't a triggering question, just trying to learn here.
Publishing an app through Google Play, even Privately, carries an additional layer of burden and scrutiny than just compiling an APK and providing it to end customers that need that app installed on their devices. There are extra requirements that Google enforces when uploading a new version of the app followed by an approval process wherein Google will review your app, sometimes over the course of multiple days before approving it for distribution, even privately. I am not sure about you're environment, but I deal with mission critical apps in the sense that if the app isn't running or working correctly a warehouse or retail store is down. These operations depend on the mobile apps we develop for all workflow execution in the building, payment & order processing, etc. If an end customer of mine needs an emergency upgrade to their Point of Sale mobile app or their end user warehouse execution app I don't want to tell them they have to wait an arbitrary amount of time for Google to approve the new app before they can install it on the devices that they own. Businesses that own their own devices and the software that runs on them don't typically want Google in the middle deciding what they can and can't install on their own assets. Many of Google and/or Androids features are built around consumer protections. I personally deal exclusively with corporate owned line of business shared assets where there is no consumer to protect. In these situations these extra restrictions and scrutiny of Google become a burden. I've also only really covered the delays in the app approval process in this response. This also doesn't even touch on how long it can actually take to deploy an app through managed play to a fleet of dedicated devices and the lack of proper version control. Once the new app version is approved that is only half the battle to getting it rolled out across a fleet of devices.
I am honestly a little jealous of the perspective you have coming into this Android management space without any background experience of Device Administrator or the widespread usage of EMM API and Custom DPC prior to the push toward Cloud DPC AMAPI. To you this might just be how things work, whereas I come from a perspective of being frustrated that it used to work better for admins like myself and Google has made certain things progressively worse over time. I'm just constantly bitter that the dedicated device space is mostly ignored by Google but then we still get caught up in the trends toward concepts like Cloud DPC and AMAPI. I can't name a single end customer who was happy to go from DA to AEDO, and now potentially from Custom DPC to Cloud DPC. Each one of those steps is progressively worse relative to the ability to comprehensively manage a mission critical dedicated Android device. I find it interesting that the perspective of newcomers to the space is that the app developers are at fault here for not aligning with Google Play when my perspective is almost the exact opposite. As an app developer and EMM admin I have a view of the space that is more developer centric than EMM centric. I think the EMM, at least for the dedicated device space, should be selected based on the needs of the mission critical apps that it is supporting and I don't agree that the mission critical apps should have to change their distribution mechanisms or design approaches (eg. config files vs managed configurations) to comply with the limitations of the EMM. As much as I am an EMM fan and expert I am not afraid to acknowledge it is an ancillary support tool and not the primary business function compared with the business apps running on the devices.
I admittedly somewhat of a contrarian in this viewpoint but feel the need to constantly speak up for the dedicated device space in the Android community as I often feel like the voice of that management use case. So please take what I have to say with a grain of salt and understand that my lens on the world is completely based around the Device Owner / Fully Managed/ Dedicated Device/ Line of Business use cases.First of all, I just want to say there are so many interesting things happening in this conversation and I'm happy that we're having it. I understand your perspective and I think we are both coming from vastly different organizations/use cases so let me tell you a little bit about me and what my work looks like:
I work as a systems engineer at a university. Historically, we've only managed Windows machines, Macs and iPads. We've only just begun managing Android devices this past year, which really excited me as a long time Android dude. It was initially a project to deploy 20 or so tablets to faculty that taught online classes so they could more easily annotate with a pen and touchscreen. There's some drama that happened with this project that I won't get into but ultimately it got axed and these tablets aren't used very much. This was very disappointing for me as I put in a TON of work to get it off the ground and built some pretty awesome custom integrations with our asset management system, Intune, Entra, AD and ZTE. But that aside, it did open doors for us as we are now ready to manage Android devices and can offer them as solutions to our users.
Cue Poppulo and digital signage. You already saw my post on that so I won't re-hash it. But basically we want to move away from Windows kiosks to run the Poppulo app and start using some sort of Android solution instead.
So for us, Android devices and the apps that run on them are not mission critical. This is what sets us apart. Digital signs just sit on walls and display information about the university and the academic department they are in front of. If they go down, nothing bad will happen. Another thing is that as a university, we're limited on funds, so we don't always have the pleasure of choosing our software. We have to work with what we have. That doesn't mean we never spend money on software, we do, but we have to be efficient with our choices. Since we are a Microsoft shop, we get Intune for free so it just makes sense for us. Doesn't mean I love it, in fact, I downright hate it most of the time (mostly on the Windows side). These digital signs aren't mission critical so we don't need to go choosing an EMM that supports Poppulo. In fact, if I had it my way, we'd choose a digital sign software that works well with Intune. I think that's another way we differ as well: you're working with mission critical apps that are a part of a large process/workflow and you can't just switch to using something else all willy nilly. It makes sense that you'd choose the EMM that fits the app rather than the other way around. But for us it's the opposite.
My goal as an IT admin is to make our processes as automated and simplified as possible. That way, there's less room for error when technicians are doing deployments and a future admin can easily manage the configurations and understand how to support the system. If we could switch to using a digital signage software that was already available in the Play Store with a managed configuration and deploy the Elo backpacks everywhere, this whole thing would be a BREEZE. Google Zero Touch means they're ready to go in minutes out of the box, it's practically plug and play. All the technician does is mark the device as a digital sign in our asset management system, plug it in and the integration takes care of everything.
Your comments on Google's neglect for dedicated devices brought up an interesting thought for me:
I went to Microsoft Ignite last year and attended a session on "frontline worker devices". They talked at length about how they are working to support Android devices for frontline workers. They're doing things like supporting "specialized devices", enabling FOTA deployments for Zebra devices and continuing to enhance their Entra shared device mode (enables ephemeral multi-user mode like jasonbayton is wanting from AMAPI). This was obviously irrelevant to me as I don't work for a business and have no frontline workers. But it seems at least for Android, Microsoft is very focused on the dedicated device space.But this is in stark contrast on the Windows side. We have many computer labs and shared spaces at my university as you can probably imagine. Microsoft's support for shared Windows is dismal at best. Every new feature or product they roll out is always user-based rather than device based. It's wild to me that I still have to write a script in Intune to deploy printer objects on a shared device. This was so easy in Group Policy. MS made Universal Print, but it's all user-based access which doesn't work for us. MS is focused on businesses and I get that, education orgs aren't as important to them, they give us free student licenses after all. But anyway, I think it's interesting how Google and Microsoft approach dedicated devices so I can relate to your frustration on the Windows side.
A last note on developer perspectives, in addition to managing a team of systems engineers, I am also a Computer Science student (free tuition if you work full time :D). So I am slowly learning the developer perspective more and more. For example, the rise of web apps. Google has been on the web app train since pretty much the beginning and that's kind of been their shtick. Microsoft is starting to do the same, all their native desktop apps are becoming progressive web apps, the biggest one of late is Outlook. It's been a pretty controversial move and I noticed that I had three different perspectives on that:
- as an IT admin, I love PWAs because their easy to manage. Easy to install, easy to support.
- as a developer, I love PWAs because you don't have to develop native apps for each platform. Just make a really good web app and then wrap it for desktop usage.
- as a user however, I sometimes hate them. Google's are pretty good but in the case of Microsoft Outlook, the experience is sub-par compared to Outlook classic. Everything feels slower, features are missing and I don't feel like I'm as productive.
I just mention that to say that I am constantly thinking about different perspectives. With your help, I now understand the work involved for Poppulo to publish their apps in Google Play. Even for such a simple app like this content player that doesn't do anything besides display some images and videos. It's just not something they're going to put in the effort for one customer.
This became long winded but hopefully it all makes sense. Cheers.
Incredible insights you bring to the table here. Thanks for explaining your background and perspective!
You may want to repost some version of this to the introductions thread here:New to the community? Introduce yourself here... | Android Enterprise Customer Community - 32
