Zebra DevTalk | Android 14: What's New for Enterprise Developers | Zebra
Good morning, good evening or good afternoon, depending on your time zone. Welcome to our Zebra Dev Talk. We are thrilled to have you with us for a discussion on Android 14. What's new for enterprise developers? Next slide, please. Next slide, please. Yeah, thank you.
So before we kick off, let's quickly cover some housekeeping items. The webinar is being recorded and will be up on YouTube in about a week. All attendees are currently muted. If you've got a question during the session, please use the Q&A feature in Zoom. We'll have a Q&A segment at the end and we'll do our best to answer your queries if time allows. Nicola, can we go back to the previous slide, please? Yes, thank you.
Also be sure to use the QR codes that will be shared with you throughout this presentation. So before I hand it over to our presenter, Nicola, I wanted to share this quick video highlighting our Zebra Developer portal and all the tools, resources and information we have available. Next slide, please.
Learn, connect, build all in one place The Zebra Developer Portal. As an enterprise software developer, you need fast and easy access to technical information, documentation and tutorials. You also want to connect with your peers, share and consume information to build your knowledge and competencies. The updated Zebra Developer Portal has you covered. Product pages give you quick access to product overviews, tutorials, documentation, use cases, forums, and blogs about specific products, all indexed with quick links to key developer information to help you build. Forums within the Zebra developer community make it easy to connect with your peers and find answers to your specific development questions to help you collaborate and build.
Community blogs feature content from Zebra engineers and other developer experts, all sharing the latest technologies and tools to enable your development on enterprise devices. Developer events provide knowledge and networking opportunities for our developer community. Be sure to scroll through the upcoming and past events for registration information and access to on demand content. The Zebra Developer Portal provides enterprise developers like you with the tools and services you need to build your edge.
With an easy to use interface, you will be sure to find the resources and connections you need to build all your enterprise applications. Devices built by us. Apps built by you? Yeah, please.
Debra is committed to empowering our developer community with the right tools and resources, and we would love to share with you the ways you can join and connect with us. In addition to our developer portal, we invite you to connect with us on LinkedIn X, formerly known as Twitter and GitHub. Don't miss our first series of developer podcast, Zebra Dev Cast. You can scan the QR code on the screen and we'll also share the links in the chart later today. Be sure to follow and connect with us. We'd also like to share two of our upcoming events with you.
Our next dev talk will be on January 22nd, which will focus on enhancing your web apps with RFID and barcode features using enterprise browser and data which Plus we will also discuss how a Gen. AI tool such as ChatGPT can be used to quickly and easily create the basis of an application before manually adding to the data web support. So feel free to use the QR code on the screen and register for the session. We are also excited to announce Zebra Devcon 2025. This is an in person global event that will connect you with the global developers and industry experts.
You will get hands on with our SDKS and explore trending industry topics. So keep an eye out for the registration link coming out soon. With that, I hand it over to our Zebra expert, Nikola de Zolt.
Over to you, Nikola. The state is yours. Thank you so much, Priyanka. Thank you very much and welcome everyone.
So welcome to this Andrew 14, what's new for enterprise developer webinar. My name is Nicola Desalta, I'm a software engineer. I'm working at Zebra mobile computing business unit. And today I'm going to do to explain you some topics, features and changes introduced with the Android 14.
But before getting there, I'd like to share just one slight thought about the anxiety in moving to Android 14 and we'll see the soon what what it means. We also have the thought on Android enterprise and then we'll conclude with the Q&A Second. With that said, let me move to the Android 14. So along the years we have seen many developers and decision makers be reluctant to proactively migrate to the next and latest operating system version. At the end of the day, your application still works around smoothly on an order OS version. So why taking the burden to to do a migration and spend effort and time on on that? We have collected me and my manager, Chuck Bolin, a chief architect at Zebra, a few thoughts about this topic.
And we have published that the link that you can see in the upper left side of the screen, but it's also LinkedIn, the dual code at the bottom right. So if you frame it, you'll directly go there and you can read it thoroughly. The key points. Let me go through the key point that we cover. So what needs to happen when you need and want to get your mobile devices and application up and running to and 14 and what do you do? What is the best way for this to to happen? So of course, you need to plan it carefully and the real reason, the real reason behind the immigration what, what are these reasons and what is the the the reason why not wait, but to wait as soon as possible. For instance, your operation could benefit of the latest security patches, back fixes and all the updates also from the Play Store.
But if you're also using and leveraging the the third parties application and libraries, these are also updated more frequently on the latest operating system version. And you also get a bunch of new features with the with it. So why not taking the chance to to use it? The migration happens because people are working on it.
So the first thing is filling the gap and learn about all the changes and the features that the latest operating system version is offering and then confirming what is the real gap of your application against what needed to run on end 14. Done that you just need to upgrade to commit in upgrading and set a plan and periodically update it anyway, really thoroughly at the link said and and once again, let's see in details what the the real interest of of it is in N 214. And by the way, Priyanka, I recalled you asked me recently an interesting question about the Android 14. Would you like to share this with our audience? Yes.
So there are many compelling reasons to upgrade to Android 14. And I'm wondering what Zebra devices already support Android 14? Thank you and and perfect. And I have arranged a couple slide about this topic. So what is the state-of-the-art of and 14 with the other mobile computers? So I take a snapshot. I took a snapshot of of the situation a few days ago and here for instance I'm listing all the devices based on the 660 platform.
You see a a very long list of well known devices. They have got one lifeguard update at the end of November. It's the first one for this platform. But the interesting thing is that is that the 660 platform will be getting the end of 14 and as the last major OS upgrade.
So an additional reason for upgrading these devices to the very least latest operating system. That doesn't mean we that they won't get anything else. They will get they'll go on with the lifeguard update program and we'll get security patches for a long time on but in terms of major releases and 14 will be the last for this historical platform. Here is another example. The 6490 platform introduced a few years ago devices like TC5358 or the well known TC 78 and so on have already got 6 drops in terms of like gather updates of Andrew 14.
Here is interesting to focus on the fact that for instance for this platform starting the first days of October, end of 14 has also been cut into production. It means that starting the day that you see in the third column here, the devices will be shipped to our distributors with end of 14 baked into it, so pre installed and another example for the tablets ET 40 series already free lifeguard updates available. Same same thing about the factory cutting. So starts since last November. These these devices are shipped with end of 14 pre installed.
Other platforms like the 4490 and 5430 haven't got yet an end of 14 version they will get soon. Always check the latest updates on the link that you can see. It's our support and downloads page on thezebra.com website. With that said, I'll go now to explain some security features. All the feature that you will be will see presented today are categorized under three main three main categories. The first one is that when a feature impacts all the application running on end 14 regardless of the of their target SDK version.
This is of course a road blocker for application already existing because you need to satisfy these requirements in order to run that application on end 14. There are then changes or requirements for application targeting API level 34 and above. You can get API the targeting SDK level declare for your application in your default configuration in the module Build Greater of each application the same way you define the application ID of your current application. There are also new features.
The new features are of course available only starting API level 34 and in this case you need to keep an eye if your application is defining a mean SDK which is lower than the target SDK. In that case, the application can run on past Android version, but you need to be careful not to call the new features when the application runs on previous API on previous Android version, otherwise it will fail or with with an exception that is shown for instance here at the bottom of the screen. So let's move to the first feature and it's one impacting all application running on Android 14. It's a minimum installable target API. Each year with the newer operating system version, Android raises by 1 the minimum installable target API level. In this case, the minimum installable is 23, which corresponds to an Android 6 Marshmallow.
You can read the details at the official Android documentation highlighted here. I did some experimentation for you and I took a couple of screenshots of what happened when you try to install an application targeting, in this case API level 22. If you do through the ADB, it fails, explaining that the failures because of of deprecation is the SDK version and it's also stating that your package must target at least SDK version 23, but found a lower number. If you try and install to manually install the application through the package manager, tapping on the files and APK inside the Android, the user interface, you get a disclaimer like this app not install, it's compatible, comfortable with your phone.
There are ways in reality to bypass these restrictions, so there's a specific switch of the ADB script to install even a lower target. But what happens when you run it? You will be prompted with something like this one name of your application, and this app was big for an older version and so on, and you're warmly invited to check for an update. If you dismiss this and you have Google Play Protect enable, sooner or later you'll also get a prompt from from it, same or less the same thing. So the message it's quite clear.
Raise the minimum target API level of your application, possibly aligned to to the current SDK version of Angel 14. About this changing of API levels and so on, I'd like to cover for a while the Compatibility Framework, which is a very useful tool that helps identify compatibility changes impact for your app. I have an example here based on foreground services and the types of foreground services that were introduced and and enforced in Andrew 14.
We'll see that later. So for instance, if you have an application targeting the APA level 29 and running from Andrew 14, well you you you have no issues about that. The the manifest of this application will simply use a permission of foreground service. But you what happens if you run it on a on a different target level. The Compatibility Framework tool helps you in detecting the potential issue by just turning on the specific feature.
It's highlighted here in the lower side of the screen, and when you run the same application on Enter 14 with this flag set, you'll get a runtime exception because it states that is unable to start a service because it's not, so it's not declaring that its type. This is a requirement of the API 34. If you want to sanitize this situation, you just need to add the media type, the type, the service type. In my case it was a media playback service type and the application runs smoothly also on end of 14. So this is an enabled.
How to use and get advantage of these interesting tool available under the developer options. This is also a way that suggests how to plan a road map to Andrew 14. Say for instance that you have an application targeting the previous API level and running on it.
So on Andrew 13 in this case, the gap between your current code base and Andrew 14 is very short, and what you really need to do to ensure that your application runs on Android 14 is just to review and check for gaps against the changes affecting all apps running on Android 14. Once you clear them, you your application runs on it in compatibility mode because your target API level will be lower than 34. But it will run and it's a first step toward the migration. Maybe I'd say the biggest. Optionally you can choose to upgrade your target SDK level. In that case, you have some more work to to complete them because there are different requirements as the one we have just seen about the foreground services types.
So you, but in that case you have the compatibility framework that helps you identify the potential gaps. Finally, you can also take advantage of the new Android 14 features. So in that case you realize for migration to Android 14. In the second scenario, your application could be targeting a much lower API level, say 29, and running even on a on a lower Android version in. In that case, you have more work to do, of course, so you have to satisfy all the minimum requirements to run on each platform.
In the advice here, we just try to align your application to the target version 34 and also fill the gaps in terms of the minimum requirement to run on that platform. Optionally, as as above, you can leverage the new features. Let's now move to the first feature that I want to present as a new feature of Angel 14. It's an interesting credential manager which is a set of API that allow multiple signing methods which has been made compatible with API 19 and it's based on Google Play Services. Through the credential manager you can you can develop several authentication workflows starting from the traditional username and password and or move to passkeys or even the Federated side solution and also leverage and enhanced autofill. All these workforce has been in depth tested by me and explaining A blog.
I shall later a link A blog which has also a linked gitab repository so it will be easier for you to go and check the code needed to run these examples. I just here I just want to share a few details, for instance about the username and password. If you want to you get an authentication workflow like the one on the left screen and left side of the screen, you need a Google account setup. Of course you need a first moment which you create a credential, an instance of the create division manager and you submit a password creation request passing the the needed username and password to to that object.
Of course you also need to manage exceptions of for instance that the user pressed the never button and so in that case you receive different types of exceptions and depending on them you can adapt your business logic to it. Familiarly you want to consume this password. In that case you simply need to invoke the credential manager and get credential API as seen here in the lower side part of the screen. Another example, passkeys, these are really the next generation type of credential of standard.
They are meant to replace traditional passwords and are based on kind of dual factor cryptographic techniques and biometric authentication. And these are also cross-platform because are based on, I understand that, defined by the web education and developed by the Filo Alliance and the Worldwide Web W3C. There's a very interesting blog post about that. The link is in the QR code and I advise you to to go through it if you're interested in implementing pass keys here. Just a snapshot of it. You must of course implement two different use cases.
The first one is the password creation. This is happening by generating through the credential manager a couple of pair of keys. One is the public key, the other is a private.
The public will be uploaded to an app server and the private 1 instead is saved on the user device. When you want to consume this authentication, the the challenge will be signed with the public key and then verified on the mobile device against the private key. That's an interesting video on YouTube and it's this is the QR code at the bottom of the page explaining details of how it works and how to leverage it. Finally, the Federated sign in this is a different type of approach. You in this case you rely on Identity services provider with the typical sign in width and the name of one of the identity provider available.
If you want to work with Google, you need to work on the Google Cloud Console. Create a kind of token that is then used in your code. This is shown in my sample code on the git tab. What you get is the screen on the right. So in my application here the A 14 challenger, when you press the Google flow, you you will be prompted to sign in with your credential and depending what you're entering, you will then follow the Google identity provider workflow. With that said, let me move to the screenshot detection.
This is another new feature. It aims to prevent application from grabbing sensitive information without the application know that, so potentially compromising security and privacy. A new API part of the Activity class has been made available. Its name is screen capture call back and as name suggests, it's a call back.
You just need to add permission in your manifest and declare this this call back in each activity that you want to capture. When to detect when the screenshot is captured. It's interesting to notice that only manually taken screenshots are detected, so those trigger with the power button and volume down. And this is an example of what happens with that permission and call back any world. Here is the screenshot that I took manually with the power button and the volume down.
A toast appears and this toast is managed by Android. And it's saying that your application detected this screenshot and it's showing that. I also want to mention that the actual image of the screenshot is not passed to your application. You're just notified that it happened.
It's interesting to know there also that Zebra made available a special API through MDK and Stagenow starting MX 5.0 to completely disable or enable the screenshot features in Android. So you can also leverage that still on screenshot detection. Another important thing to note is that it doesn't capture a screenshot taken through the media projection API.
I have arranged an example in my code sample in my sample application specifically for this, the Screen capture service. If you declare this service of type of media projection as I did here and you start capturing the screen, this callback won't be involved. Finally, if you really want to shut down any any chance to take screenshot of the specific activity, you can simply set the flags of the of the activity window using the FLAG SECURE. You can also revoke this at the end of the when the when the activity will close. Now some restrictions are appearing when targeting your application to API level 34 and and above. The first one is about implicity intents.
An implicit intent is one that is just defining an action and not a specific component that should consume the action. It can only be sent to component explicitly and so either your application. If you want to send an implicit intent to an application, either this is a component exported explicitly declare as reported, or you have to add the component the package name where the the implicit intent will be delivered. This is of course done for security reasons and in order not to post information, so action to unintended recipients.
Here is an example in an activity defining an action, a simple action. If you start the activity with just the implicit intent, so just defining the action, you'll get an exception activity not found. And note that the activity is not exported.
Instead if you add the package name of the target activity, you can start that activity and this is admitted and successful. Another restriction is about pending intense. Pending intense are that kind of intense that allow application to perform future operations on behalf of you of your application. Mutability is a is a specific feature of pending intents and mutability allows the the application that will execute to your intent to change it content. In this case, the restriction applies to changing the target component and also adding the specific data.
The real. The reason is also still need to preventing security issues or sharing unintended data with the different component. The in that case if the target application tries to change information in the taking leverage in the mutability, it will fail with specific exception.
There are then restriction on background work. There are several smaller, maybe far fetched for many, but let's see what happens exactly. Most of these are around are about the cache state and application is in cache state when it's in the background and no other processes of that applications are running. So it's completely inactive and in in this case 11 impact that is for all application running under 14.
So keep an eye on it, is that the background work is disallowed after the process entered the crash state. This was already in the air. It was already known in the previous version, but with Angel 14 it's actively enforced.
Another thing that maybe it's rather unusual for enterprise application it heal other application background processes. This is also forbidden with the Enter 14 and applies to all application running on Enter 14. Finally, there are also restrictions on background operations that try and tend to open activities from the background. One applies to pending intent to be able to want to launch an activity even if in the background. In this case if you want this to happen, you need to grant permission explicitly and also if visible app binds a service that is belonging to a background and application in in that case it launched an PN activity when the visible application it works, but in order to happen when the application moved to the background you still need to add an additional permission to that.
In this case, this applies to APIs targeting the API level 34 and above. With that, I'd like to move to performance and core features of Android. The first one is about exact alarms. It's important because it's impacting all application.
Again, brief history here in exact alarm were addressed starting end to 12 where the when the schedule exact alarm permission was introduced and pregnanted by default. This was setting the expectation that Google wanted to address the use of exact alarms and exact alarms are consuming a lot of system resources. And so with end of 13 they introduced the use exact alarm permission granted automatically and subject to different policy compared to the schedule exact alarm in for Play Store in. And with end of 13, the schedule exact alarm permission was no longer granted by default.
Finally, in end of 14 the schedule exact alarm is denied by default, and that doesn't mean you can't use it. I'll show you in a moment how to use it, but the user is expected to set it explicitly. It's worth noting that if your application already had the permission to use it in a previous version and you upgrade the device from 12 or 13 to 14, that would be persisted here. In a code example, for instance, to use the schedule exact alarms, you have to declare the permission in the, you know, manifest. Note that it's not a runtime permission a usual 1, so even if declare no permission requested or or request the user intervention, instead it's a special permission and needs the user to visit the Alarm and Reminders menu under the setting options and you have to select specifically the application that you want to allow it.
By default as I said, it's not allowed, but once you set it back to the Application Info screen down to the bottom you'll see Alamana reminders allowed. And here is the API to call to set an exact alarm. Set exact you have to specify the type of alarm. So for instance a real time clock, wake up and set the time when you want it to trigger the alarm.
If you want to know if your application is setting alarms, you can use the ADB shell dances alarm. You get a list like the one I'm showing here and it's telling everything about your alarm, when it was set and what is the package using it and so on. I'm sharing this because since this is a a feature impacting all application run in Manda 14, this is one of the first check that you want to make to your cost base. And so this is another way to know if your application is setting the alarms and a way to change the their to change them with different objects and ways to achieve the same functionality. Let me now move to the QA broadcast.
This is still impacting all applications. Again, the cachet state concept is back. I have already covered that and another.
Another concept that you need to know here is about the contacts register receivers. These are broadcasts, we see them declared dynamically. So with the register receive the API and are not declared in the manifest and.
These these context register receiver will receive broadcast as long they as their context is valid. Regarding the context, appreciate the difference for instance between the activity context and the application context. The first is leaves as long as the activity, the second with all application life cycle. What is the statement about the queue broadcast that the operating system may place a contact register broadcast in a queue OK in set and and when it's in a cache state when the application is not active and consume then all at once in once the application is back. Also know that not all broadcaster are subject to these restrictions. For instance the action screen on is 1 that is subject to this restriction.
I have tested this before to the code that I have shot online to see. It's not that easy to witness exactly when the queuing feature is in action, but with a bit of try and and ever you'll be able to see this feature enforced. Another runtime, another epub for API level 34 is about runtime broadcast receiver export behaviour. So in API level 33 they added the export specification as optional. And as usually happens in this way in the next version, this case 34, are requested to declare the receiver behavior. So is it exported or not exported? Failing to do so is one of the most frequent reason for me when my application failed when upgrading to API level 34.
Because of course we'll have several receiver declared and if you developed them in past API level version you you were not required to declare the export behavior. Note that this behavior is not requested to receive a system broadcast, so in that case you can still ignore this requirement still on foreground services. I said something about that earlier in the example of the compatibility framework. Foreground services that are used for tasks that need to have an interaction with the user and they have declared they are required now to declare the type of activity. They mainly, they mainly do and you have to to that. For instance, as I'm highlighting here, in the service tag of your manifest file, a list of types is provided in the Google documentation.
You can see a number of cases of types here on the right side, for instance the camera, microphone, locations and so on. The recommendation by Google is that if your foreground service is not falling in any of these cases, you probably want to migrate your code to a work manager for a fully background code and activity in the background. Or involve the user in a user initiated data transfer for instance. Or any other application that requires it to interact with the application and let the user know what's happening there.
Finally, it's a new feature that has been an open JDK alignment. So end of 14 is aligned to the open JDK 17 and this might cause some API to execute slightly different than in the past. There's a list of changes affected of an API affected by this change. See Classic pattern matching. And I tested specifically the UUID and the regular expression matching and this. And I can show an example in the following slides for the UUID, for instance, if you declare a wrong UID as I did here, depending on the JDK level, for instance, if you run this code on Android 11, which is aligned to Java 8, you get an illegal state exception.
And specifically it's about misleading you because it's trying to interpret a number string as a number. It says it's a wrong number in the Rack 16. In enter 14, the same code, the legal state exception is still raised, but with the different and more relevant error messages, so the UID string is too large.
This is much more meaningful to the developer and so can be seen as an improvement for developers regular exceptions. Here is an example for instance with the group references. I have the code shared of course for this in my the GitHub report that I've shared along with my blog post. If you define a pattern that define two Capital Group groups and you try to match against the string that actually had two groups but you request a third one, this is creating an exception. The Java 17 exception suggesting an interior out of bound and is telling no Group 3 so very meaningful is exactly the arrow that I that I introduced above in the old JDK 8.
Instead you got an array out of bound, so something similar, but it was trying to interpret the string at the at some point in along the string. So much less meaningful in the end. This is the an example of how the JDK alignment would help developers. You also have some nods to where you can adjust the JDK version of your application. There's a source compatibility and target compatibility where you can work.
And also inside the big red Android you have Kotlin options where you can define the targeted John Virtual machine a level. Finally, a couple of words around the Android enterprise features of Android 14. Maybe this is relevant for a for fewer people because not everybody is developing code for entered enterprise. This is about the cross profile features. So 2 new two new methods have been made available for low personal side of the application to access the war profile contacts and phone number.
So these two new get and set, manage the profile contact access policy and color the access policy are now available. Another another feature is about the ultra wide band radio, which is a technology for short range of communication. Starting with end of 14, the administrator can now disallow the ultra wide band radio to be turned off by the user. So it's an additional restriction available to administrators. With that, on the conclusion slide here, we have seen there are several benefits in moving to Android 14.
I have listed a huge number, very large number of Zebra devices that already support Android 14. And don't forget the last upgrade for the SD 660 platform. I have also shown that with all these new features and requirements, you can carefully plan your migration to ND 14. Start cleaning the roadblocks, satisfying the minimum SDK level, the restriction on the background work, the exact LAN behavior and so on. Then upgrade the target SDK level to #34. In this case, you probably have to work on the runtime receiver actual behavior, the typed foreground services, the pending intense behavior, and the implicit intense behavior.
Finally, enrich, enrich your application with leveraging the latest new features available stacking and 14, for instance, the convention manager and the security detection. With that, it's, I'm really at the end of my presentation. I thank you so much for joining this webinar.
And I guess we have now a few minutes left for AQ and a session. So Priyanka, if you want to introduce some questions, if we have any. And in the meanwhile, I also want to share the links and the online references on which this presentation is based. Thank you so much, Nicola. Thank you for the fantastic presentation. We do have a few question that came in over the Q&A session.
So I'm going to jump into those. And if anybody helps us any other question, please use the Q&A feature within the Zoom and we try to address them during the call here today. So the first question is what does what plan does Zebra have in regard to support for Android 15 on their devices? We already working on, on it, but of course enjoy under 14. First of all, yes, we're working. But as I have shown in those specific slide that I was just mentioning, we have a lot of devices that will end their life with under 14.
So that's why our focus is so big on on this OS version. But I know that many in our business unit have already documented and us working working on it. I have no dates of course, at the moment when it would be released.
Thank you for the question. It will be interesting, of course, to see and hopefully in another presentation I'll cover that. Great. The second question is why is the Nemesis family so delayed for Android 14 compared with the other product family? Which one? I think I missed the the name. Yeah, the Nemesis family as NEMESIS. Nemesis family, OK, not sure exactly what.
I guess they refer to one of the one of the family that was not yet available if that is the question and it's about one of the two families here in the end. So the 4419, the 40 and 5430 it's a decision take into consideration that these devices that C, 53 E and 58 E have just been released and so allow the time to complete the first issue and then 14 will be will be released as well. But I don't have specific details to share on that.
All right. Next question is do the updates in the software also include an update Hal to enable newer feature that may be available in the modem slash SoC firmware? I I don't think I have understood that. Let me I can see no, no, I can see the Q&A, the Q&A window now do the other software rows include I can read now and update to enable newer feature that me available in the Oh, that's a very good question for my friends in the BSP team. I I can't answer this one, sorry, but I can take care of asking and and passing this question over to the BSP team. But this is really about the about the road map they have in in creating BSP. So I'm sorry, but I don't have anything to share with about that.
I can read another one. Yeah. Do you know if Andrew 14 we support no, no, but we can the feed those two passkey types. No, unfortunately not, not aware of that. But since it's already no, we can ask, but it all depends on what Google depend does on that.
So it's hard to say from our perspective. Another question, Yeah, please, yeah, go ahead. So those who do not know what what the question was it was about if we know if Android 14 will support the Ubiqui Fido 2 passkey types to Vishnu. OK, no, not a answer. Thank you Nicole not a the other next question to you in upgrade device is possible that installation lock and the device become unusable.
I think in my 1012 VS at Z but I have seen sometimes it happened but usually when you work with some pre production device and you load the wrong BSP. Usually it doesn't happen if you use exactly the the right BSP and you have to and you and you follow the instruction to to upgrade it. If it happens, you have to ship it to the support team and ask for a repair because they are able to refresh the device and make it and make it good again for use.
Yeah. All right. Thank you for answering that. The next question is, will there be topics specifically about changes or updates specific to the Zebra device or will this be a general Android 14 update? This is a more general Android 14 update because we didn't add the specific features as it happened in the past.
For instance when we added OEM info for serial numbers and so on. Or when we added the Secure store and Manager in response to some changes of Android that happened at the time of Android 1011 and so 13 for instance with the file based encryption file system and so on. In under 14 we mainly had the general Android updates.
So these are the major news about great. Next question is, there was originally some documentation posted indicate I lost it for a moment. OK, Intent. OK, OK, let me repeat that question again.
There was originally some documentation posted that indicated that the data which intent APIs were going to be protected by default starting in Android 14. Have the plans for that been rolled back? I don't have fresh news on that because it's slightly out of scope for this presentation. But if you reach out to us on you for instance post this question on the developer webdeveloper2zebra.com website, we might answer that there are several changes and not necessarily they are happening at the at the 1st and day at day one of and certain release.
So we can share the road map. Yeah, if you post the press in. OK. So moving to the moving on the next question, is there any mechanism to upgrade Android OS using simple means other than ATV route? Just as downloading it to the download folder and performing a app based upgrade by selecting the file for upgrade using simple means other than ADB root now easier than that unless you copy the image to the device and you pick it from the booter from.
Instead of side loading that you pick it from the Android 5 system. That's another simple way to do it. Otherwise I can think of a simple one. Got it. Another question, is 0 touch enrollment also support in Android 14? I found that some of the Zebra devices only support zero touch in Android 11 and Android 13 versions.
That might be because maybe it's not yet been made available for N 214. You have to work with your sales engineer and specifically ask for instance the about the road map of that feature. I know that that might be something specific to Zebra in that. And so as I said before, it might not be available on day one of specific release me, it may come a bit later.
Great. Thank you for answering that. And the last question for today will be, are you working with any MDM to implement the new Android Enterprise features? Not personally, because I'm more focused on the general developer experience. So I'm more in touch with developers who write usual application, but we have people specifically working with the MDM in in touch with them, the vendors.
And so, yeah, of course, if you have some specific question around that, I'd say post your question on thedeveloper.zebra.com and we'll try to address you or your specific question by one of the subject matter expert of Zebra about that. Great. We have one last questions and I hope you can in our time schedule. So other Windows provide this facility of simple OS upgrade by providing a specific folder from where the device will pick up the new OS or versions to upgrade.
If failed, it would reward back to the current version. OK, it's it's one of the option of course, so that each vendor decides. So far. You know, we usually tend to think that the devices are managed remotely by an MDM or some other enterprise feature. And so Rd. #1 would be through the enterprise doing that locally through ADB or through a folder.
Yeah, it's it's it's an option, but it's not that scalable. So in the end, I'm not aware that we are exploring other option around that. Great. Thank you so much, Nicola for answering all the questions. If you have any other questions audience, please feel free to send it to us on developer@zebra.com or you can
go to our developer forum and post your questions there. With that, we wrap up our session for today. Please watch for a quick survey that will appear as soon as the webinar ends. We greatly value your feedback, so please take a minute to share your thoughts and we look forward to seeing you again. Thank you. Thank you so much for joining.
See you next time.
2025-01-03 10:52
