The Crux of Android 14 Software Migration and Its Impression

First I want to give an outline of the Meraki Techniques Supervisor (SM) software. Techniques Supervisor is Meraki’s endpoint administration product. We help administration for a lot of completely different platforms, together with iOS, Android, macOS, and Home windows. “Managing” a tool can imply monitoring its on-line standing, pushing profiles and apps to it, and/or implementing safety insurance policies, amongst different issues. With Techniques Supervisor, this administration all occurs via Meraki’s on-line interface known as Dashboard. Examples and code snippets talked about on this weblog are extra particular to the Android SM software.

Migration of functions to any SDK primarily contains 2 duties from the developer’s perspective. One is – how the applying behaves when put in on a tool with an Android model apart from the goal SDK of the app. And secondly, how the app will behave when the goal SDK is modified. Builders want to know what new options, or updates of any current characteristic, and its influence on the applying are.

This doc focuses on a number of the modifications impacting builders with Android 14 migration. It additionally covers migration of the Techniques Supervisor app to Android 14, and challenges encountered through the migration and testing.

Font Scaling

In earlier variations of Android i.e., 13 Non-linear font scaling was supported as much as 130% however in Android 14, it’s supported as much as 200% which might influence the UI of the applying. Within the software if font dimensions are declared utilizing sp (scaled pixel) models there are possibilities of minimal influence on the applying as a result of Android framework would apply these scaling elements. Due to nonlinear scaling of font density scaling is not going to be correct.
Key factors

• TypedValue.applyDimension() to transform from sp models to pixels.
• TypedValue.deriveDimension() to transform pixels to sp
• LineHeight models needs to be laid out in sp to handle proportion together with textual content dimension.

Background Course of Limitation

Android OS is self reliant to handle the assets effectively by improvising efficiency as nicely. One of many pointers to realize the identical is by caching functions within the background and solely when the system wants reminiscence these functions will likely be faraway from reminiscence. All functions ought to adjust to Google Play coverage and therefore killing of processes of different functions are strictly restricted in Android 14. Therefore killBackgroundProcessess() can kill solely the background processes of your individual software.

Foreground Service Varieties

In Android 10, a brand new attribute was launched to specify service kind for foreground companies. When utilizing location info within the foreground service it was required to specify the sort as “location”. Whereas in Android 11, mentioning service kind for utilization of digicam or microphone in foreground service was mandated. However in Android 14 or above, all foreground companies should be declared with their service varieties.

A number of the new service varieties have been additionally launched in Android 14 – well being, remoteMessaging, shortService, specialUse and systemExempted. If service isn’t related to any of the kinds specified, then it’s endorsed to alter logic to make use of Workmanager or user-initiated information switch jobs. MissingForegroundServiceTypeException will likely be thrown by the system in case service kind is just not specified.

Service kind permissions must be declared together with specifying the sort in service.

      <uses-permission 
android:identify="android.permission.FOREGROUND_SERVICE_SYSTEM_EXEMPTED" />

      <service
            android:identify=".kiosk.v2.service.KioskBreakoutService"
            android:identify=".kiosk.v2.service.KioskBreakoutService"
            android:foregroundServiceType="systemExempted"
            android:exported="false" />

Limitations on Implicit Intent and Pending Intent

Implicit intents are solely delivered to exported elements. This restriction ensures the applying’s implicit intents aren’t utilized by every other malicious apps. Additionally, all mutable pending intent should specify a part or bundle info to the intent, if not the system throws an exception.

Implicit intent needs to be export much like this:

<exercise
   android:identify=".AppActivity"
   android:exported="true"> <!-- This should be TRUE in any other case it will throw 
exception when beginning the activity-->
   <intent-filter>
      <motion android:identify="com.instance.motion.APP_ACTION" />
      <class android:identify="android.intent.class.DEFAULT" />
   </intent-filter>
</exercise>

If pending intent needs to be mutable, then part data should be specified.

val flags = if (MerakiUtils.isApi31OrHigher()) {
   PendingIntent.FLAG_MUTABLE
} else {
   PendingIntent.FLAG_UPDATE_CURRENT
}

val pendingIntent = PendingIntent.getActivity(
   this,
   0,
   Intent(context, KioskActivity::class.java).apply {
      putExtra(ACTION, KioskActivity.BREAK_OUT_SINGLE_APP)
   },
   flags
)

Export habits to be specified for Runtime-registered broadcasts

Previous to Android 13, there have been no restrictions on sending broadcasts to a dynamically registered receiver when it’s guarded by signature permission. Whereas in Android 13, aiming at making runtime receivers secure, an optionally available flag was launched to specify whether or not the receiver is exported and visual to different functions. To guard apps from safety vulnerabilities, in Android 14 or above context-registered receivers are required to specify a flag RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED to point whether or not receiver needs to be exported or to not all different apps on the system. That is exempted for system broadcasts.

ContextCompat.registerReceiver(
   requireContext(), receiver,intentFilter(),
   ContextCompat.RECEIVER_NOT_EXPORTED

Non-Dismissable foreground notifications

In Android 14 or increased, foreground notification could be dismissed by the consumer. However exceptions have been offered for System coverage Controller (DPC) and supporting packages for enterprise.

JobScheduler reinforces callback and community habits

Previous to Android 14, for any job working for too lengthy, it might cease and fail silently. When App targets Android 14 and if the job exceeds the assured time on the primary thread, the app triggers an ANR with an error message “No response to onStartJob” or “No response to onStopJob”. It’s instructed to make use of WorkManager for any asynchronous processing.

Adjustments particular to Android Enterprise

Android Enterprise is a Google-led initiative to allow the usage of Android gadgets and apps within the office. It is usually termed as Android for Work. It helps to handle and distribute personal apps alongside public apps, offering a unified enterprise app retailer expertise for finish customers.

GET_PROVISIONING_MODE intent habits

For signing in with a Google account, GET_PROVISIONING_MODE was launched in Android 12 or increased. In Android 14 or increased, DPC apps obtain this intent which might carry the data to help both Totally managed mode or work profile mode.

wipeDevice – for resetting system

Scope of wipeData is now restricted to profile house owners solely. For apps concentrating on Android 14 or increased, this methodology would throw system error when known as in system proprietor mode. New methodology wipeDevice for use for resetting the system together with USES_POLICY_WIPE_DATA permission.

Newly added fields and strategies

ContactsContract.Contacts#ENTERPRISE_CONTENT_URI
ContactsContract.CommonDataKinds.Telephone#ENTERPRISE_CONTENT_URI

When cross-profile contacts coverage is allowed in DevicePolicyManager, these fields can be utilized for itemizing all work profile contacts and telephone numbers from private apps together with READ_CONTACTS permission.

To help setting contact entry coverage and callerID, beneath strategies are newly added;

setManagedProfileContactsAccessPolicy
getManagedProfileContactsAccessPolicy
setManagedProfileCallerIdAccessPolicy
getManagedProfileCallerIdAccessPolicy

Deprecated strategies

Beneath strategies are deprecated and as a substitute strategies specified within the earlier part needs to be used.

DevicePolicyManger#setCrossProfileContactsSearchDisabled
DevicePolicyManger#getCrossProfileContactsSearchDisabled
DevicePolicyManger#setCrossProfileCallerIdDisabled
DevicePolicyManger#getCrossProfileCallerIdDisabled

Challenges throughout Meraki Techniques Supervisor App Migration

• To make sure there was no UI breakage, we needed to recheck all of the code base of xml information associated to all fragments, alert dialog and textual content dimension dimensions.
• Few APIs like wipeDevice(), weren’t talked about within the Android migration 14. Throughout the testing part it was discovered that wipeData() is deprecated in Android 14 and wipeDevice() was supposed for use for manufacturing facility resetting the system efficiently.
• Profile info which could be fetched together with intent GET_PROVISIONING_MODE was additionally missed within the migration information. This was discovered through the regression testing part.
• requestSingleUpdate() of location supervisor all the time requires mutable pending for location updation. However nowhere within the documentation, it’s prescribed about it. Attributable to this there have been few software crashes. Needed to determine this out throughout software testing.

Helpful hyperlinks for reference

 

Share: