今天如果是要開發一個在行動平台上的應用程式，應用程式的功能要夠豐富，就勢必得牽涉到資料存取的議題。否則使用者在操作程式時，就如同和海底總動員的 Dory 對話一般，每次開啟程式都只能反覆地進行基本的作業、無法累積操作狀態的資訊。
2016/6/25
2016/5/30
使用 PMP 的 EVM 追蹤軟體開發進度
軟體開發在追蹤上的難題
一般在企業內部要開始一個軟體開發的專案有很多時候是老闆忽然靈機一動地問說：「我們來開發一個某某系統，你覺得需要多久？」有經驗的人聽到這個問題時就知道這是考驗專業能力與政治敏感度的時刻，因為這是一個兩難的問題。在好傻好天真的時期會想：「天啊！系統要做到什麼程度、有多少人參與、要給多少資源都還沒確定，就要押完成日？」會有這樣的想法不意外，就像是要蓋一個房子，連要蓋幾層都不確定、設計圖都還沒畫，更別提建材和工人都還沒有著落的情況下就要問何時入住，回答得出來才有鬼！2016/3/25
驚！點鈔機進化到足以全面取代人工作業
日前 DeepHand 發表了一款新的點鈔機取名為 BetaCo，該點鈔機具備了可自我調整力道的滾輪、高精度的感應器，並且提昇了對於各種鈔票狀況的學習能力，能夠在收集一定數量的資料後適應並清點各種不同情況的紙鈔。雖然前一代的點幣機成功地擊敗了世界知名的點幣好手，但由於紙鈔具有柔軟的特性，而且有可能因為髒污、破損、折痕等各種情況導致機器在判讀上的失誤，難度相較於硬幣要高出好幾個等級，所以這一款點鈔機問世對於產業界來說有一定的指標意義。
DeepHand 的技術人員透過大量地餵入各種情況的鈔票，來讓機器收集資料、建立樣本庫，以便機器在面對不同情況的紙鈔時能更準確的調校內部機構的出力及感應器的門檻值，正確地算出鈔票的張數。為了更進一步驗證機器的能力，於是 DeepHand 向世界排行有數的點鈔快手發出比賽的邀請。
比賽由目前排名第四的選手出陣，一共進行五局，進行的方式是每局準備一落十九疊張數不等的舊鈔，共十九落，由雙方先後以計時的方式進行點鈔並各自記下結果。下一局對調雙方的點鈔順序，由前一局後數的一方先進行點鈔。結果於該局雙方點鈔完成後同時公開，如果雙方點出的張數都正確，則以進行的時間決勝負、時間較少者獲勝。
結果，戲劇性地 BetaCo 以壓倒的秒數就取得前三局的勝利，贏得與人類對戰的比賽。接下來的二局雖不影響賽果，BetaCo 仍以一勝一負優異的成績作終，在這次的比賽 BetaCo 以四比一的比數大勝對手。唯一落敗的一局，是因為對手先攻的情況之下，在數鈔時目視到二張完全貼合的鈔票但未將其分開，而後攻的點鈔機判斷失誤以致少算一張而出現數字不正確，將勝利拱手讓人，否則以時間來看機器還是技高一籌。
對於這樣的比賽結果，大多數的人認為是人類的最大失敗、該點鈔機將全面取代所有的人工。於是人人自危、擔心飯碗不保、生計無以為繼，更甚者有人喊出人類末日到了。針對這樣的後續發展，人們是否應該開始省思點鈔機所可能帶來的危害、是否該針對點鈔機的發展計劃做出限制？
以上內容皆為杜撰、如有雷同純屬模仿。應該不會有記者真的把上面的內容拿去做成一篇報導，最後引起軒然大波吧...
不過，這篇內容和軟體開發有什麼關係？BetaCo 應該是沒有，但 AlphaGo 就義意重大了！有寫過程式的人應該都會同意，程式是開發團隊對於特定領域經驗的一種延伸。軟體開發過程中的一項核心工作就是把要被程式取代的工作內容給規則化，以便開發人員可以編寫成程式碼。
開發團隊的成員就像是在戰場上擬定戰略的主帥，主帥憑著自己的經驗預想戰場上可能出現的情況，並且逐一設定好應對的標準程序。一旦開戰主帥只能置身事外，完全讓部隊照著程序執行，如果一切和預想的一樣，則戰勝的結果可期。然而，事先訂好的規則畢竟是死的，再怎麼周詳仍然會有盲點。所以，反之，出現料想之外的情況，前線部隊將無所適從，則會一路潰敗，以致兵敗如山倒。由此可知，如何把規則明確且周詳地定義出來，這是團隊的功力所在，也是程式品質優劣的關鍵。
以圍棋這個領或來說，寫能下棋的程式不是什麼問題，市面上隨便一本入門書都已經把所有的規則定義好了，只要按圖索驥即可。只是這樣的程式並沒有辦法下贏對手，甚至有可能輸了都不知道。倒底要如何才能贏？我想就連當今棋王也不見得能夠說出個所以然！AlphaGo 的開發團隊能夠把抽象的圍棋致勝規則給歸納出來，並且落實到程式中，還能夠真的在棋局中獲勝。對於現階段的軟體開發工作而言，是一項了不起的成就、一個重要的里程碑。也讓在軟體界打滾了一陣子，但才能平庸、學藝不精的我來說是一個難以望其項背的層次。
至於 AlphaGo 是否有可能統治人類？也許吧！但就現階段來說，應該還是跟一般程式一樣有其侷限性，大概就是止於模仿人類學習圍棋的程度，否則這次就不會只是挑戰圍棋了。所以要說 AlphaGo 有什麼更進一步的能力似乎還早了點，因為歷來這麼多棋手也沒看過有哪個職業被棋手取代，即使 AlphaGo 贏了棋，最應該擔心失業的是棋手才對吧！就像對點鈔機稍有概念的人看到這個文章的標題，應該都會一笑置之，畢竟點鈔機是專門設計用來點鈔，要用來清點書本頁數都不太可能！
DeepHand 的技術人員透過大量地餵入各種情況的鈔票，來讓機器收集資料、建立樣本庫，以便機器在面對不同情況的紙鈔時能更準確的調校內部機構的出力及感應器的門檻值，正確地算出鈔票的張數。為了更進一步驗證機器的能力，於是 DeepHand 向世界排行有數的點鈔快手發出比賽的邀請。
比賽由目前排名第四的選手出陣，一共進行五局，進行的方式是每局準備一落十九疊張數不等的舊鈔，共十九落，由雙方先後以計時的方式進行點鈔並各自記下結果。下一局對調雙方的點鈔順序，由前一局後數的一方先進行點鈔。結果於該局雙方點鈔完成後同時公開，如果雙方點出的張數都正確，則以進行的時間決勝負、時間較少者獲勝。
結果，戲劇性地 BetaCo 以壓倒的秒數就取得前三局的勝利，贏得與人類對戰的比賽。接下來的二局雖不影響賽果，BetaCo 仍以一勝一負優異的成績作終，在這次的比賽 BetaCo 以四比一的比數大勝對手。唯一落敗的一局，是因為對手先攻的情況之下，在數鈔時目視到二張完全貼合的鈔票但未將其分開，而後攻的點鈔機判斷失誤以致少算一張而出現數字不正確，將勝利拱手讓人，否則以時間來看機器還是技高一籌。
對於這樣的比賽結果，大多數的人認為是人類的最大失敗、該點鈔機將全面取代所有的人工。於是人人自危、擔心飯碗不保、生計無以為繼，更甚者有人喊出人類末日到了。針對這樣的後續發展，人們是否應該開始省思點鈔機所可能帶來的危害、是否該針對點鈔機的發展計劃做出限制？
以上內容皆為杜撰、如有雷同純屬模仿。應該不會有記者真的把上面的內容拿去做成一篇報導，最後引起軒然大波吧...
不過，這篇內容和軟體開發有什麼關係？BetaCo 應該是沒有，但 AlphaGo 就義意重大了！有寫過程式的人應該都會同意，程式是開發團隊對於特定領域經驗的一種延伸。軟體開發過程中的一項核心工作就是把要被程式取代的工作內容給規則化，以便開發人員可以編寫成程式碼。
開發團隊的成員就像是在戰場上擬定戰略的主帥，主帥憑著自己的經驗預想戰場上可能出現的情況，並且逐一設定好應對的標準程序。一旦開戰主帥只能置身事外，完全讓部隊照著程序執行，如果一切和預想的一樣，則戰勝的結果可期。然而，事先訂好的規則畢竟是死的，再怎麼周詳仍然會有盲點。所以，反之，出現料想之外的情況，前線部隊將無所適從，則會一路潰敗，以致兵敗如山倒。由此可知，如何把規則明確且周詳地定義出來，這是團隊的功力所在，也是程式品質優劣的關鍵。
以圍棋這個領或來說，寫能下棋的程式不是什麼問題，市面上隨便一本入門書都已經把所有的規則定義好了，只要按圖索驥即可。只是這樣的程式並沒有辦法下贏對手，甚至有可能輸了都不知道。倒底要如何才能贏？我想就連當今棋王也不見得能夠說出個所以然！AlphaGo 的開發團隊能夠把抽象的圍棋致勝規則給歸納出來，並且落實到程式中，還能夠真的在棋局中獲勝。對於現階段的軟體開發工作而言，是一項了不起的成就、一個重要的里程碑。也讓在軟體界打滾了一陣子，但才能平庸、學藝不精的我來說是一個難以望其項背的層次。
至於 AlphaGo 是否有可能統治人類？也許吧！但就現階段來說，應該還是跟一般程式一樣有其侷限性，大概就是止於模仿人類學習圍棋的程度，否則這次就不會只是挑戰圍棋了。所以要說 AlphaGo 有什麼更進一步的能力似乎還早了點，因為歷來這麼多棋手也沒看過有哪個職業被棋手取代，即使 AlphaGo 贏了棋，最應該擔心失業的是棋手才對吧！就像對點鈔機稍有概念的人看到這個文章的標題，應該都會一笑置之，畢竟點鈔機是專門設計用來點鈔，要用來清點書本頁數都不太可能！
2016/2/25
使用 iWork 的 Pages 來撰寫軟體開發文件
撰寫軟體開發文件在團隊裡往往都是一個讓人愛恨交織的課題，開發人員的身體裡大多都帶著討厭寫文件的基因。所以在時程不充裕的案子中，文件撰寫一定是背負著拖累時程的原罪、頭一個被捨棄的工作項目。但是在接手既有系統時，又期昐原本系統的開發相關人員能留下文件，哪怕是文字殘缺不全、沒有隨著最新的程式碼同步修正，就算只有隻字片語也多少能做為一窺系統設計全貌的契機。
文件本來的目的就是用來溝通(不過制度僵化的公司也許會拿文件來做神主牌)，而用什麼工具來撰寫文件會是個影響這項工作成效的關鍵因素。用 iWork 的 Pages 來撰寫軟體開發文件？用慣微軟產品組合的人第一個想法可能會是：為什麼這麼想不開？既然是要溝通，撰寫出來的文件內容就要具備可交換性。如果只是要文件內容可以被閱讀，那麼能輸出成類似 PDF 的通用格式的工具問題都不大。但如果牽涉到協同合作、共用編輯之類的情境，文件的格式轉換工作將會是一場災難。就算是微軟的 Word 在不同作業系統之下，呈現出來的效果也沒有辦法百分之百完全相同，更何況是使用二個設計概念不同的工具要進行轉換。
再者，以功能豐富度的角度來看，使用 Microsoft Word 上手之後，會覺得 Pages 像是 Windows 裡的 WordPad 加強版。Microsoft Word 在發展了這麼多年之後，考慮到許多內容呈現、版面排列、資訊彙整等除了文字以外附帶的功能，甚至也有為亞洲語系的特殊需求做設計，都大幅地增加文件製作者在使用上的彈性。反觀 Pages 在功能上則感覺不到有任何重大地進展或是想要向 Word 致敬的意圖，就是維持在大概夠用的程度。
的確，考慮到文件的可交換性，Pages 並不是個值得推薦的選項，除非整個團隊的工作環境都籠罩在蘋果光之下，不是使用 OSX 就是以 iOS 做為平台。如同大多數以 Windows 為平台的團隊會選擇使用 Microsoft Word 做為文件撰寫工具的第一首選，因為以 Word 普及的程度，就算開發團隊以外傳入的文件也有很大的機率是使用 Word 來撰寫。而 Pages 功能的豐富度上也遠不及 Microsoft Word，如果可以接受使用 Windows 裡的 WordPad 來撰寫開發文件、或是更原始地使用記事本來製作文件，在 OSX 上 Pages 才相對地是可以列入考慮的選項。
那為什麼要還要考慮使用 Pages 來撰寫文件？
隨著 iOS 成為行動裝置平台的顯學，改變了軟體開發的生態與銷售模式，為軟體開發從業人員帶來了不同的機會。想要靠開發 iOS App 來賺錢，受限於 Apple 的策略，所有開發的工作環境就必須要和 OSX 綁在一起。但日常事務性的作業卻不見得可以一併移轉，仍然要在 Windows 的平台中進行，而形成雙作業系統的狀態。如果要像過往在 Windows 平台一樣，以 Word 為撰寫文件的工具，就算公司有購置 Word 授權，也是 Windows 平台上的授權沒有辦法移轉到 OSX 上。所以勢必需要二份的授權費用，對許多團隊來說要再提撥額外的授權預算是沈重的選項。
所以，在 Apple 宣佈 iWork 免費下載之後，在不考慮其他開源的文書編輯軟體的情況下，Pages 是目前在 OSX 上可以直接取得、堪用、門檻最低的選擇。
只不過要拿 Pages 來撰寫文件在作法上還是要有一些調適，文件的可交換性降低了，就沒有特別期待能夠使用於共同編輯的情況，主要是著眼在做為「記錄設計軟體過程中思考路徑」的用途之上。設計通當都是反覆構思的循環，在設計的初始階段，為了釐清設計的重點，Mind Map 是一個值得推薦的工具。隨著工作的演進，我習慣用文字記錄設計上的一些想法，做為進一步文件的基礎。一般的純文字編輯器並沒有辦法滿足我的需求，畢竟思考是一個很容易被中斷的活動，像是生理時鐘、外在環境的干擾，甚至思考本身也會因為總總的想法造成設計上的分歧點，需要不斷的放下、回復。使用 Pages 可以做一些顏色、排版上的變化來幫助我記錄思考中斷的位置，讓我可以接續原本思考的狀態，做為後續調整設計方向的依據。
Pages 只是功能上和 Word 相比有一些不足之處，但仍是一個功能健全的文書編輯工具。如果是講究一點，還是可以套用 Pages 內建提供的範本，讓這些內容能夠直接輸出成一份俱專業感的正式文件。至於要和團隊中既有不同工具的文件體系銜接，就只能依靠 Pages 的格式轉換功能，和後續版面調整的功夫了。
文件本來的目的就是用來溝通(不過制度僵化的公司也許會拿文件來做神主牌)，而用什麼工具來撰寫文件會是個影響這項工作成效的關鍵因素。用 iWork 的 Pages 來撰寫軟體開發文件？用慣微軟產品組合的人第一個想法可能會是：為什麼這麼想不開？既然是要溝通，撰寫出來的文件內容就要具備可交換性。如果只是要文件內容可以被閱讀，那麼能輸出成類似 PDF 的通用格式的工具問題都不大。但如果牽涉到協同合作、共用編輯之類的情境，文件的格式轉換工作將會是一場災難。就算是微軟的 Word 在不同作業系統之下，呈現出來的效果也沒有辦法百分之百完全相同，更何況是使用二個設計概念不同的工具要進行轉換。
再者，以功能豐富度的角度來看，使用 Microsoft Word 上手之後，會覺得 Pages 像是 Windows 裡的 WordPad 加強版。Microsoft Word 在發展了這麼多年之後，考慮到許多內容呈現、版面排列、資訊彙整等除了文字以外附帶的功能，甚至也有為亞洲語系的特殊需求做設計，都大幅地增加文件製作者在使用上的彈性。反觀 Pages 在功能上則感覺不到有任何重大地進展或是想要向 Word 致敬的意圖，就是維持在大概夠用的程度。
的確，考慮到文件的可交換性，Pages 並不是個值得推薦的選項，除非整個團隊的工作環境都籠罩在蘋果光之下，不是使用 OSX 就是以 iOS 做為平台。如同大多數以 Windows 為平台的團隊會選擇使用 Microsoft Word 做為文件撰寫工具的第一首選，因為以 Word 普及的程度，就算開發團隊以外傳入的文件也有很大的機率是使用 Word 來撰寫。而 Pages 功能的豐富度上也遠不及 Microsoft Word，如果可以接受使用 Windows 裡的 WordPad 來撰寫開發文件、或是更原始地使用記事本來製作文件，在 OSX 上 Pages 才相對地是可以列入考慮的選項。
那為什麼要還要考慮使用 Pages 來撰寫文件？
隨著 iOS 成為行動裝置平台的顯學，改變了軟體開發的生態與銷售模式，為軟體開發從業人員帶來了不同的機會。想要靠開發 iOS App 來賺錢，受限於 Apple 的策略，所有開發的工作環境就必須要和 OSX 綁在一起。但日常事務性的作業卻不見得可以一併移轉，仍然要在 Windows 的平台中進行，而形成雙作業系統的狀態。如果要像過往在 Windows 平台一樣，以 Word 為撰寫文件的工具，就算公司有購置 Word 授權，也是 Windows 平台上的授權沒有辦法移轉到 OSX 上。所以勢必需要二份的授權費用，對許多團隊來說要再提撥額外的授權預算是沈重的選項。
所以，在 Apple 宣佈 iWork 免費下載之後，在不考慮其他開源的文書編輯軟體的情況下，Pages 是目前在 OSX 上可以直接取得、堪用、門檻最低的選擇。
只不過要拿 Pages 來撰寫文件在作法上還是要有一些調適，文件的可交換性降低了，就沒有特別期待能夠使用於共同編輯的情況，主要是著眼在做為「記錄設計軟體過程中思考路徑」的用途之上。設計通當都是反覆構思的循環，在設計的初始階段，為了釐清設計的重點，Mind Map 是一個值得推薦的工具。隨著工作的演進，我習慣用文字記錄設計上的一些想法，做為進一步文件的基礎。一般的純文字編輯器並沒有辦法滿足我的需求，畢竟思考是一個很容易被中斷的活動，像是生理時鐘、外在環境的干擾，甚至思考本身也會因為總總的想法造成設計上的分歧點，需要不斷的放下、回復。使用 Pages 可以做一些顏色、排版上的變化來幫助我記錄思考中斷的位置，讓我可以接續原本思考的狀態，做為後續調整設計方向的依據。
Pages 只是功能上和 Word 相比有一些不足之處，但仍是一個功能健全的文書編輯工具。如果是講究一點，還是可以套用 Pages 內建提供的範本，讓這些內容能夠直接輸出成一份俱專業感的正式文件。至於要和團隊中既有不同工具的文件體系銜接，就只能依靠 Pages 的格式轉換功能，和後續版面調整的功夫了。
2016/1/29
來自 Play Store 的流量垃圾 (Referrer Spam)
長見識了，原來流量垃圾 (Referrer Spam) 的「轉介網址」跟廣告信的「寄件信箱」一樣，可以被設定成任何的網址。不過想想也不意外，HTTP 裡本來就有轉介規格，如果 Blogger 是利用這個規格來記錄流量來源，那送出要求端要設定成什麼字串就隨人高興了。
最近在檢視 Blogger 提供的「統計資料」功能時，發現有一個集中的流量來源是轉自 Play Store (play.google.com)，看網址是指向某個 App。至於哪一個就不附上來，被騙已經心有不甘了，不想再替他廣告，讓更多人點進去。
看到這個網址當下的想法是，會不會有人在評論中加上了文章的網址。但想想又有點奇怪，有什麼樣的 App 評論需要附上別人的文章？佐證？讓我變相去站台？
基於好奇就點了那個網址，想看一下是什麼人？寫了什麼樣的評論？結果，是一個交友的 App，新上架的，根本還沒有任何人留下評論！那是有客服或連絡資訊誤植了文章的網址？我知道，很白痴的想法！但我還是檢查了一下，的確沒有。
讓我意識到這應該是一個流量垃圾的原因是：簡介的內容全部都是俄文，是個戰鬥民族開發的軟體。一個連英文簡介都沒有的 App，怎麼可能會和中文為主的 Blog 有關係？！雖然我不清楚這個廣告是怎麼鎖定我的文章，也沒有直接的證據顯示這是個流量垃圾，但我高度的懷疑，就算是網址中的 Domain 和常見的流量垃圾 Domain 不同。
所以還是留下個記錄，讓收到相同資訊的人有個戒心。我覺得應該還不致於有病毒或木馬，畢竟是在 Play Store 上的標準頁面，主要的目的應該還是增加曝光度吧！
在查詢相關資料時，發現了一個有趣的小插曲。Referrer 因為經常被誤拼為 Referer，反而積非成是地被列入規格文件之中！
最近在檢視 Blogger 提供的「統計資料」功能時，發現有一個集中的流量來源是轉自 Play Store (play.google.com)，看網址是指向某個 App。至於哪一個就不附上來，被騙已經心有不甘了，不想再替他廣告，讓更多人點進去。
看到這個網址當下的想法是，會不會有人在評論中加上了文章的網址。但想想又有點奇怪，有什麼樣的 App 評論需要附上別人的文章？佐證？讓我變相去站台？
基於好奇就點了那個網址，想看一下是什麼人？寫了什麼樣的評論？結果，是一個交友的 App，新上架的，根本還沒有任何人留下評論！那是有客服或連絡資訊誤植了文章的網址？我知道，很白痴的想法！但我還是檢查了一下，的確沒有。
讓我意識到這應該是一個流量垃圾的原因是：簡介的內容全部都是俄文，是個戰鬥民族開發的軟體。一個連英文簡介都沒有的 App，怎麼可能會和中文為主的 Blog 有關係？！雖然我不清楚這個廣告是怎麼鎖定我的文章，也沒有直接的證據顯示這是個流量垃圾，但我高度的懷疑，就算是網址中的 Domain 和常見的流量垃圾 Domain 不同。
所以還是留下個記錄，讓收到相同資訊的人有個戒心。我覺得應該還不致於有病毒或木馬，畢竟是在 Play Store 上的標準頁面，主要的目的應該還是增加曝光度吧！
在查詢相關資料時，發現了一個有趣的小插曲。Referrer 因為經常被誤拼為 Referer，反而積非成是地被列入規格文件之中！
2015/12/1
在 Android 6.0 上免 Root 備份及還原 Line
這篇文章是「修正 Android 上免 Root 備份 Line 不正常的問題」的延續，這次是要從 Android 4.x 移到 Android 6.0 的手機上，以「免 Root 備份與還原 3.9.0v5」這個工具的命名模式，還原的標的手機用 B 為代碼，備份的來源手機就稱為 A。
在前一次操作時 A 與 B 手機都是 Android 4.x 的系統，除了 Line 的版本所造成的問題之外，並沒有遇到其他的情況。但完成了「1.A手機備份資料.bat」、「2.B手機還原資料.bat」的動作之後，要在 Anroid 6.0 的 B 手機上執行「3.B手機免root清除重登.bat」卻出現了問題！
B 手機上並沒有如預期地出現備份的畫面，同時電腦命令列視窗上也有以下的錯誤訊息：
為了要解決問題，所以就著手研究了一下「3.B手機免root清除重登.bat」的執行細節，最後終於順利地把 Line 由 Android 4.x 備份並還原到 Android 6.0 上。由於會遇到的情況不只一個，以下分不同的小節按照備份序順說明解決的方式。
如果你的 A 手機已經是 Android 6.0，應該在「1.A手機備份資料.bat」時就會出現問題，最明顯的特徵就是 A 手機上沒有出現要求備份的畫面，而且備份很快就完成了，但檔案大小遠小於 14M。試著更新 adb.exe 到最新應該不會有錯，最少在我操作的環境是可行的。
不過更新的程序有點複雜，沒有辦法一鍵下載。首先要到 Android Developer Tool 網頁下載 SDK 工具，在執行安裝或解壓縮之後，進入 SDK 的根目錄中執行 SDK Manager.exe。SDK Manager 的畫面中，因為我們只是要 adb.exe 所以選擇清單中最上方的 Android SDK Platform-tools 並取消其他所有的勾選後，按下【Install 1 packages...】按鈕。官方網站中有相關的操作說明可供參考。
更新完成之後，可以在 SDK 的 platform-tools 目錄下找到 adb.exe，把檔案複製並覆蓋到「免 Root 備份與還原 3.9.0v5」所在的目錄。
請注意：如果你的 Line 已經更新到最新的版本，備份前，前一篇說明的降版程序還是要先執行。
在執行備份時，由於 Android 6.0 是預設全機加密，所以在手機上出現備份畫面時會要求要設定密碼，才能進行備份，這會和「免 Root 備份與還原 3.9.0v5」的說明有衝突。但也只能設定密碼，否則接下來的動作無法進行。密碼設定好了之後要記得，待會會用到。不過，所設定的密碼不用考慮強度的問題，隨便打一個字元也行。
當 A 手機是 Android 6.0 時，執行「1.A手機備份資料.bat」就會要在 A 手機上輸入備份的密碼。所以在 B 手機執行「2.B手機還原資料.bat」時就不能像「免 Root 備份與還原 3.9.0v5」的說明直接按還原，要把原本設定的備份密碼輸入之後才能成功地執行還原的程序。
完成備份之後最好檢查一下備份結果的檔案大小，如果小於 14M 接下來的步驟大概也不用試了，只能說你跟這個解決方案無緣了！
所以如果在備份時有設定密碼，「3.B手機免root清除重登.bat」在執行到這一步時會失敗。必須要修改「3.B手機免root清除重登.bat」的內容，在大約 51 行的指令最後加上備份時所設定的密碼字串。例如：在備份時使用的密碼是「0」，則修改的結果如下：
如果加了密碼還是會出現錯誤，有可能是 abe.jar 的版本還沒有支援使用密碼，可以到 SourceForge 下載最新的版本，並且覆蓋「免 Root 備份與還原 3.9.0v5」所提供的檔案即可。
會看到命令列視窗中輸出「java version "1.x.x_x"」的字串，其中 1.x 的 x 代表的就是 JCE 要下載的對應版本，應該會是 6、7、8 其中一個。確定 Java 版本之後，可以到以下對應的網址下載：
下載後依照壓縮檔內的說明文件，把二個 jar 檔放到指定位置後再執行一次「3.B手機免root清除重登.bat」。JCE 通常放置的位置應該是在安裝 Java 路徑的 lib\security 目錄內。
假設過程一切正常，就可以開始在 Android 6.0 上繼續無接縫地使用 Line 了。如果還是不成功，那就麻煩大喊三聲「我支持拒用 Line」，因為我也愛莫能助了，請節哀！
至於前一篇提到的電話認證的疑問，這次有特別試了一下其實是可以用的，並不一定要使用 Facebook 認證，也許是電話認證的失敗率比較高，所以網路上的文章才比較不推電話認證的方式。
在前一次操作時 A 與 B 手機都是 Android 4.x 的系統，除了 Line 的版本所造成的問題之外，並沒有遇到其他的情況。但完成了「1.A手機備份資料.bat」、「2.B手機還原資料.bat」的動作之後，要在 Anroid 6.0 的 B 手機上執行「3.B手機免root清除重登.bat」卻出現了問題！
B 手機上並沒有如預期地出現備份的畫面，同時電腦命令列視窗上也有以下的錯誤訊息：
abe unpack 錯誤 ab檔案 unpack tar錯誤
為了要解決問題，所以就著手研究了一下「3.B手機免root清除重登.bat」的執行細節，最後終於順利地把 Line 由 Android 4.x 備份並還原到 Android 6.0 上。由於會遇到的情況不只一個，以下分不同的小節按照備份序順說明解決的方式。
更新最新版本的 adb
「免 Root 備份與還原 3.9.0v5」所附的 adb.exe 應該不是最新的版本，由於「3.B手機免root清除重登.bat」和 「1.A手機備份資料.bat」一樣會執行 adb 的 backup 指令，但檢查「3.B手機免root清除重登.bat」的備份輸出檔 db.ab 卻發現檔案大小是 0。所以導致後續的動作出現錯誤，也由於 db.ab 的內容不正確，unpack 會出現錯誤是必然的情況。猜測應該是因為 adb.exe 與 Android 6.0 不相容，所以才沒有辦法在 Android 6.0 的手機上觸發備份的程序。如果你的 A 手機已經是 Android 6.0，應該在「1.A手機備份資料.bat」時就會出現問題，最明顯的特徵就是 A 手機上沒有出現要求備份的畫面，而且備份很快就完成了，但檔案大小遠小於 14M。試著更新 adb.exe 到最新應該不會有錯，最少在我操作的環境是可行的。
不過更新的程序有點複雜，沒有辦法一鍵下載。首先要到 Android Developer Tool 網頁下載 SDK 工具，在執行安裝或解壓縮之後，進入 SDK 的根目錄中執行 SDK Manager.exe。SDK Manager 的畫面中，因為我們只是要 adb.exe 所以選擇清單中最上方的 Android SDK Platform-tools 並取消其他所有的勾選後，按下【Install 1 packages...】按鈕。官方網站中有相關的操作說明可供參考。
更新完成之後，可以在 SDK 的 platform-tools 目錄下找到 adb.exe，把檔案複製並覆蓋到「免 Root 備份與還原 3.9.0v5」所在的目錄。
請注意：如果你的 Line 已經更新到最新的版本，備份前，前一篇說明的降版程序還是要先執行。
在執行備份時，由於 Android 6.0 是預設全機加密，所以在手機上出現備份畫面時會要求要設定密碼，才能進行備份，這會和「免 Root 備份與還原 3.9.0v5」的說明有衝突。但也只能設定密碼，否則接下來的動作無法進行。密碼設定好了之後要記得，待會會用到。不過，所設定的密碼不用考慮強度的問題，隨便打一個字元也行。
當 A 手機是 Android 6.0 時，執行「1.A手機備份資料.bat」就會要在 A 手機上輸入備份的密碼。所以在 B 手機執行「2.B手機還原資料.bat」時就不能像「免 Root 備份與還原 3.9.0v5」的說明直接按還原，要把原本設定的備份密碼輸入之後才能成功地執行還原的程序。
完成備份之後最好檢查一下備份結果的檔案大小，如果小於 14M 接下來的步驟大概也不用試了，只能說你跟這個解決方案無緣了！
更新最新版本的 abe.jar
由於到了「3.B手機免root清除重登.bat」時還會再對 B 手機執行一次同機的備份與還原，所以一定會要在備與及還原時輸入密碼。但是在還原之前會需要做 unpack 的動作，批次檔中進行 unpack 的方法是使用 abe.jar，但「免 Root 備份與還原 3.9.0v5」的批次檔中並沒有指定密碼。所以如果在備份時有設定密碼，「3.B手機免root清除重登.bat」在執行到這一步時會失敗。必須要修改「3.B手機免root清除重登.bat」的內容，在大約 51 行的指令最後加上備份時所設定的密碼字串。例如：在備份時使用的密碼是「0」，則修改的結果如下：
如果加了密碼還是會出現錯誤，有可能是 abe.jar 的版本還沒有支援使用密碼，可以到 SourceForge 下載最新的版本，並且覆蓋「免 Root 備份與還原 3.9.0v5」所提供的檔案即可。
下載 UnlimitedJCEPolicyJDK
如果已經做了以上的步驟，在 abe.jar 進行 unpack 的過程中還是有問題，可以試著下載 Java Cryptography Extension (JCE)，依照你目前的 Java 版本，下載對應的壓縮檔，要確認 Java 的版本可以在命令列視窗執行以下的指令：會看到命令列視窗中輸出「java version "1.x.x_x"」的字串，其中 1.x 的 x 代表的就是 JCE 要下載的對應版本，應該會是 6、7、8 其中一個。確定 Java 版本之後，可以到以下對應的網址下載：
- Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6
- Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7 Download
- Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 Download
下載後依照壓縮檔內的說明文件，把二個 jar 檔放到指定位置後再執行一次「3.B手機免root清除重登.bat」。JCE 通常放置的位置應該是在安裝 Java 路徑的 lib\security 目錄內。
假設過程一切正常，就可以開始在 Android 6.0 上繼續無接縫地使用 Line 了。如果還是不成功，那就麻煩大喊三聲「我支持拒用 Line」，因為我也愛莫能助了，請節哀！
至於前一篇提到的電話認證的疑問，這次有特別試了一下其實是可以用的，並不一定要使用 Facebook 認證，也許是電話認證的失敗率比較高，所以網路上的文章才比較不推電話認證的方式。