5 Replies Latest reply on Jan 30, 2019 7:57 AM by Darryn Campbell

    Handling multiple EMDK versions

    Joseph Nicolia

      When our app encounters a device with an old version of the emdk (less than 4) our application throws a Fatal Exception: java.lang.VerifyError exception and the app crashes.  The crash happens on this line

       

      EMDKResults results = EMDKManager.getEMDKManager(context, setUpEmdkListener(reset));
      

       

      Currently we are in control of our fleet of devices and can simply upgrade that device to have a more current version of the EMDK and all is well.  Moving forward I'd like to be able to handle this more gracefully and also design the app to work regardless of the device emdk version.  I was wondering if this was possible and how I'd go about doing it.  I'm thinking about using something like this to determine the version

      try {   
         String emdkPkgName = "com.symbol.emdk.emdkservice";
         PackageInfo pinfo = getPackageManager().getPackageInfo(emdkPkgName, 0);
         String emdkVersion = pinfo.versionName;
      } catch (PackageManager.NameNotFoundException e) {
         // EMDK does not exists on the device.
      }
      
      
      
      
      

      And then having the application have several versions of the emdk sdk (jar file?) and load the appropriate one.  Is this possible?  Any help would be appreciated because in the near future we will not be able to guarantee what version of the emdk is on a device and we will need to handle this case in some fashion.

        • Re: Handling multiple EMDK versions
          Darryn Campbell

          Hi, I'm not sure you will be able to chose the jar file dynamically at runtime.  A while ago I published a post describing how to use build flavours to use different versions of the emdk at build time: Deploying an application to Zebra Android devices ranging from Jellybean to Marshmallow and beyond .  I know you would rather have a runtime solution but I hope that post helps.

            • Re: Handling multiple EMDK versions
              Joseph Nicolia

              Sorry for the late reply, priorities changed but I am back on this now.  I have a couple of questions about the EMDK support and compatibility.

               

              1. What is the relationship between the version of the jar file compiled into the app and the version of the EMDKService that runs on the device?

               

              2. What happens when you run a version of Android that doesn't support the current jar file (example running Android 7 with version 5 sdk)?

                • Re: Handling multiple EMDK versions
                  Darryn Campbell

                  Hi,

                   

                  1. What is the relationship between the version of the jar file compiled into the app and the version of the EMDKService that runs on the device?

                  DCC: The EMDKService on the device provides the functionality and the jar file provides the method signatures and definitions allowing your application to build.  At runtime the jar file will bind to this service and provide functionality.

                   

                  2. What happens when you run a version of Android that doesn't support the current jar file (example running Android 7 with version 5 sdk)?

                  DCC: Undefined.  It might work or it might crash but we have not tested any scenarios beyond the devices stated as supported by each version of the SDK

                    • Re: Handling multiple EMDK versions
                      Joseph Nicolia

                      Is there anyway to guarantee that the EMDKService is the right version for the emdk jar file? Or do we just make that assumption based on the OS level?

                       

                      In the past we had an issue where older devices would crash because the EMDKService was too old (we are currently using version 5 of the emdk sdk jar file) and I am just trying to make sure that I do not have that issue again.  I am planning on implementing the build variant solution you suggested in that blog post, but just triple checking.