[Feature Request] Ability to set AddAirToAppID using ADT

[neilrackett]

We maintain a number of AIR applications, some require an air. prefix when published for Android (but not iOS) and others don't.

At present this setting can only be controlled globally, either by changing the value of the environment variable AIR_NOANDROIDFLAIR or, with Adobe AIR SDK 33+, by updating adt.cfg's AddAirToAppID setting. Both methods are sub-optimal when you're jumping between projects or can't remember which project requires which setting.

Please could you therefore add the ability to change this setting at compile time, so that it can be set on a per-project basis, perhaps using one of the following methods:

1. An ADT parameter for this specific setting, e.g. -addAirToAppId [true|false]; or
2. An ADT parameter that enables users to select which adt.cfg file to use at compile time, e.g. -cfg /path/to/no-air-adt.cfg

Option 2 may be more useful, since it would enable debug and architecture settings to be set on a per-project basis too.

Please vote for this feature on Adobe Tracker.

(Of course, if there's an undocumented method of doing this already, please don't hesitate to let me know!)

[itlancer]

May be it will be better to completely remove air. prefix as legacy so users could add it by themselves manually if it necessary to maintain applications with it.

[neilrackett]

It would be useful to keep it (but maybe switched off by default) for maintaining legacy projects, because it affects Android and iOS builds differently; if you add it manually, you end up with the wrong app ID for iOS.

[ajwfrost]

My concern with changing the default value is that it's likely to cause problems for people who are just using one SDK for their application, install a later SDK, and suddenly all their updates will fail because the appid has changed. But if you think this is something that developers would cope with, then I have no objection to this..

Afaik this is something that's only added as a prefix to Android applications, so we'd ignore the setting for iOS: in those cases, the application ID is always just whatever's given in the XML descriptor file. Currently we ignore this config setting unless it's an APK packaging - and if we had a "-addAirToAppId' flag, it would only be something you could add when packaging APK.

thanks

[neilrackett]

Yes, this setting only affects Android, which is the primary reason why it would be great to have the ability to set it using ADT, as it isn't something that can easily be resolved by editing app.xml.

If you added an -addAirToAppId flag to ADT, couldn't you simply ignore it when you're packaging something other than an APK, the same way the config setting is ignored now? Or even name it -addAirToAndroidAppId if you wanted to be really explicit that it has no affect on other builds? Even if it were only supported when packaging an APK, that would still be useful.

Basically, anything that would allow me to change/save this setting on a per-project basis (whether a flag, support for a local adt.cfg or something else) would be a massive help.

The default value doesn't really matter.

[marchbold]

The way we do it is the way that Adobe had set it up originally just with an environment variable.

As part of our builds we often have a script at some point that generates the APK and we just set the AIR_NOANDROIDFLAIR environment variable just before the adt build:

export AIR_NOANDROIDFLAIR=true 
adt -package -target apk ...

We use this as part of a build script for a project, and we can then read the value for this environment variable from a project config.

Would definitely advise against changing the default (however annoying it is...)

[neilrackett]

Thanks @marchbold, most projects are in Flash Builder / Eclipse, which doesn't have a build script as such, but that may well be the kind of solution we end up using; either with additional Builders (which has been a bit hit-and-miss so far) or, if it comes to it, switching to a different IDE.

[marchbold]

Been a long time since I worked with FlashBuilder but with other IDEs they respect the environment variables in the context that launch them so you can write a script for your project and set the environment variable there and then launch your IDE, eg I have a script like this for IntelliJ:

#!/bin/bash
export AIR_ANDROID_SHARED_RUNTIME=false
# Launch IntelliJ
open -a "/Applications/IntelliJ IDEA.app" .

[FliplineStudios]

I'd be wary of changing the default behavior for adt, this could definitely lead to problems with developers updating an existing app with a newer AIR SDK, if they're unaware about needing an additional parameter just to retain the same app ID they're already using. Setting a new adt parameter for removing the prefix or targeting a different cfg file sounds fine, as long as adt would still default to including the air. prefix when the parameter hasn't been set.

[neilrackett]

In case it's useful to anyone, the best workaround we've come up with so far for Flash Builder on Windows is to add a builder (project properties > Builders) at the top of the list that replaces adt.cfg with project-specific settings by running one of the following scripts:

copy /y adt.cfg "%AIR_HOME%\lib\" > nul

or

echo AddAirToAppID=false> "%AIR_HOME%\lib\adt.cfg"

[zwetan]

At present this setting can only be controlled globally, either by changing the value of the environment variable AIR_NOANDROIDFLAIR or, with Adobe AIR SDK 33+, by updating adt.cfg's AddAirToAppID setting. Both methods are sub-optimal when you're jumping between projects or can't remember which project requires which setting.

An env var does not have to be global and system-wide, as @marchbold indicates you can set it up per project

export AIR_NOANDROIDFLAIR=true 
adt -package -target apk ...

it would work also from automated builds, Ant for ex

<exec executable="exe-here">
  <env key="AIR_NOANDROIDFLAIR" value="true"/>
  ...
</exec>

or

<java dir="${basedir}" jar="${ADT}" fork="true" failonerror="true">
  <env key="AIR_NOANDROIDFLAIR" value="true"/>
  <arg line="-package"/>
  ...
</java>

That's because those env vars are pretty much standards across ALL operating systems.

Now, the default should not be changed, it would break already existing builds, codes, setups, etc.

The standard way to update this, is if you got an env var AIR_NOANDROIDFLAIR then you could add a command-line parameter to override it for ex --noandroidflair=true

There are precedences order rules for configuring command-line tools, please don't mess that up see for example Environment variables to configure the AWS CLI

Environment variables provide another way to specify configuration options and credentials, and can be useful for scripting or temporarily setting a named profile as the default.

Precedence of options

• If you specify an option by using one of the environment variables described in this topic, it overrides any value loaded from a profile in the configuration file.

  • If you specify an option by using a parameter on the CLI command line, it overrides any value from either the corresponding environment variable or a profile in the configuration file.

@neilrackett

the best workaround we've come up with so far for Flash Builder on Windows

learn how works environment variables, you are overcomplicating things for nothing here

you can perfectly launch a Flash Builder IDE with a specific env var setup or define that env var from the publish settings

[neilrackett]

Just to give a bit more background to the thinking behind my feature request:

• At present, some ADT settings are environment variables, some are in adt.cfg and the rest are ADT parameters - it would be great to have everything available as a parameter, even if the default could be set using other methods
• In the specific context of Flash Builder 4.7 for Windows, it is not possible to set environment variables in the project or export/publish settings and any environment variables set using other methods in Builders appear to be sandboxed and so do not persist to the point where ADT runs
• It's really easy to add project- and platform-specific ADT parameters in Flash Builder

@marchbold's suggestion to set environment variables as part of IDE launch is a good workaround, but has the disadvantage that you have to restart Flash Builder before working on another project that requires a different configuration.

I know other IDEs are available, but I still like Flash Builder, and with legacy projects in particular we'd prefer to take an if it ain't broke don't fix it approach rather that switching to other tools or building with shell or ANT scripts.

While I appreciate that my current workaround is very far from ideal, it's the simplest solution we've found so far that works consistently with Flash Builder.

So, as @zwetan suggests, why not add a command line parameter to override it in ADT?

[ajwfrost]

Thanks everyone! Yes it's a little confusing with the use of environment variables, a config file, and command-line options. @zwetan thanks for the precedence list, yes that sounds like a good approach! @neilrackett I actually would have gone more with a config file rather than a longer list of command-line options but if we go with an approach that combines the two, then it might make sense. Very early on, I'd wondered whether we could pass all the various parameters to ADT via a config file so that we don't have to keep entering all the certificate/provisioning details in full etc.. but I take your point, it would be good to have everything set as a parameter too.

The original reason for the adt.cfg file was because we needed a way to allow developers to build ARMv8 builds, and some toolchains such as Animate didn't give you options to select that yourself (until their 2020 update) and were still passing -armv7 on the command line to us (and Flash Builder bypasses the command line entirely!!)

So we could just do: 1) we extend the capabilities of the config file so that it can contain other options too (maybe..?) 2) we allow a wider range of options to be set via environment variables (these have precedence over the above) 3) we ensure everything could also be set on the command line (as these have the highest precedence).

If we also allowed a config file to be specified on the command line, then I would suggest that this has the highest precedence and we'd throw an error if you had conflicts between a command-line-specified config file and other command-line options.

Would that work? - and definitely agree, we keep the 'default' behaviour as it is now..

[marchbold]

Generally I was always confused by the adoption of the environment variables for adt. So my suggestion would be to not extend these (and probably deprecate them to some degree?) I have had to use AIR_IOS_SIMULATOR_DEVICE, AIR_ANDROID_SHARED_RUNTIME, and AIR_NOANDROIDFLAIR in our projects.

I don't like the config file in the SDK, to me an SDK shouldn't be modified by a developer. And if it does it should only be global SDK related configuration that relates to every project a developer is working on, and definitely shouldn't be needed for a per project build. (I understand the need for it for animate but still feel that should be an exception rather than the standard). Honestly I'd even question the usage of putting the license file in the sdk but hey...

I think command line arguments are obviously the best approach and unless you see an advantage to introducing another project config file, I would avoid the introduction of another option avenue.

So

1. no! :)
2. maybe...
3. definitely!
4. new config file only if it provides something new / better

My only concern is that new command line options will affect the command line length issue we already have on windows?

[neilrackett]

Yes, that sounds like it should work, although I'm not personally in favour of using environment variables and would suggest a warning instead of an error, so that:

1. Command line specified config file, e.g. adt -cfg my-project.cfg ..., overrides
2. Command line parameters, which overrides
3. Environment variables, which overrides
4. Global settings in adt.cfg

I can definitely see advantages in using a local config file rather than an ever increasing number of command line parameters.