【Android AES】SHA1PRING + Crypto

Google提供的範例檔案


好像是Android6以後，AES加解密如果是使用SecureRandom這個物件搭配演算法「SHA1PRING」和Provider「Crypto」來取得RawKey（用來產生SecretKeySpec時需要的導入參數），會發生失敗的情況。

雖然Google提供了一組叫做CryptoProvider的物件在網路上讓人下載（或複製貼上），但在Cipher進行解密（執行dofinal這個函數）時一樣會出錯。

Google這個超級天才就繼續提供了一組物件叫做「InsecureSHA1PRNGKeyDerivator」在網路上，（載點在上面，）來解決這個問題。


這個物件的用法很單純，就是呼叫一組static物件取得Instance然後再導出 RawKey即可。

方法大概是這樣...

byte[] raw = InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(seed, 16);

比較詭異、比較巧妙的是這個「16」，因為大多數使用這個物件的範例都使用「32」，可是解密部分一樣會在Cipher的地方出錯。這似乎是看你使用的Key長短而定，或是你設定的加密位元。

(32是256位元？16是128位元？）

其他部分都可以循著一般標準範例。

【Android】Mac Adress的可用求法（純Java、不含Android API）

根據官方文件的說法，所有可行的Android API都已經不可以取得Mac Address。

所以要取得Mac Address，必須要回歸原始Java方法。

public static String getMacAddr() {
    try {
        List<NetworkInterface> all = Collections.list(NetworkInterface.getNetworkInterfaces());
        for (NetworkInterface nif : all) {
            if (!nif.getName().equalsIgnoreCase("wlan0")) continue;

            byte[] macBytes = nif.getHardwareAddress();
            if (macBytes == null) {
                return "";
            }

            StringBuilder res1 = new StringBuilder();
            for (byte b : macBytes) {
                String hex = Integer.toHexString(b & 0xFF);
                if (hex.length() == 1)
                    hex = "0".concat(hex);
                res1.append(hex.concat(":"));
            }

            if (res1.length() > 0) {
                res1.deleteCharAt(res1.length() - 1);
            }
            return res1.toString();
        }
    } catch (Exception ex) {
    }
    return "";

簡單來說就是去取得無法閱讀的編碼然後轉換成Mac Address格式。(但也不是真的無法閱讀，只是送出的資料為數值，要轉16進位、還要轉成統一文字格式。

方法很簡單，但是困死許多人。

【Android】APP內部的「返回APP首頁」

（思考這個題目的目的在於........官方所提供關於Activity的某些控制機制其實邏輯不明確，很難知道照表操課的結果，所以會想要思考如何自己「實作一套機制」。）

雖然已經有Fragment，可以讓開發者用「切換」Fragment來製造「回到首頁」的效果，但這種做法其實極限很多。

問題在於「產品設計」通常不會希望APP設計上的「使用流程」受到嚴格拘束，他們總是會希望「APP的功能可以自由地切換。」


嚴格拘束、嚴格規範過的APP操作流程基本上都是樹狀圖。

假設首頁是Activity，下面的幾個主功能則是Activity1、Activity2、Activity3...

如果Activity1下面還有子功能，則是Activity1_1、Activity1_2、Activity1_3...

在Activity1內新增一個static的布林值，假設命名為「Close」，則Activity1_1、Activity1_2、Activity1_3內（還有未來可能延伸出來「子功能的子功能」）的「首頁」鍵按下後都會把這個Close的內容改為true。

另外在Activity1的onResume內檢查它的值，如果為true就把這個Activity關閉，如果false就繼續執行正常功能。

但記得永遠在onCreate內將Close設為false。因為如果經過onCreate就表示這個Activity是被正常且完整的流程給啟動的，可以視為一個「新的呼叫或使用」。

以此類推，Activiy1_1內也可以有自己的Close，讓 Acitivity1_1_1、Activity1_1_2....可以關閉。


這樣的缺點是「APP的操作路徑必須永遠是樹狀的。不同的樹枝之間不可以隨意橫跨呼叫。」


有辦法克服嗎？.......當然有，但是那必須要用靈魂交換.......開玩笑的。

其實這個方法反而相較簡單，但要使用它，必須要對Activity的生命週期應用非常嚴謹。




但最理想的方式是使用「ActivityLifecycleCallbacks」。

（注意！這個方法跟上述的方法是互相矛盾不可並行的。）

一般來說返回首頁會是個按鈕，則可以將這個按鈕統一用一個View類別來擴稱，不管是哪個類別，假設擴充之後的名稱為「HomeCall」。

HomeCall基本上是個要用在XML Layout檔中的類別，並不需要在個別Activity中使用它，（但要使用也可以，必須斟酌發揮一些巧思，）在建構子中使用傳入的Context去將「ActivityLifecycleCallbacks」實作並呼叫。

(應該已經有人知道我要做什麼了。）

然後一樣設置一個static的布林參數，假設命名為「HomeCall」.......（這地方可以依照實務上的需要做調整，不用布林改用其他數值參數也可以。）

在這個View自身上設置OnClickListener，然後內容設計為「一律將HomeCall設為false」，然後在之前實作的「ActivityLifecycleCallbacks」中的「onActivityResume」設計為「一律將傳入的Activity關閉」.......



【未完】

【Android】修改螢幕亮度

應該是Android 6.0以後，這類的硬體功能調整光是在Manifest檔中加上「User-Permission」並不夠，還需要有「權限啟動」的通知。

Intent intent1 = new Intent(android.provider.Settings.ACTION_MANAGE_WRITE_SETTINGS);intent1.setData(Uri.parse("package:" + getPackageName()));intent1.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);startActivity(intent1);

方法大概如上。這個功能會啟動特定APP的權限管理頁，讓使用者決定是否要自己打開權限。

但在執行這行之前，要詢問系統是否有「執行他們」的能力，－－是否有修改Setting的權限。

Settings.System.canWrite

這是個函數，後面要傳入「Activity」作為參數。

如果回傳false，就表示權限未開啟，如果執行程式碼會導致當機。


之後就是很一般的程式碼，直接取得Setting類別後，要求修改特定參數。

android.provider.Settings.System.putInt(
        getContentResolver(),        android.provider.Settings.System.SCREEN_BRIGHTNESS_MODE,        android.provider.Settings.System.SCREEN_BRIGHTNESS_MODE_MANUAL);android.provider.Settings.System.putInt(
        getContentResolver(),        android.provider.Settings.System.SCREEN_BRIGHTNESS,        brightNeess);

brightNeess這個參數要自己自訂。（寫死？或是可以讓使用怎選取、輸入想要的數直。）

【Android】如何讓WebView大小自動擴展為內容的大小

WebViewClient的「onPageFinished」被呼叫執行時，就表示網頁已經有一個初步的大小可供計算。但從Java端並無法去取得這個到小，只有網頁本身可以知道自己的大小，所以我們必須要使用JavaScriptInterface去取得這個大小。

在「onPgaeFinished」內執行一段JavaScript：「"javascript:MyApp.resize(document.body.getBoundingClientRect().height)"」，功能大概是說「執行resize這個函數，並將網頁body的高度傳入。」

所以接著要設計一個名稱為「resize」的函數並掛上「@JavascriptInterface」。

函數的內容基本上是重新設定整個WebView的LayoutParams，尤其是寬高。

高度的算法大概是「height * getResources().getDisplayMetrics().density」，「height」大概就是在JavaScript中傳入「resize」函數的數值。因為網頁有自己的高度單位，所以要換算成density才能取得正確大小。


注意！要記得執行addJavascriptInterface這個功能。這是讓網頁內容可以取得加註了「@JavascriptInterface」函數的必要辦法。（記得「javascript」中的「MyApp」和這裡的「MyApp」是連動的，如果要修改或自訂，記得一起完成。）


以下是更完整的程式碼。

private void setupWebView() {
    webView.getSettings().setJavaScriptEnabled(true);
    webView.setWebViewClient(new WebViewClient() {
        @Override
        public void onPageFinished(WebView view, String url) {
            webView.loadUrl("javascript:MyApp.resize(document.body.getBoundingClientRect().height)");
            super.onPageFinished(view, url);
        }
    });
    webView.addJavascriptInterface(this, "MyApp");
}

@JavascriptInterface
public void resize(final float height) {
    MyActivity.this.runOnUiThread(new Runnable() {
        @Override
        public void run() {
            webView.setLayoutParams(new LinearLayout.LayoutParams(getResources().getDisplayMetrics().widthPixels, (int) (height * getResources().getDisplayMetrics().density)));
        }
    });
}

[Android]使用DownloadManager

DownloadManager是個可以直接把檔案存進「下載區」、而不是在專案路徑下的工具。

它算是SystemService的一種，取得實體的方式跟其他Manager大同小異。（使用Activity下的getSystemService，並傳入Context.DOWNLOAD_SERVICE這個參數。)

但實際執行下載動作的不是DownloadManager，而是DownloadManager.Request。只要使用一般物件宣告實體的方式並指定一組網址參數給它，然後將它轉交給DownloadManager的「enqueue」就會開始執行下載動作。

下載完畢的時候，它會發出一個帶有「DownloadManager.ACTION_DOWNLOAD_COMPLETE」的Intent，所以這個工具要使用BroadcastReciever去接收這個Intent已完成「下載完成」的偵測。（這跟常見的Http管理工具風格有點相違背，因為這年頭習慣製作一個「事件」的Listener後，再把這個事件傳給Http的行為Thread。所以不習慣什麼事情都用BroadcastReciever的人在使用這個物件時可能會猶豫。）

開始下載前（執行「enqueue」指令時）， DownloadManager會回傳一組長整數（Long）：fileID。在BroadcastReciever中，要使用這個fileID去取得「下載完的檔案實體路徑」。（顯然Google注意到了並不是每家廠牌手機都使用相同的路徑設定，下載區有可能會有很獨特的路徑，這會導致APP崩潰。）

以下功能寫在BroadcastReciever中。（範例是個圖檔，所以使用ImageView顯示。）

DownloadManager.Query query = new DownloadManager.Query(); query.setFilterById(downloadId); Cursor c = manager.query(query); if (c.moveToFirst()) { int columnIndex = c.getColumnIndex(DownloadManager.COLUMN_STATUS); if (DownloadManager.STATUS_SUCCESSFUL == c.getInt(columnIndex)) {
String uriString = c.getString(
c.getColumnIndex(DownloadManager.COLUMN_LOCAL_URI)); imageView.setImageURI(Uri.parse(uriString)); Toast.makeText(MainActivity.this,
"download success",
Toast.LENGTH_SHORT).show(); } }

它提供了一個快速打開「檔案區」的方法。
Intent i = new Intent(); i.setAction(DownloadManager.ACTION_VIEW_DOWNLOADS); startActivity(i);

但一般來說都會希望自動導引使用專門開啟檔案的APP來瀏覽檔案。

要讓「其他APP」瀏覽「檔案」從API:24以後都強制使用FileProvide。

FileProvider不用複寫任何功能，只需擴充就可以發揮功用。（這樣做的意義何在？研究中。）

演算法練習「Candidate Report: Anonymous」

解答...


這題是「Stacks and Queues」的第一題練習。

簡單來說就是「後進先出」：用一個矩陣逐一紀錄並疊加收到的資料。

例如：資料1收在矩陣0，資料2收在矩陣1...資料N收在矩陣N-1，但等到要處理資料時，先從資料Ｎ、資料N-1...逐一開始往回處理，如果臨時又有資料加入，則繼續疊加程序。


這跟一般來說的「排隊」不同，這是文本或編譯器的基礎。

例如JSON翻譯器，或程式碼編譯時用來辨識「區段」的開始與結束，例如for迴圈或類別檔的內容。

本身反而沒難度，搞懂邏輯程序、確保題目結果正確後，效能並沒有什麼難度。（因為題目本身就是個一維迴圈。）