2012-03-26 47 views
16

我需要使用新的google-play(或market)擴展庫,而且我很難用它。 我想知道是否有其他人使用它,並注意到我可以看到的同樣的問題,所以如果你可以幫助解決它們,我會非常高興:android-擴展庫的問題很多

1.有時我沒有得到重要的事件(錯誤,例如)回到下載器活動。

2.it在某些設備上完全不起作用,如xoom。我想我已經修復了它: Download expansion files on tablet

3.even對於相同的設備,一個可以下載文件,另一個可以總是獲得連接錯誤。對於某些設備來說,它永遠無法下載(即使是擁有谷歌播放應用的無根設備)。

4.下載完成後,文件可能會損壞,所以我需要使用CRC校驗並重新下載一切。

5.notification在按下按鈕時有時會打開下載程序活動的多個實例。另外,我不明白爲什麼他們讓通知留下以防止活動仍然顯示。

6.當發生錯誤並稍後處理時,它不會等待用戶告訴它恢復。我不確定它在哪些情況下發生,但它確實很奇怪且不可預測。

7.upon留下下載活動,我得到一個泄漏服務的例外。

8.upon對應用程序進行模糊處理時,由於通過庫執行的SQL操作而崩潰。如何以及爲什麼是這樣? 編輯:這是因爲谷歌決定對SQL部分(文件「DownloadsDB.java」)進行一些反思操作。爲了解決這個問題,我試圖設置proguard來忽略整個庫(無論如何它都是開源的),但它沒有工作,所以我所做的就是給自己想要的類,所以我已經用「new Class [] {MetadataColumns.class,DownloadColumns.class}」替換「DownloadsDB.class.getDeclaredClasses()」;「 。

我只是不明白爲什麼不能谷歌只是發佈一個簡單的API發送意向市場下載文件,並檢查是否沒問題,或提供一個不太複雜的庫。由於其複雜性,很難找到並修復它們的錯誤。

我的問題是:有沒有其他人試過這個庫,並有其他人成功使用它沒有任何問題?如果是這樣,請發佈解決方案...


編輯:它似乎谷歌已更新其庫(到版本2)。

他們聲稱在未來的變化:

  • 列表項
  • 補丁文件現在被下載。
  • 蜂窩設備現在支持ICS狀通知
  • CRC校驗(從樣品)現在支持壓縮的Zip文件
  • 使用反射的移除,以允許容易混淆
  • 服務泄漏固定
  • 不可打印字符從除去ZipResourceFile
  • 小調格式更改
  • 補充意見和編輯這個文件

我已經測試過,現在看起來他們差不多了。

我發現的唯一的錯誤是,如果我更新擴展文件(和CRC &文件大小& CRC),下載開始,但它並沒有刪除舊的擴展文件。

此外,通知還會顯示當前時間,而不是其他可能與下載相關的其他任何內容。

現在,因爲我只有一個擴展,所以我每次從服務中獲得STATE_COMPLETED狀態都會執行下一次檢查。我希望它沒有任何其他問題:

private void deleteOldExpansionFile() 
{ 
    int fileVersion = 0; 
    final int versionCode = App.getAppVersionCode(DownloaderActivity.this); 
    fileVersion = versionCode; 
    final String fileName = Helpers.getExpansionAPKFileName(this, true, fileVersion); //get the expansion file name based on the build version of the app. 
    final File newFile = new File(Helpers.generateSaveFileName(this, fileName)); 
    final File[] listFiles = newFile.getParentFile().listFiles(); 
    for (final File file:listFiles) 
    { 
    final String name = file.getName(); 
    if (name.startsWith(fileName)) 
     continue; 
    file.delete(); 
    } 
} 

回答

3

。你好 !對於CRC校驗失敗,我也遇到過這個問題。對我來說解決這個問題的方法是用7zip壓縮我的擴展文件,壓縮格式完全不壓縮(存儲)。

這樣的:http://floy.fr/perso/floy/expfiles/crc.PNG

現在CRC工作就像一個魅力對我來說!

我同意你的看法..這個庫是非常痛苦的使用..

+0

您還可以創建自己的格式,它將爲您合併所有資源。原因是:可能會更安全一些,並防止其他人查看您的文件。 – 2012-06-08 20:37:06

0

的代碼不支持包含壓縮文件的壓縮文件驗證。將驗證函數中的doInBackground循環替換爲正確驗證Zip文件中的CRC。請注意,您無法從Zip文件中壓縮存儲的文件中流式傳輸視頻/音頻。

 @Override 
     protected Boolean doInBackground(Object... params) { 
      for (XAPKFile xf : xAPKS) { 
       String fileName = Helpers.getExpansionAPKFileName(SampleDownloaderActivity.this, 
         xf.mIsMain, xf.mFileVersion); 
       if (!Helpers.doesFileExist(SampleDownloaderActivity.this, fileName, 
         xf.mFileSize, false)) 
        return false; 
       fileName = Helpers 
         .generateSaveFileName(SampleDownloaderActivity.this, fileName); 
       ZipResourceFile zrf; 
       byte[] buf = new byte[1024 * 256]; 
       try { 
        zrf = new ZipResourceFile(fileName); 
        ZipEntryRO[] entries = zrf.getAllEntries(); 
        /** 
        * First calculate the total compressed length 
        */ 
        long totalCompressedLength = 0; 
        for (ZipEntryRO entry : entries) { 
         totalCompressedLength += entry.mCompressedLength; 
        } 
        float averageVerifySpeed = 0; 
        long totalBytesRemaining = totalCompressedLength; 
        long timeRemaining; 
        /** 
        * Then calculate a CRC for every file in the 
        * Zip file, comparing it to what is stored in 
        * the Zip directory. Note that for compressed 
        * Zip files we must extract the contents to do 
        * this comparison. 
        */ 
        for (ZipEntryRO entry : entries) { 
         if (-1 != entry.mCRC32) { 
          long length = entry.mUncompressedLength; 
          CRC32 crc = new CRC32(); 
          DataInputStream dis = null; 
          try { 
           dis = new DataInputStream(
             zrf.getInputStream(entry.mFileName)); 

           long startTime = SystemClock.uptimeMillis(); 
           while (length > 0) { 
            int seek = (int) (length > buf.length ? buf.length 
              : length); 
            dis.readFully(buf, 0, seek); 
            crc.update(buf, 0, seek); 
            length -= seek; 
            long currentTime = SystemClock.uptimeMillis(); 
            long timePassed = currentTime - startTime; 
            if (timePassed > 0) { 
             float currentSpeedSample = (float) seek 
               /(float) timePassed; 
             if (0 != averageVerifySpeed) { 
              averageVerifySpeed = SMOOTHING_FACTOR 
                * currentSpeedSample 
                + (1 - SMOOTHING_FACTOR) 
                * averageVerifySpeed; 
             } else { 
              averageVerifySpeed = currentSpeedSample; 
             } 
             totalBytesRemaining -= seek; 
             timeRemaining = (long) (totalBytesRemaining/averageVerifySpeed); 
             this.publishProgress(
               new DownloadProgressInfo(
                 totalCompressedLength, 
                 totalCompressedLength 
                   - totalBytesRemaining, 
                 timeRemaining, 
                 averageVerifySpeed) 
               ); 
            } 
            startTime = currentTime; 
            if (mCancelValidation) 
             return true; 
           } 
           if (crc.getValue() != entry.mCRC32) { 
            Log.e(Constants.TAG, 
              "CRC does not match for entry: " 
                + entry.mFileName); 
            Log.e(Constants.TAG, 
              "In file: " + entry.getZipFileName()); 
            return false; 
           } 
          } finally { 
           if (null != dis) { 
            dis.close(); 
           } 
          } 
         } 
        } 
       } catch (IOException e) { 
        e.printStackTrace(); 
        return false; 
       } 
      } 
      return true; 
     } 
+0

我認爲CRC是錯誤的(也許它是),但重新上傳文件後,我認爲沒關係。也許他們在服務器上有問題。 – 2012-06-08 20:35:51