Hi, rather than using separate profiles you may want to just update the current profile's decoder settings. There is a ready made sample showing how to do this here: GitHub - Zebra/samples-emdkforandroid-6_6 at ProfileDataCaptureSample1 .
Thanks for the pointer - that way new settings apply instantly.
Unfortunately the results don't change. The result XML says everything went OK and reading the profile gives the expected settings. But the scanners accept the same barcode types as before.
I'm using ProfileManager.processProfileAsync() instead of ProfileManager.processProfile() in an AsyncTask like the example code shows. Shouldn't make a difference though.
And we are still on EMDK 6.6 but will upgrade soon.
By the way: from EMDK for Android Support & Downloads | Zebra it seems we could upgrade to 6.7 but not 6.8. But About EMDK For Android - Zebra Technologies TechDocs lists TC8000 as supported.
Are you able to get the sample to work with the standard barcode types that it demonstrates (e.g. EAN13)? That would at least show the basic setup is working
Yes, the sample enables and disables barcode types as expected.
I was mostly worried that I mixed up DataWedge and ProfileManager APIs or something like that.
Copying the relevant example code to our app didn't change the results. Creating a new profile and fiddling with version strings didn't change anything either.
But I found that even your example app fails to control the Aztec decoder and of course that's the one we are interested in :-). It does control the Datamatrix decoder that I added.
Any ideas how that's happening? i didn't see any special settings for Aztec decoders in EMDKConfig.xml.
I'll update to EMDK-A-0608086 tomorrow morning and let you know if that helped.
I don't have a TC8000 to test with unfortunately but the attached (modified) file works with a TC51 in the ProfileDataCaptureSample1. I am just using the aztec barcode from the wikpedia page to test with: https://upload.wikimedia.org/wikipedia/commons/2/20/Azteccodeexample.svg . You can also tell if the profile was processed successfully as you should have a new DataWedge profile titled 'DataCaptureProfile-1' under the DataWedge application on your device associated with your application.
MainActivity.java 6.5 K
My bad, I used decoder_Aztec instead of decoder_aztec. But that wasn't the case with our app.
That's the culprit (from EMDKConfig.xml):
<characteristic type="ActivitySelection" version="0.1">
<parm name="emdk_name" value=""/>
<parm name="PrefixAppName" value="true"/>
<parm name="package" value="de.my.app"/>
<parm name="activity" value="*"/>
By connecting profiles to a package multiple profiles can apply to an app. And the scanner stores all profiles that were ever activated.
When it's time to apply a profile the 1st from the internal list for that app will be used - no matter what name you pass to ProfileManager.processProfile().
It also means you'll have to delete old profiles from the scanner - it's not enough to remove them from the app's EMDKConfig.xml.
Would be nice if ProfileManager could retrieve the profile that's actually applied - afaik it's possible with the DataWedge API. And even if there's a use case for connecting multiple profiles to an app there should be a warning about the risk.
And sometimes ProfileManager doesn't like a profile but doesn't tell you why. All you get is EMDKResults.STATUS_CODE.FAILURE or "The parameter/s given are invalid.". I still haven't figured out what it didn't like and reverted to an older profile.
But the problem is solved and thanks for your help!