Age | Commit message (Collapse) | Author |
|
* changes:
Translation tweaks.
Migrated context menu to be a PopupMenu instead.
Add column for call mapping id to AnnotatedCallLog database.
Don't force open keyboard when RTT is active.
|
|
This will ensure call mapping used by RTT etc. won't break when migrating to
new way to generate the call mapping id since they are stored in the database
already.
Bug: 77717594
Test: unit tests
PiperOrigin-RevId: 195132562
Change-Id: Ieb52489b19b37ac2701967eb570a96457ceed4c0
|
|
They are not constant across different Duo implementations.
TEST=TAP
Bug: 76430187,78783816
Test: TAP
PiperOrigin-RevId: 195001650
Change-Id: I4356d04c9eeac50fefd41e1142f3123591e93bc0
|
|
Use ShortNumberInfo to identify shortcodes and apply more basic matching for them; without this short codes like '5555' and '55555' would match due to being a SHORT_NSN_MATCH even though they should not match.
Also removed the PhoneNumberUtil argument from DialerPhoneNumberUtil's constructor as it was always PhoneNumberUtil.getInstance(). (This allowed me to do a similar thing for ShortNumberInfo.getInstance()).
TEST=unit
Bug: 71586485
Test: unit
PiperOrigin-RevId: 193288929
Change-Id: Ia16c78e7eee5e0912d3913660952b9ee32713731
|
|
call log.
Bug: 77808449
Test: NewCallLogViewHolderTest + existing tests for the call log framework
PiperOrigin-RevId: 193086917
Change-Id: I39244c69acf1d261699610f6010c0cf147ca3492
|
|
Bug: 77496097
Test: SystemCallLogDataSourceTest
PiperOrigin-RevId: 191845115
Change-Id: Id0d3770e0cd21383cf2f4c5ae5314ca4de258edd
|
|
We want to be more consistent with other usages of NEW in the app, i.e. NEW should be used primarily by notifications.
Bug: 74821515
Test: unit
PiperOrigin-RevId: 191139559
Change-Id: Ib6fbead8b5589aedd881db26a07f7daed4d83543
|
|
This makes the old peer read the CallLogConfig#isNewCallLogFragmentEnabled and show the old or new fragment accordingly.
If the user is viewing the NewCallLog and the CallLogConfig needs to disable the framework, the new fragment is immediately replaced with the old one. This is necessary because if the user were to scroll the fragment, the AnnotatedCallLog and PhoneLookupHistory databases would be read, which would trigger creation.
I don't expect this to be a common case because 1) we hopefully never have to disable the framework and 2) Framework is only updated on Phenotype broadcasts and JobScheduler jobs, which hopefully don't typically happen when user is viewing the call log. However, I still want to make sure that if it happens we don't irreversibly break users when we turn the framework back on.
I tested this by flipping flags and observing underlying data being removed:
> dialer-cmd configprovider set new_voicemail_fragment_enabled false
> adb shell ls /data/data/com.google.android.dialer/databases/ && echo && adb shell cat /data/user_de/0/com.google.android.dialer/shared_prefs/com.google.android.dialer_preferences.xml
I test flipping flags back and forth on the call log tab, speed dial tab, and while the activity was paused (pressing Home after viewing call log).
Note that this CL doesn't address showing missed calls and badge counts correctly with the new fragment; that will come in a later CL.
Bug: 74821995
Test: unit and manual
PiperOrigin-RevId: 190706481
Change-Id: I618d9c1649169abd65733502cfebc662a835e787
|
|
Bug: 72125574
Test: None.
PiperOrigin-RevId: 190572832
Change-Id: I581d3c9e366a1190c1608b369700aeb511fe51d1
|
|
Manually set to M
- MissedCallNotifierTest (not sure what the issue is here...)
- CallLogGroupBuilderTest (because a check was removed, some NPEs are thrown)
- MainSearchControllerTest (/system/etc/fonts.xml (No such file or directory))
Ignore Tests
- a few random ones in incallui/answer/impl/hint (shared prefs aren't working for some reason)
- VisualVoicemailUpdateTaskTest (disabled the whole test, issue unclear)
Bug: 73902692
Test: tap
PiperOrigin-RevId: 190030202
Change-Id: I1e9b61d758a61582c5a183ee884dd2181d1c10de
|
|
Impls can access appContext via dagger.
Test: existing
PiperOrigin-RevId: 189974157
Change-Id: Ie64d2c6f9ba08fc914d3c31f7e014c2beef3ab00
|
|
This is necessary to disable the call log framework via flags.
This isn't yet called anywhere.
Bug: 74821995
Test: unit
PiperOrigin-RevId: 189838957
Change-Id: I926c02c41151528eabc208c874acbfe7897a2f93
|
|
This is needed to support flag changes which should cause the call log framework to become disabled.
It's not called anywhere yet.
Bug: 74821995
Test: unit
PiperOrigin-RevId: 189761665
Change-Id: I914c690448f03ebacd7d05c9ad082aba7bf1a4ce
|
|
This data source determines if the call is to the voicemail inbox.
isVoicemail() is removed from NumberAttributes and PhoneLookup. It is yet decided how in call UI should handle voicemail calls in the future.
TAG_CHANGE_OK=proto not in prod yet. Please clear app data.
TYPE_CHANGE_OK=above
Bug: 70989587
Test: Unit tests
PiperOrigin-RevId: 189650273
Change-Id: Iafebf1abb18c74301b62a72d1d04deecd6d78d29
|
|
metrics.
This required creating "CallLogState" which is currently just a boolean value which can only be turned on once (when the annotated call log flow finishes for the first time).
This CL also changes CompositePhoneLookup to no longer implement PhoneLookup. This was done to support a now reverted implementation of CallLogState but it's easier for me to keep the change and it shouldn't be harmful.
Bug: 70989667
Test: unit
PiperOrigin-RevId: 186852257
Change-Id: I3f342737aaf909f8230b8a69d9c21e6e5c19b84e
|
|
Bug: 73347270
Test: Existing tests
PiperOrigin-RevId: 186475562
Change-Id: I622b52f4d74b26fd084b6588da6321c46458aa9d
|
|
Bug: 73347270
Test: Existing tests + RefreshAnnotatedCallLogNotifierTest
PiperOrigin-RevId: 186347066
Change-Id: I5a530416bdaa9edc7131a0d5ced44f1b5ee1692b
|
|
Bug: 73007132
Test: NumberAttributesConverterTest, PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 185545712
Change-Id: I228d8c4e1b6327e38057f73aad63bb7048704d49
|
|
Bug: 73077158
Test: CallLogEntryTextTest, GlidePhotoManagerImplTest, PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 185017362
Change-Id: I113472482da2213d17a847054272a22249edc578
|
|
Transcription state column is needed for voicemail transcriptions. This CL adds the support for it in the NUI so that it maybe used by the VM Tab.
Bug: 72491920
Test: Unit Tests
PiperOrigin-RevId: 184335015
Change-Id: I14a71890224216c957e0d6146af9dafaa1550865
|
|
These are frequently used attributes of numbers that we can compute once at parse-time.
Also did some general cleanup of DialerPhoneNumberUtil:
-Removed unused Future version of parse()
-Remove formatToValidE164 now that the new fields are available
-Inlined normalizeNumber()
Bug: 72563861
Test: existing
PiperOrigin-RevId: 183720128
Change-Id: I702dc265360e590439c5352c493ae8a858f36812
|
|
Updated the new call log UI to properly show text based on the presentation.
Bug: 70989592
Test: unit
PiperOrigin-RevId: 183414195
Change-Id: I2123f37cd3c733060125b6e894c1a80be4193ad6
|
|
Methods moved to TelecomUtils
Test: Unit tests
PiperOrigin-RevId: 183305626
Change-Id: Idd6604e58c06a36066bd49870849dd71747969c6
|
|
CallLogPhoto.getPhotoUri() returns a URI to a drawable so it will be easier to transition into glide. Meanwhile ContactPhotoManager will just show the drawable directly.
Bug: 70989547
Test: Unit tests
PiperOrigin-RevId: 183163818
Change-Id: I4ee4ff98782e35d2be03dfe14f8bf3dfd6ded074
|
|
We currently limit the size of AnnotatedCallLog to 999 via a trigger, but it doesn't exclude voicemails. Since we don't want to ever garbage collect the user's voicemails, exclude them from the trigger.
This means that we can no longer assume a maximum size for the table (the user culd have more than 999 voicemails) so I've updated the places in the code where we did that before.
Finally, I changed AnnotatedCallLog's CALL_TYPE column to be non-null. This is so that we can have more confidence that the trigger will work as intended. Null values cannot be compared in SQLite, so an expression like "where call_type != 4" won't actually match a null call type. Rather than implicitly fail to clean up such rows, we just crash completely when encountering such rows (even though I don't expect that to happen).
Bug: 70989634
Test: unit
PiperOrigin-RevId: 183006714
Change-Id: I9f4394a4812afe4b65c1e8427c355d825356557c
|
|
-Don't ever coalesce rows with different post-dial digits
-Made matching of unparsable numbers a little more intelligent by comparing national/postdial portions which have undialable characters removed (rather than exact string match)
-Read and append the post-dial digits from the system call log when building DialerPhoneNumbers to place in the AnnotatedCallLog. Note: PhoneNumberUtil will parse numbers with exactly one post-dial character, but not more than one.
-Use post-dial digits when building the AnnotatedCallLog's FORMATTED_NUMBER value
-Display the formatted number in CallDetails when the name is missing, instead of the unformatted number
-Don't set the displayNumber in CallDetails when the name is missing, because we are showing the (formatted) number via the nameOrNumber field.
-Treat numbers with post-dial digits as invalid in PartitionedNumbers; batch operations are not possible with these numbers because their normalized representations strip the post-dial digits (and they are significant for contact matching)
Bug: 70989632
Test: unit and manual
PiperOrigin-RevId: 182557754
Change-Id: Idcdefce0946a189e5b350a53ec2a16a96a8d4552
|
|
This is an optimization to reduce popping in the new call log. Currently when Cp2LocalPhoneLookup determines a number to be "incomplete" (because it is an invalid number and there are too many invalid numbers in the call log to efficiently bulk update) we clear the existing data, which has been populated in PhoneLookupHistory (for example, from InCallUi). This means that we will show the number initially when displaying the call log, and then when the query completes we will "pop in" the new information.
This change makes it so that we don't clear the existing data from PhoneLookupHistory, and just add the "incomplete" bit. The result of this is that we immediately display the available information when initially displaying the call log (even though it may be out of date). When the query completes, the row will be updated with the most recent information; in most cases this is likely to be the same as the information used to initially display the row, and no update will need to be applied.
Additoinal changes to support this functionality:
-RealtimeRowProcessor is now just responsible for returning an updated row, and NewCallLogView holder will compare the result to the originally displayed row and only update the UI if there are differences.
-NewCallLogFragment now calls clears the RealtimeRowProcessor's cache and notifies data set changed during onResume. This is to account for the fact that AnnotatedCallLog no longer contains the complete set of information necessary to show the call log; there may be changes we need to show which can't be detected by the cursor loader. We now show those potential changes in onResume.
Additional notes:
-If there is real-time data that changes after onResume it won't be detected but there shouldn't be such cases; changes made to contact information from dialer are always done through contact cards which pause the fragment.
-This change has the effect that whatever information was written to PhoneLookupHistory during the previous invocation of InCallUi will always be (initially) shown. For example, if the contact name for number "123" is "Joe" when the call comes in, we'll write "Joe" to PhoneLookupHistory. If the user changes Joe's name to "Jane", the UI will pop from "Joe" to "Jane" until PhoneLookupHistory is updated (which is currently only done from InCallUi). If this turns out to be a problem it could be mitigated by writing updated results to PhoneLookupHistory from the UI.
Test: unit, manual
PiperOrigin-RevId: 182277145
Change-Id: I3d9916b7747390ff956f399fe84b26d578e5a07f
|
|
PhoneLookupInfoConsolidator is designed for the following two purposes.
(1) Different sub-messages in a PhoneLookupInfo proto can contain information for the same purpose. For example, all of cp2_local_info, cp2_remote_info, and people_api_info have the information for a contact's name. PhoneLookupInfoConsolidator defines the rules that determine which sub-message should be used to display the name in the UI. This is the same as PhoneLookupSelector.
(2) Avoid mixing info from different sub-messages when we are supposed to stick with only one sub-message. For example, if a PhoneLookupInfo proto has both cp2_local_info and cp2_remote_info but only cp2_remote_info has a photo URI, PhoneLookupInfoConsolidator should return an *empty* photo URI as cp2_local_info has higher priority and we should not use cp2_remote_info's photo URI to display the contact's photo. This is what PhoneLookupSelector is unable to do.
Bug: 71763594
Test: PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 182236013
Change-Id: If19cdc1a9e076f3ebc8f9e2901f050b519e273f2
|
|
Voicemails that are deleted or marked as deleted should not show up in the annotated call log.
Bug: 71885122
Test: N/A
PiperOrigin-RevId: 181719056
Change-Id: I7a5f7769ecbfc5feaaee36f0f1de48155576f458
|
|
This allow extra information from PhoneLookup to be more easily added. Only PhoneLookupSelector and the proto will be affected for new attributes.
Test: Unit tests.
PiperOrigin-RevId: 181675568
Change-Id: I4e0bc1c6005b58a9b684b030b55bea6223af9ce3
|
|
Empty numbers were not being inserted into PhoneLookupHistory because the URI "content://.../PhoneLookupHistory/" is treated the same as "content://.../PhoneLookupHistory" (w/o the trailing slash). This caused the update (i.e. replace) operation to incorrectly update all rows in the table when it should have updated a single row.
The fix for this was to switch to a query parameter, so the empty number URI now looks like "content://.../PhoneLookupHistory?number="
Also improved some logging while debugging this problem.
Bug: 71866050
Test: unit and manual
PiperOrigin-RevId: 181659081
Change-Id: Idec4fb77e74920cd5485620b0a997db03aa8ff9b
|
|
-Reuse the adapter in NewCallLogFragment to maintain position in call log when returning from call details
-Convert empty values to null when invoking ContactPhotoManager to make photos appear correctly in new call log bottom sheets
-Added CallLogContactTypes to be shared between proper call log and bottom sheets
-Fixed vertical alignment in bottom sheet when there was no secondary text
-Added some verbose logging
Test: unit and manual
PiperOrigin-RevId: 181655715
Change-Id: I9c1a42ad8d529ee2327e15fcc1d32b7b83982014
|
|
Test: Unit tests.
PiperOrigin-RevId: 181512134
Change-Id: If64b4cd184c60a807541cfe8727aa03532a80cb4
|
|
PhoneLookupInfo.cp2_local_info.
To support remote CP2 contacts, there will be a new PhoneLookup ("Cp2RemotePhoneLookup") and a new field in proto PhoneLookupInfo ("cp2_remote_info").
In proto PhoneLookupInfo, cp2_local_info and cp2_remote_info will be of the same type ("Cp2Info").
Bug: 71763594
Test: Existing tests
PiperOrigin-RevId: 181405798
Change-Id: I6c43b486229d4e9ae7b55c579d9c9997a2884c80
|
|
This is for performing work inside of the call log's RecyclerView, when the view holder is bound. Most of the time, this should be a no-op but there are possible edge cases where the call log data cannot be updated efficiently through the standard batch mechanism.
One example of this is when there are too many invalid numbers in the call log; the CP2 information for invalid numbers cannot be efficiently batch updated so we fetch this information at display time. (Note that we do handle up to 5 invalid numbers in the batch update mechanism, but if there are more than that we fallback to this realtime processing.)
Test: unit, manual
PiperOrigin-RevId: 181400016
Change-Id: Iea6b380742e757b48d19f319fe46dc5fae837604
|
|
This CL implements looking up the dialer internal database for blocked numbers when the system database is not available yet.
Data is only invalidated when dialer is alive since that is the only time blocked numbers can be set and removed.
Bug: 70989538,70989547
Test: DialerBlockedNumberPhoneLookupTest
PiperOrigin-RevId: 180956355
Change-Id: Ie7acf091bf58a074d0a1ee39613fad035d2e6e60
|
|
This column is filled by PhoneLookupDataSource using PhoneLookupInfo#PeopleApiInfo.
Bug: 70218437
Test: AnnotatedCallLogDatabaseHelperTest, PhoneLookupDataSourceTest, RowCombinerTest, CoalescedAnnotatedCallLogCursorLoaderTest, PhoneLookupSelectorTest
PiperOrigin-RevId: 180839783
Change-Id: I8d5ddb940670724fd4bf6dd6a50dcf408f91da9d
|
|
Bug: 70506228
Test: new unit tests
PiperOrigin-RevId: 180610636
Change-Id: I7f498df1a529737bf8473584836bdc3e04a5043c
|
|
This allows indvidual PhoneLookups to define and deal mostly with their own submessage type (with the exception of trivial setter and getter methods for converting from/to PhoneLookupInfo).
This also simplifies the FakePhoneLookup and tests which use it a bit, I think.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 179976215
Change-Id: I2db1fc85771621be2f2afcd6af114d82680e30d0
|
|
If there is a new call with a number that hasn't been seen before, it should be considered the same as numbers that are already part of the call log.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 179628789
Change-Id: I422c24c444958dd8842aa14cf8a8069da5cec2c1
|
|
When a new voicemail is received, it is written in the voicemail table by the Voicemail service. However the new voicemail will not get updated/shown in the New Voicemail UI as the annotated call log would be stale. This CL ensures that when the voicemail is added, the annotated call log is marked dirty and refreshed. This way the new voicemail will be shown in the new voicemail UI. Since a new voicemail is also added, we want to make sure the headers for "today" and "older", their positions are also updated accordingly.
Bug: 64882313
Test: Unit tests
PiperOrigin-RevId: 179623267
Change-Id: I5dfc84f62f9f37c57ffb2dbbe7e848a58306a19d
|
|
Bug: 34672501
Test: unit
PiperOrigin-RevId: 179012381
Change-Id: Icb78c73e243702a71f1a48692151b696ae2ac95f
|
|
We're not going to use the "cached" columns from the system call log any longer, and instead will write them using PhoneLookup.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 178788155
Change-Id: I9255dd3cb727eef3b45bc05aeb3c6fd6fd513d63
|
|
Required adding applyBatch functionality to PhoneLookupHistoryContentProvider so that the updates can be performed in a transaction. This code was just copied and modified from AnnotatedCallLogContentProvider.
Also removed the trigger which limited the size of the PhoneLookupHistory, since we now delete rows from PhoneLookupHistory when the last occurrence of a number is deleted from AnnotatedCallLog. Since AnnotatedCallLog is bounded to 1000 rows PhoneLookupHistory is now indirectly bounded by that as well.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 178323464
Change-Id: I233163fe70641b0e4b1d4c5c0e8970ad0b4b167d
|
|
We were previously calling get() which can cause deadlocks.
Bug: 34672501
Test: existing
PiperOrigin-RevId: 178192772
Change-Id: Id9088b12b765307c778d101d847cb1016ea828d1
|
|
This is just to more clearly convey what the method does.
Bug: 34672501
Test: existing
PiperOrigin-RevId: 178188575
Change-Id: Id02f34b1d79346ecd8ca9eebc043fe9b3063264b
|
|
Use them where appropriate.
Bug: 34672501
Test: existing
PiperOrigin-RevId: 178182298
Change-Id: If454225e0d636c7cb14b5af02d46780d7732abf0
|
|
Bug: 34672501
Test: existing
PiperOrigin-RevId: 178038086
Change-Id: I1230992ad04bb4415f5a29bd15802d23dff88012
|
|
Data in this column are copied from the DATA_USAGE column in the system call log (android.provider.CallLog.Calls#DATA_USAGE).
Bug: 70218437
Test: AnnotatedCallLogDatabaseHelperTest, SystemCallLogDataSourceTest
PiperOrigin-RevId: 177999609
Change-Id: I64d70734e8e85767f1e93a4a22ce2aae6c2168a1
|
|
This class is responsible for prioritizing and selecting data from a PhoneLookupInfo object, which contains information from many phone lookup sources.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 177893924
Change-Id: Ib98a4656fe87141162a7ac53af4a0ad421196046
|
|
Also added onSuccessfulBulkUpdate method.
It is safer for each PhoneLookup to keep track of its own last processed time via shared prefs where the value saved is the actual last processed timestamp from the underlying data. This is because it is difficult or impossible to select a single time that spans lookups due to queries being run and processed at different times.
The onSuccessfulBulkUpdate method is provided as a hook for PhoneLookups to persist their shared pref once they know the result of bulkUpdate have been successfully saved.
Finally, removed usage of the lastModified timestamp from PhoneLookupHistory in PhoneLookupDataSource since I believe the cases it was originally intended to cover are now handled by populateInserts().
Bug: 34672501
Test: unit
PiperOrigin-RevId: 177891586
Change-Id: I072409fc217e4d7e36816548862e8b358aebf165
|
|
Rewrote FakePhoneLookup to be more realistic.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 177376374
Change-Id: Ifcd52b16b7046f39d1bfc0e8b8e76452a9daadd2
|
|
Also extracted FakePhoneLookup to a testing package.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 175923790
Change-Id: I866708a676e788051b369a024344967975c05979
|
|
We need to be able to write the shared prefs when the device is in direct boot mode, and this data is not sensitive so can be unencrypted.
Bug: 68350256
Test: existing unit, manual
PiperOrigin-RevId: 174075154
Change-Id: Ib52e11c6abba0812d1dc07c642691359089c3e6e
|
|
VoicemailUri is required to play voicemail audio files. We need it to be able to play the voicemails in the voicemail tab. A follow up CL will be using the uri to play the audio, but via a media player.
Bug: 64882313
Test: Unit tests
PiperOrigin-RevId: 173422683
Change-Id: Ib438e3020c83e11a2c54c3e941c93e83dba9bc90
|
|
It fixes AOSP for package name conflict.
Test: manual
PiperOrigin-RevId: 173298696
Change-Id: Id10ebe0bcf029e61f65cf6580c7198abd8395081
|
|
Currently the SystemCallLogDataSource queries the call log table with CONTENT_URI. This works for the call log tab, but will not work for the voicemail tab. To allow the voicemail tab to query annotated call log for voicemail information, we need to surface up voicemail data from the system call log data source into the annotated call log.
Bug: 64882313,33006245
Test: Unit tests, also verified that in the call log only the non-voicemail entries show
PiperOrigin-RevId: 172036196
Change-Id: Ieac855ae854a043207c9ae668280391c790ac33d
|
|
Also added ability to click on row to call.
Required plumbing through the original phone number and phone account info through AnnotatedCallLog and CoalescedAnnotatedCallLog, so that clicking to dial doesn't require an additional lookup.
Required some refactoring:
-created autovalue for CoalescedRow.
-created autovalue for ContactPrimaryActionInfo and use it in ContactActionBottomSheet
-moved logic for building primary and secondary text into CallLogUtils so it can be shared between call log list and bottom sheets
-moved clipboard logic to own package for copying numbers
Bug: 34672501
Test: unit
PiperOrigin-RevId: 171760252
Change-Id: I645d89974460b611c1d9668c3ca3e50a716c7f8f
|
|
last 3.
This is according to the latest PRD:
https://docs.google.com/document/d/1FLoQ6kNYL-QKplbniJAIUCHku87S9eYuYPs6IXe-U78
Also cleaned up warnings in CallLogQueryHandler.
Screenshot: https://screenshot.googleplex.com/Z7p4BRVpLpE
Bug: 34672501
Test: unit
PiperOrigin-RevId: 170941445
Change-Id: Ibf79b70eda3837ea46d365729aaed0a87961e42b
|
|
Previously, Android's Dialer app was developed in an internal Google
source control system and only exported to public during AOSP drops.
The Dialer team is now switching to a public development model similar
to the telephony team.
This CL represents all internal Google changes that were committed to
Dialer between the public O release and today's tip of tree on internal
master. This CL squashes those changes into a single commit.
In subsequent changes, changes will be exported on a per-commit basis.
Test: make, flash install, run
Merged-In: I45270eaa8ce732d71a1bd84b08c7fa0e99af3160
Change-Id: I529aaeb88535b9533c0ae4ef4e6c1222d4e0f1c8
PiperOrigin-RevId: 167068436
|
|
This release was created following the instructions at:
go/dialer-aosp-release
Subsequent dialer releases will follow as O bugs are
fixed, until we reach our final RC.
Version: 10
Candidate: RC32
Branch: dialer-android_release_branch/153304843.1
dialer-android_20170416.00/dialer-android_20170416.00_RC32
This release contains the following bug fixes since RC17:
Bug: 33176679 33272455 3646510 36773894 37297649 37413780
37513689 37640315 37680595 37698062 37873639 37901752
37919295 37953423 38062852 38069600 38137349 38173549
38180252 38191514
Test: make, on device
Change-Id: I4e4bb630082758e418ff24892b7db3142c6eb09a
|
|
RC00 is based on:
branch: dialer-android_release_branch/153304843.1
synced to: 153304843
following the instructions at go/dialer-aosp-release.
In this release:
* Removes final apache sources.
* Uses native lite compilation.
More drops will follow with subsequent release candidates
until we reach our final v10 release, in cadence with our
prebuilt drops.
Test: TreeHugger, on device
Change-Id: Ic9684057230f9b579c777820c746cd21bf45ec0f
|