App Publication
App Publication
Statement Purpose:
In this section students learn that how to make their application public.
Activity Outcomes:
After completing this chapter we will be able to understand the following topics.
- Debugging
- Android App Development Life Cycle
- APK Conversion Process
- App Publishing Guidance
- Tips for Launching an App
Instructor Note:
Debugging
The Android SDK provides most of the tools that you need to debug your applications. You need a JDWP-compliant debugger if you want to be able to do things such as step through code, view variable values, and pause execution of an application. If you are using Android Studio, a JDWP- compliant debugger is already included and there is no setup required. If you are using another IDE, you can use the debugger that comes with it and attach the debugger to a special port so it can communicate with the application VMs on your devices. The main components that comprise adb acts as a middleman between a device and your development system. It provides various device management capabilities, including moving and syncing files to the emulator, running a UNIX shell on the device or emulator, and providing a general means to communicate with connected emulators and devices.
Dalvik Debug Monitor Server
DDMS is a graphical program that communicates with your devices through adb. DDMS can capture screenshots, gather thread and stack information, spoof incoming calls and SMS messages, and has many other features.
Device or Android Virtual Device
Your application must run in a device or in an AVD so that it can be debugged. An adb device daemon runs on the device or emulator and provides a means for the adb host daemon to communicate with the device or emulator. cseitquestions.blogspot.in cseitquestions.blogspot.in
JDWP debugger The Dalvik VM (Virtual Machine) supports the JDWP protocol to allow debuggers to attach to a VM. Each application runs in a VM and exposes a unique port that you can attach a debugger to via DDMS. If you want to debug multiple applications, attaching to each port might become tedious, so DDMS provides a port forwarding feature that can forward a specific VM’s debugging port to port 8700. You can switch freely from application to application by highlighting it in the Devices tab of DDMS. DDMS forwards the appropriate port to port 8700. Most modern Java IDEs include a JDWP debugger, or you can use a command line debugger such as jdb.
DDMS Android ships with a debugging tool called the Dalvik Debug Monitor Server (DDMS), which provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more. This page provides a modest discussion of DDMS features; it is not an exhaustive exploration of all the features and capabilities. The following operation done using DDMS
- Viewing heap usage for a process
- Tracking memory allocation of objects
- Working with an emulator or device’s file system
- Examining thread information
- Starting method profiling
- Network Traffic tool
- LogCat
- Emulating phone operations and location
Android App Development Life Cycle
Android application publishing is a process that makes your android applications available to users. Infact, publishing is the last phase of the android application development process.
Introduction
APK Conversion Process
Before exporting the apps, you must be aware of some of the tools like
- Dxtools(Dalvik executable tools ): It going to convert .class file to .dex it hasuseful for memory optimization and reduce the boot-up speed time
- AAPT(Android assistance packaging tool):it has useful to convert .Dex file Apk
- APK(Android packaging kit): The final stage of deployment process is called as .apk.
You will need to export your application as an APK (Android Package) file before you upload it Google Play marketplace.
Export Android Application Process
To export an application, just open that application project in Android studio and selectBuild
→ Generate Signed APK from your Android studio and follow the simple steps to export your application.
Exporting (generating signed APK) your application from Android Studio for installing on mobile devices. Application is exported with apk extension.
App Publishing Guidance
To release your application to users you need to create a release-ready package that users can install and run on their Android-powered devices. The release-ready package contains the same components as the debug .apk file — compiled source code, resources, manifest file, and so on — and it is built using the same build tools. However, unlike the debug.apk file, the release- ready .apk file is signed with your own certificate and it is optimized with the zipalign tool.
You perform five main tasks to prepare your application for release. The signing and optimization tasks are usually seamless if you are building your application with Android Studio. For example, you can use Android Studio with the Gradle build files to compile, sign, and optimize your application all at once. You can also configure the Gradle build files to do the same when you build from the command line. For more details about using the Gradle build files, see the Build System guide.
To prepare your application for release you typically perform five main tasks (see figure 2). Each main task may include one or more smaller tasks depending on how you are releasing your application. For example, if you are releasing your application through Google Play you may want while you are configuring your application for release. Similarly, to meet Google Play publishing guidelines you may have to prepare screenshots and create promotional text while you are gathering materials for release.
You usually perform the tasks listed in figure 2 after you have throroughly debugged and tested your application. The Android SDK contains several tools to help you test and debug your Android applications.
Step 1 Gathering Materials and Resources
To begin preparing your application for release you need to gather several supporting items. At a minimum this includes cryptographic keys for signing your application and an application icon. You might also want to include an end-user license agreement.
Cryptographic keys
The Android system requires that each installed application be digitally signed with a certificate that is owned by the application’s developer (that is, a certificate for which the developer holds the private key). The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The certificate that you use for signing does not need to be signed by a certificate authority; the Android system allows you to sign your applications with a self- signed certificate.
Important: Your application must be signed with a cryptographic key whose validity period ends after 22 October 2033.
Application Icon Be sure you have an application icon and that it meets the recommended icon guidelines. Your application’s icon helps users identify your application on a device’s Home screen and in the Launcher window. It also appears in Manage Applications, My Downloads, and elsewhere. In addition, publishing services such as Google Play display your icon to users. Note: If you are releasing your application on Google Play, you need to create a high resolution version of your icon. See Graphic Assets for your Application for more information. End-user License Agreement Consider preparing an End User License Agreement (EULA) for your application. A EULA can help protect your person, organization, and intellectual property, and we recommend that you provide one with your application. Miscellaneous Materials You might also have to prepare promotional and marketing materials to publicize your application. For example, if you are releasing your application on Google Play you will need to prepare some promotional text and you will need to create screenshots of your application.
Step 2 Configuring Your Application for Release
After you gather all of your supporting materials you can start configuring your application for release. This section provides a summary of the configuration changes we recommend that you make to your source code, resource files, and application manifest prior to releasing your application. Although most of the configuration changes listed in this section are optional, they are considered good coding practices and we encourage you to implement them. In some cases, you may have already made these configuration changes as part of your development process. Choose a good package name Make sure you choose a package name that is suitable over the life of your application. You cannot change the package name after you distribute your application to users. You can set the package name in application’s manifest file. For more information, see the package attribute documentation.
Also, you should remove all Debug tracing calls that you added to your code, such as startMethodTracing() andstopMethodTracing() method calls.
Important: Ensure that you disable debugging for your app if using WebView to display paid for content or if using JavaScript interfaces, since debugging allows users to inject scripts
and extract c o n t e n t u s i n g C h r o m e D e v T o o l s . T o d i s a b l e d e b u g g i n g , u s e t h e WebView.setWebContentsDebuggingEnabled() method.
Clean up your project directories
Clean up your project and make sure it conforms to the directory structure described in Android Projects. Leaving stray or orphaned files in your project can prevent your application from compiling and cause your application to behave unpredictably. At a minimum you should do the following cleanup tasks:
- Review the contents of your jni/, lib/, and src/ directories. The jni/ directory should contain only source files associated with the Android NDK, such as .c, .cpp, .h, and .mk files. The lib/ directory should contain only third-party library files or private library files, including prebuilt shared and static libraries (for example,
.so files). Thesrc/ directory should contain only the source files for your application (.java and .aidl files). The src/ directory should not contain any .jar files.
- Check your project for private or proprietary data files that your application does not use and remove them. For example, look in your project’s res/ directory for old drawable files, layout files, and values files that you are no longer using and delete
- Check your lib/ directory for test libraries and remove them if they are no longer being used by your
- Review the contents of your assets/ directory and your res/raw/ directory for raw asset files and static files that you need to update or remove prior to
Correct App Code
Caution: Modifying code in the debugger window impacts future app behavior in the emulator; however it does not modify actual source code, so make your source code modifications in
the DEVELOP tab.
- Close the Developer Tools floating
- If necessary, click the DEVELOP
- In the file tree, open the www/js folder and choose the js file.
- Scroll to near line 46 and comment out var breakDebugger = invalidVariable;>
- Choose File>Save.
Retest App Functionality
Now try clicking the Bad button in the Intel XDK Emulator floating window. Better? If not, click the the Reload App icon on the toolbar and try again.
More Handy Information
What you are actually debugging is a simulation of a real mobile device using the Chromium desktop engine augmented with Cordova* and Intel XDK APIs. This simulation is designed to provide an idea of how your app will render on various devices and form factors. Some visual aspects of your app may render differently on real devices, especially if the real devices have an old OS version.
Using the built-in version of the CDT debugger, you can set breakpoints, single-step, display variables in your JavaScript* code, do full DOM debugging, and see the effects of CSS on the DOM. You also have access to the CDT JavaScript* console, where you can view your app console.log messages and interact with your app JavaScript* context by manually inspecting properties and executing methods.
Lab Activities:
Activity 1:
Run Your App on a Real Mobile Device
Now that you are confident your XDKTutorial app works properly on virtual devices, it is time to run it on a real mobile device.
- Click the TEST
- Click the I HAVE INSTALLED APP PREVIEW button – because you already did this, right? 😉
- Your development machine displays a Please sync with our testing server message the first time you click the TEST tab for a project. Click the DISMISS button so we can first explore theTEST
Package Options
Check Your App Package Options
Now that you are confident the XDKTutorial app works properly on a real mobile device, it is time to build your app. But let’s check your app package options first. Click the PROJECTS tab to display a window similar to the following.
If the build fails, click the link to review a more detailed build log.
The Intel XDK does not provide actual store submission services for your app; however, it does explain a variety of possible next steps (which we obviously will not perform for this XDKTutorialapp). Click the Close Build Page button.
More Handy Information
Builds are performed in the cloud, so you do not need to install and configure an SDK or native development system for each target platform (as you must do if you are building a Cordova*/ PhoneGap* app).
You must obtain the proper developer credentials to submit apps to most app stores.
With the exception of Crosswalk for Android* packages, all packages use the built-in webview (embedded browser) that is part of the target mobile device firmware to execute (render) your app.
For example, Android* packages use the Android* browser webview built into the Android* mobile device, and iOS* packages use the Apple Safari* browser webview built into the iOS* mobile device.
Home Activities:
Activity 1:
Upload your semester project (error free) as an app for free download.
