Motorola T720 Errors


The following errors apply to the Motorola T720 (GSM) phone.  If you learn
anything more about these errors, let me know and I will update this page.



"Download Failed"

CAUSE #1

Any file (HTM, JAD, JAR, MID, GIF) over 1644 bytes will cause this error for
certain web hosts and servers.  Here is a brief list of hosts and servers:


Host / Server                                               Error
===================================================    =================
Apache                                                       No
Microsoft Personal Web Server (direct from your PC)          No
Earthlink (Apache)                                           No
Yahoo! (unknown)                                             Yes


The problem has to do with a flaw in the Motorola T720 firmware, which affects
how downloading files in fragments works.

The only apparent work-around is to switch web hosts or server type.  Other
phone models do not have this problem.

CAUSE #2

  The "MIDlet-Jar-Size:" field of a JAD does not match the exact byte size of
the corresponding JAR.






"Failed: File Corrupt"

CAUSE #1

   The JAR file uses unsupported APIs (e.g., MIDP 2.0).

   This is a very easy mistake to make!  Check the J2ME APIs in your
   code, starting with the most advanced methods.  Look at the 
   corresponding API documentation.  Perhaps there is a method that
   is only available with MIDP 2.0 instead of MIDP 1.0.  The code
   might work with the emulator, but not the device (e.g., actual
   T720).

CAUSE #2

The manifest.mf file used to create the JAR file (via the "jar" utility)
contains errors.  Make sure the manifest.mf has the following versions of CLDC
and MIDP:
   

MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0


The entire manifest.mf file should look almost exactly like the following:
  

MIDlet-1: My_Description,, HelloMIDlet[CR][LF]
MIDlet-Name: My_Midlet_Suite[CR][LF]
MIDlet-Vendor: Colin Fahey, Inc.[CR][LF]
MIDlet-Version: 1.0[CR][LF]
MicroEdition-Configuration: CLDC-1.0[CR][LF]
MicroEdition-Profile: MIDP-1.0[CR][LF]


(NOTE: [CR][LF] represents the carriage-return character (CR; 13; 0xd)
and the line-feed character (LF; 10; 0xa) that terminates each line of the 
manifest.mf file, including the final line of the file, followed by the actual
end of the file.)

The only fields that should differ in your own manifest.mf file are
the first three fields listed above.  The final three fields should
be an exact character-for-character match, right up to the final
[CR][LF] combination at the end of this file.

If you received the "Failed: File Corrupt" error message, the 
cause is one or more of the following conditions:
==============================================================

(1) Your manifest.mf file contains non-ASCII characters;
      (Check an ASCII chart; any character outside the 
      0 to 127 range is invalid)
(2) Your manifest.mf file does not have a line-feed [LF] character
      after the carriage-return [CR] character at the end of
      each line;
(3) Your manifest.mf file has invisible spaces or tabs at the
      end of each line *before* the [CR][LF] termination;
(4) Your manifest.mf file contains a "Manifest-Version:" line;
(5) The last line of your manifest.mf file does not end with a
      [CR][LF] combination, but instead simply reaches the 
      end of the file;
(6) Your manifest.mf file does not have the exact fields and
      exact ORDER of fields as shown in the example above;
(7) Your CLDC version is not 1.0, or your MIDP version is not 1.0;
(8) Your vendor name has non-ASCII characters (try to be very
      conservative, like letters, numbers, period, comma);
(9) Your manifest.mf file does not have a space after the second
      comma in the "MIDlet-1:" line;

Perhaps some of this is unnecessarily conservative, but unless you
are willing to take the care to follow all of the guidelines above,
no matter how apparently illogical or moronic, you risk being 
frustrated for a longer period of time.

When a "manifest.mf" file is added to a *.jar file via the jar
utility, fields are added by the jar utility itself, and the
modified form of the manifest is in a file called "MANIFEST.MF".
Do NOT extract this file and use for reconstruct a jar file 
UNLESS you change the name back to "manifest.mf" and carefully
edit, eliminate, and reorder fields to conform to the guidelines
listed above -- otherwise you are likely to get a mysterious
download error, which will just waste your time.






"Unsupported Content Type"

CAUSE #1

  The mobile phone cannot handle the MIME type reported by the remote server
  for a given file.

  For example, JPG image files are not supported by the Motorola T720.

  This error can also occur if the MIME type for a supported file type (e.g.,
  GIF, MID, JAD, JAR) is not reported correctly by the server.  One must be
  very careful to report the exact MIME type text for the supported file types.
  
CAUSE #2

  The file cache on the mobile phone itself needs to be cleared.
  (Browser Settings --> Clear Cache)
  
  If you recently added MIME types to a remote server, and later attempt
  downloading a file that failed to install due to a lack of a MIME type, the
  file cache on the mobile phone may be an obstacle to downloading the file
  again with the proper MIME type.

  It is also possible that the remote file was modified and the cached version
  is defective and yet prevents downloading the fixed version.

  Clearing the browser cache on the mobile phone should ensure that a
  subsequent download benefits from the latest server configuration (MIME
  settings) and remote file updates.

CAUSE #3

  [Quoting Motorola literature]


How to avoid "Unsupported Content type" errors in WAP

If you get an error in WAP saying Unsupported Content type, 
it's not necessarily due to the content-type setting. Many 
WAP pages contain special characters, such as Swedish å ö ä,
and in order to get them to display properly you need to 
specify which character set you use. In order to specify which
character set is used on a WAP page, you modify the Content-Type
header in the server response to include the character set, for
example "Content-Type: text/vnd.wap.wml; iso-8859-1". When a user
gets the response from a server, it should have all the needed
information to display the content properly.

However, there's a problem with using this approach. All phones
indicate to the gateway which character set they support by using
"Accept-Charset" in the request header. According to HTML 
specifications, this should be compared to the character set
specified in a server response, and if they don't match, the
error Unsupported Content type should be generated.

To make the problem more complicated, some WAP gateways don't
care about comparing the character set supported by the requested
device, hence the content will not display properly on those
devices. Another complication is that the string specifying the
character set is case insensitive, but some WAP gateways treat
them as case sensitive strings.

All together, there will be very different results depending on
what device you use, which WAP gateway you use and what the
server response is.

The only way to be sure that your content will be displayed
properly is to always check what character set is accepted by
the client and transform your response to that character set
before sending it.

[Original Source]
 







"406: Not Acceptable"

  "The server cannot generate a response that your client can accept."

CAUSE #1

  You have a Verizon phone!

  Verizon does not allow its customers to download images (GIF), ring tones
  (MID), or applications, from arbitrary sites on the Internet.  One must
  use "Get It Now" or "Get Around 'Get It Now'" (GAGIN).  Complain!

CAUSE #2

  This indicates that the MIME type on the web server has not been established
for the file type being downloaded.

  If you have an Apache server, for example, you must alter an .htaccess file,
adding the following lines:


AddType text/vnd.sun.j2me.app-descriptor jad
AddType application/java-archive jar
AddType text/vnd.wap.wml wml
AddType audio/midi mid






"413: Requested Entity Too Large"

CAUSE #1

  The server hosting the file being downloaded did not specify the MIME type
for that file (e.g., GIF, MID, JAR).  Thus, the mobile phone assumes the file
is text.  The phone has a limit on text file size that is smaller than the 
limits for binary file size, so a binary file interpreted as plain text is
liklely to cause the error based on size alone.

  If you have an Apache server, for example, you must alter an .htaccess file,
adding the following lines:


AddType text/vnd.sun.j2me.app-descriptor jad
AddType application/java-archive jar
AddType text/vnd.wap.wml wml
AddType audio/midi mid



CAUSE #2
 
  Apparently this error can also occur even if the remote server has the 
proper MIME types established.  I have not yet determined when this
error occurs instead of "Download Failed" for this condition.

  The T720 cannot handle a certain aspect of the HTTP 1.1 specification
that allows for files to be broken up in to fragments, requiring multiple
"GET" requests.

  It turns out that any file (HTM, JAD, JAR, MID, GIF) over 1644 bytes
will cause this error for certain web hosts and servers.  Here is a brief
list of hosts and servers:


Host / Server                                               Error
===================================================    =================
Apache                                                       No
Microsoft Personal Web Server (direct from your PC)          No
Earthlink (Apache)                                           No
Yahoo! (unknown)                                             Yes


The problem has to do with a flaw in the Motorola T720 firmware, which affects
how downloading files in fragments works.

The only apparent work-around is to switch web hosts or server type.  Other
phone models do not have this problem.




"Connection unsuccessful. Try again later."

CAUSE #1

  This error has nothing to do with the server hosting the requested file.

If you get this error, I strongly suggest doing the following:


(1) Clear the browser cache;
(2) Clear the browser history;
(3) Turn off the phone;
(4) Remove the battery;
(5) Wait a few seconds;
(6) Replace the battery;
(7) Power up the phone;
(8) Try the download again;


I received the "Connection unsuccessful. Try again later." message for several
days when I first bought the phone.  By chance I removed the battery.  When I
put the battery back in, I immediately had network access.

When I received this error again on other days over the past six months, this
procedure worked every time.  I haven't bothered to isolate the critical steps.

The bad thing about this error message, like the other error messages, is the
vagueness.  Why was the attempt to connect unsuccessful?  Network too
busy?  Gateway down?  Bad signal?  When would be a good time to try
again?  Ten seconds from now?  An hour from now?  A week from now?  A cause
and estimated time for a fix would be nice.

CAUSE #2

  If you did a Master Reset, or if you have never been able to access the
Internet, check the network settings.

  AT&T Phone Settings (Network)