System requirements
Starting with the 505i phones, the i-mode service by NTT DoCoMo supports the ability to view Flash Lite movies. The same Flash Lite functionality is available on all 505i phones, regardless of manufacturer.

	When viewing a swf that contains animated buttons, if one of the animated buttons receives focus then the default yellow focus rectangle remains visible and the position of the default yellow focus rectangle does not update with the position of the animated button. This behavior of Flash(TM) Lite is consistent with the MX External Player (Test Movie) and all desktop Flash Players.
	Buttons outside the stage cannot be navigated to and hence do not receive rollOver and rollOut events. This behavior of Flash(TM) Lite is different from desktop Flash Players.
	Certain buttons that are marginally outside the viewable area of the screen (stage) cannot be navigated to. This is because the defined hit area of the button is used to identify buttons that are in the stage. The defined hit area of the button needs to intersect the stage for it to be considered a navigatable button.
	In Flash(TM) Lite, button (focus rect) navigation ordering is from left to right and then top to bottom. The ordering is based on the centers of the buttons. However, there are situations where this ordering is not followed. This happens when buttons are close together and have y centers close together. This is because Flash(TM) Lite uses the formula (cx + cy * 6) to decide on the ordering of buttons, where cx and cy are the coordinates of the center of the defined hit area of the button.
	Button maintains focus when the movie is rewound. Conditions for reproducing the problem: a) Movie contains buttons that are persistent across all frames of the movie. b) One such button has focus. c) Playhead of the movie is not on the first frame. c) Movie is stopped and then rewound back to the first frame.
	If the <Enter> KeyPress event handler is associated with multiple buttons on the stage, then when the <Enter> key is pressed, the <Enter> keyPress event handler associated with the button that was placed first on the stage (during authoring) is triggered and processed. <Enter> keyPress event handlers associated with other buttons are not triggered and processed. This behavior in Flash(TM) Lite is consistent with the behavior on all desktop Flash Players.
	The value of the "Loop" PARAM affects all movieClips in the Flash(TM) Lite movie. It applies to the main movie and to all movieClips that exist at the start of playback and to all the movieClips that get introduced during playback of the movie. This also applies to the Native Applications where looping is always toggled off. This behavior of Flash(TM) Lite is different from desktop Flash Players.
	DoCoMo's i-mode compatible HTML uses "on" and "off" to control the "Loop" PARAM tag - this is different from standard Flash where "true" and "false" are used to control this tag..
	Adding two very large positive numbers can result in a negative number instead of infinity. This behavior of Flash(TM) Lite is different from the desktop players.
	If there is a TAB between characters then the space occupied by the TAB character varies based on: a) display screensize b) device font characterestics c) number of characters in the string d) starting point of text
	Only 252 lines of text can be displayed in a text box in Flash(TM) Lite. Text longer than 252 lines get clipped and will not be visible.
	Large amounts of text contained in a single text field can be expensive to render. This is more so when the text field contains TAB characters. The operation that slows down rendering is the code used to perform line wrapping of long lines. The problem is less pronounced when new line characters are used to break the large amounts of text into multiple lines.
	Properties and variables should be initialized in the first frame of a movie. When Properties and variables are used to control and monitor different behaviors of the Flash movie, the values of the properties and variables are not initialized when the movie is rewound back to the first frame. This is standard behavior on all Flash Players. Be sure to initialize all relevant properties and variables in the first frame of the movie. Do not explect the Flash Player to initialize the properties and variables to their default values.
	"gotoAndPlay" action used with a variable as argument. Conditions for reproducing this problem: a) "gotoAndPlay" action is used with a variable as argument b) The frame that the playhead is being moved to is the last frame of the movie or the movieClip. c) Looping is toggled off (either through the Loop PARAM in the HTML wrapper or in the native applications like StandBy Screen and My Picture). What happens: The ActionScript on the frame that the playhead is being moved to (the last frame of the movie or movieClip) will not be processed. The movie is rewound and the playhead is moved back to the first frame *before* the actionscript on the last frame is processed. Note: This issue does not exist if "gotoAndPlay" is used with a constant value as argument.
	In Flash(TM) Lite, the allowable number of levels of nested movieClips is 7. Movies with more than 7 levels of nested movieClips require more runtime stack space than is made available for Flash(TM) Lite. Phones provide limited runtime stack space to the Flash(TM) Lite Player.
	If rendering quality is set to High or Medium, a maximum of 5 consecutively overlapping areas of transparent objects can be blended together. This means that areas of overlapping objects where there are more than 5 levels of transparency, will not display correctly. Only those parts of the top 5 mutually overlapping transparent objects will be blended together with either the first opaque object behind them or the background. This is different from the Flash6 player which will properly render up to 11 consecutively overlapping transparent objects.
	Text that is not visible on stage in the authoring tool may be visible on the actual handset. This happens when using static device text fields. This is because static device text fields are published with a width that is larger than the width displayed in the authoring tool. The result is that a static device text field that is to the left and just off the display area in the authoring tool may actually cover part of the display area on the handset. The work around is to keep static device text that is off screen farther to the left.