Verified
Status Update
Comments
ho...@gmail.com <ho...@gmail.com> #2
Long overdue functionality that would help Android catch up.
mi...@google.com <mi...@google.com> #3
LONG LONG LONG overdue.
va...@gmail.com <va...@gmail.com> #4
Can't wait, please support this function..
mi...@google.com <mi...@google.com> #5
This is really needed! Please add this soon!
ho...@gmail.com <ho...@gmail.com> #6
I would like it too.
mi...@google.com <mi...@google.com> #7
ID3v2.2 uses the ULT tag, while ID3v2.3 uses the USLT ID3 tag to store lyrics embedded in an MP3.
Hopefully Android will implement a robust system can display lyrics from either ID3 version.
Hopefully Android will implement a robust system can display lyrics from either ID3 version.
ho...@gmail.com <ho...@gmail.com> #8
this must be done asap.
mi...@google.com <mi...@google.com> #9
Has anyone successfully ported Jaudiotagger to Android? That would be one solution.
wo...@google.com <wo...@google.com> #10
#8 Jaudiotagger works in Android 'out of the box'.
I added lyrics support for Apollo, CyanogenMod's default audio player using that library, and works fine:http://review.cyanogenmod.com/#/c/20056/
Anyway, it would be better and easier if Android provided access to 'lyrics' in the MediaProvider.
I added lyrics support for Apollo, CyanogenMod's default audio player using that library, and works fine:
Anyway, it would be better and easier if Android provided access to 'lyrics' in the MediaProvider.
wo...@google.com <wo...@google.com> #11
@rafagames92
I saw the linked page is for ICS branch. You imported Jaudiotagger without any problems? Perhaps the problems I had were related to Froyo, which doesn't have as complete of a Java system as the newer ICS?
I saw the linked page is for ICS branch. You imported Jaudiotagger without any problems? Perhaps the problems I had were related to Froyo, which doesn't have as complete of a Java system as the newer ICS?
dc...@gmail.com <dc...@gmail.com> #12
Yes. Please add this soon!
wo...@google.com <wo...@google.com> #13
I would like it too.
dc...@gmail.com <dc...@gmail.com> #14
i'm really looking forward for this feature! it's a little shame if android phones cannot display embedded lyrics, especially the high-end ones when they are compared to other brands :)
wo...@google.com <wo...@google.com> #15
I'm really lookng ford to see this feature on android phones! Without this function android will have hard to call better than I.os media play features.
ku...@gmail.com <ku...@gmail.com> #16
Please add this soon
ta...@kk-grp.jp <ta...@kk-grp.jp> #17
This would be a great idea , it would just make android better .
mi...@google.com <mi...@google.com> #18
I I want this,please add
Description
Hello,
This is an update about the upcoming changes to the Address Types and Address Component Types for addresses in Japan. These changes may challenge your current handling of addresses in Japan.
The changes will affect all places and geocoding results in Japan. Such results are returned by Place Autocomplete, Place Search, Place Details, Geocoding API, and their respective JavaScript® services.
If you are using the affected APIs, we highly recommend that you review these changes, to prepare your applications accordingly when appropriate.
Watch point:
- If you are simply using Geocoding or Places API without relying on specific "address_component" types, there is no impact. (e.g. use of "formatted_address")
- If you rely on specific "address_component" types in Japan, you may be impacted. Implementations should be updated to accommodate the new "address_component" types as explained in detail below. Note: we recommend not ‘hardcoding’ to specific type values.
The new political model will launch on January 29, 2018 in PST (January 30, 2018 in JST)
We will be posting regular updates here as the change takes place.
You can star this issue to get updates delivered by email directly to you.
Changes on the result and address component types:
Google Maps basemap data (roads, addresses, postal, and political entities) will move to a different political model. This move changes the types for most places and address components.
In the current political model:
- Prefectures (including Tokyo) have type 'administrative_area_level_1'
- Gun districts have type 'colloquial_area' (on top of 'locality')
- Shichouson have type 'locality' (no additional types)
- Special wards of Tokyo has type 'locality' (no additional types)
- Wards in all other cities have type 'ward' (on top of 'locality')
- Ooaza and Chou have type 'sublocality_level_1'
- Koaza and Chome have type 'sublocality_level_2'
- Gaiku have type 'sublocality_level_3'
- Chiban and Jukyobango have type 'sublocality_level_4'
- Edaban have type 'sublocality_level_5'
- Buildings have type 'premise'
In the upcoming political model:
- Prefectures (including Tokyo) have type 'administrative_area_level_1'
- Gun districts have type 'administrative_area_level_2'
- Shichouson have type 'locality' (no additional types)
- Special wards of Tokyo has type ‘locality’
- Wards in the other cities have type 'sublocality_level_1'
- Ooaza and Chou have type 'sublocality_level_2'
- Koaza and Chome have type 'sublocality_level_3'
- Gaiku have type 'sublocality_level_4' as both result type and address component type
- Chiban / Jukyobango and Edaban have type 'street_address' as result type ─ 'premise' as address component type
- Buildings have type 'premise'
Edaban and Chiban / Jukyobango address components will be merged into a single 'premise' component. Gaiku address components will not be merged in the same way.
For the purpose of illustration, here is an example of how the following specific place will change:
Place ID: ChIJyUeXNQMdAWARtoSWEBBJ-tk
Formatted address: 日本、〒569-0034 大阪府高槻市大塚町2丁目15−1−2 庭園工務結樹
Place types with the current political model: premise
Address components with the current political model:
- premise: 庭園工務結樹
- sublocality_level_5: 2
- sublocality_level_4: 1
- sublocality_level_3: 15
- sublocality_level_2: 2丁目 / 2 Chome
- sublocality_level_1: 大塚町 / Ōtsukachō
- locality: 高槻市 / Takatsuki-shi
Place types with the upcoming political model: premise
Address components with the upcoming political model:
- premise: 庭園工務結樹
- premise: 1−2
- sublocality_level_4: 15
- sublocality_level_3: 2丁目 / 2 Chome
- sublocality_level_2: 大塚町 / Ōtsukachō
- locality: 高槻市 / Takatsuki-shi
各位
これは、日本の住所の住所タイプと住所コンポーネントタイプに対して入る変更のアップデートです。この変更により、日本の住所の扱い方を変える必要がある場合があります。
この変更により、日本のすべてのプレイスとジオコーディングの結果が影響を受けます。ここでの “結果” とは、プレイス オートコンプリート、プレイス検索、プレイス詳細、Geocoding API および、それらの JavaScript® サービスを使って得られる結果のことを指します。
もし影響を受ける可能性のある API を使っているのであれば、変更内容をよく確認していただき、必要に応じてアプリケーションの改修を行うことを強く推奨します。
確認すべき点:
- 特定の “address_component” タイプに依存しないシンプルな方法で Geocoding API や Places API を使っている場合は、今回の変更による影響は受けません(例えば、”formatted_address” の情報のみを利用している。)
- 日本の住所の ”address_component” タイプを利用、フィルタしている場合は、影響を受ける可能性が高いです。下記で詳細を説明しているように、新しい “address_component” タイプに対応できるようにアプリケーションの実装を変える必要があります。なお、Google はソースコード内で特定のタイプをハードコードする方法を推奨していません。
新しい住所タイプと住所コンポーネントタイプへの変更は 2018 年 1 月 29 日 (太平洋時間)/ 1月30日(日本時間)を予定しています。
進行状況については、定期的に Issue Tracker にアップデートを投稿します。
この Issue に対してスターをつけることで、アップデートを直接メールで受信することができます。
住所タイプと住所コンポーネントタイプの変更:
Google Maps ベースマップデータ(道路、住所、そして行政上のエンティティ)は、新しい行政区画モデルに移行します。この移行により、ほとんどのプレイスと住所コンポーネントのタイプが変更されることになります。
従来の行政区画モデル:
- 都道府県(東京都を含む)は administrative_area_level_1 タイプを持つ
- 郡は locality タイプと colloquial_area タイプの両方を持つ
- 市町村は locality タイプを持つ(他のタイプは持たない)
- 東京の特別区は locality タイプを持つ(他のタイプは持たない)
- 他の全ての都市の行政区は locality タイプと ward タイプの両方を持つ
- 大字と町は sublocality_level_1 タイプを持つ
- 小字と丁目は sublocality_level_2 タイプを持つ
- 街区は sublocality_level_3 タイプを持つ
- 地番と住居番号は sublocality_level_4 タイプを持つ
- 枝番は sublocality_level_5 タイプを持つ
- 建物は premise タイプを持つ
新しい行政区画モデル:
- 都道府県(東京都を含む)は administrative_area_level_1 タイプを持つ
- 郡は administrative_area_level_2 タイプを持つ
- 市町村は locality タイプを持つ(他のタイプは持たない)
- 東京の特別区は locality タイプを持つ
- 他の都市の行政区は sublocality_level_1 タイプを持つ
- 大字と町は sublocality_level_2 タイプを持つ
- 小字と丁目は sublocality_level_3 タイプを持つ
- 街区は結果のタイプおよび住所コンポーネントタイプとして sublocality_level_4 を持つ
- 地番 / 住居番号そして枝番は結果のタイプとして street_address を持ち、住所コンポーネントのタイプとして premise タイプを持つ
- 建物は premise タイプを持つ
枝番と地番 / 住居番号の住所コンポーネントは一つの premise コンポーネントに統合されます。街区の住所コンポーネントは premise コンポーネントに統合されません。
説明のために、次のプレイスに対して従来の行政区画モデルと新しい行政区画モデルが返す結果の例を示します:
プレイス ID: ChIJyUeXNQMdAWARtoSWEBBJ-tk
フォーマットされた住所:日本、〒569-0034 大阪府高槻市大塚町2丁目15−1−2 庭園工務結樹
従来の行政区画モデルが返す結果のタイプ :premise
従来の行政区画モデルが返す住所コンポーネント:
- premise: 庭園工務結樹
- sublocality_level_5: 2
- sublocality_level_4: 1
- sublocality_level_3: 15
- sublocality_level_2: 2丁目 / 2 Chome
- sublocality_level_1: 大塚町 / Ōtsukachō
- locality: 高槻市 / Takatsuki-shi
新しい行政区画モデルが返す結果のタイプ:premise
新しい行政区画モデルが返す住所コンポーネント:
- premise: 庭園工務結樹
- premise: 1−2
- sublocality_level_4: 15
- sublocality_level_3: 2丁目 / 2 Chome
- sublocality_level_2: 大塚町 / Ōtsukachō
- locality: 高槻市 / Takatsuki-shi