Android: Problem with "Debug Certificate expired on.."

This note is created for anybody who have the same issue like me when built an Android project by Eclipse and got "Error generating final archive: Debug certificate expired on !". It occurs to me when i tried to open and build a very old Android project. The reason for it happened is:

Android required the applications to be signed even in the debug mode. So it uses a keystore file called debug.keystore to provide keys for signing applications in debug mode. This key store file has a validity period by default 365 days from its creation date.
(From Android-pro)

And there have 2 ways to resolve this issue:

A. Navigate to the ".android" folder in your home directory
“~/.android” (Linux,Mac OS) or
"C:\Documents and Settings\[User Name]\.android" in windows XP or
"C:\Users\[User Name]\.android" in windows Vista or Windows 7,
then delete debug.keystore file. Then go to eclipse clean the project, this will create a new debug.keystore file with default validity period 365 days.."

Or

Create a new default.keystore file with custom validity period (say 1000 days).

1. Navigate to the ".android" folder.
2. Delete the old default.keystore file.
3. We will use JDK Keytool.exe to generate the new key file. It is found in
4. Run the following command in the "cmd" (or terminate):
   keytool -genkey -keypass android -keystore debug.keystore -alias androiddebugkey -storepass android -validity 1000 -dname “CN=Android Debug,O=Android,C=US”
5. This will generate a new default.keystore file with validity period 1000 days.
6. Copy the generated file to the ".android" folder, go to eclipse and clean projects and it should work.

Good luck,

Android: Problem with "DalVM" when build project

This note is created for anybody who have the same issue like me when built an Android project and got "Conversion to dalvik format failed with error 1". It occurs to me when i tried to open and build a very old Android project. The reason for it happened is:

DX tool can not convert all java classes to dex format then this error occurs. In my case when i was getting error because there are some class which are using Java standard edition references and can not converted to dex. Generally it will convert all J2Me lib to dex format.

Second scenario is that when you are changing target platform or work space then there might be some inconsistency in build and it was fixed by just cleaning and rebuilding workspace.

(From Bimbim.in)

As the suggestion from Bimbim.in, they said:

"please clean your project and rebuild it when you are getting this exception."

but, one more thing had to be done before:

Right click on the project, move the cursor to Android Tools and choose "Fix Project Properties"

Good luck,

Android: SDK - Development Tools 01

DX

The dx tool lets you generate Android bytecode from .class files. The tool converts target files and/or directories to Dalvik executable format (.dex) files, so that they can run in the Android environment. It can also dump the class files in a human-readable format and run a target unit test. You can get the usage and options for this tool by using dx --help.

This tool was placed in : %sdk%\platforms\%androidplatform%\tools\

AAPT

aapt stands for Android Asset Packaging Tool and is included in the tools/ directory of the SDK. This tool allows you to view, create, and update Zip-compatible archives (zip, jar, apk). It can also compile resources into binary assets.

Though you probably won't often use aapt directly, build scripts and IDE plugins can utilize this tool to package the apk file that constitutes an Android application.

This tool was placed in : %sdk%\platforms\%androidplatform%\tools\

AIDL

AIDL (Android Interface Definition Language) is an IDL language used to generate code that enables two processes on an Android-powered device to talk using interprocess communication (IPC). If you have code in one process (for example, in an Activity) that needs to call methods on an object in another process (for example, a Service), you would use AIDL to generate code to marshall the parameters.

The AIDL IPC mechanism is interface-based, similar to COM or Corba, but lighter weight. It uses a proxy class to pass values between the client and the implementation.
(In detail at Android - aidl)

(Refer from Development Android)

Android: How to upgrade your Nexus One from Android 2.1 to 2.2?

To manually install Android 2.2 on the Nexus One, perform the following steps:

1. Download the official Android 2.2 firmware for the Nexus One.
2. Copy the file to your microSD card and name it update.zip (newb warning: not update.zip.zip)
3. Power off your phone.
4. Hold down the VOLUME DOWN button and power it back on.
5. The phone will now search for files like PB00IMG.zip, etc. This is normal. Scroll down to recovery and press the POWER button.
6. When you see the “/!\” symbol, press the POWER button and the Volume Up button at the same time. You should be presented with a menu and one of the options should be “Apply sdcard:update.zip”.
7. Use the trackball to navigate to “apply sdcard:update.zip” and select it.
8. When you see “Install from sdcard complete”, select “reboot system now”.

Enjoy and once you’ve had a chance to play for awhile let us know what you think.

The resources:
- Upgrade from Android 2.1 (ERE27) to FRF50.
- Upgrade from FRF50 to FRF83.
- Upgrade from FRF72 to FRF83.
- Upgrade from ERD79 to ERE27. (~16MB),
22607-ERD79-update-nexusone-stock-signed-boot-img. (~2MB)
- Update for ERE27. (~65MB)

(Referred from: AndroidAndMe, Links from the Net)

Avoiding Memory Leaks

From: http://developer.android.com/resources/articles/avoiding-memory-leaks.html

Android applications are, at least on the T-Mobile G1, limited to 16 MB of heap. It's both a lot of memory for a phone and yet very little for what some developers want to achieve. Even if you do not plan on using all of this memory, you should use as little as possible to let other applications run without getting them killed. The more applications Android can keep in memory, the faster it will be for the user to switch between his apps. As part of my job, I ran into memory leaks issues in Android applications and they are most of the time due to the same mistake: keeping a long-lived reference to a Context.

On Android, a Context is used for many operations but mostly to load and access resources. This is why all the widgets receive a Context parameter in their constructor. In a regular Android application, you usually have two kinds of Context, Activity and Application. It's usually the first one that the developer passes to classes and methods that need a Context:

@Override
protected void onCreate(Bundle state) {
super.onCreate(state);

TextView label = new TextView(this);
label.setText("Leaks are bad");

setContentView(label);
}

This means that views have a reference to the entire activity and therefore to anything your activity is holding onto; usually the entire View hierarchy and all its resources. Therefore, if you leak the Context ("leak" meaning you keep a reference to it thus preventing the GC from collecting it), you leak a lot of memory. Leaking an entire activity can be really easy if you're not careful.

When the screen orientation changes the system will, by default, destroy the current activity and create a new one while preserving its state. In doing so, Android will reload the application's UI from the resources. Now imagine you wrote an application with a large bitmap that you don't want to load on every rotation. The easiest way to keep it around and not having to reload it on every rotation is to keep in a static field:

private static Drawable sBackground;

@Override
protected void onCreate(Bundle state) {
super.onCreate(state);

TextView label = new TextView(this);
label.setText("Leaks are bad");

if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);

setContentView(label);
}

This code is very fast and also very wrong; it leaks the first activity created upon the first screen orientation change. When a Drawable is attached to a view, the view is set as a callback on the drawable. In the code snippet above, this means the drawable has a reference to the TextView which itself has a reference to the activity (the Context) which in turns has references to pretty much anything (depending on your code.)

This example is one of the simplest cases of leaking the Context and you can see how we worked around it in the Home screen's source code (look for the unbindDrawables() method) by setting the stored drawables' callbacks to null when the activity is destroyed. Interestingly enough, there are cases where you can create a chain of leaked contexts, and they are bad. They make you run out of memory rather quickly.

There are two easy ways to avoid context-related memory leaks. The most obvious one is to avoid escaping the context outside of its own scope. The example above showed the case of a static reference but inner classes and their implicit reference to the outer class can be equally dangerous. The second solution is to use the Application context. This context will live as long as your application is alive and does not depend on the activities life cycle. If you plan on keeping long-lived objects that need a context, remember the application object. You can obtain it easily by calling Context.getApplicationContext() or Activity.getApplication().

In summary, to avoid context-related memory leaks, remember the following:

* Do not keep long-lived references to a context-activity (a reference to an activity s

có liên quan tới: Avoiding Memory Leaks | Android Developers (xem trên Google Sidewiki)

Android - Killing Processes

http://developer.android.com/reference/android/os/Process.html#killProcess%28int%29

Due to kernel restriction, Process.killProcess(processID) is not allowed to kill processes that they did not in the application package/system-default application like: Calculator, BrowserActivity, ...

Using:
>adb -[option d/e] shell top
to show updated running processes.

có liên quan tới: Process | Android Developers (xem trên Google Sidewiki)

Android: Emulator

Using "-cpu-delay <delayinMs>" to slow down your emulator. Put this string to your emulator run command (or emulator arguments in EclipseIDE). The range is 0 -> 1000. Effective performance does not always scale in direct relationship with values.

Using "-netdelay <delayinMs> " to set the network latency. The default value is none.