Aug 24, 2016: libphonenumber-7.6.0
Code changes:
Refactored metadata loading and closed all streams after loading.
Made isNumberGeographical public, and changed the geocoder to use this when checking whether to give a detailed answer or country-level only.
Build changes:
Use protobuf-javanano 3.0.0-alpha-7 from Maven Central.
Metadata changes:
Updated phone metadata for region code(s): EH, ET, JM, MA, SK, SN, SY, ZM
Updated short number metadata for region code(s): ZA
Updated geocoding data for country calling code(s): 212 (en)
New carrier data for country calling code(s): 86 (zh, zh_Hant), 852 (zh, zh_Hant), 963 (en)
Updated carrier data for country calling code(s): 86 (en), 212 (en), 251 (en), 421 (en)
Deleted unsupported SingleFilePhoneNumberMetadataProto
Making function IsNumberGeographical public. This function operates on
the type of number and the country it belongs to only, so may have some
false positives.
Using this in the geocoder so that geocoding now limited to numbers that
we consider geographical, based on their type and country, rather than
just based on their type. The C++ geocoder did not previously check the
number type/country at all.
Indonesian and Chinese mobile numbers have now been added to the list of
possibly-geographical numbers.
A future change to RE2 will replace the VariadicFunction2 objects with variadic
templates, which would break the code in libphonenumber as it currently stands.
* New useful getExampleNumber methods (for testing) - one for invalid
numbers and one for getting a number of a particular type without
specifying a country.
The preprocessor expression defined(COMPILER_GCC) is used in code copied
from the Chromium project, but COMPILER_GCC is not defined by GCC itself,
but by the following expression in Chromium's build_config.h:
#if defined(__GNUC__)
#define COMPILER_GCC 1
#elif // ...
It must therefore be changed when copying the code out of the Chromium
code base.
Includes corresponding changes for C++ and JavaScript as well to keep the implementations in sync. (C++ and JS didn't exhibit buggy behavior because the corresponding substring methods don't throw errors for invalid start positions.)
Bugfix for https://github.com/googlei18n/libphonenumber/issues/592