2019年12月18日水曜日

iOSアプリのアプリ内課金の審査で"デベロッパの対応が必要"と言われる

かなりトラブったのでメモ。

iOSアプリのアプリ内課金を非消耗型からサブスクリプション型に変えた
非消耗型の時には特に苦労した覚えがないのだが、
今回はApp内課金を審査したところ"デベロッパの対応が必要"という形で差し戻された

内容を読むと「君のアプリがちゃんとサブスクリプションに対応できてるか確認するからバイナリをアップロードしてね」というもの。

これが不親切で具体的にどういう手順でバイナリをアップロードすればいいのかが全く書かれていない。そして、App Store Connect内を隅から隅まで探してもそれに対応するようなアップロード場所がない。

調べたところフォーラムで対応策が書かれていた(codeulikeさんの投稿)
https://forums.developer.apple.com/thread/35757

以下日本語版手順
1.App内課金から、差し戻されたサブスクリションを削除して、作り直し。この時「審査へ提出」してはならない。
※製品IDを変えないといけなくなるが、この状態に陥っている場合これは避けられない(個別に問い合わせればなんとかしてくれるかもしれない)

2.新しい製品IDで動作確認。

3.普段通りアプリのリリース作業をする(Xcodeからアップロード->App Store Connectで編集)。この時、App Store Connect上で情報を入力する時にGame Centerの項目の上に「App内課金」という項目が付加されるので、ここで1で作り直したApp内課金を追加する。1で「審査へ提出」してしまった場合はこの項目が表示されないのでもう一度やりなおし。


2019年7月12日金曜日

Gitで SSL certificate problem: Invalid certificate chainと表示されクローンできない

Gitで SSL certificate problem: Invalid certificate chainと表示されクローンできない

こんな時Web上ではSSLの検証をoffにすれば解決するよという情報が目につくが、
自分の場合は端末の時刻が年単位でずれているせいだった。

時刻を直すことで無事cloneできるようになった。

2019年5月6日月曜日

Androidのjava.net.URI.relativizeの挙動がおかしい

URI base = new URI("http://hostname/root");
URI uri  = new URI("http://hostname/root/yyy/zzz.html");
URI rel = base.relativize(uri);

上記コードのrelは
yyy/zzz.html
となるのが正しい挙動(Javaではそうなる)のはずだが、
Android 8ではroot/yyy/zzz.html が返ってくる。

調べてみると、Androidのrerativizeのソースにこの挙動が明記されていた

// Android-changed: The original OpenJdk implementation would append a trailing slash
// to paths like "/a/b" before relativizing them. This would relativize /a/b/c to
// "/c" against "/a/b" the android implementation did not do this. It would assume that
// "b" wasn't a directory and relativize the path to "/b/c". The spec is pretty vague
// about this but this change is being made because we have several tests that expect
// this behaviour.

解決策はない? 自分はhttp://www.devx.com/tips/Tip/13737 を使うことにした

2019年3月24日日曜日

ActionModeの下線の色の変え方(actionModeSplitBackgroundが効かない)

どうやらAppCompatではActionModeでの下線がactionModeSplitBackgroundで変えられないもよう。
対策は、なんてことはない、actionModeBackgroundで下線がつくようにBackgroundを設定するだけ。

@drawable/am_background


    
    
        
            
        
    
    
    
        
            
        
    

2018年8月14日火曜日

Google Driveのバックアップと同期をインストール後、NASにアクセスできなくなった

Google Driveの「バックアップと同期」をインストールしてバックアップするフォルダとしてNAS上のフォルダーを指定して再起動したところ、NASにアクセスできなくなった。

\\192.168.1.x\
ではアクセスできたが、
\\<ネットワークドライブ名>\
ではアクセスできず、以下のエラーメッセージが出た。

「このネットワーク リソースを使用するアクセス許可がない可能性があります。アクセス許可があるかどうかこのサーバーの管理者に問い合わせてください。
同じユーザーによる、サーバーまたは共有リソースへの複数のユーザー名での複数の接続は許可されません。サーバーまたは共有リソースへの以前の接続をすべて切断してから、再試行してください。」

色々試した結果、タスクマネージャーからgoogledrivesync.exeを強制終了したところNASにアクセスできるようになった。
試していないが資格情報を保存してしまえば次回の再起動以降エラーが出なくなるような気がする。

2018年6月20日水曜日

ファイルを共有しようとするとFileUriExposedExceptionが出る場合

Target SDKがN以降の場合、ファイルパスを指定する従来の共有をしようとするとFileUriExposedExceptionが出る

FileProviderを使うのが楽で、以下はFileProviderを使ってACTION_SENDで共有する例

<provider
    android:name="android.support.v4.content.FileProvider"
    android:authorities="${applicationId}.provider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/provider_paths"/>
</provider>
 
<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <external-path name="external_files" path=".">
    <external-files-path name="external_files_path" path=".">
    <root-path name="external_files" path="/storage/">
</root-path></external-files-path></external-path></paths>
File file = new File(filesToSend.get(0));
Uri contentUri = FileProvider.getUriForFile(App.getContext(), App.getContext().getPackageName() + ".provider", file );
String mimeType = "audio/*";
Intent intent = new Intent();
intent.setAction(Intent.ACTION_SEND);
intent.setType( "application/octet-stream");
intent.putExtra(Intent.EXTRA_STREAM, contentUri);
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
App.getContext().startActivity(intent);

2018年6月18日月曜日

adb install で INSTALL_PARSE_FAILED_NO_CERTIFICATESが出る場合の対処法

adb install で INSTALL_PARSE_FAILED_NO_CERTIFICATESが出る場合、
Android StudioでGenerate Signed APKを実行するときに、最後のページのSignature VersionsでV1とV2両方にチェックを入れましょう