Gemalto is now part of the Thales Group, find out more.

You are here

AT^SJOTAP inconsistency

Tonino

March 24, 2015 - 5:57pm, 1914 views

Hi (again),

now that i can successfully run OTAP, I'm noticed a very annoying behaviour change in aT^SJOTAP.

Usually we deliver our device with a modem and a preinstalled midlet.

^SJAM: "a:/Java/jam/pqgprs/ehs5.jar","PqGprs","Parkare Group S.L.","08",0,68540,0

therefore, this midlet is called as

AT^SJAM=1,"a:/Java/jam/pqgprs/ehs5.jar",""

if for some reason the module needs to be updated, or it just doesn't contain any midlet, an OTAP process is triggered as:

AT^SJOTAP=,"http://80.37.229.215:19002/OTAP/ehs5.jad","a:/Java/jam/pqgprs",,,"gprs","ac.vodafone.es","vodafone","vodafone","10.32.0.1",

hoever, my surpise is that the installed/updated midlet is now installed as:

^SJAM: "http://80.37.229.215:19002/OTAP/ehs5.jad","PqGprs","Parkare Group S.L.","08",0,69146,0

Therefore if I try to run it, it will no longer work because as seen before I'm using AT^SJAM=1,"a:/Java/jam/pqgprs/ehs5.jar",""

It appears the <Appl_Dir> parameter in AT^SJOTAP is no longer used to identify the applet.

is the only way to sidestep this issue to always use the OTAP url ("http://80...") instead of the local one("a:...")?

This would mean that the app manually installed at "a:..." would never be used because I would look for url "http://..." and it would not be found, so an OTAP process will always be run regardless of the manual installation the first time.

Am i right, or I'm missing something?