Follow @mycb750

はじめに

ToolbarやTabLayoutなどに影の設定(elevation)が効いていなかったため対応をメモします。
※ロリポップより前はもともと影は標準ででません

CollapsingToolbarLayoutでtoolbarなどを括った場合に影が表示しない不具合があるようです。

対応策

stackoverに答えがありました。

参考：
http://stackoverflow.com/questions/32474073/android-design-library-toolbar-shadow

stackoverのとおりカスタムしたCollapsingToolbarLayoutを作成します。
※コンストラクタも必要です

public class ShadowCollapsingToolbarLayout extends CollapsingToolbarLayout {

    private AppBarLayout.OnOffsetChangedListener mOnOffsetChangedListener;
    
    public ShadowCollapsingToolbarLayout(final Context context) {
        super(context);
    }

    public ShadowCollapsingToolbarLayout(final Context context, final AttributeSet attrs) {
        super(context, attrs);
    }

    public ShadowCollapsingToolbarLayout(final Context context, final AttributeSet attrs, final int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }

    @Override
    protected void onAttachedToWindow() {
        super.onAttachedToWindow();
        ViewParent parent = this.getParent();
        if (parent instanceof AppBarLayout) {
            if (mOnOffsetChangedListener != null)
                ((AppBarLayout) parent).addOnOffsetChangedListener(mOnOffsetChangedListener);
        }
    }

    public void setOnOffsetChangeListener(AppBarLayout.OnOffsetChangedListener listener) {
        mOnOffsetChangedListener = listener;
    }
}

レイアウトファイルでCollapsingToolbarLayoutをShadowCollapsingToolbarLayoutに差し替えます。あとはmCollapsingLayoutとした変数に以下のコードを実行します。
※CollapsingToolbarLayoutの中にあるAppBarLayoutにはelevationの数値設定をしてください。

mCollapsingLayout.setOnOffsetChangeListener(new AppBarLayout.OnOffsetChangedListener() {
            @Override
            public void onOffsetChanged(AppBarLayout appBarLayout, int i) {
                ViewCompat.setElevation(appBarLayout, appBarLayout.getTargetElevation());
            }
        });

これでうまく影が表示されるようになりました。

Follow @mycb750

はじめに

AndroidでAPI通信またはWebViewでページにアクセスする場合のSSLの必要性と対応についてメモします。

元々の考えでは、サイトの情報、apiにセキュアなデータが存在する場合はhttpsで、一般サイトなどはhttpを使っていました。
今後はスマホのセキュリティ的な考えのもと、httpsのみが推奨されてきています。

iOSはiOS9以降よりATSの有効化を推奨しておりデフォルトもオンになっています。

ATSについてはこちら：
http://to-developer.com/blog/?p=2036

Androidのセキュリティについて

Googleはセキュアな通信を推奨しています。ただAndroid上ではまだ推奨はしているとはおもいますが、特に設定上でデフォルトでセキュアな対応にはまだなっていないといった状態です。

AndroidにもあるiOSのATSなものについて

マニフェストの設定でusesCleartextTrafficがiosのATSと同等と思われます。デフォルトはhttpとしているため、まだhttpsを推奨としているわけではないようですが、いずれ推奨またはデフォルトは変わるのではないかと思います。

usesCleartextTraffic

アプリは、平文HTTPとして、クリアテキストのネットワークトラフィックを使用しようとするかどうかを示します。デフォルト値は「真」です。
属性は「偽」、プラットフォームコンポーネントに設定されている場合（例えば、HTTPおよびFTPスタックは、DownloadManager、MediaPlayerのは）クリアテキストトラフィックを使用するアプリケーションの要求を拒否します。サードパーティのライブラリを強く同様に、この設定を尊重することをお勧めします。クリアテキストトラフィックを回避するための主な理由は、機密性、真正性、および改ざんに対する保護の欠如である：ネットワーク攻撃者は、送信されたデータを盗聴し、また、検出されることなく、それを変更することができます。

このフラグは、それが彼らに提供されるアクセスのレベルを指定したAndroidアプリケーションからすべてクリアテキストのトラフィックを防止することは不可能ですので、ベストエフォートベースで表彰されます。例えば、それは、そのトラフィックがクリアテキストであるかどうかを判断できないため、ソケットAPIはこのフラグを尊重するという期待がありません。ただし、アプリケーションからのほとんどのネットワークトラフィックがどちらかがApplicationInfo.flagsまたはNetworkSecurityPolicy.isCleartextTrafficPermittedからそれを読み取って、このフラグを尊重することができ、より高いレベルのネットワークスタック/コンポーネントによって処理されます（）。

引用：
https://developer.android.com/guide/topics/manifest/application-element.html

webviewでhttps/http混在コンテンツについて

セキュリティのルールが変わり、Androidのロリポップ(5系)以上では、httpとhttpsの混在コンテンツのあるページをwebviewで表示しようとすると通信がブロックされるようになりました。httpsサイトの中でhttpの画像リソースを置いた場合などが混在コンテンツ扱いになります。
混在コンテンツをロリポップ以上でも許容するにはwebviewの設定でsetMixedContentModeでモードを「 MIXED_CONTENT_ALWAYS_ALLOW」に切り替えると、ブロックされなくなります。このデフォルトの設定がロリポップ(5系)以上で変更になってます。
５系以前はMIXED_CONTENT_ALWAYS_ALLOWでした。SEOとしても混在コンテンツはhttpsと評価されずに効果がでなくなるようです。

setMixedContentMode (Added in API level 21)

void setMixedContentMode (int mode)
Configures the WebView’s behavior when a secure origin attempts to load a resource from an insecure origin. By default, apps that target KITKAT or below default to MIXED_CONTENT_ALWAYS_ALLOW. Apps targeting LOLLIPOP default to MIXED_CONTENT_NEVER_ALLOW. The preferred and most secure mode of operation for the WebView is MIXED_CONTENT_NEVER_ALLOW and use of MIXED_CONTENT_ALWAYS_ALLOW is strongly discouraged.

引用：
https://developer.android.com/reference/android/webkit/WebSettings.html

httpsにする必要性

セキュアにする理由

クリアテキストトラフィックを回避するための主な理由は、機密性、真正性、および改ざんに対する保護の欠如である：ネットワーク攻撃者は、送信されたデータを盗聴し、また、検出されることなく、それを変更することができます。

httpsによるSEOの評価について(HTTPSをランキングシグナルに利用する)

https化対応にするメリットはSEOでクローラーの評価が違うことがあります。

セキュリティは Google の最優先事項です。Google は、デフォルトで強力な HTTPS 暗号化を導入するなど、業界でも最先端のセキュリティを Google サービスに導入することに力を注いでいます。これにより、たとえば Google 検索、Gmail、Google ドライブを使用しているユーザーは自動的に、Google に安全に接続することができます。
Google は、Google のサービスだけにとどまらず、より広い範囲でインターネットを安全に利用できるように取り組んでいます。そこで大きな割合を占めているのは、ユーザーが Google から安全なサイトにアクセスできるようにすることです。たとえば、Google ではウェブマスター向けにハッキングの対策や修正方法について詳しい情報を提供するサイトを作成しました。
Google ではさらにもう一歩踏み込んで、数か月前の Google I/O では、「HTTPS everywhere」をウェブで提唱しました。
また、ますます多くのウェブマスターが HTTPS（HTTP over TLS / Transport Layer Security）を彼らのサイトに導入するようになってきています。これはとても心強いことです。
こうした理由から、Google では過去数か月にわたり、Google のランキング アルゴリズムでのシグナルとして、暗号化された安全な接続をサイトで使用しているかを考慮に入れたテストを実施してきました。この実験ではよい結果が得られているため、ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。

Google は、みなさんがより簡単に TLS を導入し、よくある失敗を避けられるように、今後数週間のうちに詳細なベスト プラクティスを公開する予定です（Update: こちらのヘルプ記事内で公開しました）。開始にあたって、以下の基本的なヒントもご確認ください。
必要な証明書タイプを決定します: シングル、マルチ ドメイン、ワイルド カード
2048 bit の証明書を使用します
同じ安全なドメイン上にあるリソースには相対 URL を使用します
他のすべてのドメインにはプロトコル相対 URL を使用します
サイトのアドレスの変更方法について詳しくは、サイト移転に関するヘルプ記事をご覧ください
robots.txt を使用して HTTPS サイトへのクロールをブロックしないでください
可能な限り検索エンジンがページをインデックス登録できるようにします。Noindex メタタグの使用は避けます。
サイトが既に HTTPS で配信されている場合は、Qualys Lab ツールを使用してウェブサイトのセキュリティ レベルと設定をテストできます。TLS とサイト パフォーマンスについて不安がある場合は、「Is TLS fast yet?」（英語）をご覧ください。また、ご質問やご不明な点がある場合は、ウェブマスター ヘルプ フォーラムでお尋ねください。
このランキングの変更は、グローバルでクエリの 1% 未満にしか影響しませんが、これから長い期間をかけて強化していきます。全体的に見ると、このシグナルは良質なコンテンツであるといった、その他のシグナルほどウェイトは大きくありません。HTTPS は、優れたユーザー エクスペリエンスを生み出す多くの要素のうちの 1 つです。
今後、より多くのウェブサイトで HTTPS が使用されることを期待しています。ウェブの安全性をさらに強化しましょう。

参考：
http://googlewebmastercentral-ja.blogspot.jp/

発表当時2014/8/7は
「このランキングの変更は、グローバルでクエリの 1% 未満にしか影響しませんが、これから長い期間をかけて強化していきます。全体的に見ると、このシグナルは良質なコンテンツであるといった、その他のシグナルほどウェイトは大きくありません。HTTPS は、優れたユーザー エクスペリエンスを生み出す多くの要素のうちの 1 つです。」
の通りのため、ほとんどhttps化によるSEOの効果はなかったと思います。
いまはどうでしょうか。

Indexing HTTPS pages by default
Thursday, December 17, 2015
At Google, user security has always been a top priority. Over the years, we’ve worked hard to promote a more secure web and to provide a better browsing experience for users. Gmail, Google search, and YouTube have had secure connections for some time, and we also started giving a slight ranking boost to HTTPS URLs in search results last year. Browsing the web should be a private experience between the user and the website, and must not be subject to eavesdropping, man-in-the-middle attacks, or data modification. This is why we’ve been strongly promoting HTTPS everywhere.
As a natural continuation of this, today we’d like to announce that we’re adjusting our indexing system to look for more HTTPS pages. Specifically, we’ll start crawling HTTPS equivalents of HTTP pages, even when the former are not linked to from any page. When two URLs from the same domain appear to have the same content but are served over different protocol schemes, we’ll typically choose to index the HTTPS URL if:
It doesn’t contain insecure dependencies.
It isn’t blocked from crawling by robots.txt.
It doesn’t redirect users to or through an insecure HTTP page.
It doesn’t have a rel=”canonical” link to the HTTP page.
It doesn’t contain a noindex robots meta tag.
It doesn’t have on-host outlinks to HTTP URLs.
The sitemaps lists the HTTPS URL, or doesn’t list the HTTP version of the URL
The server has a valid TLS certificate.
Although our systems prefer the HTTPS version by default, you can also make this clearer for other search engines by redirecting your HTTP site to your HTTPS version and by implementing the HSTS header on your server.
We’re excited about taking another step forward in making the web more secure. By showing users HTTPS pages in our search results, we’re hoping to decrease the risk for users to browse a website over an insecure connection and making themselves vulnerable to content injection attacks. As usual, if you have any questions or comments, please let us know in the comments section below or in our webmaster help forums.

クローラーのindexはhttpsを優先するとあります。
効果はわかりませんが、だいぶ優先してくれるようです。

まとめ

AppleもGoogleもセキュアな通信を基本推奨しているので、今後はサーバ側で対応しアプリも基本Strictな設定（https通信のみ）にすることが必要となるようです。
現行ではiOSであればATSを無効にすることやAndroidはデフォルト無効のため、急ぐ必要はまだないとはおもうのですが。

参考：
https://koz.io/android-m-and-the-war-on-cleartext-traffic/
https://developer.android.com/guide/topics/manifest/application-element.html