分类： Android

在Android系统中，当SD卡挂载在电脑上时候，如果手动将语音备忘录中的录音删除的时，那么相应数据库中的数据也是需要修改的。此时实现需要对挂载进行监听，需要继承BroadcastReceiver类，实现其中的onRecieve(Context context, Intent inten)方法。代码如下:

此时须在Manifest中进行注册：

参考链接

android中对SD卡挂载和卸载的监听

最近在开发Android时遇到插U盘获取U盘内容的需求，但是按照传统的Environment.getExternalStorageDirectory()只能读取到插入的SD卡的路径，如果是U盘的话无法读出U盘的路径。

最终在一个在CSDN的论坛里找到相关的东西，就试了下直接通过StorageManager获取存储路径的。

核心如下，volumePaths的数组就是系统外接设备的路径，经过测试的确是挂载的路径。不过有些是不可用的，它只是列出了系统可支持的外接路径。

参考链接

android获取外接SD卡或者U盘路径方法

获取指定已安装完整签名信息,包括MD5指纹：

参考链接

android获取APK签名信息及MD5指纹

使用adb命令时的错误

如果直接使用adb命令会产生以下错误:

你是没有权限的。

正确使用adb读取data目录下的文件方式

将你要访问的package目录下的db文件拷贝到sdcard中，这样就可以正常访问了！

使用限制

1.在Android 4.3的某些版本上面，存在BUG，导致这个功能是没办法使用的,一般会提示android run-as permission denied。
具体的讨论参考run-as doesn't work after update to 4.3

2.应用的AndroidManifest.xml中必须设置了android:debuggable="true"。

从Android设备拉取文件

4.x系统

5.x系统

参考资料

在不root手机的情况下读取Data目录下的文件
android adb, retrieve database using run-as

[This post is by Elliott Hughes, a Software Engineer on the Dalvik team. — Tim Bray]

If you don’t write native code that uses JNI, you can stop reading now. If you do write native code that uses JNI, you really need to read this.

What’s changing, and why?

Every developer wants a good garbage collector. The best garbage collectors move objects around. This lets them offer very cheap allocation and bulk deallocation, avoids heap fragmentation, and may improve locality. Moving objects around is a problem if you’ve handed out pointers to them to native code. JNI uses types such as jobject to solve this problem: rather than handing out direct pointers, you’re given an opaque handle that can be traded in for a pointer when necessary. By using handles, when the garbage collector moves an object, it just has to update the handle table to point to the object’s new location. This means that native code won’t be left holding dangling pointers every time the garbage collector runs.

In previous releases of Android, we didn’t use indirect handles; we used direct pointers. This didn’t seem like a problem as long as we didn’t have a garbage collector that moves objects, but it let you write buggy code that still seemed to work. In Ice Cream Sandwich, even though we haven't yet implemented such a garbage collector, we've moved to indirect references so you can start detecting bugs in your native code.

Ice Cream Sandwich features a JNI bug compatibility mode so that as long as your AndroidManifest.xml’s targetSdkVersion is less than Ice Cream Sandwich, your code is exempt. But as soon as you update your targetSdkVersion, your code needs to be correct.

CheckJNI has been updated to detect and report these errors, and in Ice Cream Sandwich, CheckJNI is on by default if debuggable="true" in your manifest.

A quick primer on JNI references

In JNI, there are several kinds of reference. The two most important kinds are local references and global references. Any given jobject can be either local or global. (There are weak globals too, but they have a separate type, jweak, and aren’t interesting here.)

The global/local distinction affects both lifetime and scope. A global is usable from any thread, using that thread’s JNIEnv*, and is valid until an explicit call to DeleteGlobalRef(). A local is only usable from the thread it was originally handed to, and is valid until either an explicit call to DeleteLocalRef() or, more commonly, until you return from your native method. When a native method returns, all local references are automatically deleted.

In the old system, where local references were direct pointers, local references were never really invalidated. That meant you could use a local reference indefinitely, even if you’d explicitly called DeleteLocalRef() on it, or implicitly deleted it with PopLocalFrame()!

Although any given JNIEnv* is only valid for use on one thread, because Android never had any per-thread state in a JNIEnv*, it used to be possible to get away with using a JNIEnv* on the wrong thread. Now there’s a per-thread local reference table, it’s vital that you only use a JNIEnv* on the right thread.

Those are the bugs that ICS will detect. I’ll go through a few common cases to illustrate these problems, how to spot them, and how to fix them. It’s important that you do fix them, because it’s likely that future Android releases will utilize moving collectors. It will not be possible to offer a bug-compatibility mode indefinitely.

Common JNI reference bugs

Bug: Forgetting to call NewGlobalRef() when stashing a jobject in a native peer

If you have a native peer (a long-lived native object corresponding to a Java object, usually created when the Java object is created and destroyed when the Java object’s finalizer runs), you must not stash a jobject in that native object, because it won’t be valid next time you try to use it. (Similar is true of JNIEnv*s. They might be valid if the next native call happens on the same thread, but they won’t be valid otherwise.)

The fix for this is to only store JNI global references. Because there’s never any automatic cleanup of JNI global references, it’s critically important that you clean them up yourself. This is made slightly awkward by the fact that your destructor won’t have a JNIEnv*. The easiest fix is usually to have an explicit ‘destroy‘ function for your native peer, called from the Java peer’s finalizer:

You should always have matching calls to NewGlobalRef()/DeleteGlobalRef(). CheckJNI will catch global reference leaks, but the limit is quite high (2000 by default), so watch out.

If you do have this class of error in your code, the crash will look something like this:

If you’re using another thread’s JNIEnv*, the crash will look something like this:

Bug: Mistakenly assuming FindClass() returns global references

FindClass() returns local references. Many people assume otherwise. In a system without class unloading (like Android), you can treat jfieldID and jmethodID as if they were global. (They’re not actually references, but in a system with class unloading there are similar lifetime issues.) But jclass is a reference, and FindClass() returns local references. A common bug pattern is “static jclass”. Unless you’re manually turning your local references into global references, your code is broken. Here’s what correct code should look like:

If you do have this class of error in your code, the crash will look something like this:

Bug: Calling DeleteLocalRef() and continuing to use the deleted reference

It shouldn’t need to be said that it’s illegal to continue to use a reference after calling DeleteLocalRef() on it, but because it used to work, so you may have made this mistake and not realized. The usual pattern seems to be where native code has a long-running loop, and developers try to clean up every single local reference as they go to avoid hitting the local reference limit, but they accidentally also delete the reference they want to use as a return value!

The fix is trivial: don’t call DeleteLocalRef() on a reference you’re going to use (where “use” includes “return”).

Bug: Calling PopLocalFrame() and continuing to use a popped reference

This is a more subtle variant of the previous bug. The PushLocalFrame() and PopLocalFrame() calls let you bulk-delete local references. When you call PopLocalFrame(), you pass in the one reference from the frame that you’d like to keep (typically for use as a return value), or NULL. In the past, you’d get away with incorrect code like the following:

The fix is generally to pass the reference to PopLocalFrame(). Note in the above example that you don’t need to keep references to the individual array elements; as long as the GC knows about the array itself, it’ll take care of the elements (and any objects they point to in turn) itself.

If you do have this class of error in your code, the crash will look something like this:

Wrapping up

Yes, we asking for a bit more attention to detail in your JNI coding, which is extra work. But we think that you’ll come out ahead on the deal as we roll in better and more sophisticated memory management code.

原文链接

JNI Local Reference Changes in ICS
Android冰淇淋三明治ICS(4.0+)JNI局部引用的变化

DDMS里有个Cause GC命令，用来要求虚拟机强制GC,如下图：

但是在有些环境下面，测试同学，或者用户机器上面没有安装Android Sdk，这个时候使用adb shell来执行GC命令是比较合适的，但是网上搜索了一下，发现adb shell下没有提供这个命令。

根据网上介绍，执行GC命令实际上是通过kill命令向进程发送了数字为10的自定义信号而已，代码如下：