Robert's here: Android

顯示具有 Android 標籤的文章。顯示所有文章

2012/04/12

一路看到底之apk反組譯

這篇要講的，其實也不是真的都看光光，在有名的拍照分享應用程式裡的濾鏡效果，就是用了比較隱晦的方式在作濾鏡。

觀看.jar檔的GUI工具，也另外提供eclipse plugin（個人偏好在獨立的GUI裡看）：
http://java.decompiler.free.fr/?q=jdgui

dex2jar 可直接到手的apk檔轉譯成 jar檔：
http://code.google.com/p/dex2jar/

常見FAQ：http://code.google.com/p/dex2jar/wiki/Faq
實際的操作方式請參考：http://code.google.com/p/dex2jar/wiki/UserGuide

除了用dex2jar可以把應用程式內的整個package結構完整呈現外（目前覺得這樣的用途比較大），另外如果要看AndroidManifest.xml等其他相關layout及resource檔的話，這邊我是用apktool來處理。

apktool：http://code.google.com/p/android-apktool/
依照各個環境下載後解開至定位，需下載 apktool-install-[OS]-* file及 apktool-* file（要不要加到path隨個人喜好）

環境：
Ubuntu 12.04
SUN Java 1.6.0_31

心得：

既然apk都能被看光光，那一般的熱門應用程式他們有用ProGuard之類的混淆器來處理apk，掩蓋他們的程式碼嗎？

Instagram沒有，Path也沒有。

我猜，他們的思維已經把應用程式視為「載具」，iOS應用程式是載具，android應用程式當然也是如此，跨平台當然可以幫助增加使用者量，但重要的還是如何讓使用者喜歡！（Instagram Android 版載入圖片速度超慢阿...但我還是會用耶！真神奇！）

也許我們還小鼻子小眼睛，總是寫了一些東西就怕被抄，想趕快保護起來吧！算算歐美也被我們抄了幾十年了，為何我們產業還是只能跟隨在後面？心態思維上的差異，讓我不僅汗顏...

真正有價值的是能創造出整個服務跟體驗的團隊人員，寫出來的程式只是結果，就像你看NBA球員滿場飛奔猛灌很爽，也來學個他們的動作，比一比當然是自娛娛人，但為何他們除了可以做出誇張的動作，生涯又可長可久，還能做出經濟效益？因為他們除了天份，基本功底子深厚，投入自主練習時間超長（長不是代表我們這種長工時...），自然能各自發展出各種類型的球員，既互補、又競爭。

比賽只是展現結果，
程式碼也是如此！

2012/04/05

使用Fragment寫的第一個案例

follow http://www.vogella.de/articles/Android/article.html#fragments 這個教學自製了一個簡單的project: android.fragments

一路卡關...

先是...

FragmentActivity causing ClassNotFoundException

(若使用一般方法將support library匯入便會出現以上錯誤...)

不知道在我的v 2.3.7上deploy要先把神奇的android.support.v4加到prj中，而且還不能用一般方法從property>java build path去加，得用官方的android tools>add support library... 的動作才能正確加入能完整支援fragment的library，讓低於android v3.0的機器也能正確顯示。

加入後
把所有原本 "extends Activity" 的 activity都改成 "extends FragmentActivity"

把所有原本 "extends Fragment" 的 activity都改成 "extends android.support.v4.app.Fragment"

第二關..目前還無解...
04-05 18:02:57.748: E/AndroidRuntime(26450): Caused by: java.lang.UnsupportedOperationException: Can't convert to dimension: type=0x2

只好先run在v 4.0模擬器上

環境:
UBUNTU 12.04
JAVA 1.6.0_31
Android phone @ v2.3.7 with 小米ROM
eclipse 3.7
ADT-17

後記:

UBUNTU環境真的是得很克難的一直調整到符合自己使用的狀態阿...
是不是乾脆把手機升到miui 4.0呢?哎唷!

更新:

關於java.lang.UnsupportedOperationException: Can't convert to dimension: type=0x2的問題，看來是因為在main.xml裡面有幾個設定找不到這個東西：
android:layout_marginTop="?android:attr/actionBarSize"，看來在4.0的SDK裡找的到這個定義，但跑在pre 4.0的版本上，直接把layout_marginTop寫成個固定值即可！CASE CLOSED！

2012/04/02

Android apk installation problem:INSTALL_PARSE_FAILED_NO_CERTIFICATES

在UBUNTU 12.04上，好不容易把預設的OpenJDK改掉，改成SUN-JAVA-7，接著又遇到打包signed apk後，安裝會出現INSTALL_PARSE_FAILED_NO_CERTIFICATES的問題...經過千山萬水，果然還是得用SUN-JAVA-6，才能正常打包！

安裝SUN-JAVA-6的方法請見UBUNTU官方說明。

裡面wget的路徑都消失了，請自行到Oracle官網下載後再依照指示步驟完成檔案的搬移跟安裝：

JRE: http://www.oracle.com/technetwork/java/javase/downloads/jre-6u31-download-1501637.html

JDK: http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u31-download-1501634.html

官網上的這個指令可以省略，因為路徑已不存在:

 $ sudo update-alternatives --install "/usr/lib/mozilla/plugins/libjavaplugin.so" "mozilla-javaplugin.so" "/usr/lib/jvm/jre1.6.0_31/lib/i386/libnpjp2.so" 1

完成安裝之後，輸入下面的指令才能確認是不是有改到設定：

記得最後也看看java -version及javac -version顯示的版本是不是改成1.6。

若編譯還是有問題，可以在多個選擇中調整看看。

另外記得follow一下code.google.com上的issue，目前已經變成兩隻了...

解法不一，但最保險的方法還是...遠離JDK7，最新的不一定最好，畢竟google跟oracle關係不是很好，不相容的事情...呵呵...不意外嘛!

2012/03/12

android:layerType 的設定

我們可以設定View用哪種方法來Render

其中的none（Don't use a layer, aka disabled），我不太懂它的意義，我猜應該是不分層次的去處理這個View，而software跟hardware就很清楚字意上的意思了。

在SOFTWARE裡的定義是，一旦View指定了用這個參數，就算硬體加速有打開（或有支援）還是要求系統用Android的軟體方式來把View繪製出來。

軟體層可以把硬體加速（HA）不支援的物件繪製出來，可以算是互補的把圖像處理掉，並且暫存起來。但也因為它會暫存，表示如果需要不斷更新畫面，連續的存取代表著就是速度會變慢！因此如果在應用程式中，某個View只需要繪製一次，而硬體加速又可能不支援，我們可以把layerType設定成SOFTWARE。

目前常遇到的案例是，Android 4.0有支援硬體加速，但發佈出去的應用程式支援版本括及2.2甚至更低，所以很不好預測某些ROM是不是寫的很完全，一個自製的4.0 ROM就是強制開啟HA，但承載它的硬體可能根本不支援，簡單的客制化就能讓你的應用程式當掉！

所以，讀了那麼多文件跟說明，回到原點！把android:layerType="software" 拿掉...

後記：

在SW跟HW的文件敘述裡面都有一段一樣的敘述：

From LAYER_TYPE_SOFTWARE:

When the application is using hardware acceleration, a software layer is useful to render drawing primitives not supported by the hardware accelerated pipeline. It can also be used to cache a complex view tree into a texture and reduce the complexity of drawing operations. For instance, when animating a complex view tree with a translation, a software layer can be used to render the view tree only once.

FROM LAYER_TYPE_HARDWARE:

A hardware layer can be used to cache a complex view tree into a texture and reduce the complexity of drawing operations. For instance, when animating a complex view tree with a translation, a hardware layer can be used to render the view tree only once.

無論如何，一定有一段是錯的，或是兩段都是對的！反正Android系統一直改，沒人完全搞懂實際的作法！

2012/02/08

Eclipse批次處理程式碼格式

Eclipse的Formatter你應該用的很習慣了，也許還會編輯一些特定的格式讓Tab變成Space，再來個匯出匯入。

如果有天見到一大片成千上百個java檔都是隨手寫寫沒有format，你會不會手癢開始見一個format一個，三五個也許你還能這樣搞，但如果連續好幾個package都這樣呢？（格式是很重要的，至少讓你看別人程式的日子好過些！）

2011/12/23

那些年我們一起下載的巨大Android Source Code

我一直以為得下載repo、得有git、然後repo sync個半天一天才能擁有某一個release版本的source code...

$repo init -u git://android.git.kernel.org/platform/manifest -b "relaese-name"
$repo sync

blah blah blah blah
blah blah blah
blah blah
blah...

2011/11/21

Google在Galaxy Nexus上想通了

今天在老人與蘋果上看到Google與三星合作的那隻Galaxy Nexus不支援外部記憶卡，並引用了Google家Android工程師Dan Morrill 的話，提到…

There's no particular hardware reason a device can't have both. The problem is that there is no good UI for it.

2011/07/01

less is more

最近我在對ExpiredPrj進行bug修正時，對加入IMG到畫面上的像框裡的功能一直不是很滿意。

不管是選擇檔案、或是直接拍照，有時後圖就是太小，有時候圖卻太大！真的很困擾！

後來研究了一下Bitmap的旋轉跟縮放功能後，參考的範例是做好了這兩種功能，直覺我就想把兩個SeekBar都擺到畫面裡去。

結果好不容易設計過的畫面竟變得無法一目瞭然，還得用ScrollView去包所有的component！

天人交戰之下，我發現縮放功能其實是可以拿掉的，為什麼呢？

user選圖後還要讓user去縮放，實在是不夠聰明！

應該只要留下旋轉的SeekBar，而圖片的縮放應該由程式自行處理，畢竟圖片框的大小也是開發者去設定的！

捨棄一個縮放的SeekBar，節省空間！讓沒有介面的程式做掉！

也許又會有人說這樣的工具不夠自由，Well~至少這邊有專業考量，請予以尊重！不爽不要用！哈~

2011/05/16

迎接春雨跟夏天的到來

這週末回嘉義搭火車，把小白留在新竹後火車站停車場，自以為如意算盤打得精，省車錢還省掉自己開車的疲憊，可沒想到…

2011/04/17

談Google最近管控硬體制造商的作法

Google受不了硬體製造商拿Android亂改，改到每家都有不一樣的介面，不同的品質，OS版本更新絮亂，影響user體驗。

Jollen大大說的順序是：品牌商 => OEM => 研究者從AOSP免費取得

我很好奇Google會選擇怎樣的道路，在天平一端的蘋果軟硬一把抓的一言堂（硬體代工），另一端是規格/體驗百家爭鳴的Android生態。

2010/10/14

來自Google的App Inventor使用心得

在上次看到這東東之後，很興奮的進去看了一下才發現…他們尚未開放此工具給大眾使用，所以只留下了Email通知，這週終於讓我等到了！趕快一起來看看吧～

不用寫一行程式就做出一隻軟體出來，你沒有搞錯！

Google大本營內的創意一直源源不絕，並不是沒有原因，就算概念現實不可行。很多研究單位大學內的實驗室，其實早就存在這種以圖形拖拉方式來快速開發軟體的研究！當然這邊提到的大學，是指美國的大學，台灣的軟體實驗室早就被硬體製造綁架，就算能作也不能說（出來會被笑），因此這類東西大多被歸類在幻想的領域～（如果真的有教授在研究也請指正我～）

為了有個快速的概念，先從個人經驗講起，App Inventor基本上的特色是：用圖形來表現邏輯、順序、參數、結構這些東西的工具（透過一個跟網頁內的Project作連結以定義畫面元件的JNLP檔），那些平常在程式中必須一行行用鍵盤輸入、常被其他人稱為外星文的字串。

當然一開始會對這些拖拉的元件不熟悉，在App Inventor的Tutorial中有一系列從簡單到複雜教學可以讓大家練習，特別的是每個課程裡還提供一些變化題讓自己練習（上面也沒有答案XD，歡迎討論～）

雖然沒辦法debug，但邏輯寫錯了在畫面上可以很快速的刪除或搬移整個區塊，玩積木的樂趣的的確確是減少了很多寫程式的困擾：像是設定環境/路徑、工具熟悉度不足等等這些很基本卻可能讓大多數人很挫折的過程手續。

App Inventor中所謂的Blocks Editor

畫面中間一大塊的畫布就是我們發揮（寫）程式的地方。左方的兩個Tab分別是內建元件跟我們事先在Project中定義的元件（自定義元件），點下每個自定義元件都會出現相對應可供使用的事件或功能（有點像Setter & Getter），拖拉到畫布上之後就可以繼續後續的定義像是…

這樣的動作。

元件相對應的工具抽屜

而內建元件的部份就是文字、顏色、邏輯、清單等等的控制項（在畫布上點左鍵也可以叫出來），舉凡像文字的串接、真假值判斷、數字大小判斷、亂數產生器、迴圈等都可以達成！

你一定會懷疑這能寫出多厲害的程式，這根本就只是堆積木嘛！你要怎麼堆、堆的最多都可以阿～沒錯！再複雜的程式都是從基本的元件堆疊起來的，這些元件不就是積木嗎？更有趣的是，不只是要寫要改很快，要看懂範例裡面的邏輯也很快呀！

單純到一個不行的例子就是按下按鈕之後就發『聲』…這邊是按下去會Meow一聲…誰有Keroro之類的聲音檔可以借我測嗎？XD

複雜的Canvas或是計算區塊可以佔掉整個畫面區塊（只是說畫面是可以縮放的啦～），所以不用擔心自己太囉唆弄了一大串邏輯！

另外特別要點到的是網頁上的Project只要進行切換，Blocks Editor中的內容會隨著更新，而非我一開始以為的換一個Project就要重新下載一次（Open in Blocks Editor）。

最後呢，我大致把個人對App Inventor的優缺點條列出來。

優點：