How to develop Japanese FlashLite contents



This entry is English version of Adobe DevNet “An introduction to Flash Lite lecture“. There is the case that information is old.

In Japan, the three big carrier’s influence is very strong that the function carrier hopes is added to the terminal every season. All of the three carriers vary; therefore the manufacturer makes the terminal according to the specification that each carrier settled on.

Flash Lite 1.1 ~ FlashLite3.1 loaded terminal exists in Japan (excluding smart phones), however, the function Adobe has prepared such as Flash Lite, which is not an exception, has been restricted by each carrier. Therefore, an original improvement was done repeatedly

This document is prepared for developers of Flash Lite loaded terminal in Japan, to use as a guideline of the part which can be used in common without considering the difference of carrier/version.

Please try to produce the Flash Lite contents for Japan by all means.

Different in Japan – Flash Lite Development Surroundings

“Flash Lite” is a Flash Player for mobile, which already have been released version 1-3. Compared with the versions for PC Flash Player, each Flash Lite version’s relation is the following. However, the full spectrum of the corresponding Flash Player is not supported.

  • Flash Lite 1.x … Flash Player 4
  • Flash Lite 2.x … Flash Player 7
  • Flash Lite 3.x … Flash Player 8

We must be careful further more. It is a little more different in Japan! In Japan, each carrier such as NTTdocomo, KDDIau, and Softbank is providing different functional restriction based on the Flash Lite developed by Adobe Systems. For instance, “XMLSocket Connect ”, “Reproduction of flv”, or “external communication according to optional timing” cannot be used. Therefore, it would be easier to understand to work on development as “Flash Lite according to carrier”.

Please refer the followings: the version and the main feature of the Flash Lite each carrier has adopted (April 2009).

Version and the main feature of Flash Lite for each carrier

As you can see in the table, every carrier/version is slightly different. Please see the following links for further specification.

Lets create i-mode contents | service÷function | NTT docomo
KDDI au : EZfactory > multimedia・contents

Six Guidelines based on carrier’s common matter

If you are to develop mobile Flash as work, it is intended for a lot of users in most case. I would like to set the common guideline without considering the difference of carrier/version as following

The following 6 can be enumerated as a common matter.

  1. Develop with Flash Lite1.1.
  2. The capacity of the file up to 100KB.
  3. The only terminal keys allowed to use are: “upper-and-lower”, “enter”, “numbers (0-9,#,*)”.
  4. If the keys aren’t pressed, it cannot access external.
  5. Basically use 12pixel or 24pixel for device font size.
  6. The memory that can be used is about 1MB.

Let’s explain each guideline.

1.Develop with Flash Lite 1.1.

To develop mobile Flash contents, it is based on Flash Lite 1.1. The script supported by Flash Lite 1.1 is equal level as Flash 4 Script; therefore Flash 4 Script will develop it.

The reason why it is based on Flash Lite 1.1 is because “Flash Lite 1.1 diffusion is the highest” in general. This is an outlook that most of the terminal loads Flash Lite 1.1 among NTTdocomo which accounts for about 52%, more than half of the share. By the way, Flash Lite version upgrade is not possible in mobile terminal, which is different from the PC environment.

Number of contracts according to entrepreneur by investigation of Telecommunications Carriers Association Corp. (End of March, 2009) *exclude EMOBILE

Data above is the “number of line contracts”. The actual number/share of terminal has not been officially announced. As far as I searched through access analysis of mobile site I handled, terminal with Flash Lite version 2.x or after has been increasing, although yet Flash Lite 1.1 covers majority. Therefore under present conditions, development using Flash Lite 1.1 is the most appropriate way.

For supplementary explanation, the functional difference between Flash Lite 1.1 and 2.x, though it is a little rough expression, is mainly “Compress movie (Publish Settings → SWF settings → check Compress movie)” and “the difference of memory volume allocation” in Guideline 6. It will be simpler to develop by version after 2.x, in terms of using Dot-think-tacs, but there is less merit when considering more less people will be disabled to browse the contents.

2.The capacity of the file up to 100KB.

According to the graph “Version and the main feature of Flash Lite for each carrier”, the file capacities are as follows:
NTTdocomo and KDDIau – 100KB,
Softbank – 150KB.
Files over capacity will not appear in mobile terminals. Therefore, “develop in less than 100KB” to match the smaller size is required.

Only au and NTTdocomo terminal with Flash Lite 3.1 has “the limit of 100KB per communication,” which is able to play forever as long as the memory allows it by repeating “load Movie,” which I will explain in Guideline 4.

3.The only terminal keys allowed to use are: “upper-and-lower”, “enter”, and “numbers (0-9, #,*)”.

The keys allowed to use in mobile Flash are as follows:

Keys possible to use

  • upper and lower key
  • enter key
  • number key (0-9,#,*)

Keys not possible to use

  • soft key
  • clear key
  • call/hold key
  • left and right key (excluding Softbank)
    Left and Right key can be used in Softbank but it is not appropriate to use them in terms of NTTdocomo and KDDIau sets the key as “back” and “forward.”

4.If the keys aren’t pressed, it cannot access external.

In order to access external, the user is required to “press terminal key” in an active manner. In other words, it is inaccessible if there is neither a click nor a keyboard operation, which corresponds to press/release/key kress and MovieClip.onRelease of OnHandler in PC. Therefore, load system action is never automatically executed from the frame action. However, the new NTTdocomo series, loading Flash Lite 3.1, are possible to execute it from the frame.

Events that can access external of OnHandler

  • upper and lower key unable to access external
  • press, release, keyPress”
  • (keyPress”<0>”-“<9>”,<#>,<*>)

Please note an upper and lower key. These keys correspond to “Tab key” in PC, which means “movement of focus.” Usually focus is moved by Tab key when entering a form, which exactly is the same thing. Upper and lower key neither can acquire “key Press “” and “key Press “””, and also inaccessible external.

Capacity of possible load
Please note that specification changes by each carrier and the version.


  • docomo1.1-3.0 … The total capacity of the file:up to 100KB
  • docomo3.1 … The capacity of one file: up to 100KB. Flame call : up to 100KB in total.

au…The capacity of one file: up to 100KB.

SofBbank…up to 150KB(depends on the model)

* Attention when reading external text
In case of au, it is necessary to declare the header specifying it when reading a parameter output from cgi etc.. For example, it declares it’s a plain text like following (example of php side’s output).

//var”print_text” is returned to swf file.
header("Content-Type: text/plain");

5.Basically use 12pixel or 24pixel for device font size.

To save the file capacity lightly, you may often use device font. However, it is necessary to consider following in case of using the device font.

  • The font size available to use of each terminal is limited.
  • The font is different in each terminal.

No formal document exists for device font. Therefore, I examined by making test files. Assuming that there are many chances to express Japanese text in device font, I examined how many letters it allows to show Japanese font. Please try to show test file from the Q code below. If “あtoこ” shows it means 10 letters, if “あtoそ” shows, it means 15 letters.

The result of the examinations of few terminals is as follows. It would be greatly appreciated if you send comments by e-mail to the writer ( after examination test file so the graph could be updated.

Though I have checked various display sizes of the device font, common sizes after Flash Lite 1.1 are 12 pixels and 24 pixels as you can see in the “Version and the main feature of Flash Lite by carrier”, mentioned in the beginning, Moreover, when you see each number of minimum display letters from the table mentioned above, it will be as the following:

  • 19 Japanese letters in 12 pixels
  • 9 Japanese letters in 24 pixels

In this number of letters or this size, it will seem the same way in spite of the carrier/terminal difference.

6.The memory that can be used is about 1MB.

Although it is not well known, memory control is most important. The memory I mentioned here is the memory volume allocated to Flash Lite from mobile phones. The bit map is displayed in red when the memory is insufficient, and, in the worst case, the reproduction of contents stops. The allocation of each terminal/Flash Lite version’s, memory is as follows:

Memory volume allocation of each carrier/Flash Lite version

Please note that au’s Flash Lite 1.1 is “1MB and over.” It is necessary to note that the allocated volume for Flash Lite is approximately 1MB for au’s initial Flash Lite loaded terminal. To save memorym, please note as follows:

  • Vector complex graphic
  • Mask processing within large range
  • A large amount of bitmapped image
  • Image with Alpha Channel
  • Use of many lines
  • Large amount of variable.

There are 2 methods to confirm memory utilization while producing contents.

1.Use command fscommand2() for mobile phones.

You use this script.

//Using Memory = Installing Memory - Free Memory
useMemory = fscommand2("GetTotalPlayerMemory") - fscommand2("GetFreePlayerMemory");

2.Confirm with Device Central

Adjust while confirming beep memory of Device Central while developing.

Though, even consuming only about 900KB of memory, it may cause memory shortage depending on the way of development when actually confirming with the terminal.


FlashLite is produced in such a tight specification in Japan. How did you feel about it? Does it sound like a hard work to you? W

The Japanese ownership rate of cellular phone compared with the population is 89% as of June, 2010.
It is a remarkable figure. In another words, most of the people own the cellular phone.

Also, users of surprising number have already experienced Flash with a mobile device.

With Android2.2 terminal, it comes to be able to play FlashPlayer10.1, and in the future, it is expected that the experience of mobile Flash increases all over the world.
At that time, a mode of expression and a manner of operation different from Flash of PC are needed.

If you haven’t experienced mobile Flash yet, why not try the Japanese cellular phone, a mobile advanced countries’ one.

The exciting experience in your hand is waiting for you.


  1. 岡田昇三 より:

    Thank you!;-)

  2. Nguyen より:

    Great post.

  3. supabok より:

    this is fantastic information! very helpful for everyone developing flash lite content for japanese devices!! thank you very much!!!

  4. 岡田昇三 より:

    Hi supabok,
    Thank you for your comment!! so, I want that will you tell about this entry to FlashLite developer. Twiiter or Facebook , your blog…Please!;-)

  5. Jim Borden より:

    How do I feel about it? Incredibly annoyed…Flash Lite 1.1 is such a joke platform…Flash 4 is nearly 10 years old, and Actionscript 1.0 is barely even a language ><. It bothers me that I have to use it at work. めんどくせー. This is 2011…not 2003.

    でも、そんな文句を言っても、このエントリーはありがたいですね。とても勉強になりました。仕事で無理やりFlash Lite 1.1を使わせられているんです。前のプロジェクトはiPhoneアプリだったのにな…

  6. Jim より:

    私の意見は、Flash Liteは死ぬべきです。未来へ進みましょう。Flash Lite1.1しかできない携帯なら、そろそろアップグレードの時間ですよ。やりきれないほど原始的…Actionscript 1.0は非常に汚くてほとんど機能が入っていないんです。さすが8年前に作られたソフトです。1993年のプレステーだって2MBのRAMがありました。


  7. Jim より:

    あ!2つ入れちゃってごめんなさい! (前のは途中で切られたから通じていないと思いました)

  8. 岡田昇三 より:

    Hang in there!;-)

Leave a Reply