ManifestMergerのログを見てみる
ManifestMergerとは
Android Gradle Pluginが提供するビルド時に自身のマニフェストファイルやライブラリプロジェクトのマニフェストファイルをマージしてくれる機能です。
だから、私たちはbuild.gradleに数行追加するだけで、ライブラリのダウンロードから依存解決・参照設定まで何も気にせず開発できます。
ただ、ManifestMergerが全てやってくれるので、ManifestMergerのことを知っておかないと、意図せぬパーミッション追加や(依存解決による)ライブラリダウンロードに気づけなくなるのです。
テストアプリを作ってみる
確認用テストアプリの為、build.gradleを書きます。
build.gradle
dependencies { compile 'com.google.android.gms:play-services:7.5.0' }
上記でビルドしてみます。すると、書いた覚えのないパーミッションがマージ後のマニフェスに現れます。
module/build/outputs/intermediates/manifest/full/flavor/buildType/AndroidManifest.xml
<uses-permission android:name="android.permission.INTERNET" />
それでは、マージのログを見ていきましょう
ログは
module/build/outputs/logs/manifest-merger-buildVariant-report.txt
です。
以下はログの一部ですが、play-services-ads7.5.0
からandroid.permission.INTERNET
が付与されていることが分かります。
uses-permission#android.permission.INTERNET ADDED from [com.google.android.gms:play-services-ads:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-ads/7.5.0/AndroidManifest.xml:20:5-66 MERGED from [com.google.android.gms:play-services-analytics:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-analytics/7.5.0/AndroidManifest.xml:21:5-67 MERGED from [com.google.android.gms:play-services-analytics:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-analytics/7.5.0/AndroidManifest.xml:21:5-67 MERGED from [com.google.android.gms:play-services-appinvite:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-appinvite/7.5.0/AndroidManifest.xml:19:5-67 MERGED from [com.google.android.gms:play-services-maps:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-maps/7.5.0/AndroidManifest.xml:21:5-66 MERGED from [com.google.android.gms:play-services-maps:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-maps/7.5.0/AndroidManifest.xml:21:5-66 MERGED from [com.google.android.gms:play-services-maps:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-maps/7.5.0/AndroidManifest.xml:21:5-66 MERGED from [com.google.android.gms:play-services-wallet:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-wallet/7.5.0/AndroidManifest.xml:20:5-66 MERGED from [com.google.android.gms:play-services-maps:7.5.0] app/build/intermediates/exploded-aar/com.google.android.gms/play-services-maps/7.5.0/AndroidManifest.xml:21:5-66
また、このmanidest-merger-buildVariant-report.txtは、ダウンロードしたライブラリとそのバージョンも見られるので、確認にとても便利です。
ちなみにtools:node=“remove"属性でマージから除ける
xmlns:tools="http://schemas.android.com/tools"
を記載した上でtools:node="remove"
を指定すればOKです。
<uses-permission android:name="android.permission.INTERNET" tools:node="remove" />
参考
Merge Multiple Manifest Files | Android Studio
Android Studioの落とし穴 ライブラリプロジェクト - リスクファインダーブログ
影響力の武器 1. 返報性
ロバート・B・チャルディーニ博士の『影響力の武器』を読んでいるのですが、良書だと思うので内容をまとめたいと思います😎
人間は固定的動作パターンをとることが多々ある
固定的動作パターンとは、信号刺激に対してとる決まった行動パターンです。
例えば、依頼するとき「〜ので」とつけた方が承諾した方がいいと思う、値段が高いと価値があると思う、値段の高いものを見た後に安いものを見るとより安く感じる(知覚のコントラスト)などがあります。
なぜ固定的動作パターンをとるかと言うと、情報の溢れる複雑な環境に生きる私たちは、時間や頭を効率的に使う必要があるからです。多くの場合、固定的行動パターンによる選択は正解なのです。
この固定的動作パターンのうち影響力の大きい6つをCLRASSの原理と言います。
CLRASSの原理
クラッサスと読みます。
以下の頭文字を取っています。
Consistency:一貫性
Linking:好意
Reciprocation:返報性
Authority:権威
Social proof:社会的証明
Scarcity:希少性
CLRASSの原理をうまく利用できると、相手にYesと言わせる承諾誘導が行えます。
今回は返報性(Reciprocation)を取り上げます。
返報性の原理とは、施しを受けた場合お返しをしなければならないという心理
人は他人から何らかの施しを受けた場合に、お返しをしなければならないという感情を抱くが、こうした心理をいう。この「返報性の原理」を利用し、小さな貸しで大きな見返りを得る商業上の手法が広く利用されている。
返報性の原理 - Wikipediaより
「Give and Take」という言葉が表す通り、私たちは恩を受けたら返さなきゃいけないと思っています。
そのお陰で、相手から何ももらっていなくても安心して相手に与えることができる、そんな社会が成り立っているのです。
問題があるのは固定的動作パターンを悪用する人間であって、固定的動作パターン自体でないことに注意が必要です。
返報性は実験によって証明されている
デニス・リーガン博士が行ったこんな実験があります。
見知らぬ二人の被験者を集め、二人一組で美術館を鑑賞し絵画を評価してもうらう実験を行いました。
しかしこの実験は実はフェイクで、片方の被験者は実験者の助手なんです。
被験者は2つのグループに分けられます。
A: 実験の休憩時間に助手がジュースを2本買ってきて、1本をもう一人の被験者にご馳走する
B: 実験の休憩時間に助手は自分の分のジュースだけ買ってくる
そして実験が終わった後、助手はもう一人の被験者に「自分は宝くじを売らなくてはいけない。多ければそれにこしたことはないが、いくらか買ってくれないだろうか?」と頼みます。
結果、ジュースをご馳走された方(A)がされなかった方(B)より、購入率が2倍も増えました。
ちなみに宝くじ購入に助手への好感度は関係ありませんでした。
また、この返報性で最初に受け取るものは、受け取る側がほしいものである必要はありません。つまりこの場合、真の被験者がジュースを求めている必要はないのです。
返報性の原理を利用した例として、ドア・イン・ザ・フェイス・テクニックがある
譲歩的依頼法とも言われます。
相手にお願いを拒否されてから譲歩した依頼(本来の依頼)をすると、本来の依頼の承諾率を上げられるテクニックです。
例えば、「3,000円のコンサートチケットを買ってくれませんか?」と頼み、断られたら「では、1,000円の映画チケットはどうですか?」と聞くと、3,000円の話をしなかった場合より相手の承諾率が上がるというものです。
なぜ承諾率が上がるかというと
- 相手が3,000円のチケットから1,000円のチケットに譲歩してくれたので、自分も譲歩で返さなくてはいけないと思う(譲歩=与えられたものという認識)
- 3,000円と1,000円との間でコントラストの原理が働き、1,000円がとても安く感じる(コントラストの原理とは、最初に提示したものと次に提示したものの差が、対比によってより大きく見えること)
からです。
仕事で頼み事をするときに使える
例えば
- 仕事を依頼する時にチョコやジュースをプレゼントしてからお願いする(これは何の意図もなくやっていたw むしろ依頼しよう→お願いを聞いてくれるだろう→お礼をしなきゃという思考回路で私が返報性の原理の受ける側になっていたのだろうか
- 相手の話を愚痴とか相談とかを聞いてから、自分の相談をする
- 自分の得意分野で仕事を手伝ってから、他の仕事をお願いする
- 大きめの開発依頼をして拒否されたら、それを細分化したタスクをお願いする
などで使えると思います。
効果があったらまた記事を書きます。
参考
影響力の武器[第三版]: なぜ、人は動かされるのか | ロバート・B・チャルディーニ, 社会行動研究会 |本 | 通販 | Amazon
アプリのOpenSSLバージョンを確認する
OpenSSLのバージョン確認は必要
脆弱性があるとお客様を危険に晒すことになるので大事なことです。
もちろんGoogle PlayのリリースではセキュリティスキャンとしてOpenSSLのバージョン確認も行われています。
アプリの OpenSSL の脆弱性への対処方法 - Google ヘルプによると、OpenSSL1.02f/1.01rより前のバージョンはだめとのことです。
fとかrの部分はアルファベット順で1.01qはNG、1.01sはOKという認識です。
OpenSSLとは、暗号通信プロトコルの機能を実装したオープンソースのライブラリ
セキュリティーを要求される通信のためのプロトコルである「SSLプロトコル」と「TLSプロトコル」を容易に実装できるオープンソースパッケージ。ソフトウェアライブラリ。
確認は、解凍したapkからOpenSSLでgrepする
$ cd {$project}/{$module}/build/outputs/apk $ unzip -p {$name}.apk | strings | grep "OpenSSL"
unzip
は解凍です。-pオプションでパイプ(stdout)に抽出してくれ、元ファイルがどうこうなることはありません。
strings
はプリント可能な文字列を検索してくれます。
grep
はgrep "hoge"
でhogeを検索します。
ちなみにGoogle Playのベータ版テストでリリース前にセキュリティスキャンができる
なので、Google Playは上手く使いこなしたいですね。
Google playでのベータ版配布機能について - Qiita
参考
OpenSSLの仕組みとは?初歩から解説! | Tech2GO
OpenSSLの説明
aarをローカルから読み込む
概要
aarをローカルから読み込む方法を知った(教えていただいた)ので、メモしときます。
🔍ちなみにaarとは
Android ARchiveの略です。
Androidリソースやマニフェストファイルを含めることのできるAndroidライブラリです。
作り方としては、[File] > [New] > [New Module] > [Android Library] > [Next] > 必要に応じて設定変更 > [Finish]で、{$project}/{$library_name}/build/outputs/aar/{$library_name}.aarができます。
対応方法
1. aarをモジュールのlibsディレクトリに置く
aarをドラッグ&ドロップで取り込めます。
初回にファイル形式を聞かたことが一度だけあります。aarがなくて困ったんですが、textを選んで問題なく進められました。
2. dirsにaarを探索するディレクトリをbuild.gradleからの相対パスで書く
{$module}/build.gradle
repositories { flatDir { dirs 'libs' } }
3. nameに2からの相対パス、extに拡張子を書く
{$module}/build.gradle
dependencies { compile(name:'拡張子を除くaarファイル名', ext:'aar') }
参考
Material Design 1.マテリアルデザインとは何か
同期のデザイナーの子にマテリアルデザインのことを聞かれた時、答えられなくて悔しかったのでw
公式ドキュメントを読みつつ、マテリアルデザインについてまとめていきたいと思います。(全10回くらいの予定)
デザインの歴史
スキューモーフィズムからマテリアルデザインに到るまでの流れを追っていきます。
スキューモーフィズム(1890年頃〜)
現実世界の視覚のルールをデザインに落とし込んだものです。
図1:スキューモーフィズムの例。紙のノートのような質感を持つ立体的なデザイン。
フラットデザイン(1920年頃〜)
装飾性を抑えたシンプルで平面的なデザインです。
図2:フラットデザインの例
こんなこと言うとなんですが、私は洗練されていて結構好きですw
メトロUI(2010年頃〜)
過剰な装飾を削ぎ落とした点において、フラットデザインの一種と言えます。
しかし、完全なフラットデザインではなく、もちろん完全なスキューモーフィズムでもなく、中間的な立ち位置(フラットデザイン寄り)です。
図3:メトロUIの例
マテリアルデザイン(2014年頃〜)
フラットデザイン及びメトロUIの持つ以下の課題を解決するものとして、マテリアルデザインが登場しました。
- 立体的な表現をなくしたため、どこを押すことができるのか、あるいはどこに文字を入力できるのかわからない。
- 無駄な装飾をなくしたため重要度が分かりづらい。
マテリアルデザインは
マテリアル(物質)のメタファー(比喩)
です。現実世界のルールをデザインに落とし込むことで、いつの時代でも、誰にでも、どんなデバイスでも通じるデザインを目指しています。
具体的には光と影、奥行きの概念を取り入れることで、現実世界の質量を表現し、直感的に分かりやすくしています。 ( →マテリアルは3D)
また、ユーザの操作に対しアニメーションで反応するなど触覚を大事にしている点でスキューモーフィズムと異なります。 (→意味のあるアニメーション)
マテリアル環境は3D
マテリアルデザインについて
「紙」と「インク」で構成されており、印刷物を意識した作り
という表現をよく見かけますが、つまり画面の縦横だけでなく、高さ(奥行き)も意識しているということです。
図4:x軸y軸に加えz軸が存在する
図5:パーツはそれぞれ3次元上に存在する。あるパーツがあるパーツを突き抜けるような現実にあり得ないデザインはない。
意味のあるアニメーション
ユーザの操作に対し、アニメーションでレスポンスを返すことによって、ユーザは自分の操作がどう伝わったのか、理解しやすくなります。
www.youtube.com 映像:マテリアルデザインの説明動画。「慣性」が意識されていることがよく分かる。
参考
■ エンジニアが武器にするMaterial Design // Speaker Deck
ーエンジニアがマテリアルデザインを学ぶことの大切さが語られています。
■ マテリアル – 日本語
ー公式ドキュメント。これは最低限読んでおくべきだと思います。(読んでいる途中だけどw)
■ マテリアルデザインについて少し調べる - Qiita
■ Googleマテリアルデザインとフラットデザインって結局何が違うの?[UI/UX] - NAVER まとめ
■ マテリアルデザインとは〜基本概念と実務で使える無料フレームワーク6選 |ferret [フェレット]
ーマテリアルデザインって何?フラットデザインとどう違うの?という疑問に端的に答えてくれるサイトたちです。
AtomでMarkdown記法時に普通に改行する(Atom v1.14.1)
fatal: Commit <コミットID> is a merge but no -m option was given.
git revert <コミットID>ができない
こんなエラーが出ました。
$ git revert f780e4d fatal: Commit f780e4d is a merge but no -m option was given. # コミット「f780e4d」はマージされてるけど、`-m`オプションが付与されてないよ。
マージコミットをリバートしようとしているのが原因
マージコミット(例、プルリクエストのマージボタンを押したときにできるコミット)はgit revert
だけではリバートできません。
今回はテストのため、意図的にマージコミットを作りました。やり方はこちらです。
$ git branch * master $ git checkout -b a $ touch a.tsv $ git add a $ git commit $ git checkout -b b $ touch b.tsv $ git add b.tsv $ git commit $ git checkout master $ git merge a b
対応方法
①本線を確認する
git rever -m
には親番号を指定する必要があります。
コミット履歴をグラフ化すると一目瞭然なのですが、マージコミットには2つ以上の線が存在します(その線がマージされてコミットとなっています)。
今回は「30cc2f4」に「beb91c3」がマージされているので、「30cc2f4」が本線と分かります。
$ git log --graph --oneline * f780e4d Merge branches 'a' and 'b' |\ | * beb91c3 add b * | 30cc2f4 add a |/
②親番号を確認する
「30cc2f4」の番号はgit show
やgit cat-file -p
で確認できます。
git show <コミットID>
Mergeの左から1, 2です。
$ git show 8dcc4d7 commit xxx Merge: 30cc2f4 beb91c3 ...
git cat-file -p <コミットID>
parentの上から1, 2です。
$ git cat-file -p 8dcc4d7 tree xxx parent 30cc2f48c07f368cd91e794865efae3b5ef5d3b3 parent beb91c34f591a1998ac59606269f60f275fc7cbf ...
③git revert -m <親番号>でリバートする
1つめのコミットID「30cc2f4」が本筋であるので、親番号は「1」です。
$ git revert -m 1 f780e4d
参考
akiyoko.hatenablog.jp qiita.com
追記
記事の整理をしているので、更新通知が飛びまくったりしていたらすみません :bow: