Flutterアプリを作成している際、ネイティブコードを使いたい時があります。
ここではAndroidでの実装方法を2パターンご紹介します。
外部パッケージの導入は保守や脆弱性対応の対象も増えます。
実装量もそれほど多くないため、選択肢として把握しておくと便利です。
Flutterからネイティブコードを呼ぶ場合、MethodChannelを使用します。
Android側で入り口（MethodChannel）を名前付きで用意しておき、名前を元にFlutter側で呼ぶイメージです。
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.MethodCall
import io.flutter.plugin.common.MethodChannel
class MainActivity(): FlutterActivity() {
override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
super.configureFlutterEngine(flutterEngine)
MethodChannel(flutterEngine.dartExecutor.binaryMessenger, "jp.co.jwork.sample.app/sample")
.setMethodCallHandler { methodCall: MethodCall, result: MethodChannel.Result ->
if (methodCall.method == "input") {
val args: List<Any> = methodCall.arguments as List<Any>
// ... Androidでやりたい処理 ...
result.success("ok") // "ok"部がレスポンスになります。エラーの場合、result.errorも使えます。
} else {
result.notImplemented()
}
}
}
}
import 'dart:async';
import "package:flutter/services.dart";
class Caller {
static const MethodChannel _methodChannel = const MethodChannel('jp.co.jwork.sample.app/sample');
Future run(String param) async {
try {
return await _methodChannel.invokeMethod("input", [ param ]);
} on PlatformException {
// エラーハンドリング
}
}
}
AndroidからFlutterへ渡す場合、EventChannelを使用できます。
Flutter側で入り口（EventChannel）を名前付きで用意しておき、名前を元にAndroid側で呼ぶイメージです。
なお、1回きりで良い場合は、同じ流れでパターン1のMethodChannelを使うことでも実現可能です。
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.EventChannel
class MainActivity(): FlutterActivity() {
private var mInputEventSink: EventChannel.EventSink? = null
override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
super.configureFlutterEngine(flutterEngine)
EventChannel(flutterEngine.dartExecutor.binaryMessenger, "jp.co.jwork.sample.app/sampleEvent")
.setStreamHandler(object : EventChannel.StreamHandler {
override fun onListen(arguments: Any?, events: EventChannel.EventSink?) {
mInputEventSink = events
}
override fun onCancel(arguments: Any?) {
mInputEventSink = null
}
})
}
// 何らかのAndroid側処理の値
private fun onInput(value: String) {
mInputEventSink?.success(value)
}
}
import 'dart:async';
import "package:flutter/services.dart";
class Receiver {
static const EventChannel _eventChannel = const EventChannel("jp.co.jwork.sample.app/sampleEvent");
StreamSubscription? _listenEventStreamSubs;
// 引数で関数を受けていますが、単純にStreamSubscriptionを返す作りでも良いと思います。
Future<void> listen(void Function(String value) onListen) async {
await _listenEventStreamSubs?.cancel();
_listenEventStreamSubs = null;
_listenEventStreamSubs = _eventChannel.receiveBroadcastStream().listen((event) {
if (event is String) {
onListen(event);
}
}, onError: (error) {
// エラーハンドリング
}, cancelOnError: true);
}
// 不要になったら閉じます。
Future<void> cancel() async {
await _listenEventStreamSubs?.cancel();
_listenEventStreamSubs = null;
}
}
MethodChannel、EventChannelで簡単にAndroidコードとやりとりが出来ました。
汎用的なものならpluginとして切り出し、使いまわせるようにするのも良いと思います。
Flutterアプリを作成している際、ネイティブコードを使いたい時があります。
ここではiOSでの実装方法を2パターンご紹介します。
外部パッケージの導入は保守や脆弱性対応の対象も増えます。
実装量もそれほど多くないため、選択肢として把握しておくと便利です。
import Flutter
@main
@objc class AppDelegate: FlutterAppDelegate, FlutterImplicitEngineDelegate {
func didInitializeImplicitFlutterEngine(_ engineBridge: FlutterImplicitEngineBridge) {
GeneratedPluginRegistrant.register(with: engineBridge.pluginRegistry)
...
let methodChannel = FlutterMethodChannel(name: "jp.co.jwork.sample.app/sample", binaryMessenger: engineBridge.applicationRegistrar.messenger())
methodChannel.setMethodCallHandler({(call: FlutterMethodCall, result: @escaping FlutterResult) -> Void in
let method = call.method
if (method == "input") {
let args = call.arguments as! [Any]
// ...iOSでやりたい処理 ...
result("ok")
} else {
result(FlutterMethodNotImplemented)
}
})
}
}
import 'dart:async';
import "package:flutter/services.dart";
class Caller {
static const MethodChannel _methodChannel = const MethodChannel('jp.co.jwork.sample.app/sample');
Future run(String param) async {
try {
return await _methodChannel.invokeMethod("input", [ param ]);
} on PlatformException {
// エラーハンドリング
}
}
}
iOSからFlutterへ渡す場合、EventChannelを使用できます。
Flutter側で入り口（EventChannel）を名前付きで用意しておき、名前を元にiOS側で呼ぶイメージです。
なお、1回きりで良い場合は、同じ流れでパターン1のMethodChannelを使うことでも実現可能です。
import Flutter
@main
@objc class AppDelegate: FlutterAppDelegate, FlutterImplicitEngineDelegate {
static var eventSink: FlutterEventSink?
func didInitializeImplicitFlutterEngine(_ engineBridge: FlutterImplicitEngineBridge) {
GeneratedPluginRegistrant.register(with: engineBridge.pluginRegistry)
...
FlutterEventChannel(name: "jp.co.jwork.sample.app/sampleEvent", binaryMessenger: engineBridge.applicationRegistrar.messenger())
.setStreamHandler(self)
}
// 何らかのiOS側処理の値
private func onInput(_ value: String) {
AppDelegate.eventSink?(value)
}
}
extension AppDelegate: FlutterStreamHandler {
func onListen(withArguments arguments: Any?, eventSink events: @escaping FlutterEventSink) -> FlutterError? {
AppDelegate.eventSink = events
return nil
}
func onCancel(withArguments arguments: Any?) -> FlutterError? {
AppDelegate.eventSink = nil
return nil
}
}
import 'dart:async';
import "package:flutter/services.dart";
class Receiver {
static const EventChannel _eventChannel = const EventChannel("jp.co.jwork.sample.app/sampleEvent");
StreamSubscription? _listenEventStreamSubs;
// 引数で関数を受けていますが、単純にStreamSubscriptionを返す作りでも良いと思います。
Future<void> listen(void Function(String value) onListen) async {
await _listenEventStreamSubs?.cancel();
_listenEventStreamSubs = null;
_listenEventStreamSubs = _eventChannel.receiveBroadcastStream().listen((event) {
if (event is String) {
onListen(event);
}
}, onError: (error) {
// エラーハンドリング
}, cancelOnError: true);
}
// 不要になったら閉じます。
Future<void> cancel() async {
await _listenEventStreamSubs?.cancel();
_listenEventStreamSubs = null;
}
}
MethodChannel、EventChannelで簡単にiOSコードとやりとりが出来ました。
汎用的なものならpluginとして切り出し、使いまわせるようにするのも良いと思います。
iOS標準の「メモ」アプリにリンクを貼り付け、リンクを長押しして表示されるメニューからアプリを起動できる場合があります。
リンクをタップした時にアプリが起動しない、と問い合わせが来ることがたまにあります。
そういった時にご紹介している回避策です。
ユニバーサルリンクは、アプリインストール時にApple CDNからAASA（apple-app-site-association）ファイルを取得することで動作しています。
そのため、今回は何らかの理由でAASAファイルを取得できておらず、アプリが起動しない状態になっていると考えています。
当ブログはAmazon CloudFrontで公開、GitHubで記事を管理する構成です。
ここでは、その際に行ったOIDC設定について説明します。
ソースコードを配置します。パブリックアクセスは全てブロックで問題ありません。
CloudFrontでディストリビューションを作成します。色々プランがありますが、今回は無料プランにしました。
オリジンタイプを「Amazon S3」とし、オリジンに作成したS3バケットを設定します。OACでS3へアクセスします。
作成したCloudFrontからのアクセスを許可します。
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "AllowCloudFrontServicePrincipal",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::[bucket name]/*",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:cloudfront::[aws id]:distribution/[distribution id]"
}
}
}
]
}
AWS IAMのID プロバイダでOpenID Connectのプロバイダを作成します。
プロバイダのURLはhttps://token.actions.githubusercontent.com、対象者はsts.amazonaws.comです。
GitHubのリポジトリが未作成の場合、作成しておきます。
ここまでに作成したS3、CloudFront、GitHubリポジトリのリソースで、IAMロールを作成します。
OIDCの設定を行います。この後使うため、ARN IDをコピーしておくと良いと思います。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowDevBucketList",
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::[bucket name]"
},
{
"Sid": "AllowDevBucketSync",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::[bucket name]/*"
},
{
"Sid": "AllowCloudFrontInvalidation",
"Effect": "Allow",
"Action": [
"cloudfront:CreateInvalidation"
],
"Resource": "arn:aws:cloudfront::[aws id]:distribution/[distribution ID]"
}
]
}
subはブランチ名まで指定すると安心です。
ここでは単に組織名、リポジトリ名、ブランチ名を指定していますが、2026年7月15日以降に作られたGitHubリポジトリでは、repo:org@id/repo@id:...形式とする必要があるようです。
id部分には、各々固有の値が入ります。idはGitHub CLI（gh）を使って取得するのが一番手軽かと思います。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::[aws id]:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:[github organization]/[github repository]:ref:refs/heads/[branch name]"
}
}
}
]
}
リポジトリに.github/workflows/deploy.ymlを作成、S3へのOIDC設定を記載します。
今回はJekyllを使用しています。
また各種環境値は、GitHub ActionsのRepository Variablesに設定して参照するようにしています。
※ymlファイルの名称は任意です。
name: Deploy Dev to S3
on:
push:
branches:
- dev
workflow_dispatch:
permissions:
contents: read
id-token: write
concurrency:
group: deploy-dev-s3
cancel-in-progress: false
env:
AWS_REGION: $
AWS_ROLE_ARN: $
S3_BUCKET: $
CLOUDFRONT_DISTRIBUTION_ID: $
jobs:
deploy:
name: Build and Deploy
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Ruby
uses: ruby/setup-ruby@v1
with:
ruby-version: "3.3"
bundler-cache: true
- name: Validate deployment settings
run: |
test -n "${AWS_REGION}" || (echo "AWS_REGION repository variable is required" && exit 1)
test -n "${AWS_ROLE_ARN}" || (echo "DEV_AWS_ROLE_ARN repository variable is required" && exit 1)
test -n "${S3_BUCKET}" || (echo "DEV_S3_BUCKET repository variable is required" && exit 1)
test -n "${CLOUDFRONT_DISTRIBUTION_ID}" || (echo "DEV_CLOUDFRONT_DISTRIBUTION_ID repository variable is required" && exit 1)
- name: Validate content
run: bundle exec ruby scripts/validate_content.rb
- name: Build site for dev
run: JEKYLL_ENV=production bundle exec jekyll build --strict_front_matter --baseurl ""
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v6
with:
aws-region: $
role-to-assume: $
role-session-name: sample-deploy
- name: Sync site to S3
run: aws s3 sync _site/ "s3://${S3_BUCKET}/" --delete
- name: Invalidate CloudFront
run: |
aws cloudfront create-invalidation \
--distribution-id "${CLOUDFRONT_DISTRIBUTION_ID}" \
--paths "/*"
GitHub Actionsの設定が済んだらpushします。
Build and Deployが走り、正常終了すれば成功です。S3に反映されていると思います。
今年もtargetSdkVersionの引き上げ対応が必要になりました。
その際に調査・整理した内容を記載します。
基本的には下記リンクの内容を確認して、1つずつアプリ影響有無をチェックしていく作業です。
エッジツーエッジのオプトアウトが出来なくなりました。
予告もされていたので困ることはなかったですが、当時対応するのが少し面倒だったのは覚えています。
戻る操作をした時、戻り先がちらっと見えるようになりました。戻る操作は手が入れられることが多いですね。
これ自体は良いのですが、下記の記載がさらっと書かれています。
onBackPressed が呼び出されなくなり、 KeyEvent.KEYCODE_BACK がディスパッチされなくなります。
長く運用されているアプリだと、どちらもまだ使われているのではないでしょうか。
対応自体はonBackPressedDispatcher等の新しい仕組みに移行すれば良いので、そこまで大変ではありませんでした。
下記のようにオプトアウトも可能です。数年で廃止される可能性はありますが・・。
<application
...
android:enableOnBackInvokedCallback="false"
...
>
elegantTextHeight機能が無効化されました。
一部言語の時に自動でフォントが入れ替わる仕組みのようですが・・・、多言語対応をしているアプリでは確認が必要そうです。
定期実行系の処理の動作変更のようです。タスクの実行を逃した場合というのが具体的にどのタイミングを指すのか分かりかねたのですが・・・、これまで不定だった実行回数が最大1回になるようです。
今回、一番影響が大きい変更点と思っています。
最小幅が 600 dp 以上のディスプレイで画面の向き、サイズ変更、アスペクト比の制限が適用されなくなりました。
特に縦向き固定にしているアプリは多いと思います。ちゃんと対処するならデザインから見直しが必要ですね。
なお、下記のようにオプトアウトは可能なものの、一時的な措置とのことです。
<application ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>
今後、アプリを構築する際に悩むことが一つ増えてしまいました。
センサー周りの権限が細分化されたようです。Wear OS系はいつかやってみたいと思いつつ中々機会がありません。
Bluetoothのペアリング周りで変更が入ったようです。
Bluetoothを使用しているアプリでは一通り機能の動作確認をした方が良さそうですね。
Intentやローカルネットワーク周りのセキュリティ強化が行われています。
action無しのIntent実装がないか確認した方が良さそうです。
また、自身が受け手側のアプリを作成している場合は、intentMatchingFlagsの導入要否を検討すると良いのではないでしょうか。
今回のバージョンは、アプリによって影響度合いが全然違っていたんじゃないかと思います。
幸い？にして、私の担当するアプリは影響軽微でした。
CloudFrontで検証サイトを配信する場合、簡易的な認証として、Basic認証をかけたい時があると思います。
ここではその手順について説明します。
なおIaC的な仕組みは使わず、ブラウザ操作で進める場合の内容になっています。
Basic認証に用いるユーザー名/パスワードを準備します。
色々なやり方があると思いますが、コマンドラインで作るなら、次のように作成できます。
echo -n "test:hoge" | base64
# dGVzdDpob2dl
パスワード生成のWebサービス等もありますが、漏洩リスクとなるためあまりお勧めできません。
CloudFront Functionsは、AWS CloudFrontサービスの「Functions」ないし「関数」です。
JavaScriptコードを実行することができるので、ここでBasic認証の処理を行います。
「関数」->「関数を作成」から作成し、コードを貼り付けます。
function handler(event) {
var request = event.request;
var authResponse = basicAuth(request);
if (authResponse) {
return authResponse;
}
return rewriteIndexHtml(request);
}
function basicAuth(request) {
var expected = 'Basic dGVzdDpob2dl'; // 上で生成したダミー値
var headers = request.headers;
if (headers.authorization && headers.authorization.value === expected) {
return null;
}
return {
statusCode: 401,
statusDescription: 'Unauthorized',
headers: {
'www-authenticate': { value: 'Basic' },
'cache-control': { value: 'no-store' }
},
body: 'Unauthorized'
};
}
function rewriteIndexHtml(request) {
var uri = request.uri;
if (uri.endsWith('/')) {
request.uri = uri + 'index.html';
} else if (!uri.includes('.')) {
request.uri = uri + '/index.html';
}
return request;
}
Jekyllの構成では、リクエストURIを index.html に書き換える必要があるため、rewriteIndexHtml部分で一手間かけています。
あとは「発行」メニューから、ディストリビューションのビューワーリクエストと関連づければ完了です。
ブラウザでアクセスし、Basic認証が表示されればOKです。
念の為トップ以外のページが問題なく開けるかもよく確認しておきましょう。