- コードの難読化
- コピー防止(将来廃止予定)
- LVLの実装(Googleライセンスサービスの利用)
の3種類があるようです。
コードの難読化は、Java特有の事情でしょう。
なので、InvaderBlock2(殆どCのみで実装)ではほぼ影響なしだと思います。
※ただし、ARMの逆アセンブルは、6502系統だけあって純RISCアーキテクチャ(Rシリーズ等)と比較して解析し易いと思いますが。
コピー防止は将来廃止予定とのこと。
とりあえず、root化した端末で簡単にコピーできない程度のもののようです。
外的にAPKに埋め込むものらしいので、恐らく、突破は簡単。
外的にAPKに埋め込むから導入も簡単。
LVLは、コード変更が必要。
サンプルと解説を斜め読みした限り、通信が発生しそうな気がしています。
結構複雑なので、読みきれてませんが。
・・・で、「何をやり、何をやらないか」ですが。
- コード難読化 → 殆どCで実装しているからやらない
- コピー防止 → やる
- LVLの実装 → やらない
かな。
InvaderBlock2は今のところ通信処理を一切入れていないです。
アフィリエイト広告はヤメにしたので。
折角、無通信&処理も軽い電池にやさしいアプリなのに、LVLのためにそれを行うのは・・・
もちろん、不正コピーの横行は防止したいですが。
しかし、公式ドキュメントを未だ理解しきれていない。(結構複雑です・・・英語だからかもしれませんが)
その状態で実装を入れるのは、かなりリスクが高い。
最低限のコピー禁止の意思表示はコピー防止の導入で伝わる筈。
そもそも、悪意がある人への防止は、如何にLVLを導入しても難しいと思います。
という訳で、利用者の善意に委ねるのがベストと判断。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。