六月工作总结

一、            总结

1.  tombstones log的分析2012-06-04

     附件是一个tombstones log的分析工具，具体使用方法如下：

1．将panic1.py拷贝到编译服务器上的driod目录下；

2．运行soucebuild/envsetup.sh设置好环境变量；

3．将tongstone log中的如下部分单独拷贝到一个文件中，例如lll.txt

        #00  pc 001a280c  /system/lib/libwebcore.so

        #01  pc 001a185c  /system/lib/libwebcore.so

        #02  pc 001a2e46  /system/lib/libwebcore.so

        #03  pc 001a727a  /system/lib/libwebcore.so

        #04  pc 001a72f6  /system/lib/libwebcore.so

        #05  pc 00011ef4  /system/lib/libdvm.so

4．运行脚本panic1.py lll.txt，即可看到相应的call stack；

   需要注意的是：你必须编译debug版本的system.img。

 

lirayi@localhost:~/m8665mo/trunk/droid$sourcebuild/envsetup.sh

includingdevice/htc/passion/vendorsetup.sh

includingdevice/qcom/common/vendorsetup.sh

includingdevice/samsung/crespo/vendorsetup.sh

lirayi@localhost:~/m8665mo/trunk/droid$./panic1.pylll.txt

read file ok

CachedNode.h:114             android::CachedNode::clearCursor(android::CachedFrame*)

CachedFrame.cpp:138          android::CachedFrame::clearCursor()

CachedRoot.cpp:1386          android::CachedRoot::setCursor(android::CachedFrame*, android::CachedNode*)

WebView.cpp:885              android::WebView::motionUp(int, int, int)

WebView.cpp:1678             android::nativeMotionUp(_JNIEnv*, _jobject*, int, int, int)

CallEABI.S:243               dvmPlatformInvoke

2.  media缩略图问题 2012-06-06

 

有些设备的ROM,mediastore的数据库可能没有提供thumbnails，这样会造成其他设备访问时，ArcSoftDMS在解图CPU占用率过高

经测试，当前ArgonSpins的mediastore的没有photo thumbnails，但是TinBoost的mediastore是好的，请帮忙调查（argonspin测试设备使用的rom为ARGONS_4_07.15.11RDS）

         Tinboost以及argonspin的thumbnail文件夹的路径是如下

         /mnt/sdcard/DCIM/.thumbnails

argonspin在以下两个版本查看，发现没有生成thumbnail文件夹。

ARGONS_4_07.15.11RDS_flex_LATAM_CLALA_v5_0423.sbf

ARGONS_4_07.19.16RDS_flex_LATAM_Claro_LATAM_v12_0525_CELLONAPR.sbf

 

这个早期的版本也是没有的。ARGONS_4_02.0D.11RDD_flex_PRC_Retail_v5_0217.sbf

 

         Tinboost在以下版本查看，发现有生成thumbnail文件夹。这是一个比较旧的版本。

TNBST_4.02.19.0brps

 

         Tinboost在以下版本查看，发现并没有生成thumbnail文件夹。这是个比较新的版本。

TNBST_4_0A.1F.3DRPS

         需要帮忙调查下为什么mediastore没有生成thumbnail。

         Photo以及video会生成thumbail，但是audio不会生成thumnail。

 

         需要再去看看audio不会生成thumnail的原因，查清我们代码有没实现。若没实现，简单评估下实现该功能的思路以及工作量。

         在tinboost上面，发现会在/mnt/sdcard/Android/data/com.android.providers.media/albumthumbs/下生成文件名是数字的文件，文件大小非0，且是概率性出现的。该文件打开就是乱码，其实这是否就是audio专辑图片缩略图的数据，类似编码后的图片数据吗？

         在argon spin上，也曾试过在/mnt/sdcard/Android/data/com.android.providers.media/albumthumbs/下生成文件名是数字的文件，文件大小却是0。

         在argon spin上，暂未发现生成audio的thumbnail的代码，下一步可以对比下tinboost相关代码。

         在可以正常拿到audiothumbnail的设备上测试，在这个目录下生成的文件如图所示，为非0的文件，以数字命名

         而在将此文件加后缀名jpg后，是可以用看图工具打开的，但是这个应该只是一般规则，具体要根据实际设备上的代码实现来确定

   

确认结果：

               经过确认，在ARGONS_4_07.19.16RDS_flex_LATAM_Claro_LATAM_v12_0525_CELLONAPR.rar进行测试，photo和video会生成thumbnail。

               测试描述：

在ARGONS_4_07.19.16RDS_flex_LATAM_Claro_LATAM_v12_0525_CELLONAPR.rar进行测试，拍照增加图片、视频，filemanager中对图片视频进行删除操作，通过adb放入手机图片视频，格式化SD卡再增加图片视频等操作，次数为30+次，photo以及video均会生成thumbnail。只是在filemanager中删除图片或是视频文件时，会概率性存在该图片或视频删除了，缩略图仍未删除的情况。

mediastore的thumbnail数据库，含有thumbnails,videothumbnails和album_art三个表用来存放thumbnail的信息，实际的thumbnail文件保存在SDcard上面（/mnt/sdcard/DCIM/.thumbnails/目录下放photo和video的，/mnt/sdcard/Android/data/com.android.providers.media/albumthumbs/下面放audio的album）

        

         6090改出的问题，一个判断条件弄错。

 

3.  APR问题_20120605_gallery  2012-06-07

 

  atcom.cooliris.media.MediaFeed.shutdown(MediaFeed.java:~107)

  - waiting to lock<0x407b3600> (a java.util.ArrayList) held by threadid=18 (MediaSets)

  atcom.cooliris.media.GridLayer.shutdown(GridLayer.java:229)

  atcom.cooliris.media.Gallery.onDestroy(Gallery.java:295)

  atandroid.app.ActivityThread.performDestroyActivity(ActivityThread.java:2665)

  atandroid.app.ActivityThread.handleDestroyActivity(ActivityThread.java:2696)

  atandroid.app.ActivityThread.access$2100(ActivityThread.java:117)

  atandroid.app.ActivityThread$H.handleMessage(ActivityThread.java:964)

  atandroid.os.Handler.dispatchMessage(Handler.java:99)

  atandroid.os.Looper.loop(Looper.java:179)

  atandroid.app.ActivityThread.main(ActivityThread.java:3689)

  atjava.lang.reflect.Method.invokeNative(Native Method)

  atjava.lang.reflect.Method.invoke(Method.java:507)

  atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:875)

  atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:633)

  atdalvik.system.NativeStart.main(Native Method)

 

         初步分析，认为是某个对mMediaSets的同步块出现sleep或是无终止执行，导致死锁问题。可以在有mMediaSets的地方打印，看哪里调用的比较耗时。

         在mediafeed这个文件中，每个同步mMediaSets的地方都打印出执行这个块的时间。如下：

然后让测试去反复操作使得可以走过那些有这些同步块的地方。最后看看执行哪个块占用时间长。

自己的测试结果：

Rom：ARGONS_4_07.1A.13RDS_flex_LATAM_Claro_LATAM_v13_0530_CELLONAPR.sbf

次数：30+

其他预置环境：SD卡内有200+张图片，10+个视频文件。

出现lock的shutdown的同步块最长试过1046ms的等待时间，然后每个同步块（包括该shutdown同步块）执行时间一般小于1ms,等待时间也是如此，可以说总体需时很短。

 

测试方法，发布如下：

1） 将附件apk安装在机器上，保证测试时不重启手机，重启的话需要重新安装。

安装命令： adb install -r[gallery3D.apk存放路径]

2） 保证SD卡内有1000+个图片文件，100+个视频文件。

3）       用adb命令打印log。

adb logcat>gallery_lock.log

4） 进行如下操作

1>进入gallery。

2>多次操作，多选删除图片，或者可以多选删除多个相册，或者可以进入某个相册然后多选相片进行删除。

3>退出gallery。

4>重复。尽量重复多次，100+次。

此为一组测试。Rom使用最新的三个不同版本测试，各测试一组，共三组。

5） 退出adblogcat命令。Log文件保存下来。

 

测试结束后，麻烦测试人员提供以下信息：

1） 每组的log文件。

2） 每组的rom信息。

3） 测试中碰到的异常，有的话就截图。

 

结果如下：

 

         在mediafeed.shutdown出现waiting for lock问题，推测现象是冻屏现象。

        

压力测试结果如下：

ARGONS_4_07.1A.13RDS_flex_LATAM_Claro_LATAM_v13_0530_CELLONAPR.sbf

在mediafeed.shutdown的同步块中，最长测得1046ms的等待时间。

ARGONS_4_07.1A.11RDS_flex_LATAM_Retail_AR_v11_0529_CELLONAPR.sbf

在mediafeed.Refresh的同步块中，最长测得2472ms的等待时间。

ARGONS_4_07.1A.11RDS_flex_LATAM_Movistar_AR_v11_0529_CELLONAPR.sbf         

在mediafeed.Refresh的同步块中，最长测得2295ms的等待时间。

每个同步块（包括该shutdown同步块）执行时间一般小于1ms，等待时间也是如此，可以说总体需时很短，只是在有时会等待时间过长，但是不会出现waiting forlock问题，因为未能出现冻屏现象，因此现象不能复现。同时无exception。另外不能知道等待时间长时是哪一块线程访问该临界区变量。

 

Monkeytest结果如下：

用以下三个版本测，

ARGONS_4_07.1B.11RDS_flex_LATAM_Claro_LATAM_v16_0606_CELLONAPR.sbf

ARGONS_4_07.19.16RDS_flex_LATAM_Claro_LATAM_v12_0525_CELLONAPR.sbf

ARGONS_4_07.1A.13RDS_flex_LATAM_Claro_LATAM_v13_0530_CELLONAPR.sbf

跑了三个晚上，未出现冻屏现象，同时无exception，未能复现。

 

 

综上，未能复现。

4.  Monkeytest_20120704问题2012-07-04

   private void showToast(final String string, final int duration, finalboolean centered) {

       if (mContext != null && !App.get(mContext).isPaused()) {

           App.get(mContext).getHandler().post(new Runnable() {

         分析结果：

         在App.get返回的app对象是null。进一步跟进得出根据context查询hashmap，查询不到该context记录。尚未了解不能成功查询到该记录的原因。

         Mediafeed.showToast在gallery3D中用于显示toast信息，本人尚未碰到该现象，估计复现概率较低，有待进一步跟进。

 

5.  [Gallery] The deletedpictures/video still lists in gallery . SMPCQ00009711 Level B 2012-07-03

描述：

在filemanager中删除图片后，保证gallery不是挂起后台的情况下进入，就一切正常。否则，不正常，需要重新进入gallery才正常。

 

分析：

1）现在需要尝试能否完全解决该问题。

2）理清cacheservice中相关流程。

updateNumExpectedItems中mNumExpectedItems取值，关系到最终显示在界面的相册照片张数值。需要确认该值获取的正确流程。

3）

MediaFeed.run分析，数据库已经更新了，怀疑与更新mediaset有关系。需要继续分析MediaFeed.run。

4）对比DLNA应用。

         同样操作，DLNA会表现正常，不管是否有挂起DLNA应用。

5）

         Mediaset中保存的mediaitem数组mItem中，被删除文件的mFlagForDelete没有被设置为true，导致在mediaset中没有被删除，这样就导致在更新相册的标签时出错。（相片张数不对）可以从这里入手寻找roorcause。

 

6）

         对mFlagForDelete的操作有两个函数，如下。

         Mediaset.refresh

         Mediaset.additem

         对于第二种情况。发现Mediaset.additem会对传入的mediaitem的mFlagForDelete设置为false，也即是不要删除。Cacheservice.loadMediaItemsIntoMediaFeed中，

byte[] albumData = sAlbumCache.get(set.mId, 0);

获取存在问题，看看是否存在异步操作以及看看该获取的函数调用流程。

 

         6.1）

         获取数字值正确，但是在显示出现问题。

 

         6.2）

         需要跟踪每次对应mediaset的操作，看看cache文件的变化。        

  
Cacheservice. loadMediaItemsIntoMediaFeed中，

在syncCache中会对所有的mediaset进行更新，包括mediaset里面的mediaitem。然后AlbumData是根据传入的mediaset获取对应的mediaset数据。AlbumData是否为null与该问题无关。

 

boolean setLookupContainsItem = set.lookupContainsItem(item);

这句执行的取值存在问题，正常情况下与非正常情况下存在问题，可以进一步分析。

 

addItem存在异步调用问题，导致Mediaitem的mFlagForDelete赋值存在问题。需要继续查看。与set.lookupContainsItem也存在问题。

 

         populateMediaItemsForSets内addItem存在问题，rootcause仍在查找。

        

        

         已经跟老大说，周三可以解决问题。

7）

         概率性复现。

8）

         挂起gallery与没挂起所走路径不一样。

         Cacheservice.refresh

         会将数据库查询到的image以及video记录写入mediaset中。对于mediaset，存在两个形式，一个是标准的mediaset，使用arraylist存放。还有一个是LongSparseArray，这个当做是个快表，可以快速查询，效率比hashmap高。

         然后将mediaset写入cache文件中。

         很大可能是additem问题。查看调用地方。

         1>

         从以下三方面入手。

Mediaset.generateTitle中生成相册名称，与相册张数正确与否。mNumExpectedItemsCountAccurate变量的研究。

Mediaset. Additem。

Localdatasource.refresh中流程。

9）

         在删除文件后，Mediaset的mediaitem更新，从arraylist头开始更新覆盖，但是被删除的元素尚未被移出mediaset。

1） 尝试过假定只删除一个元素，然后把mediaset的mediaitem的list删除最后一个元素，正常，等待修改为删除多个元素验证。

2） 需要确认additem覆盖的是从头开始覆盖。

是。  

3） 需要考虑把相册内图片全部删除的情况。

4） 当出现多个相册时，使用本方法会出现问题。

mItems即使改变正确了，也是会存在问题。Mitems.size与显示的size不一样。

5） 在additem中，mitems的变化出现异步问题。

 

今天：

1） 将removeDuplicate中修改为也同时改变LongSparseArray数组的情况。

 

2） 不能将mitems按照最后开始重复项删除的原则来删除所谓的被删除条目，因为会存在最后几项存放的本应被删除的条目不存在重复项。

 

1>改进使得根据实际剩余items数来删除所谓被删除条目。

   Cacheservice .loadMediaItemsIntoMediaFeed中获取数目存在问题，概率性不正确。

   通过在additem中获取的数字记下每个相册的个数不可行，因为此数字也许不准确。因此通过此记下每个相册的确切数目会有问题。

3）

当出现多个相册时，使用本方法会出现问题。

                   是否是异步出现问题？

1> 尝试查看synchronized的调用是否正确。

可以将additems中synchronized修改范围。

不能修改范围。

7）

当存在多个相册时，概率性有些相册不会调用additem去更新。

         8）

                   可以尝试将updateNumExpectedItems回退，观察相片张数的变化。

 

关于SMPCQ00009711问题的情况

Gallery这个删除照片的问题目前能的情况如下：

1）      经过初步修改，对于手机中存在单个相册的情况，可以在删除图片后在gallery3D中及时更新过来，但是测试时还会存在概率性不能及时更新的情况，20%的概率，代码修改仍然存在问题，问题所在，但是不知如何修改。

2）      对于手机中存在多个相册的情况，仍会有问题。

3）      目前很大可能需要将SMPCQ00003717、SMPCQ00007699这两个bug回退回去，再进行修改，相当于要解3个bug。对于该相关代码逻辑关系，仍然存在问题，此问题有跟shaking一起看过，都觉得比较难改。

4）      若要修改，还需考虑sideeffect，而七月份就要latam版的SA，风险觉得还是有的。

结论：

诚然，这个bug的确是个问题，jimmy也曾经要求需要修改，即使是在对比机以及一些已经上市机型也存在该问题时，也要解决该问题。但是鉴于目前已经花费一段时间在该问题上仍未能解决该问题，建议不要解决该问题。

另外，手头还有几个latam以及taiwan的bug，鉴于项目进展，想尽快解决这些问题。

6.   Adb install时more than one device解决方法 2012-06-06

问题描述：

         如下，

解决方案：

         使用adb kill-server。