跳到主要內容

Automatic play android games by adb tools with shell script I

Do you had ever dream about game will auto-play without using hack/cheat applications? Here is the solution. adb tool is packged in google sdk, All you just need to know were some shell scripts and some adb commands. You can make your own script to auto-play the game your are playing. At this article, I will mention some very easy and useful commands that could using right away.

Here are some commands:
adb shell input tap x y # tap x, y
adb shell input swipe x1 y1 x2 y2 # swipe form x1, y1 to x2, y2
adb shell am start com.android.settings # launch settings app
adb shell input text "123456"  # input text 123456
adb shell input keyevent 03 # andoird home key
sleep 3 # sleep for 3 second

You could use above command to make your own script to auto play some very simple games. such as tap titans, but for some more complex games these command is not enough at all. Next article I will mention some shell script to let you create more useful script for some huge games. btw, I use my scripts to play hearthstone :)
標籤：

留言

張貼留言

這個網誌中的熱門文章

[學習iOS之路] Lifecycle 比較

在開發Android很多年之後終於開始學習寫iOS了 契機就是工作需要，果然工作需求就是推開最大靜摩擦力的原動力啊！ 在這邊寫下學習Swift的一些筆記，希望在自己忘記或是需要給別人教學的時候可以起到一點點作用。 因為對Android比較熟悉，所以透過比較來熟悉iOS架構 首先是iOS與android的比較 可以參考這張圖 Android vs iOS lifecycle 與這張 iOS 詳細state 流程 Android lifecycle OnCreate -> OnStart -> OnResume ->(running) -> OnPause -> OnStop -> OnDestroy                        ^                  ^                                  |               |                         |                  |-------------------v               |                         |-----<-----   OnRestart   ------<---------v iOS lifecycle LoadView -> ViewDidLoad -> ViewWillAppear -> ViewDidAppear -> (running) -> ViewWillDisappear -> ViewDidDisappear -> ViewWillUnload -> ViewDidUnload -> dealloc 於ViewDidDisappear之後view就看不見了，如果view要再次被看到且view還存在 那就會是ViewWillAppear，否則就是LoadView從頭開始 下一篇是語言的比較 Java vs Swift
張貼留言
閱讀完整內容

Docker vs VM 的學習

工作上用到 Docker 也一段時間了，剛接觸到 Docker 時常常會聽到別人這樣解釋，" Docker 的 Container 技術，類似於 VM 。差別是 Container 比較小，沒有包含 OS，而 VM 會包含 OS"。 這段話我覺得不算是全錯，所以我一開始也是這樣去解釋給別人聽，直到我聽到我同事在面試求職者時問了這句話，"如果 Container 比較快，比較輕量，優點這麼多，為什麼 VM 沒有被淘汰?" 我才忽然意識到，我並沒有真正瞭解這兩種技術的差別。 事實上，這件事情要從解決問題的角度上出發去理解。任何技術的產生應該都是為了解決某些痛點，從這點來思考的話網路上就有很多文章可以查到了，我把我查到的最清楚的文章連結放下本文最下方，有興趣的可以去看看。 VM 是為了解決硬體的資源共享的問題所產生出來的技術，而這個需求仍然存在，並不會因為有了 Docker 的 Container 技術就取代了。這個可以回答為什麼 VM 沒有被淘汰。因為要解決的問題不一樣，事實上很多 Container 還是跑在 VM 裏頭，可謂是相輔相成。 那 Docker 是為了解決什麼問題才發明的呢? 我的消化與理解是 "解決建置環境的複雜度" 而發明的，每個 Dockerfile 會指定使用的映象檔(image)，然後寫下需要安裝的 Tool 指令。按照這個 Dockerfile 上面列下的指令去安裝與建置，就可以重現執行這個 APP Runtime 所需要的環境。這解決了以前工程師常說的那句話 "在我的電腦上跑得好好的，為什麼在正式環境就行不通" 的問題。   參考連結
張貼留言
閱讀完整內容

C# CSRF attribute 的錯誤追蹤與處理

最近開發網站碰到一個問題，有時候可以登入成功，有時候不行。但明明帳密都是 Google 記憶的，不可能打錯帳號密碼。後來猜想到是 CSRF 認證的問題，由於網站是透過 k8s 建立的，且 replicas: 2。很大可能性是因為拿 token 是跟 A Pod 拿，但登入是跟 B pod 登入，造成 token 無法驗證成功。 想證明這個問題，我們必須去紀錄 Log，由於我們是透過 C# 的 ValidateAntiForgeryToken Attribute 實作 CSRF 的防禦，因此一開始想法是寫一個 ExceptionFilter 去攔截例外。但發現無法攔截 CSRF 的問題。後來找了一段時間發現，CSRF 並不是丟出例外，而是結果回覆 HttpStatusCode 400。查到可實作 IAlwaysRunResultFilter 攔截結果，並判斷是否是 IAntiforgeryValidationFailedResult 的一種。 程式碼如下:  public void OnResultExecuting(ResultExecutingContext context) { if (context.Result is IAntiforgeryValidationFailedResult result) { // Log here } } 但是這樣還不夠。還必須要強制關閉客戶端錯誤的轉換才行，這樣才可以精準的把結果視為 IAntiforgeryValidationFailedResult 至於怎麼關閉則是在註冊 MVC 服務的時候設定 Config SuppressMapClientErrors = true 即可。      services.AddMvc().ConfigureApiBehaviorOptions(options => { options.SuppressMapClientErrors = true; }); 詳細可以參考 MSDN
張貼留言
閱讀完整內容