I developed an application for watching camera videos, which has been used very well. One day, the customer suddenly reported that the video crashed on his mobile phone and was speechless. After asking, I realized that the customer used the Galaxy Nexus 3 android4.2 system.Program4.2 of devices are still available, which is probably a compatibility issue.
If a 4.2 device is found, the following error is reported during running:
05-29 16:21:22. 389: D/androidruntime (1173): Shutting Down VM05-29 16:21:22. 389: W/dalvikvm (1173): threadid = 1: thread exiting with uncaught exception (group = 0x40a71930) 05-29 16:21:22. 459: E/androidruntime (1173): Fatal exception: main05-29 16:21:22. 459: E/androidruntime (1173): Java. lang. runtimeexception: Buffer not large enough for pixels05-29 16:21:22. 459: E/androidruntime (1173): At android. graphics. bitmap. copypixelsfrombuffer (bitmap. java: 417)
It seems that the copypixelsfrombuffer () method of Bitmap has a problem. It is estimated that Google has moved its hands and feet in the system, and it is annoying to think about it. No way,CodeNo. The first thing that comes to mind is to look at the differences in API 4.2, without mentioning content related to copypixelsfrombuffer. After reading this article online, I found the key to the problem at http://blog.sina.com.cn/s/blog_7b83134b0101brgs.html.
Originally, the buffer executed by copypixelsfrombuffer () was adjusted in 4.2. After each copy is completed, the starting position of the next copy is set to the position at the end of the previous copy. In this way, if you execute multiple consecutive copies for the same bytebuffer, pay attention to the starting position of each copy. I read my own code. It turns out that this error is caused by a continuous secondary copy of a bytebuffer and the starting position of the second copy is not reset to 0. So the second execution
Before copypixelsfrombuffer (), run the rewind () of bytebuffer to solve the problem.