• Installation Issues
• Build Issues
• Debugging Issues

You can safely install multiple versions of Java side by side. If you make Java 1.8 or newer the primary version of Java on your system, the ActionScript & MXML extension will find it automatically. If you prefer to make Java 1.6 the primary version, for some reason, you can use the as3mxml.java.path setting for the ActionScript & MXML extension to manually specify the path to Java 1.8 or newer.

See also: Adobe: Running Adobe Flash Builder on Win and Mac with Java 7/8

Sometimes, when trying to use a compiler option in the compilerOptions field of asconfig.json, a build will fail with an "Unknown compiler option" error. This could happen if you try to use a new compiler options that the extension doesn't know about (sometimes, even advanced options that are less commonly used may result in this error).

As a workaround, try to add the option to the additionalOptions string instead. Then, create a new issue for the missing compiler option so that it can be added in a future version.

This error may be displayed by Visual Studio Code for one of the following reasons:

• The current workspace may not have an ActionScript SDK configured, or the currently selected SDK is invalid. Choose a different ActionScript SDK for the current workspace.

• The chosen task may be misconfigured in your workspace's tasks.json file. Learn how to build an ActionScript project in Visual Studio Code.

• The location where you saved asconfig.json may be incorrect. This file should be saved in the root directory of your project. Check if you've accidentally placed it in .vscode/ or another incorrect sub-directory.

You may receive this error if the default target-player value in your workspace SDK is targeting a runtime that is older than Adobe Flash Player version 10.1. For example, this error may be reported when you select Adobe Flex 3.6 or older as your workspace SDK.

To use an older SDK that was released before Flash Player 10.1, you can fix this issue by specifying the target-player compiler option with the value 10.1 or newer.

{
	"compilerOptions": {
		"target-player": "10.1"
	}
}

Additionally, your SDK must contain a playerglobal.swc file in the appropriate folder in the SDK for the specified target-player value. For version 10.1, it should be frameworks/libs/player/10/playerglobal.swc. Use a different version value for the directory name, as appropriate.

This error can happen when your main/root class is inside a package instead of at the top-level. You have two options for fixing this error:

1. As a workaround, move the main class to the top-level package. In other words, use package {} instead of package com.example {}.

2. Add your project's source directory to the source-path compiler option. So, if your class is in src/com/example/Main.as, add src to the source-path.

This error can happen sometimes when using JDK version 8. Try updating to a newer JDK, such as version 11 or version 17.

Check that the XML namespace in your AIR application descriptor matches the version of your Adobe AIR SDK. For example, if you are using AIR SDK 27, the XML namespace should be http://ns.adobe.com/air/application/27.0. This error occurs when this XML namespace refers to an older version of Adobe AIR, but the SWF file is compiled with the swf-version set too high for that older version.

Alternatively, if you need to target an older version of Adobe AIR, but you need to compile with a newer SDK, set the swf-version compiler option to the appropriate value for the older version of AIR that you are targeting.

You may have set the application field in asconfig.json incorrectly. It should point to a file in your workspace that does not overlap with the output folder.

Additionally, double-check that the <initialWindow> section includes a <content> element. The extension will automatically populate this element when it copies your Adobe AIR application descriptor to the output folder. It may fail if the element is missing.

There are a few things that you can try to resolve this issue:

• Ensure that your Adobe AIR application descriptor was correctly copied to the output directory when you compiled your project. If it is be missing, something may be misconfigured in asconfig.json
• Check that the contents of the Adobe AIR application descriptor are valid and do not contain any typos. For example, you may encounter this error when this file contains invalid XML (even if the file actually exists).

Download the Adobe Flash Player projector content debugger for your platform from Adobe Flash Player Debug Downloads, and make it the default program that opens .swf files.

If you prefer not to set the default program for .swf files, you may use the runtimeExecutable field in your project's launch.json file. Set runtimeExecutable to the path of the Adobe Flash Player projector content debugger.

{
	"type": "swf",
	"request": "launch",
	"name": "Launch SWF",
	"runtimeExecutable": "c:\\Downloads\\flashplayer_sa_debug.exe"
}

On Windows, set it to the path to the .exe file. On macOS, set it to the path of the .app file.

The Adobe AIR: ADT error messages documentation describes status code 15 like htis:

No devices | Verify that a device is attached and turned on or that an emulator is running.

This error means that your Android or iOS device cannot be found. There are a few things that you can try.

1. Ensure that your Android or iOS device is connected to your computer with a USB cable.
2. Enable development mode on your device, if it is not already enabled.
3. If your device is on the lock screen, try unlocking it.
4. Check if your device is asking for permission to connect to your computer.
5. Disconnect the USB cable from your device and your computer, and try to reconnect them.

If you're launching your Apache Royale app in Firefox, the debugger may not stop at certain breakpoints when your app first loads. However, you will find that breakpoints that are triggered later (such as those added inside mouse event listeners) work correctly.

This is a limitation of the Firefox debug protocol. The JavaScript starts executing before the debugger can connect, so these breakpoints are essentially ignored. However, there is a workaround. You may add a debugger statement before the main class is instantiated (usually, that's the ${body} token) in a custom HTML template file:

<!DOCTYPE html>
<html>
<head>
${head}
</head>
<body>
<script>
	debugger;
</script>
${body}
</body>
</html>

Use your custom template by specifying the html-template compiler option.

The debugger will automatically pause at this line. Press the green continue button in the debugger controls, or use the F5 keyboard shortcut, to resume debugging and access the breakpoints that previously didn't work.

Note: The debugger statement cannot be used in ActionScript code. It must be added inside a JavaScript <script> tag on the HTML page.