Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
I started following the Android track after I installed the tools. After the FunFacts segment, I found it difficult to keep up using different tools, so I decided to install the suggested version. Hilarity ensued. Now I have a mess! I've unintalled SDK and AS, and reinstalling the suggested AS keeps giving me errors that I don't have the 2.2.1 platform installed, and I'm stuck.
I'll try my best to guide you through removing all of the Android Studio files on a Windows System. Note that some files may be located in a different location depending on where you chose to install and the versions you've been using so if something is not in its normal place, please let me know.
If you want to delete any of your previous projects, the directory where your projects are found is the AndroidStudioProjects directory. It is located in your root user file, C:\Users\[YOUR WINDOWS USERNAME]\.
First of all, thank you for taking time out of your day to help. I did all that, then followed the instructions Ben put forth in the "setting-up-an-android-development-environment-for-windows" almost to the letter - I put Android Studio in C:\Program Files\android-studio.It started up OK, and I opened the project, which presented only one gripe, that AS used to be in C:\Program Files]Android Studio\android-studio. After a build attempt, I get a message similar to the one I had before:Installing Archives: Preparing to install archives Downloading SDK Platform Android 5.1.1, API 22, revision 2 URL not found: C:\Program Files\android-studio\sdk\temp\android-22_r02.zip (Access is denied) Done. Nothing was installed.
Figured it out. Doh. I had installed SDK under \Program Files\, and Windows (silently) objected to that, disallowing such fun things as fetching android-22_r02.zip, which subsequently could not be found and unzipped.
Having the Android development tools installed on your development system is required for developing Android apps using RAD Studio. To build mobile apps for the Android target platform, you also need to add an Android SDK to the RAD Studio SDK Manager.
If you installed the JDK yourself, Java might not be in your system path. For example, if Java is not in your system path, you must use android.bat to start the Android SDK Manager (instead of SDK Manager.exe).If you want to optimize for Android development, you should add Java to your system path environment variable.
The JAVA_HOME environment variable must be set according to your JDK installation path. See the Setting Environment Variables section on how to set up environment variables. Alternatively as of cordova-android 10.0.0 or greater, CORDOVA_JAVA_HOME can be set in place of JAVA_HOME, allowing a JDK install to be used specifically for Cordova development.
When installing on Windows, you need to add the path to the Gradle's binary directory to your path environment variable. See Setting Environment Variables) on how to configure system environment variables.
Note: This is the system's Gradle version. The system's Gradle binary will create the Gradle Wrapper file that declares and obtains the appropriate version of Gradle needed for building the Android application. The system-level and project-level version of Gradle may not and does not need to match. The project-level's version of Gradle is defined in the Cordova-Android's package and set based on what Android supports.
It is recommended to install the highest supported version of the SDK Platform and Build Tools based on the project's installed version of Cordova-Android. Please see the Android API Level Support to find the supported version based on the Cordova-Android versions.
Cordova's CLI requires specific environment variables so it can function correctly. If the environment variables are missing, the CLI will attempt to resolve the variable temporarily. If the missing variables fail to resolve, they must be set manually.
The latter two options both involve including an extra file in your Android platform folder. In general, it is discouraged to edit the contents of this folder because it is easy for those changes to be lost or overwritten. Instead, these files should be copied into the folder as part of the build command by using the before_build hook script.
If you need to customize the build.gradle file, rather than edit it directly, it is recommended to create a sibling file named build-extras.gradle. This file will be included by the main build.gradle script when present. This file must be placed in the app folder of the Android's platform directory (/platforms/android/app). It is recommended to use the before_build hook script to copy this file over.
To change the Gradle JVM args, the --jvmargs flag can be used with both Cordova's build and run commands. This is mostly useful for controlling how much memory gradle is allowed to use during the build process. It is recommended to allow at least 2048 MB.
If your application has enabled the cdvBuildMultipleApks Gradle property (see Setting Gradle Properties), the version code of your app will also be multiplied by 10 so that the last digit of the code can be used to indicate the architecture the apk was built for. This multiplicationwill happen regardless of whether the version code is taken from the android-versionCode attribute or generated using the version.
Note: When updating the android-versionCode property, it is not recommended to increment the version code taken from built apks. It is recommended to increment the code based off the value in your config.xml file's android-versionCode attribute. This is because the cdvBuildMultipleApks property causes the version code to be multiplied by 10 in the built apks and thus using that value will cause your next version code to be 100 times the original, etc.
By default, if the build.json file exists in the project's root directory, it will automatically be detected and used. If the file is not located in the project's root directory or has multiple configuration files, the command line argument --buildConfig must be supplied with the path to the file.
There is also support to mix and match command line arguments and parameters in build.json. Values from the command line arguments takes precedence. This can be useful for specifying passwords on the command line.
You can also specify signing properties by including a .properties file and pointing to it with the cdvReleaseSigningPropertiesFile and cdvDebugSigningPropertiesFile Gradle properties (see Setting Gradle Properties).
For details on the debugging tools that come packaged with the Android SDK, seeAndroid's developer documentation for debugging.Additionally, Android's developer documentation for debugging web appsprovides an introduction for debugging the portion of your app running in theWebview.
Cordova-Android projects can be opened in Android Studio. This can be useful if you wish to use Android Studio's built in Android debugging and profiling tools or if you are developing Android plugins.
Note: When opening your project in Android Studio, it is recommended to NOT edit the code within the IDE. Editing in Android Studio will edit code residing in the platforms directory of your project. It is not updating the code in the projects root www)directory. The changes are liable to be overwritten. Instead, edit the www folder and copy over your changes by running cordova prepare.
Plugin developers wishing to edit their native code in Android Studio should use the --link flag when adding their plugin to the project with the cordova plugin add. This will create a symbolic link of the plugin files from the plugin source directory to the project's platforms directory.
Native Android apps typically consist of a series of activities that the user interacts with. Activities can be thought of as the individual screens that makeup an application; different tasks in an app will often have their own activity. Each activity has its own lifecycle that is maintained as the activity enters and leaves the foreground of a user's device.
In contrast, Cordova applications on the Android platform are executed within a Webview that is embedded in a single Android activity. The lifecycle of this activity is exposed to your application through the document events that are fired. The events are not guaranteed to line up with Android's lifecycle, but they can provide guidelines for saving and restoring your state. These events roughly map to Android callbacks as follows:
Most other Cordova platforms have a similar concept of lifecycles and should fire these same events when similar actions happen on a user's device. However, Android presents some unique challenges that can sometimes show up thanks to the native Activity lifecycle.
In Android, the OS can choose to kill activities in the background in order to free up resources if the device is low on memory. Unfortunately, when the activity holding your application is killed, the Webview in which your application lives will be destroyed as well. Any state that your application is maintaining will be lost in this case. When the user navigates back to your application, the Activity and Webview will be recreated by the OS, but state will not be automatically restored for your Cordova app. For this reason, it is imperative that your application be aware of the lifecycle events that are fired and maintain whatever state is appropriate to make sure a user's context in your app is not lost when they leave the application.
Your application is susceptible to being destroyed by the OS whenever it leaves the sight of the user. There are two main situations in which this can occur. The first and most obvious case is when the user presses the home button or switches to another application.
d3342ee215