Edit appinfo

The appinfo.json configuration file contains information defining the operation of your app, stored as key-value pairs. Many of the properties defined in the file are configured in AppStudio Settings, but there are cases in which you must add items to the file manually.

Some categories listed below are not in the appinfo.json configuration file at all by default. Other categories do already appear in the configuration file, with properties that are managed in Settings. The properties listed in this topic are additional to those that configured in Settings.

The appinfo.json file resides in your app's main folder. To access it, click the Files button for your app in ArcGIS AppStudio.

Capabilities

The capabilities category will already exist in the appinfo.json configuration file and may be populated with options that have been selected in the Capabilities section of the Settings tool. You can also manually add any of the following properties.

  • backup—When set to false, no backup or restore of the application is ever performed on Android, and the app is excluded by full-system backups. If not specified, the default value is false.
  • ios.appTransportSecurity.allowArbitraryLoads—If set to false, transport security restrictions are applied for network connections. If not specified, the default value is false.
  • interAppFileSharing—When set to true, the files in your app can be accessed using the Files app on iOS. If not specified, the default value is false.
  • mediaLocation— When set to true, your app can retrieve unredacted Exif metadata from photos. If not specified, the default value is false.
  • indoorLocation—When set to true, all required Bluetooth capabilities for indoor positioning are enabled. If not specified, the default value is false.

In the following example, no transport security restrictions are applied.

"capabilities": {
    "ios": {
        "appTransportSecurity": {
             "allowArbitraryLoads": true
    }
},

Deployment

The deployment category will already exist in the appinfo.json configuration file and may be populated with options selected on the Platforms and Advanced sections of the Settings tool. You can also manually add any of the following properties.

  • android.trustUserCertificates—Setting this property to true causes an app to accept all certificate authorities. By default, this is false and AppStudio apps don't trust user-added certificate authorities for secure connections on Android.
  • android.minimumSdkVersion—Defines the minimum API level required for the app to run. If not specified, the default value of an AppStudio app is 23.
  • android.targetSdkVersion—Defines the intended API level for the app. It also affects the way the user must grant app permissions. If the device is running Android 6.0 or later, and your app's target SDK is 23 or higher, the user must request each permission it needs while the app is running. If not specified, the default value of an AppStudio app is 31 for local Make and 33 for cloud Make. For more information, see the Google Play Console help.
    Note:

    Local make users must set deployment.android.targetSdkVersion to 33 in their app's appinfo.json file to meet the requirements listed in https://developer.android.com/google/play/requirements/target-sdk.

  • android.enableGooglePlayServicesSecurityProvider—Controls whether your app calls the Google Play security provider to ensure that the app is running on a device with the latest updates to protect it from known exploits. If not specified, the default value of an AppStudio app is false.
  • ios.minimumVersion—Defines the minimum operating system version on which your software can run. If not specified, the default value of an AppStudio app is 13.0.
  • desktop.allowOverwrite—If set to true, the app can be installed on Windows without uninstalling a previous version of the app. If not specified, the default value is false.

In the following example, all certificated authorities will be accepted on Android, and the minimum operating systems that the app can be installed on for Android and iOS are 6.0 and 13.0 respectively.

"deployment": {
    "android": {
        "trustUserCertificates": true,
        "minimumSdkVersion": 23,
        "targetSdkVersion": 31
    },
    "ios": {
        "minimumVersion": "13.0"
    }
},

Display

The display category will already exist in the appinfo.json configuration file and may be populated with options that have been selected in the Display section of the Settings tool. You can also manually add any of the following properties.

  • enableHighDpi—Determines whether the app will open in high DPI mode on devices that support this mode. If not specified, the default value is false.
  • statusBar—Defines whether the status bar appears when using your app on any iOS and Android device. This should not be confused with the usesStatusBar property set in the Status Bar options on the Settings > Devices tab for your app, which controls whether the status bar appears on phones or tablets. If not specified, the default value is false.
  • ios.windowMode—Defines how the app interacts with the iPad Multitasking capability, allowing the app to be used alongside other apps on the same screen. By default, this property is enabled if either portrait or landscape mode is disabled in the Tablet options on the Settings > Devices tab for your app. To disable ios.windowMode, allowing your app to only run on the iPad full screen, set it to fullscreen.

In the following example, high DPI is enabled, the status bar is enabled on all iOS devices and the app will only run in full screen on an iPad.

"display": {
    "enableHighDpi": true,
    "statusBar": true,
    "ios": {
       "windowMode": "fullscreen"
    }
},

Make

The make category does not already exist in the appinfo.json configuration file. You can manually add any of the following properties.

  • ignore—Defines a list of file name patterns to be excluded from an app's resources when built. This allows files to be kept in the app item that are useful during development and testing but aren't needed when building the app.
  • ios.enableBitcode—Specifies whether the app supports Bitcode. Apple optimizes the app binary for specific devices without requiring updating or resubmission. Bitcode is only available for iOS apps and is enabled by default for Apple App Store builds.

Management

The management category does not already exist in the appinfo.json configuration file. You can manually add any of the following properties.

  • configurationSchema—Accepts a file name or path for an .xml file that contains app configuration defaults used when deploying your app with Enterprise Mobile Management (EMM) software. For information about how to format this .xml file, see the Android developer reference for Set up managed configurations.
  • android.restrictionFile—Accepts a file name or path for an .xml file used to impose restrictions on Android devices. This is required to use app configuration when deploying your app with EMM software. For information about how to format this .xml file, see the Android developer reference for RestrictionsManager.
  • windows.applicationName—The name of the application that needs app configuration properties, if the app requires enterprise configuration.
  • windows.keyRoot—The registry key root under which to look for these app configuration properties. If not specified, this defaults to HKEY_CURRENT_USER.
  • windows.vendorName—The software vendor name responsible for the application. For Esri apps, the value is ESRI.

In the following example, configuration files and parameters used when deploying the app with EMM software are listed.

"management": {
     "android": {
         "restrictionFile": "AppConfig_Android.xml"
     },
     "configurationSchema": "AppConfig.xml",
     "windows": {
         "applicationName": "MyApp",
         "keyRoot": "HKEY_CURRENT_USER",
         "vendorName": "MyName"
     }
},

Resources

The deployment category will already exist in the appinfo.json configuration the file and may be populated with options selected on the Resources sections of the Settings tool. You can also manually add any of the following properties.

  • appIconBackgroundColor—Accepts a hex color value and defines the background fill color for platforms that enforce a specific icon shape. For example, iOS enforces a rounded rectangle for app icons and automatically fills transparent areas with black. If no value is specified, the default behavior for the platform is applied.
  • launchImageTextColor—Accepts a hex color value and defines the color of text that appears on your app's splash screen. The default color for this text is black, which may be difficult to see, depending on your app's splash screen.
  • platformName.appIcon—Additionally, platformName should be replaced with the platform you use. This accepts a file path to define a platform-specific app icon. If an icon is not provided for a platform, the general icon provided for the app is used.
  • android.adaptiveIcons—When set to true, Android devices will show the app’s adaptive icon. The following properties should also be specified under resources, defining file paths to elements of the adaptive icon.
    • android.appIcon—File path to the launcher for the adaptive icon. References the foreground and background files.
    • android.appIconForeground—File path to the foreground of the adaptive icon. Can be a .xml or .png file.
    • android.appIconBackground—File path to the background of the adaptive icon. Can be a .xml or .png file.
    • android.appIconBackgroundColor—Hex color value, an optional alternative to android.appIconBackground. If both are defined, android.appIconBackground will be used.

The following code sample shows an adaptive icon for Android and unique icons for each platform.

"resources": {
    "android": {
       "adaptiveIcons": true,
	      "appIcon": "ic_launcher.xml",
	      "appIconBackgroundColor": " ic_launcher_background.xml",
	      "appIconForeground": " ic_launcher_foreground.xml"
	     
    },
    "ios": {
        "appIcon": "ios_appicon.png"
    },
    "linux": {
        "appIcon": "linux_appicon.png"
    },
    "macos": {
        "appIcon": "mac_appicon.png"
    },
    "windows": {
        "appIcon": "windows_appicon.png"
    }
},

Adaptive icons are unique to Android and are used to ensure that your app icon displays as expected on a wide range of operating system configurations. Adaptive icons can be shown as circles, squares, or variations in between. At the most basic level, an adaptive icon can be made from a .png in the foreground and a solid color as background. Any tool can be used to create the .png, but it is important to ensure your image has sufficient padding for it not to be cropped by the mask applied by the operating system. For the size and shape specification of adaptive icon files, see Adaptive Icons. Online tools such as EasyAppIcon can be used to create all the files you need for an adaptive icon but may be limited to only creating specific file outputs. For the best experience in creating adaptive icons, it is recommended that you use Android Studio.

In the sample code above, .xml files are used for both the foreground and background. The following code sample shows the content of the ic_launcher.xml file that references the foreground and background files.

<?xml version="1.0" encoding="utf-8"?>
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@color/ic_launcher_background"/>
    <foreground android:drawable="@drawable/ic_launcher_foreground"/>
</adaptive-icon>

The following sample code shows the content of the ic_launcher_background.xml file, which describes a solid blue background.

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="ic_launcher_background">#3697f0</color>
</resources>

The following sample code shows the content of the ic_launcher_foreground.xml file, which describes the AppStudio Run icon Player as the foreground image.

<vector xmlns:android="http://schemas.android.com/apk/res/android"
    android:width="108dp"
    android:height="108dp"
    android:viewportWidth="108"
    android:viewportHeight="108">
  <group android:scaleX="1.62"
      android:scaleY="1.62"
      android:translateX="28.08"
      android:translateY="28.08">
    <path
        android:fillColor="#FF000000"
        android:pathData="M22.079,1L9.92,1A1.921,1.921 0,0 0,8 2.921L8,28.08A1.921,1.921 0,0 0,9.921 30L22.08,30A1.921,1.921 0,0 0,24 28.079L24,2.92A1.921,1.921 0,0 0,22.079 1zM23,28.08a0.922,0.922 0,0 1,-0.921 0.92L18,29v-1h-4v1L9.921,29A0.922,0.922 0,0 1,9 28.08L9,27h14zM23,26L9,26L9,4h14zM23,3L9,3v-0.08A0.922,0.922 0,0 1,9.921 2L22.08,2a0.922,0.922 0,0 1,0.921 0.92zM12.1,10.417L12.1,20.7l8.227,-5.142zM12.9,11.86l5.917,3.698 -5.917,3.699z"/>
  </group>
</vector>

Translations

After you have generated translation files for your app, you must ensure that they are referenced in the appinfo.json file. For more information about preparing your app for translation and generating these files, see Globalize your app.

Once these files are present in your app item, the path and fileName properties must be added under a new category translations in the appinfo.json file to note their location.

The following example associates the files of a Map Viewer template app:

"translations": {
    "path": "MapViewer/languages",
    "fileName": "MapViewer"
}

After you add the code sample above to your appinfo.json file, the built app uses files in the MapViewer languages folder named MapViewer_localecode.qm (for example, MapViewer_en.qm and MapViewer_ja.qm).

Usage description keys

A common case for editing the appinfo.json file directly is to add usage description keys. These are short strings that describe why your app is requesting to use functionality such as the camera, background location capture, or Bluetooth. This is a requirement for iOS and macOS devices and cannot currently be used on other platforms. While this is intended to be implemented as a user interface item in the future, currently you must add it manually.

You must add individual usage descriptions under the usageDescriptionKeys heading. You can insert this section into the appinfo.json file at any time. The order of the values makes no difference to functionality. While there is no harm in including descriptions for all capabilities, even those not supported by the app, unnecessary description strings are not included in the app-building process.

In the following code sample, bluetoothUsageDescription would not be used, because the app doesn't include Bluetooth functionality.

"usageDescriptionKeys": {
    "bluetoothUsageDescription": "This app uses Bluetooth to scan and connect to devices. (iOS only)",
    "cameraUsageDescription": "This app needs access to the camera to take a picture. (iOS only)",
    "faceIDUsageDescription": "This app uses face ID to authenticate using facial recognition. (iOS only)",
    "locationAlwaysUsageDescription": "This app needs access to device location when the app is running or in the background. (iOS and macOS)",
    "locationWhenInUseUsageDescription": "This app needs access to device location when the app is running. (iOS and macOS)",
    "microphoneUsageDescription": "This app needs access to a microphone to record audio. (iOS only)",
    "photoLibraryUsageDescription": "This app needs access to the photo library to select a photo. (iOS only)",
    "photoLibraryAddUsageDescription": "This app uses your photo library to save photos in the camera roll for use in the app. (iOS only)",
    "locationAlwaysAndWhenInUseUsageDescription": "This app needs access to device location when the app is running or in the background. (iOS and macOS)",
    "sensorsUsageDescription": "This app uses the Activity Recognizer to identify device motion."
},

Additional properties

The following property is added outside of any category.:

queryApps.packageNames—This property is added outside of any section. This accepts a list of app package names that will then be queried by the isAppInstalled function in the AppFramework component when used on Android devices.